Mida IT spetsialist ei tohiks 2020. aastal teha?

Habr on täis prognoose ja nõuandeid selle kohta, mida järgmisel aastal teha: milliseid keeli õppida, millistesse valdkondadesse liikuda, kuidas oma tervise eest hoolitseda. Kõlab inspireerivalt! Kuid igal medalil on kaks poolt ning me ei komista mitte ainult millegi uue otsa, vaid enamasti just selle tõttu, mida teeme iga päev. „Miks küll keegi mind ei hoiatanud!“, hüüame ärritunult, tavaliselt iseenda poole pöördudes. Toome tule enda peale — panime teie jaoks kokku nimekirja sellest, mida 2020. aastal (ja võib-olla üldse mitte kunagi) EI tasu teha. 

Aga gravitatsioonilt ei küsinud keegi

Tahaksime väga need vastusoovitused järjestada kõige olulisemast kõige vähemtähtsani. Kuid need on nii levinud, võrdselt tähtsad ja peaaegu kõigile tuttavad, et kirjutame neist läbisegi. Noh, vaatame nimekirja üle?

Ärge minge IT-sse, kui kõik on hästi

Ärge õppige uut tehnoloogiat ainult selleks, et ametit vahetada või nullist alustada. Meie aja juures on suurepärane see, et saab õppida, töökohta vahetada ja lausa kogu valdkonda põhjalikult muuta — kas või pensionini välja. See on äge ja ahvatlev võimalus. Kuid kui olete üle 28–30 aasta vana, ei tasu kõike sinnapaika jätta ainult selleks, et IT-sse tulla või uuele stack’ile üle minna (näiteks arendate suure koormusega süsteeme Java peal ja otsustate äkki liikuda Pythoni-põhiste närvivõrkude juurde). Põhjus on lihtne: see ei saa olema kerge. Esiteks on konkurents tugev nende spetsialistide poolt, kes on selle stack’iga töötanud juba karjääri algusest peale; teiseks peate taas alustama juniorina madalama palgaga; kolmandaks võib olla psühholoogiliselt raske saada alluvaks hierarhia kõige alumisel tasemel. Seega, kui tahate liikuda teises suunas, proovige teha seda kas oma praeguse töö ja ülesannete raamides või arendage uusi teadmisi hobina, tehke pet-project, et jõuda uuele tööle juba mitte juniorina. 

Stack’i vahetamine teise stack’i vastu on enamasti lihtsalt ajaraisk

Ärge pendeldage oma arenduses erinevate tehnoloogiastack’ide vahel. Kui kirjutate projekti ühes keeles ning kasutate kindlat framework’i ja teeke, ei tasu kõike põrgusse saata ja Darti peale ümber kirjutada ainult seetõttu, et see tundus teile huvitav. Võtke reegliks leida tehnoloogia vahetamiseks põhjendus mitte ainult tasemel „tahan nii väga“, vaid ka finants- ja insenertehnilisel tasandil. 

Ei ole vaja jääda jäigalt oma seisukoha juurde ja kivistuda

Ühte keelde või tehnoloogiasse kinni jääda ja mitte midagi uut õppida on sama äärmuslik kui vahetada stacki iga uue tehnoloogia järel. Õppige kindlasti uusi teeke ja raamistikke ning ärge kangekaelselt arvake, et kõik parim on juba enne teid välja mõeldud ja ainult teie poolt lõpuni lihvitud. Peaaegu iga keele jaoks ilmub pidevalt uuendusi, mis võivad teie projekti mõnikord märgatavalt paremaks teha. Ärge olge laisad oma stacki arengul silma peal hoidma ja kui leiate midagi tõeliselt head ning kasulikku, võtke see julgelt projekti kasutusele!

Oma pea on alati parem

Ärge mõelge teiste peaga, oma pea on parem. Kahjuks istuvad mõned arendajad ja ootavad, kuni neile antakse ülesanne lihtsalt eelmise error-i juurest kuni end-ini koodi kirjutada, proovimata projekti midagi oma poolt lisada, uut funktsiooni välja töötada, seda testida ja productionisse pakkuda. Milleks pingutada, kui on olemas team lead’i või ettevõtte juhi pea, kes otsustab niikuinii kõik ise? Kui tundsite end ära, siis on meil halvad uudised: passiivne hoiak ei aita ei karjääris ega arengus. Teil on võimalus proovida end insener-arendajana, mitte lihtsalt koodikirjutajana päris töökindlas projektis, ja mõista, kuhu edasi liikuda ning millest puudu jääb, kuid eelistate kulutada oma aega millelegi muule ja teha täpselt ainult nii palju, kui ette antud. Sellistel on tänapäeva IT-s aina raskem ellu jääda, aeg on talveunest väljuda. 

