Vad en IT-specialist inte bör göra 2020?

Habr är fullt av förutsägelser och råd om vad man ska göra nästa år - vilka språk man ska lära sig, vilka områden man ska vända sig mot, hur man ska ta hand om sin hälsa. Det låter inspirerande! Men som med varje mynt finns det två sidor, och vi snubblar inte bara över något nytt, utan mycket av det vi gör varje dag. "Varför var det ingen som varnade mig!", utbrister vi irriterat, vanligtvis riktat till oss själva. Vi riktar strålkastarljuset mot oss själva - vi har samlat en lista över vad man INTE bör göra under 2020 (eller kanske alltid). 

Men gravitationen blev inte tillfrågad

Vi skulle gärna vilja rangordna våra anti-rekommendationer, från det mest viktiga till det minst betydelsefulla. Men de är så spridda, jämlika och bekanta för nästan alla, så vi kommer att skriva dem utan särskild ordning. Så, ska vi kolla igenom listan?

Du bör inte gå in i IT-sektorn om allt går bra

Lär dig inte en ny teknik för att byta yrke eller börja från början. Vår tid är fantastisk eftersom man kan studera, byta jobb, helt byta sektor - så kan man hålla på ända till pensionen. Det är en fantastisk och lockande sak. Men om du är över 28-30 år, bör du inte överge allt för att kliva in i IT eller byta till en ny teknikstack (till exempel, om du skriver högbelastade system i Java och plötsligt bestämmer dig för att gå till neurala nätverk med Python). Anledningen är enkel: det kommer att bli svårt för dig. För det första är konkurrensen hög från specialister som har "suttit" på denna stack sedan början av sin karriär, för det andra kommer du att behöva bli junior igen med låg lön, för det tredje kommer det att vara moraliskt svårt att bli underordnad i den lägsta nivån av hierarkin. Så om du vill röra dig i en annan riktning, försök att göra det antingen inom ramen för ditt nuvarande arbete och nuvarande uppgifter, eller utveckla nya kunskaper som en hobby, skapa ett pet-project, så att du kan gå till ett nytt jobb utan att vara en junior. 

Att byta stack mot stack - slösa bara tid

Spring inte mellan teknikstackar för din utveckling. Om du skriver ett projekt på ett språk, använder ett visst ramverk och bibliotek, bör du inte överge allt och skriva om det på Dart, bara för att det verkar intressant. Gör det till en regel att finna en motivering för att byta teknologi - inte bara på nivån "jag vill - jag kan inte", utan även på finansiell och ingenjörsnivå. 

Du behöver inte stå fast vid din åsikt och bli en sten

Att fastna vid ett enda språk eller teknologi och att inte lära sig något nytt är lika extremt som att byta teknikstack vid varje ny teknologi. Se alltid till att studera nya bibliotek och ramverk, och var inte envis i uppfattningen att allt bättre redan har uppfunnits av andra och att du har finslipat det helt själv. Nästan varje språk får ständigt uppdateringar som ibland kan förbättra ditt projekt avsevärt. Tveka inte att hålla koll på utvecklingen av din teknikstack och när du hittar något fantastiskt och användbart, tveka inte att implementera det i projektet!

Egen tanke är bra, alltid bra

Tänk inte med andras huvuden, ditt eget är bättre. Tyvärr finns det vissa utvecklare som sitter och väntar på att få ett mandat att koda från det föregående felet till slutet, utan att försöka bidra med något eget, utveckla en ny funktion, testa och föreslå i produktion. Varför kämpa när det finns teamledarens eller företagets ledare som själva kommer att fatta alla beslut? Om du känner igen dig i detta så har vi dåliga nyheter: en passiv hållning hjälper varken i karriären eller i din utveckling. Du har en chans att pröva dina kunskaper som ingenjörsutvecklare, och inte bara som en kodare i ett verkligt projekt och förstå vart du ska gå, vad som saknas, men du föredrar att spendera din tid på något annat och göra exakt "från punkt A till punkt B". Sådana personer överlever allt mer sällan i dagens IT-värld, ta dig ur din dvala. 

Användare är skrämmande människor

Överskatta inte användarna av din programvara: om du skriver för icke-programmerare, var beredd på att programmet kommer att möta oförståelse. De första dagarna eller veckorna kommer användaren att hata din mjukvara eftersom "den gamla var inte så dum". För att undvika detta, skapa fantastisk dokumentation och utbildningsmaterial. Vid installation eller köp, insistera på att manualerna bör läsas innan man börjar använda programmet, inte efter krasch av databasen, förlust av lösenord och självkontroll.

Att underskatta användarna är inte klokt: de är smartare, mer listiga och nyfiknare än du tror. Om du tror att det där bugget med variabelformatet och undantaget vid den 138:e Enter-knappen med en sekunds intervall inte kommer att dyka upp, då har du fel — de kommer att dyka upp och påverka din applikations funktion på de mest bisarra sätt. Regeln om amatören gäller: det är just han som klarar av testning bäst. Men användarna verkar ogilla att hitta buggar i produktion — ingen IT-solidaritet i det. Sammanfattningsvis, ju mer du är säker på din programvara — desto bättre. I slutändan är det bättre att fördröja släppet av vissa funktioner än att lägga till dem i en fungerande applikation och göra den plötsligt ofärdig.

Sluta googla!

Sluta hänvisa till bara Google. Vi kommer inte ens att diskutera det — inom utveckling kan du hitta väldigt mycket genom att direkt söka på nätet. Ju djupare du gräver i din informationssökning, desto mer "bisysslor" får du och mer lär du dig, eftersom du kommer att upptäcka något nytt som kanske inte är relaterat till din förfrågan, men sannolikt behövs i framtiden. Titta på gedigna material, böcker, artiklar osv. Språk och bibliotek har specifikationer, community, how to och på så sätt får du det mest pålitliga sättet att utveckla programmeringsfärdigheter — genom att bara läsa dokumentationen och inte leta efter andras lokala lösningar och kodsnuttar. Vad händer om din lösning är mer optimal, snabbare och bättre? 

