Keskus on täynnä ennusteita ja neuvoja siitä, mitä tehdä ensi vuonna - mitä kieliä opiskella, mihin alueisiin keskittyä, mitä tehdä terveytesi kanssa. Kuulostaa inspiroivalta! Mutta jokaisella kolikolla on kaksi puolta, emmekä kompastu vain johonkin uuteen, vaan lähinnä siihen, mitä teemme joka päivä. "Miksi kukaan ei varoittanut minua!" huudamme ärtyneenä, yleensä kääntyen itseemme. Soitetaan tuli itsellemme – olemme koonneet sinulle listan siitä, mitä EI saa tehdä vuonna 2020 (ja ehkä aina).
Mutta he eivät kysyneet painovoimasta
Haluaisimme todella laittaa antisuositukset järjestykseen tärkeimmistä vähiten tärkeisiin. Mutta ne ovat niin yleisiä, vastaavia ja tuttuja melkein kaikille, että kirjoitamme satunnaisesti. No, tarkistetaan lista?
IT:lle ei tarvitse mennä, jos kaikki on hyvin
Älä opi uutta tekniikkaa vaihtaaksesi uraa tai aloittaaksesi alusta. Aikamme on ihanaa, koska voit opiskella, vaihtaa työpaikkaa, muuttaa alaa radikaalisti – ja niin edelleen, jopa eläkkeelle asti. Se on siisti, viettelevä asia. Mutta jos olet yli 28-30, sinun ei pidä luopua kaikesta päästäksesi tietotekniikkaan tai siirtyäksesi uuteen pinoon (esimerkiksi kirjoitat paljon ladattuja järjestelmiä Java-kielellä ja päätät yhtäkkiä mennä neuroverkkoihin Pythonissa). Syy on yksinkertainen: se ei tule olemaan helppoa sinulle. Ensinnäkin asiantuntijat, jotka ovat "istuneet" tällä pinolla uransa alusta lähtien, ovat kovaa kilpailua, toiseksi sinun on tultava jälleen junioriksi pienellä palkalla, ja kolmanneksi sinun on moraalisesti vaikeaa tulee hierarkian alimman tason alainen. Joten jos haluat siirtyä toiseen suuntaan, yritä tehdä se joko nykyisen työsi ja nykyisten tehtäviesi mukaisesti tai kehittää uutta tietoa harrastuksena, aloita lemmikkiprojekti, jotta uuteen työhön tullessasi älä ole enää juniori.
Pinon vaihtaminen pinon jälkeen on vain ajanhukkaa
Älä kiirehdi teknologiapinojen välillä kehitystäsi varten. Jos kirjoitat projektia yhdellä kielellä, käyttämällä tiettyä viitekehystä ja kirjastoja, sinun ei pitäisi heittää kaikkea helvettiin ja kirjoittaa sitä uudelleen Dartissa vain siksi, että se on kiinnostavaa. Tee säännöksi löytää perustelut teknologian muutokselle - ei vain "haluan tai en voi" -tasolla, vaan myös rahoitus- ja suunnittelutasolla.
Sinun ei tarvitse seistä maatasi ja muuttua pronssiksi
Yhteen kieleen tai tekniikkaan kiinni pitäminen ja uusien asioiden oppimatta jättäminen on yhtä äärimmäistä kuin pinon muuttaminen jokaisen uuden tekniikan myötä. Muista opiskella uusia kirjastoja ja kehyksiä, älä ole itsepäinen tietäen, että kaikki on paremmin keksitty ennen sinua ja yksinomaan sinun suorittama. Päivityksiä tulee jatkuvasti lähes kaikille kielille, mikä voi joskus parantaa projektiasi huomattavasti. Älä ole laiska seuraamaan pinosi dynamiikkaa ja heti kun löydät jotain siistiä ja hyödyllistä, vedä se projektiin!
Oma pää on hyvä, aina hyvä
Älä ajattele muiden päässä, omasi on parempi. Valitettavasti jotkut kehittäjät istuvat ja odottavat, kunnes he saavat tehtävän koodata edellisestä virheestä loppuun, yrittämättä antaa jotain omaa projektiin, kehittää uutta toimintoa, testata sitä ja ehdottaa sitä tuotantoon. Miksi vaivautua, kun on tiimin johtaja tai yritysjohtaja, joka päättää kaikesta itse? Jos tunnistat itsesi, meillä on huonoja uutisia: passiivinen asema ei auta uraasi tai kehitystäsi. Sinulla on mahdollisuus kokeilla käsiäsi kehitysinsinöörinä, ei koodaajana, todellisessa taisteluprojektissa ja ymmärtää minne mennä, mikä puuttuu, mutta käytät mieluummin aikasi johonkin muuhun ja teet täsmälleen "tästä eteenpäin" nyt." Sellaiset ihmiset selviävät yhä huonommin nykyaikaisessa IT:ssä, tulevat ulos keskeytetystä animaatiosta.
Käyttäjät ovat kauheita ihmisiä
Älä yliarvioi ohjelmistosi käyttäjiä: jos et kirjoita ohjelmoijille, odota ohjelman kohtaavan käsittämättömän väärinkäsityksen. Ensimmäiset päivät tai viikot käyttäjät vihaavat ohjelmistoasi, koska "vanha ei ollut niin tyhmä". Voit välttää tämän tekemällä hyviä dokumentteja ja opetusohjelmia. Asennettaessa tai ostettaessa, vihjaa erittäin häiritsevästi, että oppaat tulee lukea ennen ohjelman käytön aloittamista, ei tietokannan kaatumisen, salasanan ja itsehallinnan jälkeen.
Käyttäjiä ei myöskään pidä aliarvioida: he ovat ovelampia, älykkäämpiä ja uteliaampia kuin uskotkaan. Jos luulet, että muuttuvan muodon ja 138. Enter-painikkeen sekunnin välein tapahtuvan poikkeuksen sisältävä virhe ei tule esiin, olet erehtynyt - ne ponnahtavat esiin ja vaikuttavat sovelluksesi toimintaan mitä oudimmalla tavalla. Amatöörin sääntö pätee: hän selviää testaamisesta parhaiten. Mutta jostain syystä käyttäjät eivät pidä tuotantovirheiden löytämisestä – niissä ei ole IT-solidaarisuutta. Yleisesti ottaen mitä varmemmin olet ohjelmistossasi, sitä parempi. Loppujen lopuksi on parempi viivyttää joidenkin ominaisuuksien julkaisemista kuin lisätä ne toimivaan sovellukseen ja tehdä siitä yhtäkkiä raaka.
Lopeta googlettaminen!
Älä käänny yksin Googleen. Emme edes kiistele - kehittämisen alalla voit löytää paljon suoralla pyynnöllä hakukoneeseen. Mitä syvemmälle kaivaat tiedon etsimisessä, sitä enemmän “sivusuuntaista” dataa saat ja sitä enemmän opit, sillä opit jotain uutta, joka ei liity pyyntöösi, mutta jota todennäköisesti tarvitaan tulevaisuudessa. Katso täysimittaiset materiaalit, kirjat, artikkelit jne. Kielet ja kirjastot ovat määritelmiä, yhteisöjä, ohjeita, ja näin saat luotettavimman tavan kehittää ohjelmoijataitoja - lue vain dokumentaatio, etkä etsi muiden paikallisia ratkaisuja ja koodinpätkiä. Entä jos ratkaisusi on optimaalisempi, nopeampi ja viileämpi?
Luota, mutta varmista
Älä käytä kolmannen osapuolen kehittäjien luomia kirjastoja ja kehyksiä tarkistamatta koodia ja mukauttamatta sitä tarkoituksiini sopivaksi. Sinulla ei ole mitään syytä luottaa ehdoitta tähän koodin kirjoittajaan, jota et tunne ollenkaan. Kyllä, erilaiset tahalliset haitalliset elementit kolmannen osapuolen koodissa eivät ole niin yleisiä, eikä sinun pitäisi kärsiä vainoharhaisuudesta, mutta ohjelmiston valmiiden osien sokea kopioiminen projektiisi voi johtaa arvaamattomiin seurauksiin. Siksi muista lukea ja analysoida koodi ennen käyttöä ja testata koodin käyttöönoton jälkeen.
Tee varmuuskopiot!
Älä tee varmuuskopioita tai pidä niitä samoilla kolmannen osapuolen palvelimilla, joissa projektisi isännöi. Onko tämä mielestäsi naurettava ja hyödytön neuvo? Mutta yli 700 Telegramin chatin osallistujaa, jotka joutuivat äskettäin epämiellyttävään tilanteeseen yhden tunnetun datakeskuksen sulkemisen vuoksi, eivät uskoneet niin - siellä oli kaikkea: lemmikkiprojekteista suuriin valtion verkkosivustoihin. viranomaiset ja yritysten 1C- ja laskutustietokannat. Merkittävä osa on ilman varmuuskopioita tai varmuuskopioilla samassa paikassa. Joten jaa riskit ja tallenna varmuuskopio ainakin pääpalvelimelle, jollekin luotettavalle VDS:lle ja paikalliselle palvelimellesi. Tulee pitkällä aikavälillä paljon halvemmaksi.
Älä tuo omaasi projektin kustannuksella
Älä tee mitä haluat työprojektissa, vaan tee mitä asiakkaat tarvitsevat. Kyllä, on uskomattoman mielenkiintoista ja hienoa luoda oma hermoverkko, kouluttaa sitä ja toteuttaa se ohjelmistoosi, mutta jos asiakkaasi tarvitsevat yksinkertaisen yhteyshenkilön hallinnan, tämä on ylilyönti. Katso, miten projekti toimii, lue dokumentaatio, lue asiakkaiden arvostelut ja pyynnöt ja toteuta se, mikä tuo projektiin liiketoimintaa lisäarvoa. Jos haluat luoda jotain tieteellistä tai erittäin monimutkaista, aloita omasta projektistasi.
Ei koodi, vaan nippu hermoja
Älä kirjoita lukukelvotonta ja dokumentoimatonta koodia. Tämä temppu on meille tuttu: kehittäjä kirjoittaa koodia mielensä mukaan, tarkoituksella sekoittaen sitä hieman, jotta kukaan hänen kollegoistaan ei ymmärrä hänen kirjoittamiaan - tämä on eräänlainen ennaltaehkäisevä kosto ennen kuin jotain tapahtuu. Olet kuitenkin vaarassa paitsi yrityksen (joka maksaa sinulle rahaa työstäsi), myös itsesi: on todennäköistä, että et itse muista, mitä halusit sanoa tällä tahattomalla hämärtymisellä. Sama asia on dokumentoimattoman koodin kanssa: luotaen muuttujien ja funktioiden nimeämislogiikkaan ja hyvään muistiin, et ehkä parin vuoden kuluttua muista miksi valitsit kyseisen silmukan, menetelmän, kuvion jne. Koodisi ja sen hyvän rakenteen dokumentointi on hyvä palvelu kollegoillesi, työnantajallesi ja ennen kaikkea itsellesi.
Pidä se yksinkertaisena, typerys
Pidä koodisi, ratkaisusi ja projektisi yksinkertaisina. Ei ole tarvetta aidata monimutkaiseen rakenteeseen ja tuottaa kokonaisuuksia ilman erityistä merkitystä. Mitä monimutkaisempi koodisi on, sitä enemmän sinusta tulee sen panttivangi - sinun on mahdollisimman vaikeaa ylläpitää ja kehittää sitä. Kuuluisa KISS-periaate ("Keep it simple, stupid") ei tietenkään aina sovi, mutta se luotiin syystä: koodin yksinkertaisuus ja tyylikkyys ovat avain sen onnistuneeseen soveltamiseen ja uudelleenkäyttöön.
Suojele itseäsi
Älä unohda turvallisuutta – vuonna 2020 se on kirjaimellisesti rikollista. Vaikka yrityksesi, kehitystyösi ja sinä et kiinnostaisi hyökkääjiä, sinuun voivat vaikuttaa ongelmat, jotka liittyvät jonkin verkkosegmentin, isännöintipalveluntarjoajan tappioon, tietokeskukseen kohdistuviin hyökkäyksiin, sähköpostin salasanojen varkauksiin ja työntekijöiden vaaralliseen käytökseen. varastaa tietoja yrityksestä, varastaa asiakkaita tai koko projektin ohjelmakoodia. Jos se on käytettävissäsi ja osaamisalueellasi, yritä suojella projekteja, joiden parissa työskentelet. No tarkkaile tietoturvaa itse, se ei ole koskaan haitannut ketään.
Älä sylje kaivoon
Älä sotke työnantajasi kanssa. Nykyään viestintä on saavuttanut sen tason, että esimerkiksi kaikki kaupungin HR-henkilöt tuntevat toisensa poissa ollessa ja voivat vaihtaa mitä tahansa tietoa chateissa ja suljetuissa ryhmissä (molemmat auttaakseen työnhaussa ja kirjoittaakseen "Vasily Ivanov, järjestelmäarkkitehti, tappoi kaiken ennen kuin poistui tileiltä, poisti varmuuskopiot ja sammutti verkon, toipuminen kesti 3 päivää. Älä palkkaa häntä." Siten käyttäytymisesi pelaa vain sinua vastaan - ja joskus jopa muuttaminen toiseen kaupunkiin tai pääkaupunkiin ei auta. Vaikka lähdetkin kaunalla, ei ole parempaa kostoa kuin ryhtyä kilpailijan hyödylliseksi ja viileäksi työntekijäksi :) Ja mikä tärkeintä, täysin rankaisematta.
Sinun ei myöskään pitäisi tehdä niin. Mutta kuten kokemus osoittaa, emme lopeta
Yleensä, ystävät, lukekaa neuvoja, mutta tehkää niin kuin parhaaksi katsotte - todellisia löytöjä tehdään, kun epäilemme jo löydettyjä totuuksia. Hyvää uutta vuotta, menestyköön projektisi, olkoon urasi nautinnollinen, kollegasi ja johtajasi riittävät ja olkoon elämäsi yleisesti ottaen onnistunut. Yleensä tässä on uusi vuosi ja uusi koodi!
Rakkaudella
RegionSoft Developer Studio -tiimi
Uuden vuoden aikana jatkamme työskentelyäsi ja tehokkaan pöytätietokoneiden CRM-järjestelmän kehittämistä sekä yksinkertainen ja kätevä help desk ja lippujärjestelmä .
Lähde: will.com