Analyse af almindelige fejl begået af uerfarne programmører, pt. 1

Hej Verden! Når du har lært alt, hvad du har brug for at vide og endelig kommer til at arbejde som praktikant eller junior dev, kan du sikkert slappe af, ikke? Nix. Alt er lige begyndt for dig... Du er omgivet af meget, der er nyt og uforståeligt. Hvordan skruer du det op lige ud af porten? Det er det, vi skal tale om i dag. I denne artikel vil jeg analysere almindelige rookie-fejl og give nogle råd, baseret på min egen erfaring, om, hvordan man undgår dem. Så lad os starte uden videre:

1. Frygt for at søge hjælp hos mere erfarne kollegaer

Vi er alle mennesker. Vi er alle bange for at se dumme ud, især i vores nye, mere erfarne kollegaers øjne. Når udviklere tager deres første job, bliver de ofte styret af denne frygt og trækker sig med tungt hørt tilbage i sig selv og prøver at finde ud af alt på egen hånd. Derudover kan nogen være omgivet af mere erfarne kollegaer, som til gengæld er i stand til at pege ham eller hende i den mest lovende retning, hvilket hjælper med at undgå flere fejl og unødvendige "buler på hovedet". Så husk: vær ikke bange for at stille spørgsmål. Du er nybegynder, og alle forstår dette udmærket. Når du spørger, er der ingen, der vil slå dig med pinde. Måske vil endda det modsatte ske: du bliver hurtigere venner med dine kolleger og begynder at nyde mere aktiv kommunikation med dem. JEG' Jeg vil sige endnu mere: Jo mere du spørger og diskuterer forskellige tekniske spørgsmål, jo hurtigere vil du være i stand til at afgive din grønne nybegynderhud og vokse til en ekspert på dit område. Og endnu et råd. Vær ikke fremmed forStackOverflow . Jeg taler specifikt om at stille spørgsmål om denne ressource. På den ene side tager det lidt tid at få svar på dit spørgsmål. Men på den anden side kan du hurtigt lære flere tilgange til at løse dit problem og se på det fra en lidt anden vinkel. Jeg vil også bemærke, at der er praktiske fordele ved at skrive kommentarer/svar og skrive afklarende spørgsmål på StackOverflow-spørgsmål fra andre udviklere: du får en chance for at debattere og dykke dybere ned i problemerne, for ikke at nævne et karma-boost.

2. Ikke at forsøge at søge efter information på egen hånd

Denne fejl kan betragtes som bagsiden af ​​den forrige.Her mener jeg, når du begynder at plage dine kolleger og bekendte om ethvert problem eller hikke, du støder på. Det er godt at spørge, men gå ikke overbord med spørgsmål. Ellers kan folk simpelthen finde dig irriterende. Hvis du bliver forvirret over noget, er den første ting at gøre at træne dine søgeevner i den bedste søgemaskine – Google. En anden er allerede stødt på det overvældende flertal af uforståelige fejl og andre problemer. Og du vil blive ret overrasket, hvis du googler dit spørgsmål og ser antallet af personer, der kender til et lignende problem, og som allerede har fået udtømmende svar, som du kan anvende i dit eget arbejde. Derfor vil du ofte høre dine kolleger svare med "Google det". ikke ikke blive fornærmet over dette svar - din kollega er ikke din personlige lærer, der skal formidle alle finesserne i dit arbejdsfelt. Internettets endeløse vidder vil være din mentor. Nogle gange omtales programmører også sompersoner med sort bælte i Google-søgning . Så hvis vi har et "hikke", googler vi først problemet. Hvis en løsning ikke kan findes (det er sjældent, men det sker), først da begynder vi at spørge kollegerne. Umiddelbare spørgsmål er for at få råd om, hvilken tilgang du skal vælge for at løse et problem mere, end hvad du ville gøre, når du rammer et fartbump eller en uforståelig fejlmeddelelse. Når alt kommer til alt, kan de måske se ud over din foretrukne tilgang og umiddelbart forudsige, hvor en given tilgang vil føre hen i det lange løb.

3. Blind kopiering og indsættelse

