Navet är fullt av prognoser och råd om vad du ska göra nästa år - vilka språk du ska lära dig, vilka områden du ska fokusera på, vad du ska göra med din hälsa. Låter inspirerande! Men varje mynt har två sidor, och vi snubblar inte bara i något nytt, utan mest i det vi gör varje dag. "Varför varnade ingen mig!" utbrister vi irriterat och brukar vända oss mot oss själva. Låt oss kalla elden på oss själva - vi har sammanställt en lista åt dig över vad du INTE ska göra 2020 (och kanske alltid).
Men de frågade inte om gravitationen
Vi skulle verkligen vilja göra ordning på antirekommendationerna, från de viktigaste till de minst viktiga. Men de är så vanliga, likvärdiga och bekanta för nästan alla att vi kommer att skriva på måfå. Nåväl, låt oss kolla listan?
Inget behov av att gå till IT om allt är bra
Lär dig inte en ny teknik för att byta karriär eller börja om. Vår tid är underbar eftersom du kan studera, byta jobb, radikalt förändra ditt område – och så vidare, även fram till pensionen. Det är en cool, förförisk sak. Men om du är över 28-30 bör du inte ge upp allt för att gå in i IT eller flytta till en ny stack (till exempel skriver du högt laddade system i Java och bestämmer dig plötsligt för att gå in i neurala nätverk i Python). Anledningen är enkel: det kommer inte att vara lätt för dig. För det första är det hög konkurrens från specialister som har "sittat" på denna stack sedan början av sin karriär, för det andra måste du bli junior igen med låg lön, och för det tredje kommer det att vara moraliskt svårt för dig att bli en underordnad till den lägsta nivån i hierarkin. Därför, om du vill gå åt andra hållet, försök att göra det antingen i linje med ditt nuvarande arbete och nuvarande uppgifter, eller utveckla nya kunskaper som en hobby, starta ett husdjursprojekt så att när du kommer till ett nytt jobb inte längre vara junior.
Att byta stack efter stack är bara ett slöseri med tid
Rusa inte mellan teknikstaplar för din utveckling. Om du skriver ett projekt på ett språk, använder ett visst ramverk och bibliotek, ska du inte kasta allt åt helvete och skriva om det i Dart bara för att du tycker det är intressant. Gör det till en regel för att hitta en motivering för att byta teknik - inte bara på nivån "Jag vill ha det eller jag kan inte", utan också på den ekonomiska och tekniska nivån.
Du behöver inte stå på dig och slå brons
Att hålla sig till ett språk eller en teknik och inte lära sig nya saker är lika extremt som att ändra sin stack med varje ny teknik. Var noga med att studera nya bibliotek och ramverk, var inte envis i vetskapen om att allt var bättre uppfunnet före dig och avslutat exklusivt av dig. Uppdateringar kommer ständigt ut för nästan alla språk, vilket ibland kan förbättra ditt projekt avsevärt. Var inte lat för att övervaka dynamiken i din stack och, så snart du hittar något coolt och användbart, dra gärna in det i projektet!
Ditt eget huvud är bra, alltid bra
Tänk inte i andras huvuden, ditt eget är bättre. Tyvärr sitter en del utvecklare och väntar tills de får en uppgift att koda från det tidigare felet till slutet, utan att försöka bidra med något eget till projektet, utveckla en ny funktion, testa den och föreslå den för produktion. Varför bry sig när det finns en teamledare eller företagsledare som bestämmer allt själva? Om du känner igen dig själv så har vi dåliga nyheter: en passiv position hjälper inte vare sig i din karriär eller i utvecklingen. Du har en chans att prova dig fram som utvecklingsingenjör, och inte kodare, i ett riktigt stridsprojekt och förstå vart du ska vända dig, vad som saknas, men du föredrar att lägga din tid på något annat och göra exakt ”härifrån till nu." Sådana människor överlever sämre och sämre i modern IT, kommer ur avstängd animation.
Användare är hemska människor
Överskatta inte användarna av din programvara: om du inte skriver för programmerare, förvänta dig att programmet kommer att stöta på ogenomträngliga missförstånd. De första dagarna eller veckorna kommer användaren att hata din programvara eftersom "den gamla inte var så dum." För att undvika detta, skapa bra dokumentation och handledning. När du installerar eller köper, tipsa mycket påträngande om att manualerna bör läsas innan du börjar arbeta med programmet, och inte efter att databasen kraschar, förlust av lösenord och självkontroll.
Du bör inte heller underskatta användare: de är listigare, smartare och mer nyfikna än du tror. Om du tror att buggen med det variabla formatet och undantaget den 138:e tryckningen på Enter med en sekunds intervall inte kommer att dyka upp, har du fel - de kommer att dyka upp och påverka funktionen av din applikation på det mest bisarra sättet. Amatörens regel gäller: han är den som klarar tester bäst. Men av någon anledning gillar användare inte att hitta buggar i produktionen - det finns ingen IT-solidaritet i dem. I allmänhet, ju mer säker du är i din programvara, desto bättre. När allt kommer omkring är det bättre att fördröja utgivningen av vissa funktioner än att lägga till dem i en fungerande applikation och plötsligt göra den rå.
Sluta googla!
Sluta vända dig till Google ensam. Vi kommer inte ens att argumentera - inom utvecklingsområdet kan du hitta mycket med en direkt förfrågan till en sökmotor. Ju djupare du gräver efter information, desto mer "lateral" data kommer du att få och desto mer kommer du att lära dig, eftersom du kommer att lära dig något nytt som inte är relaterat till din förfrågan, men som förmodligen kommer att behövas i framtiden. Hänvisa till fullfjädrat material, böcker, artiklar etc. Språk och bibliotek har specifikationer, communities, how tos, och därmed får du det mest tillförlitliga sättet att utveckla programmeringsfärdigheter - läs bara dokumentationen, och leta inte efter andras lokala lösningar och kodfragment. Vad händer om din lösning är mer optimal, snabbare och svalare?
Lita, men kontrollera
Använd inte bibliotek och ramverk skapade av tredjepartsutvecklare utan att kontrollera koden och anpassa den för att passa dina syften. Du har ingen anledning att ovillkorligen lita på denna kodförfattare som du inte känner alls. Ja, olika medvetna skadliga element i tredjepartskod är inte så vanliga och du bör inte lida av paranoia, men att blint kopiera färdiga delar av mjukvara till ditt projekt kan leda till oförutsägbara konsekvenser. Se därför till att läsa och analysera koden före användning och testa efter implementering av koden.
Gör säkerhetskopior!
Sluta att inte göra säkerhetskopior eller behålla dem på samma tredjepartsservrar där ditt projekt är värd. Tycker du att detta är löjliga och värdelösa råd? Men mer än 700 chattdeltagare på Telegram, som nyligen befann sig i en obehaglig situation med stängningen av ett välkänt datacenter, trodde inte det - det fanns allt där: från husdjursprojekt till stora statliga webbplatser. myndigheter och företags 1C och faktureringsdatabaser. En betydande del är utan säkerhetskopior eller med säkerhetskopior på samma plats. Så fördela riskerna och lagra säkerhetskopian åtminstone på huvudhotellet, på någon pålitlig VDS och på din lokala server. Det kommer att bli mycket billigare i längden.
Sluta ta med ditt eget till skada för projektet
Gör inte vad du vill i ett arbetsprojekt, utan gör det som kunderna behöver. Ja, det är otroligt intressant och fantastiskt att skapa ditt eget neurala nätverk, träna det och implementera det i din programvara, men om dina kunder behöver en enkel kontakthanterare kommer detta att vara en överdrift. Se hur projektet fungerar, läs dokumentationen, läs recensioner och förfrågningar från kunder och implementera det som kommer att tillföra affärsnytta till projektet. Om du vill skapa något vetenskapligt eller extremt komplext, börja med ditt eget projekt.
Inte en kod, utan ett knippe nerver
Skriv inte oläsbar och odokumenterad kod. Vi är bekanta med det här tricket: utvecklaren skriver kod så gott han kan, och förväxlar den medvetet lite så att ingen av hans kollegor kan förstå vad han har skrivit - det här är en slags förebyggande hämnd innan något händer. Men du riskerar inte bara företaget (som betalar dig pengar för ditt arbete), utan också dig själv: det är troligt att du själv inte kommer ihåg vad du ville säga med denna oavsiktliga förvirring. Det är samma sak med odokumenterad kod: att lita på din variabel- och funktionsnamnlogik och bra minne, efter ett par år kanske du inte kommer ihåg varför du valde just den slingan, metoden, mönstret osv. Att dokumentera din kod och dess goda struktur är en stor tjänst för dina kollegor, din arbetsgivare och framför allt dig själv.
Håll det enkelt, dumt
Håll din kod, lösningar och projekt enkla. Det finns inget behov av att stängsla in en komplex struktur och producera enheter utan särskild betydelse. Ju mer komplex din kod är, desto mer blir du dess gisslan - det kommer att bli så svårt som möjligt för dig att underhålla och utveckla den. Naturligtvis är den berömda KISS-principen ("Keep it simple, stupid") inte alltid lämplig, men den skapades av en anledning: kodens enkelhet och elegans är nyckeln till dess framgångsrika applikation och återanvändning.
Skydda dig
Ignorera inte säkerheten – 2020 är det bokstavligen kriminellt. Även om ditt företag, utveckling och du inte är av intresse för angripare, kan du drabbas av problem relaterade till nederlag för något nätverkssegment, värdleverantör, attack mot datacentret, stöld av e-postlösenord och osäkert beteende hos anställda som kan stjäla data från företaget, stjäla kunder eller hela projektets programkod. Om det ligger inom din makt och inom ditt kompetensområde, försök att skydda de projekt du arbetar med. Tja, observera informationssäkerheten själv, det har aldrig stört någon.
Spotta inte i brunnen
Bråka inte med din arbetsgivare. Idag har kommunikationen nått en sådan nivå att till exempel alla HR-personer i staden känner varandra i frånvaro och kan utbyta all information i chattar och slutna grupper (både för att hjälpa dem att hitta ett jobb och för att skriva "Vasily Ivanov, systemarkitekt, dödade allt innan du lämnade konton, raderade säkerhetskopior och stängde av nätverket, återställningen tog 3 dagar. Anställ honom inte." Alltså kommer ditt beteende enbart att spela mot dig – och ibland hjälper inte ens flytt till en annan stad eller huvudstad. Även om du går därifrån med agg, finns det ingen bättre hämnd än att bli en användbar och cool anställd hos en konkurrent :) Och viktigast av allt, helt ostraffat.
Det ska du inte göra heller. Men som erfarenheten visar kommer vi inte att sluta
Generellt vänner, läs råden, men gör det du tycker är bäst – trots allt görs riktiga upptäckter när vi tvivlar på redan upptäckta sanningar. Gott nytt år, må dina projekt bli framgångsrika, må din karriär bli njutbar, må dina kollegor och chefer vara tillräckliga, och må ditt liv i allmänhet bli framgångsrikt. I allmänhet, här är till det nya året och den nya koden!
Med kärlek
RegionSoft Developer Studio-team
Under det nya året kommer vi att fortsätta arbeta för dig och utveckla ett kraftfullt skrivbords-CRM-system och en enkel och bekväm helpdesk och biljettsystem .
Källa: will.com