Hva bør ikke IT-folk gjøre i 2020?

Habr er fullt av spådommer og råd om hva man bør gjøre i det kommende året – hvilke språk man bør lære, hvilke områder man bør gå inn i, hvordan man bør ta vare på helsen sin. Det høres inspirerende ut! Men enhver mynt har to sider, og vi snubler ikke bare i noe nytt, men i stor grad i det vi gjør hver dag. «Hvorfor fikk jeg ikke advarsel!», utbryter vi irritert, vanligvis til oss selv. Vi legger oss i skuddlinjen – vi har samlet en liste over hva du IKKE bør gjøre i 2020 (eller kanskje alltid). 

Men gravitasjonen ble ikke spurt

Vi ville gjerne ha rangert anti-anbefalingene i rekkefølge, fra det viktigste til det minst betydningsfulle. Men de er så utbredte, likeverdige og kjent for nesten alle at vi vil skrive dem i tilfeldig rekkefølge. Klar for å sjekke listen?

Ikke gå inn i IT hvis alt går bra

Ikke lær en ny teknologi for å bytte karriere eller starte på nytt. Vår tid er fantastisk fordi man kan lære, bytte jobb, endre yrkesretning – og gjøre det helt til pensjon. Det er en spennende og fristende mulighet. Men hvis du er over 28-30, er det ikke lurt å kaste alt for å gå inn i IT eller bytte til en ny teknologi (for eksempel hvis du jobber med høyt belastede systemer på Java og plutselig bestemmer deg for å begynne med nevrale nettverk på Python). Grunnen er enkel: det vil være vanskelig for deg. For det første er konkurransen høy fra spesialister som har jobbet med denne teknologien siden starten av karrieren sin, for det andre må du begynne på nytt som junior med lav lønn, og for det tredje vil det være følelsesmessig utfordrende å være underordnet i den laveste hierarkiske stillingen. Så hvis du vil bevege deg i en annen retning, prøv å gjøre det enten innenfor rammen av nåværende arbeid og oppgaver, eller utvikle ny kunnskap som en hobby, lage et pet-prosjekt, slik at du kan gå inn i en ny jobb ikke som junior. 

Å bytte teknologi-stakk er bare å kaste bort tid

Ikke beveg deg frem og tilbake mellom teknologistakker for utviklingen din. Hvis du skriver et prosjekt på ett språk, bruker en bestemt ramme og biblioteker, er det ikke lurt å kaste alt bort og skrive det på Dart, bare fordi det virker interessant. Det bør bli en regel å finne gode grunner for å bytte teknologi – ikke bare på nivået «jeg vil-ikke kan», men også på finansielt og ingeniørmessig nivå. 

Ikke stå fast på ditt syn og bli bronsert.

Å holde seg til ett språk eller teknologi og ikke lære noe nytt er like ekstremt som å skifte teknologi hver gang det kommer noe nytt. Sørg for å lære nye biblioteker og rammeverk, vær ikke sta i troen på at alt det beste allerede er funnet og kun fullført av deg. For praktisk talt hvert språk kommer det stadig oppdateringer som kan forbedre prosjektet ditt betydelig. Ikke vær lat, følg med på utviklingen av stakken din, og så snart du finner noe kult og nyttig, er det bare å ta det inn i prosjektet!

Egen hjerne er god, alltid god.

Tenk ikke med andres hoder, ditt eget er bedre. Dessverre sitter noen utviklere og venter på oppdrag når de skal kode fra første feil til slutt, uten å forsøke å bidra med noe eget, utvikle en ny funksjon, teste og foreslå for produksjon. Hvorfor slite med dette når lederen eller teamlederen uansett vil ta avgjørelsene? Hvis du kjenner deg igjen, har vi dårlige nyheter: en passiv holdning vil ikke hjelpe verken i karrieren eller utviklingen. Du har sjansen til å prøve deg som utviklingsingeniør, ikke bare som koder i et ekte prosjekt, og forstå hvilken vei du skal gå, hva du mangler, men foretrekker å bruke tiden din på noe annet og gjøre akkurat «fra dette til dette». Slike folk overlever stadig dårligere i dagens IT-verden, så komm deg ut av dvalen. 

