Navnet er fyldt med prognoser og råd om, hvad du skal gøre næste år - hvilke sprog du skal lære, hvilke områder du skal fokusere på, hvad du skal gøre med dit helbred. Lyder inspirerende! Men hver mønt har to sider, og vi snubler ikke kun i noget nyt, men mest i det, vi laver hver dag. "Hvorfor var der ikke nogen, der advarede mig!", udbryder vi irriteret og retter os normalt mod os selv. Lad os kalde ilden over os selv - vi har samlet en liste til dig over, hvad du IKKE skal gøre i 2020 (og måske altid).
Men de spurgte ikke om tyngdekraften
Vi vil rigtig gerne bringe anti-anbefalingerne i orden, fra de vigtigste til de mindst vigtige. Men de er så almindelige, ækvivalente og velkendte for næsten alle, at vi vil skrive tilfældigt. Nå, lad os tjekke listen?
Ingen grund til at gå til IT, hvis alt er i orden
Lær ikke en ny teknologi for at skifte karriere eller starte forfra. Vores tid er vidunderlig, fordi du kan studere, skifte job, ændre dit fag radikalt – og så videre, også indtil pensioneringen. Det er en cool, forførende ting. Men hvis du er over 28-30, skal du ikke opgive alt for at komme ind i IT eller flytte til en ny stak (for eksempel skriver du højt belastede systemer i Java og beslutter dig pludselig for at gå ind i neurale netværk i Python). Årsagen er enkel: det bliver ikke nemt for dig. For det første er der høj konkurrence fra specialister, der har "siddet" på denne stak siden starten af deres karriere, for det andet skal du blive junior igen med en lav løn, og for det tredje vil det være moralsk svært for dig at blive en underordnet af hierarkiets laveste niveau. Derfor, hvis du vil bevæge dig i den anden retning, så prøv at gøre det enten i tråd med dit nuværende arbejde og nuværende opgaver, eller udvikle ny viden som en hobby, start et kæledyrsprojekt, så du, når du kommer til et nyt job, ikke længere være junior.
At skifte stak efter stak er bare spild af tid
Skynd dig ikke mellem teknologistabler for din udvikling. Hvis du skriver et projekt på ét sprog, ved hjælp af en bestemt ramme og biblioteker, skal du ikke kaste alt ad helvede til og omskrive det i Dart, bare fordi du finder det interessant. Gør det til en regel at finde en begrundelse for at ændre teknologi - ikke kun på niveauet "Jeg vil det eller jeg kan ikke", men også på det økonomiske og tekniske niveau.
Ingen grund til at stå fast og blive bronze
At holde sig til ét sprog eller teknologi og ikke lære nye ting er lige så ekstremt som at ændre sin stak med hver ny teknologi. Sørg for at studere nye biblioteker og rammer, vær ikke stædig i den viden, at alt var bedre opfundet før dig og fuldført udelukkende af dig. Der kommer konstant opdateringer til næsten alle sprog, hvilket nogle gange kan forbedre dit projekt betydeligt. Vær ikke doven til at overvåge dynamikken i din stak, og så snart du finder noget sejt og nyttigt, er du velkommen til at trække det ind i projektet!
Dit eget hoved er godt, altid godt
Tænk ikke i andres hoveder, dit eget er bedre. Ak, nogle udviklere sidder og venter, indtil de modtager en opgave til at kode fra den forrige fejl til slutningen, uden at forsøge at bidrage med noget af deres eget til projektet, udvikle en ny funktion, teste den og foreslå den til produktion. Hvorfor bøvle, når der er en teamleder eller virksomhedsleder, der bestemmer alt selv? Hvis du genkender dig selv, så har vi dårlige nyheder: en passiv position hjælper hverken i din karriere eller i udviklingen. Du har en chance for at prøve dig frem som udviklingsingeniør, og ikke koder, i et rigtigt kampprojekt og forstå, hvor du skal hen, hvad der mangler, men du foretrækker at bruge din tid på noget andet og gøre præcis "herfra til nu." Sådanne mennesker overlever værre og værre i moderne IT, kommer ud af suspenderet animation.
Brugere er forfærdelige mennesker
Overvurder ikke brugerne af din software: Hvis du ikke skriver for programmører, skal du forvente, at programmet støder på uigennemtrængelige misforståelser. De første par dage eller uger vil brugeren hade din software, fordi "den gamle ikke var så dum." For at undgå dette skal du lave god dokumentation og selvstudier. Når du installerer eller køber, antyd meget påtrængende, at manualerne skal læses, før du begynder at arbejde med programmet, og ikke efter databasen går ned, tab af adgangskoden og selvkontrol.
Du skal heller ikke undervurdere brugere: de er mere snu, klogere og mere nysgerrige, end du tror. Hvis du tror, at fejlen med det variable format og undtagelsen ved det 138. tryk på Enter med et sekunds mellemrum ikke vil dukke op, tager du fejl - de vil dukke op og påvirke driften af din applikation på den mest bizarre måde. Amatørens regel gælder: det er ham, der klarer testen bedst. Men af en eller anden grund kan brugerne ikke lide at finde fejl i produktionen - der er ingen it-solidaritet i dem. Generelt, jo mere sikker du er i din software, jo bedre. Det er trods alt bedre at forsinke udgivelsen af nogle funktioner end at tilføje dem til en fungerende applikation og pludselig gøre den rå.
Stop med at google!
Stop med at henvende sig til Google alene. Vi vil ikke engang argumentere - inden for udvikling kan du finde meget med en direkte anmodning til en søgemaskine. Jo dybere du graver i søgen efter information, jo flere "laterale" data vil du modtage, og jo mere vil du lære, fordi du vil lære noget nyt, som ikke er relateret til din anmodning, men som sandsynligvis vil blive nødvendigt i fremtiden. Der henvises til fuldgyldige materialer, bøger, artikler mv. Sprog og biblioteker har specifikationer, fællesskaber, how tos, og dermed får du den mest pålidelige måde at udvikle programmørfærdigheder på - læs blot dokumentationen, og led ikke efter andres lokale løsninger og kodefragmenter. Hvad hvis din løsning er mere optimal, hurtigere og køligere?
Stol, men verificere
Brug ikke biblioteker og rammer skabt af tredjepartsudviklere uden at tjekke koden og tilpasse den, så den passer til dine formål. Du har ingen grund til ubetinget at stole på denne kodeforfatter, som du slet ikke kender. Ja, forskellige bevidste ondsindede elementer i tredjepartskode er ikke så almindelige, og du bør ikke lide af paranoia, men blindt kopiering af færdige dele af software ind i dit projekt kan føre til uforudsigelige konsekvenser. Sørg derfor for at læse og analysere koden før brug og test efter implementering af koden.
Lav sikkerhedskopier!
Lad være med at lave sikkerhedskopier eller opbevare dem på de samme tredjepartsservere, hvor dit projekt er hostet. Synes du, det er latterligt og ubrugeligt råd? Men mere end 700 chatdeltagere på Telegram, som for nylig befandt sig i en ubehagelig situation med nedlukningen af et velkendt datacenter, mente det ikke - der var alt der: fra kæledyrsprojekter til store offentlige hjemmesider. myndigheder og virksomheders 1C og faktureringsdatabaser. En væsentlig del er uden backup eller med backup samme sted. Så fordel risiciene og gem sikkerhedskopien i det mindste på hovedhostingen, på en pålidelig VDS og på din lokale server. Det ender med at blive meget billigere i det lange løb.
Stop med at bringe din egen til skade for projektet
Gør ikke hvad du vil i et arbejdsprojekt, men gør hvad kunderne har brug for. Ja, det er utroligt interessant og fantastisk at skabe dit eget neurale netværk, træne det og implementere det i din software, men hvis dine kunder har brug for en simpel kontaktmanager, vil dette være en overkill. Se, hvordan projektet fungerer, læs dokumentationen, læs anmeldelser og anmodninger fra kunder, og implementer, hvad der vil tilføje forretningsværdi til projektet. Hvis du vil skabe noget videnskabeligt eller ekstremt komplekst, så start med dit eget projekt.
Ikke en kode, men et bundt af nerver
Skriv ikke ulæselig og udokumenteret kode. Vi kender til dette trick: Udvikleren skriver koden til sin hjertens lyst, og forvirrer den bevidst lidt, så ingen af hans kolleger kan forstå, hvad han har skrevet – dette er en slags forebyggende hævn, før der sker noget. Du risikerer dog ikke kun virksomheden (som betaler dig penge for dit arbejde), men også dig selv: Det er sandsynligt, at du ikke selv vil huske, hvad du ville sige med denne utilsigtede sløring. Det er det samme med udokumenteret kode: afhængig af din variabel- og funktionsnavngivningslogik og god hukommelse, kan du efter et par år måske ikke huske, hvorfor du valgte netop den sløjfe, metode, mønster osv. At dokumentere din kode og dens gode struktur er en god service for dine kolleger, din arbejdsgiver og mest af alt for dig selv.
Hold det enkelt, dumt
Hold din kode, løsninger og projekter enkle. Der er ingen grund til at indhegne en kompleks struktur og producere enheder uden særlig betydning. Jo mere kompleks din kode er, jo mere bliver du dens gidsel - det vil være så svært som muligt for dig at vedligeholde og udvikle den. Selvfølgelig er det berømte KISS-princip ("Keep it simple, stupid") ikke altid egnet, men det blev skabt af en grund: kodens enkelhed og elegance er nøglen til dens succesfulde anvendelse og genbrug.
Beskyt dig selv
Ignorer ikke sikkerheden - i 2020 er det bogstaveligt talt kriminelt. Selvom din virksomhed, udvikling og du ikke er af interesse for angribere, kan du blive påvirket af problemer relateret til nederlag af et netværkssegment, hostingudbyder, angreb på datacenteret, tyveri af e-mail-adgangskoder og usikker adfærd hos medarbejdere, der kan stjæle data fra virksomheden, stjæle kunder eller hele projektets programkode. Hvis det er inden for din magt og inden for dit område af ekspertise, så prøv at beskytte de projekter, du arbejder på. Nå, observer selv informationssikkerheden, det har aldrig generet nogen.
Spyt ikke i brønden
Lad være med at rode med din arbejdsgiver. I dag har kommunikationen nået et sådant niveau, at for eksempel alle HR-folk i byen kender hinanden in absentia og kan udveksle enhver information i chats og lukkede grupper (både for at hjælpe med at finde et job og skrive "Vasily Ivanov, systemarkitekt, dræbte alt, før de forlod konti, slettede sikkerhedskopier og slukkede for netværket, genoprettelsen tog 3 dage. Lad være med at ansætte ham." Din adfærd vil således udelukkende spille imod dig – og nogle gange hjælper endda flytning til en anden by eller hovedstad ikke. Selvom du går derfra med nag, er der ingen bedre hævn end at blive en nyttig og sej medarbejder hos en konkurrent :) Og vigtigst af alt, helt ustraffet.
Det skal du heller ikke gøre. Men som erfaringen viser, vil vi ikke stoppe
Generelt venner, læs rådene, men gør hvad du synes er bedst – der bliver trods alt gjort rigtige opdagelser, når vi tvivler på allerede opdagede sandheder. Godt nytår, må dine projekter blive succesfulde, må din karriere blive fornøjelig, må dine kolleger og ledere være tilstrækkelige, og må dit liv generelt blive succesfuldt. Generelt, her er det nytår og den nye kode!
Med kærlighed,
RegionSoft Developer Studio team
I det nye år vil vi fortsætte med at arbejde for dig og udvikle et kraftfuldt desktop CRM-system og en enkel og praktisk helpdesk og billetsystem .
Kilde: www.habr.com