Analys av vanliga misstag gjorda av nybörjare programmerare, pt. 1

Hej världen! När du har lärt dig allt du behöver veta och äntligen får jobba som praktikant eller juniordev kan du nog slappna av, eller hur? Nej. Allt har bara börjat för dig... Du är omgiven av mycket som är nytt och obegripligt. Hur skruvar man inte upp det direkt ur porten? Det är vad vi ska prata om idag. I den här artikeln vill jag analysera vanliga rookiemisstag och ge några råd, baserat på min egen erfarenhet, om hur man undviker dem. Så låt oss börja utan vidare:

1. Rädsla för att söka hjälp från mer erfarna kollegor

Vi är alla människor. Vi är alla rädda för att se dumma ut, särskilt i våra nya, mer erfarna kollegors ögon. När utvecklare tar sitt första jobb, styrs de ofta av denna rädsla och drar sig, med en tung hörsel, in i sig själva och försöker komma på allt på egen hand. Dessutom kan någon vara omgiven av mer erfarna kollegor, som i sin tur kan peka honom eller henne i den mest lovande riktningen och hjälpa till att undvika fler misstag och onödiga "bulor på huvudet". Så kom ihåg: var inte rädd för att ställa frågor. Du är nybörjare och alla förstår detta mycket väl. När du frågar kommer ingen att slå dig med käppar. Kanske kommer till och med motsatsen att hända: du blir snabbare vän med dina kollegor och börjar njuta av mer aktiv kommunikation med dem. jag' Jag kommer att säga ännu mer: ju mer du frågar och diskuterar olika tekniska frågor, desto snabbare kommer du att kunna ta bort ditt gröna nybörjarskinn och växa till en expert inom ditt område. Och ett råd till. Var inte främling förStackOverflow . Jag pratar specifikt om att ställa frågor om den här resursen. Å ena sidan tar det lite tid att få svar på din fråga. Men å andra sidan kan du snabbt lära dig flera sätt att lösa ditt problem och titta på det från en lite annan vinkel. Jag vill också notera att det finns praktiska fördelar med att skriva kommentarer/svar och skriva förtydligande frågor på StackOverflow-frågor från andra utvecklare: du får en chans att debattera och fördjupa dig i frågorna, för att inte tala om en karmaboost.

2. Att inte försöka söka information på egen hand

Detta misstag kan betraktas som baksidan av det föregående.Här menar jag när du börjar plåga dina kollegor och bekanta om varje problem eller hicka du stöter på. Att fråga är bra, men gå inte överbord med frågor. Annars kan folk helt enkelt tycka att du är irriterande. Om du blir förvirrad över något är det första du ska göra att träna dina sökkunskaper i den bästa sökmotorn – Google. Någon annan har redan stött på den överväldigande majoriteten av obegripliga fel och andra problem. Och du kommer att bli ganska förvånad om du googlar din fråga och ser hur många personer som är bekanta med ett liknande problem, och som redan har fått uttömmande svar som du kan tillämpa i ditt eget arbete. Det är därför du ofta kommer att höra dina kollegor svara med "Googla det". inte Bli inte förolämpad av det här svaret - din kollega är inte din personliga lärare som måste förmedla alla finesser i ditt arbetsområde. Internets ändlösa vidder kommer att vara din mentor. Ibland kallas programmerare också förpersoner med svart bälte i Google-sökning . Så om vi har en "hicka" googlar vi först på problemet. Om en lösning inte kan hittas (detta är sällsynt, men det händer), först då börjar vi fråga kollegor. Omedelbara frågor är för att få råd om vilket tillvägagångssätt du bör välja för att lösa ett problem mer än vad du skulle göra när du stöter på ett farthinder eller ett obegripligt felmeddelande. När allt kommer omkring kanske de kan se bortom ditt föredragna tillvägagångssätt och omedelbart förutsäga vart ett givet tillvägagångssätt kommer att leda i det långa loppet.

3. Blint kopiering och inklistring