Brukere er fryktelige mennesker.

Ikke overvurder brukerne av programvaren din: hvis du skriver ikke for programmerere, forvent at programmet vil møte uforstand. De første dagene eller ukene vil brukeren hate programvaren din fordi «den gamle ikke var så dum». For å unngå dette, lag god dokumentasjon og opplæringsmateriale. Når du installerer eller kjøper, bør du på en veldig påtrengende måte antyde at manualene bør leses før man begynner å bruke programmet, ikke etter at databasen har krasjet, passordet er mistet og selvkontrollen er borte.

Ikke undervurder brukerne: de er smartere, mer kloke og nysgjerrigere enn du tror. Hvis du tror at den buggen med variabelformatet og unntaket på den 138. Enter-tasten med et intervall på ett sekund ikke vil dukke opp, tar du feil - de vil dukke opp og påvirke appens funksjon på de mest uventede måter. Dilettantreglen gjelder: det er nettopp denne kategorien som gjør testing best. Men brukerne liker av en eller annen grunn ikke å oppdage bugs i produksjon - det er ingen IT-solidaritet der. Generelt, jo mer sikker du er på programvaren din, jo bedre. Tross alt, det er bedre å forsinke lanseringen av noen funksjoner enn å legge dem til i en fungerende applikasjon og gjøre den plutselig ustabil.

Slutt å google!

Slutt å bruke bare Google. Selv om vi ikke kan diskutere det - innen utvikling kan du finne mye med en direkte søkefraser. Jo dypere du graver etter informasjon, jo mer 'sideinformasjon' får du, og jo mer lærer du, fordi du oppdager noe nytt som ikke er relatert til forespørselen din, men sannsynligvis nyttig i fremtiden. Gå til komplette materialer, bøker, artikler osv. Språk og biblioteker har spesifikasjoner, fellesskap, hvordan gjøre det, og på denne måten får du den mest pålitelige metoden for å utvikle programmeringsferdigheter - bare les dokumentasjonen, ikke let etter andres lokale løsninger og kodefragmenter. Hva om løsningen din er mer optimal, raskere og bedre? 

Stol, men sjekk

Ikke bruk biblioteker og rammeverk laget av tredjeparter uten å sjekke koden og tilpasse den til dine mål. Du har ingen grunn til å stole blindt på forfatteren av koden, som du ikke kjenner. Ja, forskjellige forsettlig skadelige elementer i tredjepartskode forekommer ikke så ofte, og det er ikke nødvendig å lide av paranoia, men blind kopiering av ferdige deler av programvare inn i prosjektet ditt kan føre til uforutsigbare konsekvenser. Derfor må du alltid lese og analysere koden før bruk og gjennomføre testing etter implementeringen av koden. 

Lag sikkerhetskopier!

Ikke stop med å ta sikkerhetskopier eller oppbevare dem på de samme tredjepartsserverne hvor prosjektet ditt er hostet. Syns du dette er et morsomt og unødvendig råd? Men mer enn 700 deltakere i Telegram-gruppen som havnet i en nylig uheldig situasjon med nedstengingen av et kjent datasenter, synes ikke det — det var alt fra pet-prosjekter til store nettsteder for statlige organer og bedriftsdatabaser for 1C og fakturering. En betydelig del — uten sikkerhetskopier eller med sikkerhetskopier der. Så fordel risikoene og oppbevar sikkerhetskopien minst på hovedhosting, på en pålitelig VDS og på din egen lokale server. Til syvende og sist vil dette koste mye mindre. 

Slutt å pådra deg tap på bekostning av prosjektet