Men at google problemer og deres løsninger har sine faldgruber. For eksempel blindt kopiering og indsættelse .Dette sker normalt, når du finder et lignende problem (men måske ikke helt det samme) og en tilhørende løsning, for eksempel på StackOverflow. Du griber denne løsning og kopierer og indsætter den uden at dykke yderligere ned i detaljerne. Og så opdager du eller dine kolleger nogle mærkelige fejl eller forkert adfærd i din kode. Og ingen kan umiddelbart gætte, hvor de kom fra. Til sidst vil stedet med den kopierede kode selvfølgelig blive fundet, og du får bestemt ikke ros for din løsning. Derfor, når du finder en færdiglavet løsning på StackOverflow (eller andre steder), skal du først grundigt forstå hvad, hvordan og hvorfor. Måske google den relevante funktionalitet og læs dokumentationen til det. Og først efter du har gjort det, skal du tilføje det til dit projekt.

4. Holder sig til den forkerte løsning

Når du skriver en løsning, vil du nogle gange opleve, at den hele tiden bliver mere og mere kompliceret, for til sidst at komme i en blindgyde. Og så forsøger man at gøre løsningen endnu mere udførlig for på en eller anden måde at få den til at fungere i stedet for at lede efter et andet, mere passende alternativ. Måske føler du, at du har investeret en masse tid og kræfter og derfor har besluttet dig for, at uanset hvad, vil du ikke give op, og du vil løse problemet med din eksisterende tilgang. Det er ikke helt den rigtige holdning. I hvert fald i programmering. Jo før du prøver en anden tilgang, jo mere tid sparer du i sidste ende. Så vær ikke bange for at eksperimentere og prøve andre tilgange, uanset hvor lang tid du har investeret i din nuværende. Hvad mere er, ved at prøve flere tilgange og dykke dybere ned i emnet,

5. Frygt for at stille spørgsmål til din nuværende opgave

At arbejde på et softwareudviklingsprojekt bunder normalt i at udføre specifikke opgaver. For eksempel i Jira. Disse opgaver er ikke altid skitseret klart og detaljeret. Opgavebeskrivelser er normalt skrevet af teamledere, som også er dødelige. De kan glemme at tilføje noget eller undlade at redegøre for, at du ikke er bekendt med denne eller hin funktionalitet. Eller måske har du ingen adgang til projektet (f.eks. adgang til databasen, logserveren og så videre). Og nu har du modtaget opgaven, studeret den i mere end et par timer, men du sidder der stadig og stirrer forvirret på skærmen. I stedet for at fortsætte med at forsøge at forstå dette uden held, bør du begynde at bede om afklaring eller vejledning fra den, der har lavet opgaven. I den app, som dit team bruger til kommunikation (for eksempel Microsoft Teams), kan du for eksempel stille spørgsmål eller komme med en direkte kommentar til opgaven. På den ene side, hvis du skriver dit spørgsmål i en personlig besked, vil du sandsynligvis få et svar hurtigere, da personen vil se dit spørgsmål med det samme. På den anden side, ved at stille et spørgsmål i Jira, etablerer du bevis for, at du gør noget, nemlig at analysere problemet. Der er en måde at fremskynde denne proces: Stil dit spørgsmål i en kommentar i Jira og derefter i en DM, smid et link til din kommentar og bed om at se.

6. At stille urealistisk høje forventninger til holdlederen

Igen, dette er bagsiden af ​​det foregående punkt. Teamlederen er leder af et udviklingsteam. Som regel bruger din teamleder det meste af sin tid på forskellige former for kommunikation. Alligevel skriver han eller hun også kode for ikke at glemme alt om programmering. Som du kan forstå, er livet for en teamleder meget travlt. At trække i ærmet på din holdleder, hver gang du skal nyse, vil naturligvis ikke være behageligt. Forestil dig, at hvert medlem af holdet bombarderer føringen med en masse spørgsmål. Det kunne gøre enhver til vanvid, ikke? Og hvis du bunker med mange spørgsmål, så skal din teamleder bruge meget tid på at svare dig. Hvad kan der gøres for at reducere antallet af spørgsmål rettet til teamlederen:

• Udforsk projektdokumentationen mere i dybden for at reducere antallet af blinde vinkler.
• Ret dine spørgsmål til dine andre teammedlemmer. De kan være lige så fortrolige med denne funktionalitet, som leadet er, eller muligvis endnu mere, da funktionaliteten højst sandsynligt er skrevet af en af ​​dem.

Alternativt kan du se på annoteringerne i IDE'en til, hvem og hvornår koden i en bestemt linje sidst blev ændret. Netop sådan kan du finde ud af, hvem der er den bedst egnede til at stille dit spørgsmål. Som du sikkert allerede er klar over, skal du, når det kommer til spørgsmål til teamlederen, ligesom med spørgsmål til kolleger, forsøge at finde et glad medie - vær ikke bange for at stille spørgsmål, men spørg heller ikke for mange af dem.

7. Frygt for kodegennemgange

En kodegennemganger sådan et trin, der sker, før du sender din kode til en fælles applikation (til en delt filial, f.eks. master eller dev). Dette tjek udføres af en udvikler, som ikke er involveret i opgaven, hvis friske øjne kan opdage fejl, unøjagtigheder eller fejl i din kodestil, som gik ubemærket hen, da du oprindeligt skrev din kode. Hvis der er kritik, efterlades de som kommentarer til visse dele af koden. I dette tilfælde skal udvikleren, der har skrevet koden, rette de fejl, der er identificeret i anmeldelsen (eller diskutere sine beslutninger med anmelderen, eventuelt overbevise ham eller hende om, at de er korrekte). Derefter sendes koden til gennemgang igen og igen, indtil anmelderen ikke har flere kommentarer. Anmelderen fungerer som en "gateway", før koden er begået. Udfordringen er, at mange uerfarne programmører opfatter kodegennemgang som kritik og fordømmelse. De sætter ikke pris på kodeanmeldelser og er bange for dem. Det burde de ikke. Kodeanmeldelser er præcis det, der lader os forbedre vores kode. Vi modtager trods alt vigtig information om, hvad vi gør forkert, og hvad der er værd at være opmærksom på. Du bør overveje hver kodegennemgang som en del af indlæringskurven, noget der kan hjælpe dig med at blive bedre. Når nogen kommenterer din kode, deler han eller hun erfaringer og bedste praksis med dig. Jeg tror personligt ikke på, at du kan blive en god programmør uden at få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten af ​​din kode, og om en erfaren udenforstående ville pege på fejl. Jeg sætter ikke pris på kodeanmeldelser og er bange for dem. Det burde de ikke. Kodeanmeldelser er præcis det, der lader os forbedre vores kode. Vi modtager trods alt vigtig information om, hvad vi gør forkert, og hvad der er værd at være opmærksom på. Du bør overveje hver kodegennemgang som en del af indlæringskurven, noget der kan hjælpe dig med at blive bedre. Når nogen kommenterer din kode, deler han eller hun erfaringer og bedste praksis med dig. Jeg tror personligt ikke på, at du kan blive en god programmør uden at få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten af ​​din kode, og om en erfaren udenforstående ville pege på fejl. Jeg sætter ikke pris på kodeanmeldelser og er bange for dem. Det burde de ikke. Kodeanmeldelser er præcis det, der lader os forbedre vores kode. Vi modtager trods alt vigtig information om, hvad vi gør forkert, og hvad der er værd at være opmærksom på. Du bør overveje hver kodegennemgang som en del af indlæringskurven, noget der kan hjælpe dig med at blive bedre. Når nogen kommenterer din kode, deler han eller hun erfaringer og bedste praksis med dig. Jeg tror personligt ikke på, at du kan blive en god programmør uden at få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten af ​​din kode, og om en erfaren udenforstående ville pege på fejl. gør forkert, og hvad er værd at være opmærksom på. Du bør overveje hver kodegennemgang som en del af indlæringskurven, noget der kan hjælpe dig med at blive bedre. Når nogen kommenterer din kode, deler han eller hun erfaringer og bedste praksis med dig. Jeg tror personligt ikke på, at du kan blive en god programmør uden at få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten af ​​din kode, og om en erfaren udenforstående ville pege på fejl. gør forkert, og hvad er værd at være opmærksom på. Du bør overveje hver kodegennemgang som en del af indlæringskurven, noget der kan hjælpe dig med at blive bedre. Når nogen kommenterer din kode, deler han eller hun erfaringer og bedste praksis med dig. Jeg tror personligt ikke på, at du kan blive en god programmør uden at få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten af ​​din kode, og om en erfaren udenforstående ville pege på fejl.