Men att googla problem och deras lösningar har sina fallgropar. Till exempel att blint kopiera och klistra in .Detta händer vanligtvis när du hittar ett liknande problem (men kanske inte exakt samma) och en tillhörande lösning, till exempel på StackOverflow. Du tar tag i den här lösningen och kopierar och klistrar in den utan att fördjupa dig mer i detaljerna. Och sedan upptäcker du eller dina medarbetare några konstiga buggar eller felaktigt beteende i din kod. Och ingen kan direkt gissa var de kom ifrån. Så småningom kommer förstås platsen med den kopierade koden att hittas, och du kommer definitivt inte att få beröm för din lösning. Därför, när du hittar en färdig lösning på StackOverflow (eller någon annanstans), måste du först noggrant förstå vad, hur och varför. Googla på relevant funktionalitet och läs dokumentationen för den. Och först efter att du har gjort det bör du lägga till det i ditt projekt.

4. Håller fast vid fel lösning

När du skriver en lösning kommer du ibland att upptäcka att den hela tiden blir mer och mer komplicerad, för att så småningom hamna i en återvändsgränd. Och så försöker man göra lösningen ännu mer genomarbetad för att på något sätt få den att fungera istället för att leta efter ett annat, mer passande alternativ. Kanske känner du att du har investerat mycket tid och ansträngning och därför bestämt dig för att, oavsett vad, du inte kommer att ge upp och du kommer att lösa problemet med ditt befintliga tillvägagångssätt. Detta är inte riktigt rätt inställning. Åtminstone inom programmering. Ju tidigare du provar ett annat tillvägagångssätt, desto mer tid sparar du i slutändan. Så var inte rädd för att experimentera och prova andra tillvägagångssätt, oavsett hur lång tid du har investerat i din nuvarande. Vad mer är, genom att prova flera metoder och dyka djupare in i ämnet,

5. Rädsla för att ställa frågor om ditt nuvarande uppdrag

Att arbeta med ett mjukvaruutvecklingsprojekt handlar vanligtvis om att utföra specifika uppgifter. Till exempel i Jira. Dessa uppgifter beskrivs inte alltid tydligt och i detalj. Uppgiftsbeskrivningar skrivs vanligtvis av gruppledare, som också är bara dödliga. De kan glömma att lägga till något eller misslyckas med att redogöra för det faktum att du inte är bekant med den eller den funktionen. Eller så kanske du inte har någon tillgång till projektet (till exempel tillgång till databasen, loggservern och så vidare). Och nu har du fått uppgiften, studerat den i mer än ett par timmar, men du sitter fortfarande där och stirrar förvirrat på skärmen. Istället för att fortsätta att utan framgång försöka förstå detta, bör du börja be om förtydligande eller vägledning från den som skapat uppgiften. Till exempel, i appen som ditt team använder för kommunikation (till exempel Microsoft Teams), kan du ställa frågor eller göra en direkt kommentar angående uppgiften. Å ena sidan, om du skriver din fråga i ett personligt meddelande kommer du förmodligen att få svar snabbare, eftersom personen kommer att se din fråga direkt. Å andra sidan, genom att ställa en fråga i Jira, etablerar du bevis på att du gör något, nämligen att analysera problemet. Det finns ett sätt att påskynda denna process: ställ din fråga i en kommentar i Jira och sedan i ett DM, släpp en länk till din kommentar och be att få ta en titt.

6. Att sätta orealistiskt höga förväntningar på lagledaren

Återigen, detta är baksidan av föregående punkt. Teamledaren är chef för ett utvecklingsteam. Som regel lägger din teamledare större delen av sin tid på olika typer av kommunikation. Ändå skriver han eller hon också kod för att inte glömma allt om programmering. Som du kan förstå är livet för en teamledare väldigt hektiskt. Att dra i ärmen på din teamledare varje gång du behöver nysa kommer uppenbarligen inte att vara tilltalande. Föreställ dig att varje medlem i teamet bombarderar ledningen med en massa frågor. Det kan göra vem som helst galen, eller hur? Och om du samlar på dig många frågor kommer din teamledare att behöva lägga mycket tid på att svara dig. Vad kan göras för att minska antalet frågor riktade till teamledaren:

• Utforska projektdokumentationen mer djupgående för att minska antalet döda vinklar.
• Ställ dina frågor till dina andra teammedlemmar. De kan vara lika bekanta med denna funktion som leaden är, eller möjligen ännu mer, eftersom funktionen troligen skrevs av någon av dem.

Alternativt kan du titta på kommentarerna i IDE till vem och när koden i en specifik rad senast ändrades. Det är precis så du kan ta reda på vem som är den lämpligaste personen att ställa din fråga. Som du säkert redan inser, när det kommer till frågor till teamledaren, precis som med frågor till kollegor, måste du försöka hitta ett lyckligt medium — var inte rädd för att ställa frågor, men ställ inte för många av dem.

7. Rädsla för kodrecensioner

En kodgranskningär ett sådant steg som händer innan du skickar in din kod till en gemensam applikation (till en delad gren, till exempel master eller dev). Den här kontrollen utförs av en utvecklare som inte är inblandad i uppgiften, vars fräscha ögon kan upptäcka fel, felaktigheter eller brister i din kodstil som gick obemärkt förbi när du först skrev din kod. Om det finns kritik lämnas den som kommentarer till vissa delar av koden. I det här fallet måste utvecklaren som skrev koden korrigera de fel som identifierats i granskningen (eller diskutera sina beslut med granskaren, eventuellt övertyga honom eller henne om att de är korrekta). Sedan skickas koden in för granskning gång på gång tills granskaren inte har några fler kommentarer. Granskaren fungerar som en "gateway" innan koden begås. Utmaningen är att många nybörjare programmerare uppfattar kodgranskning som kritik och fördömande. De uppskattar inte kodrecensioner och är rädda för dem. Det borde de inte. Kodrecensioner är precis det som låter oss förbättra vår kod. Vi får trots allt viktig information om vad vi gör fel och vad som är värt att uppmärksamma. Du bör betrakta varje kodgranskning som en del av inlärningskurvan, något som kan hjälpa dig att bli bättre. När någon kommenterar din kod delar han eller hon erfarenheter och bästa praxis med dig. Jag personligen tror inte att du kan bli en bra programmerare utan att få kodrecensioner. Eftersom du inte ens är medveten om kvaliteten på din kod och om en erfaren utomstående skulle peka på misstag. Jag uppskattar inte kodrecensioner och är rädd för dem. Det borde de inte. Kodrecensioner är precis det som låter oss förbättra vår kod. Vi får trots allt viktig information om vad vi gör fel och vad som är värt att uppmärksamma. Du bör betrakta varje kodgranskning som en del av inlärningskurvan, något som kan hjälpa dig att bli bättre. När någon kommenterar din kod delar han eller hon erfarenheter och bästa praxis med dig. Jag personligen tror inte att du kan bli en bra programmerare utan att få kodrecensioner. Eftersom du inte ens är medveten om kvaliteten på din kod och om en erfaren utomstående skulle peka på misstag. Jag uppskattar inte kodrecensioner och är rädd för dem. Det borde de inte. Kodrecensioner är precis det som låter oss förbättra vår kod. Vi får trots allt viktig information om vad vi gör fel och vad som är värt att uppmärksamma. Du bör betrakta varje kodgranskning som en del av inlärningskurvan, något som kan hjälpa dig att bli bättre. När någon kommenterar din kod delar han eller hon erfarenheter och bästa praxis med dig. Jag personligen tror inte att du kan bli en bra programmerare utan att få kodrecensioner. Eftersom du inte ens är medveten om kvaliteten på din kod och om en erfaren utomstående skulle peka på misstag. gör fel och vad är värt att uppmärksamma. Du bör betrakta varje kodgranskning som en del av inlärningskurvan, något som kan hjälpa dig att bli bättre. När någon kommenterar din kod delar han eller hon erfarenheter och bästa praxis med dig. Jag personligen tror inte att du kan bli en bra programmerare utan att få kodrecensioner. Eftersom du inte ens är medveten om kvaliteten på din kod och om en erfaren utomstående skulle peka på misstag. gör fel och vad är värt att uppmärksamma. Du bör betrakta varje kodgranskning som en del av inlärningskurvan, något som kan hjälpa dig att bli bättre. När någon kommenterar din kod delar han eller hon erfarenheter och bästa praxis med dig. Jag personligen tror inte att du kan bli en bra programmerare utan att få kodrecensioner. Eftersom du inte ens är medveten om kvaliteten på din kod och om en erfaren utomstående skulle peka på misstag.