Kasutajad on hirmus rahvas

Ärge ülehinnake oma tarkvara kasutajaid: kui te ei kirjuta programmeerijatele, arvestage sellega, et teie programm põrkub täieliku arusaamatusega. Esimestel päevadel või nädalatel vihkab kasutaja teie tarkvara, sest „vana ei olnud ju nii rumal“. Selle vältimiseks tehke väga hea dokumentatsioon ja õppematerjalid. Paigaldamise või ostmise ajal vihjake üsna pealetükkivalt, et juhendeid tasub lugeda enne programmiga töö alustamist, mitte pärast andmebaasi kokkuvarisemist, parooli kaotamist ja enesevalitsuse kadumist.

Ka kasutajaid ei tasu alahinnata: nad on kavalamad, nutikamad ja uudishimulikumad, kui arvate. Kui usute, et see muutujaformaadi viga ja exception Enteri 138. vajutamisel ühesekundilise intervalliga ei tule kunagi välja, siis eksite — tuleb küll ja mõjutab teie rakenduse tööd kõige ootamatumal viisil. Siin kehtib harrastaja reegel: just tema saab testimisega kõige paremini hakkama. Kasutajatele aga millegipärast ei meeldi production'is vigu leida — IT-solidaarsust justkui polegi. Kokkuvõttes: mida kindlam olete oma tarkvaras, seda parem. Lõppude lõpuks on parem mõne funktsiooni väljalase edasi lükata, kui lisada need töötavasse rakendusse ja muuta see äkitselt tooreks.

Aitab guugeldamisest!

Ärge piirduge ainult Google'iga. Pole mõtet vaielda — arenduses leiab otsese otsingupäringuga väga palju. Mida sügavamale infootsingusse sukeldute, seda rohkem saate ka „kõrvalist“ teavet ja seda enam õpite, sest avastate midagi uut, mis pole küll teie päringuga otseselt seotud, kuid võib tulevikus kasulikuks osutuda. Kasutage põhjalikke materjale, raamatuid, artikleid jne. Keeltel ja teekidel on olemas spetsifikatsioonid, community, how-to materjalid ning just nii jõuate programmeerija oskuste arendamiseks kõige usaldusväärsema meetodini — lugege dokumentatsiooni, mitte ärge otsige teiste lokaalseid lahendusi ja koodijuppe. Mine tea, äkki on just teie lahendus optimaalne, kiirem ja parem? 

Usalda, aga kontrolli

Ärge kasutage kolmandate osapoolte arendatud teeke ja raamistikke ilma koodi kontrollimata ning seda oma eesmärkidele kohandamata. Teil pole mingit põhjust usaldada tingimusteta koodi autorit, keda te tegelikult ei tunne. Jah, pahatahtlikke elemente kohtab kolmanda osapoole koodis küll harva ja paranoiaks pole põhjust, kuid valmis tarkvarakomponentide pime kopeerimine oma projekti võib viia ettearvamatute tagajärgedeni. Seetõttu lugege ja analüüsige koodi enne kasutamist kindlasti läbi ning tehke pärast koodi implementeerimist testimine. 

Tehke varukoopiaid!

Lõpetage varukoopiate tegemata jätmine või nende hoidmine samades kolmanda osapoole serverites, kus teie projekt töötab. Tundub naljakas ja asjatu soovitus? Üle 700 Telegrami vestluse osaleja, kes sattusid hiljuti tuntud andmekeskuse seiskumise tõttu ebameeldivasse olukorda, nii ei arvanud — seal oli kõike alates pet-project’idest kuni suurte riigiasutuste veebilehtede ning 1C ja arveldussüsteemide ettevõtteandmebaasideni. Märkimisväärsel osal polnud varukoopiaid üldse või hoiti neid samas kohas. Seega hajutage riske ja hoidke varukoopiaid vähemalt põhimajutuses, mõnes usaldusväärses VDS-is ning ka oma kohalikus serveris. Lõppkokkuvõttes tuleb see palju odavam. 

Ärge seadke oma eelistusi projektist ettepoole

Ärge tehke tööprojektis seda, mida ise tahate, vaid seda, mida kliendid tegelikult vajavad. Jah, oma närvivõrgu loomine, selle treenimine ja oma tarkvarasse juurutamine võib olla pööraselt huvitav ja äge, kuid kui teie kliendid vajavad lihtsat kontaktihaldurit, on see lihtsalt kulukas liialdus. Vaadake, kuidas projekt töötab, lugege dokumentatsiooni, tutvuge klientide tagasiside ja päringutega ning viige ellu see, mis annab projektile ärilist väärtust. Kui soovite luua midagi teaduslikku või ülikeerukat, alustage omaenda projektist.

