Hacker er fyldt med forudsigelser og råd om, hvad man skal gøre næste år - hvilke sprog man skal lære, hvilke områder man skal dykke ind i, hvordan man skal tage sig af sin sundhed. Det lyder inspirerende! Men som med enhver mønt har det to sider, og vi støder ikke kun på noget nyt, men i højere grad på det, vi gør hver dag. "Hvorfor blev jeg ikke advaret!", udbrister vi irriteret, ofte til os selv. Vi bringer ilden til os selv - vi har samlet en liste over, hvad man IKKE bør gøre i 2020 (eller måske altid).
Men gravitationen blev ikke spurgt
Vi ville meget gerne organisere anti-anbefalingerne i rækkefølge, fra det vigtigste til det mindre vigtige. Men de er så udbredte, ligeværdige og kendte af næsten alle, at vi vil skrive dem i vilkårlig rækkefølge. Nå, lad os tjekke listen?
Du skal ikke gå ind i IT, hvis alt er godt
Lær ikke en ny teknologi for at skifte karriere eller starte forfra. Vores tid er fantastisk, fordi man kan lære, skifte job, totalt forandre sit felt - og så videre indtil pensionen. Det er en fantastisk, fristende ting. Men hvis du er over 28-30 år, så undgå at kaste alt væk for at komme ind i IT eller skifte til en ny stack (for eksempel hvis du skriver højtydende systemer i Java og pludselig beslutter at gå til neurale netværk med Python). Årsagen er enkel: det vil være svært for dig. For det første er der høj konkurrence fra fagfolk, som har "sidet" i denne stack fra begyndelsen af deres karriere, for det andet, så skal du igen blive junior med lav løn, for det tredje, vil det være mentalt svært for dig at blive underordnet i bunden af hierarkiet. Derfor, hvis du ønsker at bevæge dig i en anden retning, så prøv at gøre det enten i tråd med dit nuværende arbejde og opgaver, eller udvikl ny viden som en hobby, arbejd på et pet-projekt for at komme til en ny job allerede som ikke-junior.
At skifte stack er kun et spild af tid
Løb ikke mellem stacks af teknologier til dit udviklingsprojekt. Hvis du skriver et projekt i et sprog, bruger en bestemt ramme og biblioteker, er det ikke en god idé at smide alt væk og omskrive det til Dart, bare fordi det virker interessant for dig. Gør det til en regel at finde en berettigelse for at ændre teknologi - ikke kun på niveauet "jeg vil - jeg kan ikke", men også på et finansielt og ingeniørniveau.
Du skal ikke stå fast og ruste til
Atte sig til ét sprog eller teknologi uden at lære noget nyt er lige så ekstremt som at skifte tech-stack ved hver ny teknologi. Sørg for at studere nye biblioteker og rammer, vær ikke stædig i troen på, at alt det bedste allerede er opfundet og udelukkende færdiggjort af dig. Praktisk talt hvert sprog får konstant opdateringer, som nogle gange kan forbedre dit projekt betydeligt. Lad være med at være doven med at følge med i udviklingen af din tech-stack, og når du finder noget cool og nyttigt, så tag det modigt ind i dit projekt!
Din egen hoved er godt, altid godt
Tænk ikke med andres hoveder, dit eget er bedre. Desværre sidder nogle udviklere og venter på, at de får besked om at kode fra den tidligere fejl til enden, uden at forsøge at bidrage med noget eget til projektet, udvikle en ny funktion, teste og foreslå til produktion. Hvorfor besvære sig, når teamlederen eller virksomhedens leder kan beslutte alt? Hvis du genkender dig selv, har vi dårlige nyheder: en passiv holdning vil ikke hjælpe hverken i karrieren eller udviklingen. Du har en chance for at prøve kræfter med at være ingeniørudvikler, ikke bare koder i et ægte projekt og forstå, hvilken retning du skal bevæge dig i, hvad der mangler, men du foretrækker at bruge din tid på noget andet og bare gøre det lige fra "start til slut". Sådanne i den moderne IT-verden klarer sig dårligere og dårligere, kom ud af din dvale.
Brugere er skræmmende mennesker
Undervurder ikke brugerne af din software: hvis du skriver til ikke-programmører, skal du forvente, at programmet vil møde uundgåeligt misforståelse. I de første par dage eller uger vil brugeren hade din software, fordi "den gamle ikke var så dum". For at undgå dette, lav god dokumentation og træningsmaterialer. Ved installation eller køb, giv en meget vedholdende henvisning til, at manualer bør læses, før man går i gang med programmet, og ikke efter sammenbrud af databasen, tab af adgangskode og selvkontrol.
Man skal heller ikke undervurdere brugerne: de er mere snedige, klogere og nysgerrige, end man tror. Hvis du tror, at den fejl med variabelens format og undtagelsen ved det 138. tryk på Enter med et interval på et sekund ikke vil dukke op, tager du fejl — de vil dukke op og påvirke dit applikations arbejde på de mest mærkelige måder. Amatørreglen gælder: det er netop amatøren, der klarer testningen bedst. Men brugerne bryder sig åbenbart ikke om at finde fejl i produktionen — de har ikke meget IT-solidaritet. Generelt gælder det, jo mere sikker du er på din software — jo bedre. I sidste ende er det bedre at forsinke udgivelsen af nogle funktioner end at tilføje dem i en fungerende applikation og pludselig gøre den uferdig.
Stop med at google!
Hold op med kun at henvende dig til Google. Der er ikke noget at diskutere — inden for udvikling kan man finde meget med en direkte søgning. Jo dybere du graver i din informationssøgning, desto flere "side-data" får du, og desto mere lærer du, fordi du vil opdage noget nyt, der ikke er relateret til din forespørgsel, men sandsynligvis vil være nyttigt i fremtiden. Tag fat i omfattende materialer, bøger, artikler osv. Sprog og biblioteker har specifikationer, fællesskaber, how-tos, og dermed får du den mest pålidelige måde at udvikle dine programmeringsfærdigheder på — ved simpelthen at læse dokumentationen i stedet for at lede efter andres lokale løsninger og kodefragmenter. Hvad nu hvis din løsning er mere optimal, hurtigere og bedre?
Lyt, men kontroller
Brug ikke biblioteker og rammer lavet af tredjepartsudviklere uden at kontrollere koden og tilpasse den til dine formål. Du har ingen grund til uden videre at stole på denne kodeforfatter, som du slet ikke kender. Ja, forskellige bevidste skadelige elementer i tredjepartskode forekommer ikke så ofte, og det er ikke værd at være paranoid, men blind kopiering af færdige dele af software til dit projekt kan føre til uforudsigelige konsekvenser. Derfor skal du altid læse og analysere koden, før du bruger den, og udføre test efter implementeringen af koden.
Lav backups!
Stop neglecting backups or keeping them on the same third-party servers where your project is hosted. Think it's a silly and unnecessary piece of advice? Just ask more than 700 participants from a Telegram chat who recently faced issues after a famous data center went down—there were projects ranging from pet projects to major government websites and corporate databases like 1C and billing systems. A significant portion were without backups or had backups stored there. So, spread the risk and keep a backup at least on the main hosting, on some reliable VDS, and on your local server. In the end, it will be a lot cheaper.
Stop sacrificing your needs for the project's sake.
Don't do in a working project what you want; do what your clients need. Yes, it's incredibly interesting and great to create your own neural network, train it, and integrate it into your software, but if your clients need a simple contact manager, it will be an excessive cost. Look at how the project works, read the documentation, check client reviews and requests, and implement what will bring business value to the project. If you want to create something scientific or overly complicated, start with your own project.
Not code, but a bundle of nerves.
Don't write unreadable and undocumented code. We know this trick: a developer writes code haphazardly, deliberately makes it a bit convoluted so that no one else can understand it—it's a kind of preventive revenge before anything even happens. However, you're putting not only the company at risk (which pays you for your work) but also yourself: it's very likely that you won’t even remember what you meant with this unintentional obfuscation. The same goes for undocumented code: relying on your variable and function naming logic and good memory, you might forget why you chose that specific loop, method, pattern, etc., after a couple of years. Documenting your code and structuring it well is a great service to your colleagues, employer, and most importantly, to yourself.
Keep it simple, stupid.
Gør ikke koden, løsningerne og projekterne mere komplicerede. Det er ikke nødvendigt at skabe en kompleks struktur og generere entiteter uden særlig betydning. Jo mere kompleks din kode er, desto mere bliver du dens fange — det vil være ekstremt svært for dig at vedligeholde og udvikle den. Selvfølgelig gælder det berømte KISS-princip ("Keep it simple, stupid") ikke altid, men det er ikke uden grund: enkelhed og elegance i koden er nøglen til dens succesfulde anvendelse og genbrug.
Beskyt dig selv
Ignorer ikke sikkerheden — i 2020 er det bogstaveligt talt en forbrydelse. Selv hvis din virksomhed, udvikling og du ikke er interessante for kriminelle, kan du blive påvirket af problemer relateret til angreb på en del af netværket, hostingudbyderen, angreb på datacenteret, tyveri af e-mailadgangskoder og usikker adfærd fra ansatte, som kan stjæle data fra virksomheden, tage kunder eller kildekoden til hele projektet. Hvis det ligger inden for din magt og dit ansvarsområde, så prøv at beskytte de projekter, du arbejder med. Og husk selv at overholde informationssikkerheden, det har aldrig skadet nogen.
Spyt ikke i brønden
Beskyt ikke din arbejdsgiver. I dag har kommunikationen nået et sådant niveau, at for eksempel alle HR'ere i byen kender hinanden og kan udveksle enhver information i chats og lukkede grupper (både om at hjælpe med ansættelse og skrive "Vasiliy Ivanov, systemarkitekt, dræbte alle konti før han forlod, slettede backups og slukkede netværket, hvilket tog 3 dage at genoprette. Tag ham ikke ansat"). På denne måde vil din adfærd kun spille imod dig — og nogle gange vil relocation til en anden by eller hovedstad ikke hjælpe. Selv hvis du forlader med nag, er der ingen bedre hævn end at være en nyttig og fremragende medarbejder for konkurrenten 🙂 Og vigtigst af alt, helt straffri.
Det skal man heller ikke gøre. Men som erfaringen viser, stopper vi ikke.
Og generelt, venner, læs råd, men gør som det virker bedst for dig — for ægte opdagelser sker, når vi tvivler på allerede åbenbare sandheder. Vi ønsker jer et godt nytår, må jeres projekter være succesfulde, karrierer — interessante, kolleger og ledere — rimelige, og livet generelt lykkes. Så for det nye år og for ny kode!
Med kærlighed,
teamet RegionSoft Developer Studio
I det nye år vil vi fortsætte med at arbejde for dig og udvikle et kraftfuldt desktop CRM-system. og et enkelt og brugervenligt helpdesk og ticketsystem. .
Kilde: habr.com