8. Benägenhet för svårbegripliga beslut

Olika uppgifter/problem kan ofta ha flera olika lösningar. Och av alla tillgängliga lösningar tenderar nybörjare att använda de mest komplexa och svårbegripliga. Och det är vettigt: nybörjare programmerare lärde sig igår en massa olika algoritmer, mönster och datastrukturer, så deras händer längtar efter att implementera några av dem. Lita på mig, jag var sådan, så jag vet vad jag pratar om :) Jag hade en situation där jag implementerade någon funktionalitet under en lång tid. Det visade sig vara väldigt, väldigt komplicerat. Sen skrev senior utvecklare om min kod. Naturligtvis var jag väldigt intresserad av att se vad och hur han ändrade det. Jag tittade på hans genomförande och blev förvånad över hur mycket enklare det var. Och det var tre gånger mindre kod. Och förvånansvärt nog togs de automatiska testerna för denna funktion inte bort eller ändrades! Med andra ord, den allmänna logiken förblev densamma. Av detta kom jag fram till attde mest geniala lösningarna är alltid enkla . Efter denna insikt blev kodningen mycket lättare, och min kodkvalitet hoppade till en betydligt högre nivå. Då är det värt besväret att tillämpa designmönster och snygga algoritmer, frågar du dig? När du applicerar dem kommer att vara den enklaste och mest kompakta lösningen.

9. Uppfinna hjulet på nytt

Hjulet är en hållbar lösning som uppfanns för länge sedan. I detta antimönster implementerar utvecklaren sin egen patentskyddade lösning för ett problem som redan har lösts. Ibland är dessa befintliga lösningar bättre än vad programmeraren kommer på. Som regel kommer att återuppfinna hjulet leda till förlorad tid och minskad produktivitet, eftersom lösningen du hittar kan vara långt ifrån den bästa, eller, ja, du kanske inte hittar en alls. Som sagt, vi kan inte utesluta möjligheten att skapa vår egen oberoende lösning: om vi gjorde det, skulle allt som återstår är kopiera-och-klistra programmering. Programmeraren bör styras ordentligt av de specifika programmeringsuppgifter som uppstår för att kunna lösa dem kompetent och snabbt, antingen genom att använda färdiga lösningar eller genom att skapa skräddarsydda lösningar. Å ena sidan, på universitet och i onlinekurser bombarderas vi med olika typer av uppgifter som verkar utformade för att hjälpa oss att återuppfinna hjul. Men bara vid första anblicken: Det verkliga syftet här är att utveckla algoritmiskt tänkande och en djupare behärskning av språksyntaxen. Sådana uppgifter hjälper dig också att bättre förstå algoritmer och datastrukturer, och ger dig färdigheter att implementera mer sofistikerade motsvarigheter, om det behövs (detta är ibland nödvändigt, men det är ytterst sällsynt). I verkligheten behöver du inte uppfinna ditt eget hjul i den överväldigande majoriteten av fallen, eftersom hjul som uppfyller dina behov har funnits länge. Kanske hindrar din oerfarenhet dig från att veta om existensen av implementeringar av den funktionalitet du behöver. Det är här du måste ta råden som ges i den första punkten i denna artikel, nämligen be mer erfarna kollegor om hjälp. De kommer att kunna vägleda dig (till exempel peka dig i rätt riktning i din Google-sökning) eller föreslå en specifik implementering (till exempel något bibliotek).

