Analyse av vanlige feil gjort av nybegynnere programmerere, pt. 1

Hei Verden! Når du har lært alt du trenger å vite og endelig kommer til å jobbe som praktikant eller juniorutvikler, kan du sikkert slappe av, ikke sant? Nei. Alt begynner bare for deg... Du er omgitt av mye som er nytt og uforståelig. Hvordan kan du ikke skru den opp rett ut av porten? Det er det vi skal snakke om i dag. I denne artikkelen ønsker jeg å analysere vanlige nybegynnerfeil og gi noen råd, basert på min egen erfaring, om hvordan du kan unngå dem. Så la oss starte uten videre:

1. Frykt for å søke hjelp fra mer erfarne kolleger

Vi er alle mennesker. Vi er alle redde for å se dumme ut, spesielt i øynene til våre nye, mer erfarne kolleger. Når utviklere tar sin første jobb, blir de ofte styrt av denne frykten og trekker seg med tungt hørt tilbake i seg selv og prøver å finne ut av alt på egenhånd. I tillegg kan noen være omgitt av mer erfarne kolleger, som på sin side er i stand til å peke ham eller henne i den mest lovende retningen, og bidra til å unngå flere feil og unødvendige "hud på hodet". Så husk: ikke vær redd for å stille spørsmål. Du er en nybegynner og alle forstår dette utmerket godt. Når du spør, er det ingen som kommer til å slå deg med pinner. Kanskje til og med det motsatte vil skje: du blir raskere venner med kollegene dine og begynner å nyte mer aktiv kommunikasjon med dem. JEG' Jeg vil si enda mer: Jo mer du spør og diskuterer ulike tekniske problemer, desto raskere vil du være i stand til å miste din grønne nybegynnerhud og vokse til en ekspert på ditt felt. Og ett råd til. Ikke vær fremmed forStackOverflow . Jeg snakker spesifikt om å stille spørsmål om denne ressursen. På den ene siden tar det litt tid å få svar på spørsmålet ditt. Men på den annen side kan du raskt lære flere tilnærminger til å løse problemet ditt og se på det fra en litt annen vinkel. Jeg vil også merke meg at det er praktiske fordeler ved å skrive kommentarer/svar og skrive oppklarende spørsmål på StackOverflow-spørsmål fra andre utviklere: du får en sjanse til å debattere og gå dypere inn i problemene, for ikke å nevne en karma-boost.

2. Ikke prøver å søke etter informasjon på egen hånd

Denne feilen kan betraktes som baksiden av den forrige.Her mener jeg når du begynner å plage dine kolleger og bekjente om alle problemer eller hikke du møter. Å spørre er bra, men ikke gå over bord med spørsmål. Ellers kan folk rett og slett finne deg irriterende. Hvis du blir forvirret over noe, er det første du må gjøre å trene søkeferdighetene dine i den beste søkemotoren – Google. Noen andre har allerede støtt på det overveldende flertallet av uforståelige feil og andre problemer. Og du vil bli ganske overrasket hvis du googler spørsmålet ditt og ser hvor mange personer som er kjent med et lignende problem, og som allerede har fått uttømmende svar som du kan bruke i ditt eget arbeid. Derfor vil du ofte høre kollegene dine svare med «Google det». ikke Ikke bli fornærmet over dette svaret - din kollega er ikke din personlige lærer som må formidle alle finessene i arbeidsfeltet ditt. De endeløse vidder av Internett vil være din mentor. Noen ganger blir programmerere også referert til sompersoner med svart belte i Google-søk . Så hvis vi har en «hikke», googler vi først problemet. Hvis en løsning ikke kan bli funnet (dette er sjelden, men det skjer), først da begynner vi å spørre kolleger. Umiddelbare spørsmål er for å få råd om hvilken tilnærming du bør velge for å løse et problem mer enn hva du ville gjort når du treffer en fartsdump eller en uforståelig feilmelding. Tross alt kan de kanskje se forbi din foretrukne tilnærming og umiddelbart forutsi hvor en gitt tilnærming vil føre i det lange løp.

3. Blind kopiering og liming