Lita, men kontrollera

Använd inte biblioteken och ramverken skapade av externa utvecklare utan att kontrollera koden och anpassa den för dina syften. Du har inga skäl att blint lita på denna kodförfattare som du överhuvudtaget inte känner. Ja, olika avsiktliga skadliga inslag i extern kod förekommer inte så ofta och det är inte värt att vara paranoid, men att blint kopiera färdiga delar av programvara till ditt projekt kan leda till oförutsägbara konsekvenser. Så se till att läsa och analysera koden innan du använder den och genomför tester efter implementationen av koden. 

Gör säkerhetskopior!

Sluta göra backuper eller ha dem på samma tredjepartsservrar där ditt projekt hostas. Tänker du att det är ett skämt och en onödig råd? Men över 700 deltagare i Telegramchatten, som hamnade i en nyligen obehaglig situation med stoppet av en känd datacenter, trodde inte så - där fanns allt möjligt: från pet-projects till stora statliga sajter och företagsdatabaser som 1C och billing. En stor del - utan backuper eller med backuper där. Så fördela riskerna och lagra en backup åtminstone på den huvudsakliga värdtjänsten, på en pålitlig VDS och på din egen lokala server. I slutändan kommer det att bli mycket billigare. 

Sluta låta det egna påverka projektet negativt

Gör inte i ditt arbetsprojekt det du vill, utan gör det som behövs för kunderna. Ja, det är oerhört intressant och fantastiskt att skapa ett eget neuralt nätverk, träna det och implementera det i din programvara, men om dina kunder behöver en enkel kontaktmanager, blir det en onödig kostnad. Titta på hur projektet fungerar, läs dokumentationen, läs recensioner och förfrågningar från kunder och implementera det som ger projektet affärsvärde. Om du vill skapa något vetenskapligt eller överkomplicerat, börja med ditt eget projekt.

Inte kod, utan en klump av nerver

Skriv inte oläslig och odokumenterad kod. Vi känner till detta grepp: utvecklaren skriver koden som han eller hon vill, gör den medvetet lite svår att förstå, så att ingen kollega kan räkna ut vad som skrivits - en typ av preventiv hämnd innan något händer. Men du riskerar inte bara företaget (som betalar dig för ditt arbete), utan också dig själv: det är fullt möjligt att du inte ens kommer att komma ihåg vad du ville uttrycka med denna oavsiktliga förvirring. Det är detsamma med odokumenterad kod: genom att förlita sig på sin egen logik för namngivning av variabler och funktioner och ett bra minne, kan du om några år glömma varför du valde just denna loop, metod, mönster etc. Dokumentation av koden och en bra struktur är en fantastisk tjänst för kollegor, arbetsgivare och framför allt för dig själv. 

Håll det enkelt, dumskalle

Komplicera inte koden, lösningarna och projekten. Det är inte nödvändigt att bygga komplicerade strukturer och skapa entiteter utan särskild betydelse. Ju mer komplicerad din kod är, desto mer blir du en fången av den - det blir mycket svårt att underhålla och utveckla den. Naturligtvis gäller den berömda principen KISS ("Keep it simple, stupid") inte alltid, men den skapades inte utan anledning: enkelhet och elegans i koden är garantin för dess framgångsrika användning och återanvändning.

Skydda dig

Ignorera inte säkerheten - år 2020 är det faktiskt brottsligt. Även om ditt företag, din utveckling och du själv inte intresserar angripare, kan du drabbas av problem relaterade till ett visst nätverkssegment, en hosting-leverantör, attacker mot ett datacenter, stöld av e-postlösenord och osäkert beteende från anställda som kan stjäla data från företaget, kapa kunder eller programkod för hela projektet. Om det ligger inom dina möjligheter och är relaterat till ditt kompetensområde, försök att skydda de projekt du arbetar med. Och håll också själv säkerheten, det har ingen skadat. 

Spottar inte i brunnen

Skit inte på din arbetsgivare. Idag har kommunikationen nått en sådan nivå att till exempel alla HR i staden känner till varandra på distans och kan dela vilken information som helst i chattar och stängda grupper (såväl som att hjälpa till med anställningar som att skriva "Vasilij Ivanov, systemarkitekt, förstörde alla konton innan han lämnade, raderade backuper och stängde av nätet, återställningen tog 3 dagar. Anställ inte honom"). Således kommer ditt beteende att spela emot dig - och ibland hjälper det inte ens att flytta till en annan stad eller huvudstad. Även om du går med bitterhet, finns det ingen bättre hämnd än att bli en användbar och fantastisk anställd hos konkurrenten 🙂 Och viktigast av allt, helt ostraffat.

Det är inte okej att göra så heller. Men som erfarenheten visar, slutar vi inte

Och faktiskt, vänner, läs råden, men gör som ni tycker är bäst - äkta upptäckter görs när vi tvivlar på redan upptäckta sanningar. Vi gratulerar er med det nya året, må era projekt bli framgångsrika, karriären - intressant, kollegor och chefer - rimliga, och livet i allmänhet lyckas. Skål för det nya året och för den nya koden! 

Med kärlek,
teamet på RegionSoft Developer Studio

Under det nya året kommer vi att fortsätta arbeta för er och utveckla ett kraftfullt desktop CRM-system. RegionSoft CRM och ett enkelt och användarvänligt helpdesk och ärendesystem. ZEDLine Support.

Källa: habr.com