8. Tilbøjelighed til mystiske beslutninger

Forskellige opgaver/problemer kan ofte have flere forskellige løsninger. Og ud af alle de tilgængelige løsninger har begyndere en tendens til at bruge de mest komplekse og mystiske. Og det giver mening: begyndere programmører lærte i går en masse forskellige algoritmer, mønstre og datastrukturer, så deres hænder klør efter at implementere nogle af dem. Tro mig, jeg var sådan, så jeg ved, hvad jeg taler om :) Jeg havde en situation, hvor jeg implementerede noget funktionalitet i lang tid. Det viste sig at være meget, meget kompliceret. Derefter omskrev seniorudvikler min kode. Jeg var selvfølgelig meget interesseret i at se, hvad og hvordan han ændrede det. Jeg så på hans implementering og var overrasket over, hvor meget enklere det var. Og der var tre gange mindre kode. Og forbløffende nok blev de automatiske test for denne funktionalitet ikke fjernet eller ændret! Med andre ord forblev den generelle logik den samme. Ud fra dette kom jeg til den konklusion, atde mest geniale løsninger er altid enkle . Efter denne erkendelse blev kodning meget lettere, og min kodekvalitet sprang til et væsentligt højere niveau. Hvornår er det så umagen værd at anvende designmønstre og smarte algoritmer, spørger du? Når du anvender dem, vil det være den enkleste og mest kompakte løsning.

9. Genopfinde hjulet

Hjulet er en holdbar løsning, der er opfundet for længe siden. I dette anti-mønster implementerer udvikleren sin egen proprietære løsning på et problem, der allerede er løst. Nogle gange er disse eksisterende løsninger bedre end hvad programmøren kommer med. Som regel vil genopfinde hjulet føre til tabt tid og nedsat produktivitet, fordi den løsning, du finder, kan være langt fra den bedste, eller ja, du kan slet ikke finde en. Når det er sagt, kan vi ikke udelukke muligheden for at skabe vores egen uafhængige løsning: hvis vi gjorde det, ville der kun være kopier-og-indsæt programmering. Programmøren bør styres ordentligt af de specifikke programmeringsopgaver, der opstår for at løse dem kompetent og hurtigt, hvad enten det er ved at bruge færdige løsninger eller ved at skabe skræddersyede løsninger. På den ene side, på universiteter og i onlinekurser bliver vi bombarderet med forskellige slags opgaver, der ser ud til at hjælpe os med at genopfinde hjul. Men kun ved første øjekast: Det egentlige formål her er at udvikle algoritmisk tænkning og en dybere beherskelse af sprogsyntaksen. Sådanne opgaver hjælper dig også til bedre at forstå algoritmer og datastrukturer og giver dig færdigheder til at implementere mere sofistikerede modparter, hvis det er nødvendigt (dette er nogle gange nødvendigt, men det er yderst sjældent). I det virkelige liv behøver du ikke at opfinde dit eget hjul i langt de fleste tilfælde, da hjul, der opfylder dine behov, har eksisteret i lang tid. Måske forhindrer din uerfarenhed dig i at vide, om der findes implementeringer af den funktionalitet, du har brug for. Det er her, du skal tage rådene givet i det første punkt i denne artikel, nemlig spørg mere erfarne kollegaer om hjælp. De vil være i stand til at vejlede dig (f.eks. pege dig i den rigtige retning i din Google-søgning) eller foreslå en specifik implementering (f.eks. et bibliotek).

10. Manglende skrivning af prøver