Men å google problemer og deres løsninger har sine fallgruver. For eksempel blindt kopiering og liming .Dette skjer vanligvis når du finner et lignende problem (men kanskje ikke akkurat det samme) og en tilhørende løsning, for eksempel på StackOverflow. Du tar tak i denne løsningen og kopierer og limer den inn uten å fordype deg ytterligere i detaljene. Og så oppdager du eller kollegene dine noen merkelige feil eller feil oppførsel i koden din. Og ingen kan umiddelbart gjette hvor de kom fra. Etter hvert vil selvfølgelig stedet med den kopierte koden bli funnet, og du vil garantert ikke få skryt for løsningen din. Derfor, når du finner en ferdig løsning på StackOverflow (eller andre steder), må du først forstå hva, hvordan og hvorfor. Kanskje google den aktuelle funksjonaliteten og les dokumentasjonen for den. Og først etter at du har gjort det, bør du legge den til i prosjektet ditt.

4. Holder seg til feil løsning

Når du skriver en løsning, vil du noen ganger oppleve at den stadig blir mer og mer komplisert, og kommer til slutt i en blindvei. Og så prøver du å gjøre løsningen enda mer forseggjort for på en eller annen måte å få den til å fungere i stedet for å lete etter et annet, mer passende alternativ. Kanskje du føler at du har investert mye tid og krefter og derfor bestemte deg for at uansett hva du ikke vil gi opp, og du vil løse problemet med din eksisterende tilnærming. Dette er ikke helt riktig holdning. I hvert fall innen programmering. Jo før du prøver en annen tilnærming, jo mer tid sparer du til slutt. Så ikke vær redd for å eksperimentere og prøve andre tilnærminger, uavhengig av hvor lang tid du har investert i din nåværende. Dessuten, ved å prøve flere tilnærminger og dykke dypere inn i emnet,

5. Frykt for å stille spørsmål om din nåværende oppgave

Å jobbe med et programvareutviklingsprosjekt koker vanligvis ned til å utføre spesifikke oppgaver. For eksempel i Jira. Disse oppgavene er ikke alltid skissert klart og detaljert. Oppgavebeskrivelser er vanligvis skrevet av teamledere, som også er dødelige. De kan glemme å legge til noe eller unnlate å redegjøre for det faktum at du ikke er kjent med denne eller den funksjonaliteten. Eller kanskje du ikke har noen tilgang til prosjektet (for eksempel tilgang til databasen, loggserveren og så videre). Og nå har du mottatt oppgaven, studert den i mer enn et par timer, men du sitter fortsatt der og stirrer forvirret på skjermen. I stedet for å fortsette å forsøke å forstå dette uten hell, bør du begynne å be om avklaring eller veiledning fra den som har laget oppgaven. For eksempel, i appen som teamet ditt bruker for kommunikasjon (for eksempel Microsoft Teams), kan du stille spørsmål eller komme med en direkte kommentar angående oppgaven. På den ene siden, hvis du skriver spørsmålet ditt i en personlig melding, vil du sannsynligvis få svar raskere, siden personen vil se spørsmålet ditt umiddelbart. På den annen side, ved å stille et spørsmål i Jira, etablerer du bevis på at du gjør noe, nemlig å analysere problemet. Det er en måte å fremskynde denne prosessen: still spørsmålet ditt i en kommentar i Jira og deretter i en DM, slipp en lenke til kommentaren din og be om å få ta en titt.

6. Sette urealistisk høye forventninger til laglederen

Igjen, dette er baksiden av forrige punkt. Teamlederen er leder for et utviklingsteam. Som regel bruker teamlederen mesteparten av tiden sin på ulike typer kommunikasjon. Likevel skriver han eller hun også kode for ikke å glemme alt om programmering. Som du kan forstå, er livet til en teamleder veldig travelt. Å trekke i teamlederens erme hver gang du trenger å nyse vil åpenbart ikke være behagelig. Se for deg at hvert medlem av teamet bombarderer ledelsen med en haug med spørsmål. Det kan gjøre hvem som helst gal, ikke sant? Og hvis du samler på mange spørsmål, må teamlederen din bruke mye tid på å svare deg. Hva kan gjøres for å redusere antall spørsmål rettet til teamlederen:

• Utforsk prosjektdokumentasjonen mer i dybden for å redusere antall blindsoner.
• Rett spørsmålene dine til de andre teammedlemmene dine. De kan være like kjent med denne funksjonaliteten som leadet er, eller muligens enda flere, siden funksjonaliteten mest sannsynlig ble skrevet av en av dem.

Alternativt kan du se på merknadene i IDE til hvem og når koden i en bestemt linje sist ble endret. Det er nettopp slik du kan finne ut hvem som er den mest passende personen til å stille spørsmålet ditt. Som du sikkert allerede er klar over, når det kommer til spørsmål til teamlederen, akkurat som med spørsmål til kolleger, må du prøve å finne et lykkelig medium - ikke vær redd for å stille spørsmål, men heller ikke spør for mange av dem.

7. Frykt for kodevurderinger

En kodegjennomganger et slikt stadium som skjer før du sender inn koden din til en felles applikasjon (til en delt gren, for eksempel master eller dev). Denne kontrollen utføres av en utvikler som ikke er involvert i oppgaven, hvis friske øyne kan oppdage feil, unøyaktigheter eller feil i kodestilen din som gikk upåaktet hen da du først skrev koden. Hvis det er kritikk, blir det lagt igjen som kommentarer til visse deler av koden. I dette tilfellet må utvikleren som skrev koden korrigere feilene som ble identifisert i anmeldelsen (eller diskutere hans avgjørelser med anmelderen, eventuelt overbevise ham eller henne om at de er riktige). Deretter sendes koden inn til vurdering igjen og igjen til anmelderen ikke har flere kommentarer. Anmelderen fungerer som en "gateway" før koden blir begått. Utfordringen er at mange nybegynnere programmerere oppfatter kodegjennomgang som kritikk og fordømmelse. De setter ikke pris på kodeanmeldelser og er redde for dem. Det burde de ikke. Kodevurderinger er akkurat det som lar oss forbedre koden vår. Vi får tross alt viktig informasjon om hva vi gjør feil og hva som er verdt å være oppmerksom på. Du bør vurdere hver kodegjennomgang som en del av læringskurven, noe som kan hjelpe deg å bli bedre. Når noen kommenterer koden din, deler han eller hun erfaringer og beste praksis med deg. Jeg personlig tror ikke du kan bli en god programmerer uten å få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten på koden din og om en erfaren utenforstående vil peke på feil. ikke setter pris på kodeanmeldelser og er redd for dem. Det burde de ikke. Kodevurderinger er akkurat det som lar oss forbedre koden vår. Vi får tross alt viktig informasjon om hva vi gjør feil og hva som er verdt å være oppmerksom på. Du bør vurdere hver kodegjennomgang som en del av læringskurven, noe som kan hjelpe deg å bli bedre. Når noen kommenterer koden din, deler han eller hun erfaringer og beste praksis med deg. Jeg personlig tror ikke du kan bli en god programmerer uten å få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten på koden din og om en erfaren utenforstående vil peke på feil. ikke setter pris på kodeanmeldelser og er redd for dem. Det burde de ikke. Kodevurderinger er akkurat det som lar oss forbedre koden vår. Vi får tross alt viktig informasjon om hva vi gjør feil og hva som er verdt å være oppmerksom på. Du bør vurdere hver kodegjennomgang som en del av læringskurven, noe som kan hjelpe deg å bli bedre. Når noen kommenterer koden din, deler han eller hun erfaringer og beste praksis med deg. Jeg personlig tror ikke du kan bli en god programmerer uten å få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten på koden din og om en erfaren utenforstående vil peke på feil. gjør feil og hva er verdt å være oppmerksom på. Du bør vurdere hver kodegjennomgang som en del av læringskurven, noe som kan hjelpe deg å bli bedre. Når noen kommenterer koden din, deler han eller hun erfaringer og beste praksis med deg. Jeg personlig tror ikke du kan bli en god programmerer uten å få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten på koden din og om en erfaren utenforstående vil peke på feil. gjør feil og hva er verdt å være oppmerksom på. Du bør vurdere hver kodegjennomgang som en del av læringskurven, noe som kan hjelpe deg å bli bedre. Når noen kommenterer koden din, deler han eller hun erfaringer og beste praksis med deg. Jeg personlig tror ikke du kan bli en god programmerer uten å få kodeanmeldelser. Fordi du ikke engang er klar over kvaliteten på koden din og om en erfaren utenforstående vil peke på feil.