Mitte kood, vaid närvipundar

Ärge kirjutage loetamatut ja dokumenteerimata koodi. See võte on meile tuttav: arendaja kirjutab koodi nii, nagu juhtub, ajab selle meelega veidi segaseks, et ükski kolleeg ei suudaks kirjutatust aru saada — omamoodi ennetav kättemaks juba enne, kui midagi juhtunud on. Kuid nii seate ohtu mitte ainult ettevõtte (kes maksab teile töö eest), vaid ka iseenda: on täiesti võimalik, et ühel hetkel ei mäleta te isegi enam, mida selle tahtmatu obfuskeerimisega öelda tahtsite. Sama kehtib dokumenteerimata koodi kohta: lootes oma muutujate ja funktsioonide nimetamise loogikale ning heale mälule, ei pruugi te paari aasta pärast enam mäletada, miks valisite just selle tsükli, meetodi, mustri jne. Koodi dokumenteerimine ja hea struktuur on suur teene kolleegidele, tööandjale ja eelkõige teile endale. 

Keep it simple, stupid

Ärge ajage koodi, lahendusi ja projekte asjatult keeruliseks. Pole vaja ehitada üles liigset ja keerukat struktuuri ega luua ilma mõjuva põhjuseta uusi üksusi. Mida keerulisem on teie kood, seda rohkem muutute selle pantvangiks — seda raskem on seda hooldada ja edasi arendada. Muidugi ei sobi tuntud KISS-põhimõte («Keep it simple, stupid») alati igasse olukorda, kuid see pole loodud niisama: koodi lihtsus ja elegants on selle eduka kasutamise ning taaskasutuse alus.

Kaitske end

Ärge ignoreerige turvalisust — 2020. aastal on see sõna otseses mõttes kuritegelik hooletus. Isegi kui teie ettevõte, arendus ja teie ise ei paku ründajatele huvi, võivad teid puudutada probleemid, mis on seotud mõne võrgusegmendi nakatumisega, hosting-provideri tõrgetega, rünnakuga andmekeskuse vastu, e-posti paroolide vargusega või töötajate ebaturvalise käitumisega, mille tagajärjel võidakse ettevõttest andmeid, kliente või kogu projekti programmikoodi varastada. Kui see on teie võimuses ja kuulub teie vastutusalasse, püüdke kaitsta projekte, millega töötate. Ja järgige ka ise infoturbe põhimõtteid — see pole veel kellelegi kahju teinud. 

Ärge sülitage kaevu

Ärge keerake oma tööandjale käkki. Tänapäeval on suhtlus jõudnud sellisele tasemele, et näiteks kõik linna HR-id on omavahel vähemalt kaudselt tuttavad ja saavad vestlustes ning suletud gruppides jagada ükskõik millist infot (nii selleks, et aidata kellelgi tööle saada, kui ka kirjutada stiilis: «Vassili Ivanov, süsteemiarhitekt, kustutas enne lahkumist kõik kontod, rikkus varukoopiad ja lülitas võrgu välja, taastamine võttis 3 ööpäeva. Ärge võtke teda tööle»). Nii mängib selline käitumine lõpuks ainult teie enda vastu — ja mõnikord ei aita isegi teise linna või pealinna kolimine. Isegi kui lahkute kibestunult, pole paremat kättemaksu kui saada konkurendi juures väärtuslikuks ja suurepäraseks töötajaks 🙂 Ja mis peamine — täiesti karistamatult.

Nii ei tasu samuti teha. Aga nagu kogemus näitab, me ei lõpeta seda niikuinii

Aga üldiselt, sõbrad, lugege nõuandeid, kuid tehke nii, nagu teile endale tundub kõige õigem — sest tõelised avastused sünnivad siis, kui kahtleme juba ammu tuntud tõdedes. Soovime teile head uut aastat: olgu teie projektid edukad, karjäär huvitav, kolleegid ja juhid mõistlikud ning elu tervikuna sujugu hästi. Ühesõnaga — uue aasta ja uue koodi terviseks! 

Armastusega,
RegionSoft Developer Studio meeskond

Uuel aastal jätkame teie heaks töötamist ja arendame edasi võimsat lauaarvuti CRM-süsteemi RegionSoft CRM ning lihtsat ja mugavat helpdeski ning piletisüsteemi ZEDLine Support.

Allikas: habr.com