Alle nybegyndere kan ikke lide at skrive test. Men hvorfor skulle vi fremhæve nybegyndere her? Mere erfarne udviklere bryder sig heller ikke om at skrive test, men de forstår bedre, hvorfor der er behov for tests. Når du er helt grøn, undrer du dig over, hvorfor du skal skrive dem. Alt fungerer, så der kan ikke være nogen fejl. Men hvordan sikrer du, at dine ændringer ikke ødelægger noget andre steder i systemet? Dine kolleger vil ikke sætte pris på det, hvis du skubber til ændringer, der forårsager mere skade end gavn. Det er her, test kommer os til undsætning. Jo mere en applikations kode er dækket af test, jo bedre (dette kaldes kodedækning eller testdækning). Hvis applikationen har god testdækning, så kan du køre alle testene for at finde steder, der bliver ødelagt af din kode. Og som jeg sagde i eksemplet ovenfor, da seniorudvikleren refaktorerede koden, fejlede testene ikke. Dette skyldtes, at den generelle logik ikke ændrede sig. Vi bruger test til at demonstrere, om logikken i visse funktioner er ændret eller ej. Så selvom du ikke kan lide at skrive test, er de bestemt nyttige og værd at bruge tid på dem.

11. Overdrevne kommentarer

Mange udviklere lider af perfektionisme, og nybegyndere er ingen undtagelse. De viser nogle gange kun én facet af denne tilbøjelighed, når de begynder at kommentere på alt og alle. Selv at komme med kommentarer, der er unødvendige, fordi koden er så indlysende:

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

Ikke alle nybegyndere indser umiddelbart, at det ikke altid er godt at kommentere kode, fordi de overflødige kommentarer roder koden og gør den svær at læse. Og hvad hvis koden ændres, men de gamle kommentarer ikke opdateres? Så vil de kun vildlede og forvirre os. Hvorfor så overhovedet komme med sådan en kommentar? Normalt behøver velskrevet kode ikke at blive kommenteret , da alt i den allerede er indlysende og læsbar. Hvis du har brug for at skrive en kommentar, så har du allerede ødelagt kodens læsbarhed og forsøger på en eller anden måde at afhjælpe situationen. Den bedste fremgangsmåde er at skrive læsbar kode fra starten, dvs. kode, der ikke behøver kommentarer. Jeg kan heller ikke lade være med at nævne behovet for at følge korrekte navngivningskonventioner for metoder, variabler og klasser. Her er min regel: Den bedste kommentar er enten ingen kommentar eller korrekt navngivning, der tydeligt beskriver funktionaliteten i din applikation.

12. Dårlig navngivning

Nybegyndere spiller hurtigt og løst i deres navngivning af klasser, variabler, metoder osv. For eksempel ved at skabe en klasse, hvis navn slet ikke beskriver dens formål. Eller de erklærer en variabel med et kort navn, noget som x . De når yderligere to variable kaldet n og yer skabt, bliver det meget svært at huske, hvad x er ansvarlig for. Stillet over for denne situation skal du tænke grundigt over koden, analysere den under et mikroskop (måske ved hjælp af en debugger), studere funktionaliteten for blot at forstå, hvad der sker. Det er her, de korrekte navnekonventioner, som jeg nævnte ovenfor, kommer os til hjælp. Korrekte navne forbedrer kodens læsbarhed og reducerer dermed den tid, det tager at sætte sig ind i koden, fordi det er meget nemmere at bruge en metode, når dens navn tilnærmelsesvis beskriver dens funktionalitet. Alt i kode består af navne (variabler, metoder, klasser, objekter, filer osv.), så dette punkt bliver meget vigtigt, når man laver korrekt, ren kode. Du skal huske, at navnet skal formidle betydning, for eksempel hvorfor variablen eksisterer, hvad den gør, og hvordan det bruges. Jeg vil bemærke mere end én gang, at den bedste kommentar til en variabel er at give den et godt navn. For en dybere undersøgelse af kommentarer og korrekt navngivning anbefaler jeg at læse de tidløse klassikere:"Clean Code: A Handbook of Agile Software Craftsmanship" af Robert Martin . På den baggrund er første del af denne artikel (mine overvejelser) afsluttet. Fortsættes...