8. Tilbøyelighet til mystiske beslutninger

Ulike oppgaver/problemer kan ofte ha flere ulike løsninger. Og av alle tilgjengelige løsninger har nybegynnere en tendens til å bruke de mest komplekse og mystiske. Og det er fornuftig: nybegynnere programmerere lærte i går mange forskjellige algoritmer, mønstre og datastrukturer, så hendene deres klør etter å implementere noen av dem. Stol på meg, jeg var sånn, så jeg vet hva jeg snakker om :) Jeg hadde en situasjon der jeg implementerte noe funksjonalitet i lang tid. Det viste seg å være veldig, veldig komplisert. Deretter skrev seniorutvikler koden min om. Jeg var selvfølgelig veldig interessert i å se hva og hvordan han endret det. Jeg så på implementeringen hans og ble overrasket over hvor mye enklere det var. Og det var tre ganger mindre kode. Og utrolig nok, de automatiserte testene for denne funksjonaliteten ble ikke fjernet eller endret! Med andre ord, den generelle logikken forble den samme. Ut fra dette kom jeg frem til atde mest geniale løsningene er alltid enkle . Etter denne erkjennelsen ble koding mye enklere, og kodekvaliteten min hoppet til et betydelig høyere nivå. Så når er det verdt å bruke designmønstre og fancy algoritmer, spør du? Når du bruker dem vil være den enkleste og mest kompakte løsningen.

9. Å finne opp hjulet på nytt

Hjulet er en holdbar løsning som ble oppfunnet for lenge siden. I dette antimønsteret implementerer utvikleren sin egen proprietære løsning for et problem som allerede er løst. Noen ganger er disse eksisterende løsningene bedre enn det programmereren kommer opp med. Som regel vil det å finne opp hjulet på nytt føre til tapt tid og redusert produktivitet, fordi løsningen du finner kan være langt fra den beste, eller kanskje du ikke finner en i det hele tatt. Når det er sagt, kan vi ikke utelukke muligheten for å lage vår egen uavhengige løsning: hvis vi gjorde det, ville vi bare kopiere og lime inn programmering. Programmereren bør veiledes riktig av de spesifikke programmeringsoppgavene som oppstår for å løse dem kompetent og raskt, enten ved å bruke ferdige løsninger eller ved å lage tilpassede løsninger. På den ene siden, på universiteter og på nettkurs blir vi bombardert med ulike typer oppgaver som ser ut til å hjelpe oss å finne opp hjul på nytt. Men bare ved første øyekast: Det egentlige formålet her er å utvikle algoritmisk tenkning og en dypere beherskelse av språksyntaksen. Slike oppgaver hjelper deg også til å bedre forstå algoritmer og datastrukturer, og gir deg ferdigheter til å implementere mer sofistikerte motparter, om nødvendig (dette er noen ganger nødvendig, men det er ekstremt sjeldent). I det virkelige liv trenger du ikke å finne opp ditt eget hjul i de fleste tilfeller, siden hjul som dekker dine behov har eksistert i lang tid. Kanskje din uerfarenhet hindrer deg i å vite om eksistensen av implementeringer av funksjonaliteten du trenger. Det er her du må ta rådene gitt i det første punktet i denne artikkelen, nemlig spør mer erfarne kolleger om hjelp. De vil kunne veilede deg (for eksempel peke deg i riktig retning i Google-søket ditt) eller foreslå en spesifikk implementering (for eksempel et bibliotek).

10. Unnlatelse av å skrive prøver