Ikke gjør i arbeidsprosjektet det som er spennende for deg, men gjør det som er nødvendig for kundene. Ja, det er utrolig interessant og moro å lage sitt eget nevrale nettverk, trene det og implementere det i sin programvare, men hvis kundene dine trenger en enkel kontaktbehandler, vil det være en unødvendig kostnad. Se hvordan prosjektet fungerer, les dokumentasjonen, les tilbakemeldinger og forespørselene fra kunder, og implementer det som gir prosjektet forretningsverdi. Hvis du ønsker å skape noe vitenskapelig eller overkomplisert, start med ditt eget prosjekt.

Ikke kode, men en klump med nerver

Ikke skriv uleselig og udokumentert kode. Vi kjenner denne trenden: utvikleren skriver kode som han føler for, bevisst gjør den litt forvirrende, slik at ingen andre kolleger kan forstå det som er skrevet — en slags preventiv hevn før noe skjer. Men du setter ikke bare selskapet (som betaler deg for arbeidet) i fare, men også deg selv: det er ganske sannsynlig at du selv ikke vil huske hva du mente med denne utilsiktede obfuskasjonen. Det samme gjelder for udokumentert kode: ved å stole på sin egen logikk for navngivning av variabler og funksjoner og god hukommelse, kan du om et par år glemme hvorfor du valgte nettopp denne løkken, metoden, mønsteret osv. Dokumentering av koden og en god struktur er en flott tjeneste for kolleger, arbeidsgiver og først og fremst for deg selv. 

Hold det enkelt, dumskalle

Ikke kompliser koden, løsningene og prosjektene. Det er ikke nødvendig å lage en kompleks struktur og skape enheter uten særlig betydning. Jo mer komplisert koden din er, jo mer blir du en fange av den — det blir ekstremt vanskelig å vedlikeholde og utvikle den. Selv om det berømte prinsippet KISS («Keep it simple, stupid») ikke alltid passer, er det skapt med en grunn: enkelhet og eleganse i koden er nøkkelen til suksess for dens anvendelse og gjenbruk.

Beskytt deg selv

Ikke ignorér sikkerhet — i 2020 var det bokstavelig talt kriminelt. Selv om ditt selskap, utviklingen og du ikke er interessante for kriminelle, kan problemer relatert til kompromittering av et nettverkssegment, en hosting-leverandør, angrep på datasenteret, tyveri av e-postpassord og usikker oppførsel fra ansatte, som kan stjele data fra selskapet, trekke kunder bort eller kode fra hele prosjektet, berøre deg. Hvis det er innenfor dine evner og kompetanseområde, prøv å beskytte de prosjektene du jobber med. Og følg selv informasjonsikkerheten; det har aldri skadet noen. 

Ikke spit i brønnen

Ikke vær uforsiktig mot arbeidsgiveren din. I dag har kommunikasjonen nådd et nivå der for eksempel alle HR-er i byen kjenner hverandre og kan utveksle hvilken som helst informasjon i chatter og lukkede grupper (både for å få hjelp til å få jobb og til å si "Vasilij Ivanov, systemarkitekt, drepte alle kontoene før han dro, slettet sikkerhetskopiene og koblet fra nettverket; gjenopprettingen tok 3 dager. Ikke ansett ham"). Dermed vil atferden din spille mot deg — og noen ganger vil ingen relokalisering til en annen by eller hovedstaden hjelpe. Selv om du går med sinne, finnes det ingen bedre hevn enn å bli en nyttig og flott ansatt i konkurrentens selskap 🙂 Og viktigst av alt, helt straffefri.

Det er heller ikke en god idé. Men som erfaringen viser, vil vi ikke slutte.

Generelt, venner, les rådene, men gjør det som føles best for deg — for ekte oppdagelser skjer når vi er skeptiske til allerede kjente sannheter. Vi gratulerer dere med det nye året, må prosjektene deres være vellykkede, karrieren — interessant, kollegaene og lederne — fornuftige, og livet generelt lykkes. Så skål for det nye året og ny kode! 

Med kjærlighet,
teamet til RegionSoft Developer Studio

I det nye året vil vi fortsette å jobbe for deg og utvikle et kraftig skrivebords-CRM-system. RegionSoft CRM og et enkelt og brukervennlig helpdesk og ticket-system. ZEDLine Support.

Kilde: habr.com