10. Underlåtenhet att skriva prov

Alla nybörjare ogillar att skriva tester. Men varför ska vi peka ut nybörjare här? Mer erfarna utvecklare gillar inte heller att skriva tester, men de förstår bättre varför tester behövs. När man är helt grön undrar man varför man ska skriva dem. Allt fungerar, så det kan inte vara några misstag. Men hur säkerställer du att dina ändringar inte bryter något någon annanstans i systemet? Dina kollegor kommer inte att uppskatta det om du driver in förändringar som orsakar mer skada än nytta. Det är här tester kommer till vår räddning. Ju mer en applikations kod täcks av tester, desto bättre (detta kallas kodtäckning eller testtäckning). Om applikationen har bra testtäckning kan du köra alla tester för att hitta platser som kommer att brytas av din kod. Och som jag sa i exemplet ovan, när den seniora utvecklaren refaktorerade koden misslyckades inte testerna. Detta berodde på att den allmänna logiken inte förändrades. Vi använder tester för att visa om logiken för viss funktionalitet har förändrats eller inte. Så även om du inte gillar att skriva tester är de definitivt användbara och väl värda den tid som spenderas på dem.

11. Överdrivna kommentarer

Många utvecklare lider av perfektionism, och nybörjare är inget undantag. De visar ibland bara en aspekt av denna benägenhet när de börjar kommentera alla och allt. Till och med kommentera som är onödiga, eftersom koden är så uppenbar:

Cat cat = new Cat(); // Cat object

Inte alla nybörjare programmerare inser omedelbart att det inte alltid är bra att kommentera kod, eftersom de överflödiga kommentarerna rör koden och gör den svår att läsa. Och vad händer om koden ändras, men de gamla kommentarerna inte uppdateras? Då kommer de bara att vilseleda och förvirra oss. Varför göra en sådan kommentar överhuvudtaget? Vanligtvis behöver välskriven kod inte kommenteras eftersom allt i den redan är uppenbart och läsbart. Om du behöver skriva en kommentar, så har du redan förstört kodens läsbarhet och försöker på något sätt åtgärda situationen. Det bästa sättet är att skriva läsbar kod från början, dvs kod som inte behöver kommentarer. Jag kan inte heller låta bli att nämna behovet av att följa korrekta namnkonventioner för metoder, variabler och klasser. Här är min regel: Den bästa kommentaren är antingen ingen kommentar eller korrekt namngivning som tydligt beskriver funktionaliteten i din applikation.

12. Dåligt namn

Nybörjare spelar snabbt och löst i sina namngivningar av klasser, variabler, metoder etc. Till exempel genom att skapa en klass vars namn inte alls beskriver dess syfte. Eller de deklarerar en variabel med ett kort namn, ungefär som x . De när ytterligare två variabler benämnda n och yskapas blir det väldigt svårt att komma ihåg vad x är ansvarig för. Inför denna situation måste du tänka noga på koden, analysera den under ett mikroskop (kanske med en debugger), studera funktionaliteten för att helt enkelt förstå vad som händer. Det är här de korrekta namnkonventionerna som jag nämnde ovan kommer till vår hjälp. Korrekta namn förbättrar kodens läsbarhet, vilket minskar tiden som krävs för att bekanta dig med koden, eftersom det är mycket lättare att använda en metod när dess namn ungefär beskriver dess funktionalitet. Allt i kod består av namn (variabler, metoder, klasser, objekt, filer etc.), så denna punkt blir väldigt viktig när man skapar korrekt, ren kod. Du bör komma ihåg att namnet ska förmedla betydelse, till exempel varför variabeln finns, vad den gör, och hur det används. Jag kommer att notera mer än en gång att den bästa kommentaren för en variabel är att ge den ett bra namn. För en djupare studie av kommentarer och korrekt namngivning rekommenderar jag att läsa de tidlösa klassikerna:"Clean Code: A Handbook of Agile Software Craftsmanship" av Robert Martin . På det sättet har den första delen av denna artikel (mina reflektioner) tagit slut. Fortsättning följer...