Alle nybegynnere misliker å skrive tester. Men hvorfor skal vi trekke frem nybegynnere her? Mer erfarne utviklere liker heller ikke å skrive tester, men de forstår bedre hvorfor tester er nødvendig. Når du er helt grønn, lurer du på hvorfor du skal skrive dem. Alt fungerer, så det kan ikke være noen feil. Men hvordan sikrer du at endringene dine ikke ødelegger noe andre steder i systemet? Dine kolleger vil ikke sette pris på det hvis du presser inn endringer som forårsaker mer skade enn nytte. Det er her tester kommer oss til unnsetning. Jo mer en applikasjons kode dekkes av tester, jo bedre (dette kalles kodedekning eller testdekning). Hvis applikasjonen har god testdekning, kan du kjøre alle testene for å finne steder som vil bli ødelagt av koden din. Og som jeg sa i eksemplet ovenfor, da seniorutvikleren refaktoriserte koden, mislyktes ikke testene. Dette var fordi den generelle logikken ikke endret seg. Vi bruker tester for å demonstrere om logikken til visse funksjoner har endret seg eller ikke. Så selv om du ikke liker å skrive tester, er de definitivt nyttige og vel verdt tiden du bruker på dem.

11. Overdrevne kommentarer

Mange utviklere lider av perfeksjonisme, og nybegynnere er intet unntak. Noen ganger manifesterer de bare én faset av denne tilbøyeligheten når de begynner å kommentere alle og alt. Til og med å komme med kommentarer som er unødvendige, fordi koden er så åpenbar:

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

Ikke alle nybegynnere programmerere innser umiddelbart at kommentarkode ikke alltid er bra, fordi de overflødige kommentarene roter koden og gjør den vanskelig å lese. Og hva hvis koden endres, men de gamle kommentarene ikke er oppdatert? Da vil de bare villede og forvirre oss. Hvorfor i det hele tatt komme med en slik kommentar? Vanligvis trenger ikke velskrevet kode å bli kommentert , siden alt i den allerede er åpenbart og lesbart. Hvis du trenger å skrive en kommentar, har du allerede ødelagt kodens lesbarhet og prøver på en eller annen måte å rette opp situasjonen. Den beste tilnærmingen er å skrive lesbar kode fra begynnelsen, dvs. kode som ikke trenger kommentarer. Jeg kan heller ikke la være å nevne behovet for å følge korrekte navnekonvensjoner for metoder, variabler og klasser. Her er regelen min: Den beste kommentaren er enten ingen kommentar eller korrekt navn som tydelig beskriver funksjonaliteten i applikasjonen din.

12. Dårlig navngivning

Nybegynnere spiller raskt og løst i navngivningen av klasser, variabler, metoder osv. For eksempel ved å lage en klasse hvis navn ikke i det hele tatt beskriver formålet. Eller de erklærer en variabel med et kort navn, noe som x . De når ytterligere to variabler kalt n og yopprettes, blir det veldig vanskelig å huske hva x er ansvarlig for. Overfor denne situasjonen må du tenke nøye gjennom koden, analysere den under et mikroskop (kanskje ved å bruke en debugger), studere funksjonaliteten for ganske enkelt å forstå hva som skjer. Det er her de riktige navnekonvensjonene som jeg nevnte ovenfor kommer oss til hjelp. Riktige navn forbedrer kodens lesbarhet, og reduserer dermed tiden som kreves for å gjøre deg kjent med koden, fordi det er mye enklere å bruke en metode når navnet omtrent beskriver dens funksjonalitet. Alt i kode består av navn (variabler, metoder, klasser, objekter, filer osv.), så dette punktet blir veldig viktig når man skal lage korrekt, ren kode. Du bør huske at navnet skal formidle betydning, for eksempel hvorfor variabelen eksisterer, hva den gjør, og hvordan den brukes. Jeg vil merke mer enn én gang at den beste kommentaren til en variabel er å gi den et godt navn. For en dypere studie av kommentarer og korrekt navngivning, anbefaler jeg å lese de tidløse klassikerne:"Clean Code: A Handbook of Agile Software Craftsmanship" av Robert Martin . På den måten har den første delen av denne artikkelen (mine refleksjoner) kommet til en slutt. Fortsettelse følger...