Analiza greșelilor comune făcute de programatorii începători, pct. 1

Salut Lume! Odată ce ai învățat tot ce trebuie să știi și, în sfârșit, ai început să lucrezi ca stagiar sau dev junior, probabil că te poți relaxa, nu? Nu. Totul abia începe pentru tine... Ești înconjurat de multe lucruri noi și de neînțeles. Cum să nu-l stricați imediat din poartă? Despre asta vom vorbi astăzi. În acest articol, vreau să analizez greșelile comune ale începătorilor și să dau câteva sfaturi, bazate pe propria mea experiență, despre cum să le evit. Așadar, să începem fără nicio altă problemă:

1. Frica de a căuta ajutor de la colegii mai experimentați

Cu toții suntem oameni. Tuturor ne este frică să nu arătăm proști, mai ales în ochii noilor noștri colegi, mai experimentați. Când dezvoltatorii își iau primul loc de muncă, ei sunt adesea ghidați de această frică și, cu o auz greu, se retrag în ei înșiși, încercând să-și dea seama totul singuri. În plus, cineva poate fi înconjurat de colegi mai experimentați, care, la rândul lor, sunt capabili să-l îndrepte în direcția cea mai promițătoare, ajutând să evite mai multe greșeli și „denivelări” inutile pe cap. Așa că nu uitați: nu vă fie frică să puneți întrebări. Ești începător și toată lumea înțelege acest lucru perfect. Când întrebi, nimeni nu te va bate cu bastoanele. Poate că se va întâmpla chiar și opusul: te vei împrieteni mai repede cu colegii tăi și vei începe să te bucuri de o comunicare mai activă cu ei. eu Voi spune și mai mult: cu cât întrebați și discutați mai multe probleme tehnice, cu atât mai repede vă veți putea renunța la pielea verde de începător și veți deveni un expert în domeniul dvs. Și încă un sfat. Nu fi străin deStackOverflow . Mă refer în special la adresarea întrebărilor despre această resursă. Pe de o parte, este nevoie de ceva timp pentru a obține un răspuns la întrebarea dvs. Dar, pe de altă parte, este posibil să înveți rapid mai multe abordări pentru a-ți rezolva problema și să o privești dintr-un unghi ușor diferit. De asemenea, vreau să observ că există beneficii practice în a scrie comentarii/răspunsuri și a scrie întrebări clarificatoare la întrebările StackOverflow de la alți dezvoltatori: aveți șansa de a dezbate și a aprofunda problemele, ca să nu mai vorbim de un impuls de karma.

2. Nu încercați să căutați informații pe cont propriu

Această greșeală ar putea fi considerată reversul celei anterioare.Aici mă refer la momentul în care începi să-ți deranjezi colegii și cunoștințele cu privire la fiecare problemă sau sughiț pe care îl întâlnești. A întreba este bine, dar nu exagera cu întrebările. În caz contrar, oamenii te pot considera pur și simplu enervant. Dacă te încurci în legătură cu ceva, primul lucru de făcut este să-ți exersezi abilitățile de căutare în cel mai bun motor de căutare — Google. Altcineva s-a confruntat deja cu majoritatea covârșitoare a erorilor de neînțeles și a altor probleme. Și veți fi destul de surprins dacă vă căutați pe google întrebarea și vedeți numărul de oameni care sunt familiarizați cu o problemă similară și care au primit deja răspunsuri exhaustive pe care le puteți aplica în propria muncă. De aceea, veți auzi adesea colegii răspunzând cu „Google it”. Don' Nu fi jignit de acest răspuns - colegul tău nu este profesorul tău personal care trebuie să transmită toate subtilitățile domeniului tău de activitate. Întinderile nesfârșite ale internetului vor fi mentorul tău. Uneori, programatorii sunt denumiți și capersoane cu centură neagră în căutarea Google . Deci, dacă avem un „sughiț”, mai întâi căutăm problema pe google. Dacă nu se găsește o soluție (asta este rar, dar se întâmplă), abia atunci începem să întrebăm colegii. Întrebările imediate sunt pentru a obține sfaturi despre ce abordare ar trebui să alegeți pentru a rezolva o problemă mai mult decât ceea ce ați face atunci când vă atingeți de o viteză sau un mesaj de eroare de neînțeles. La urma urmei, ei ar putea să vadă dincolo de abordarea preferată și să prezică imediat unde va duce orice abordare dată pe termen lung.

3. Copierea și lipirea orbește

Dar găsirea pe Google a problemelor și a soluțiilor lor are capcanele sale. De exemplu, copierea și lipirea orbește .Acest lucru se întâmplă de obicei atunci când găsiți o problemă similară (dar poate nu tocmai aceeași) și o soluție asociată, de exemplu, pe StackOverflow. Prindeți această soluție și o copiați și lipiți fără a mai aprofunda detalii. Și apoi tu sau colegii tăi descoperi niște erori ciudate sau comportament incorect în codul tău. Și nimeni nu poate ghici imediat de unde au venit. În cele din urmă, desigur, locul cu codul copiat va fi găsit și cu siguranță nu vei fi lăudat pentru soluția ta. Prin urmare, atunci când găsiți o soluție gata făcută pe StackOverflow (sau oriunde altundeva), trebuie mai întâi să înțelegeți temeinic ce, cum și de ce. Poate căutați pe Google funcționalitatea relevantă și citiți documentația pentru aceasta. Și numai după ce ai făcut asta ar trebui să-l adaugi la proiectul tău.

4. Rămâi cu soluția greșită

Când scrieți o soluție, veți constata uneori că aceasta devine constant din ce în ce mai complicată, ajungând în cele din urmă într-o fundătură. Și apoi încerci să faci soluția și mai elaborată pentru a o face cumva să funcționeze în loc să cauți o altă alternativă, mai potrivită. Poate simți că ai investit mult timp și efort și, prin urmare, ai decis că, indiferent de ce, nu vei renunța și vei rezolva problema cu abordarea existentă. Aceasta nu este atitudinea corectă. Cel putin in programare. Cu cât încerci mai devreme o abordare diferită, cu atât vei economisi mai mult timp în cele din urmă. Așa că nu vă fie teamă să experimentați și să încercați alte abordări, indiferent de timpul pe care l-ați investit în cea actuală. În plus, încercând abordări multiple și scufundându-te mai profund în subiect,

5. Frica de a pune întrebări despre misiunea ta curentă

Lucrul la un proiect de dezvoltare software se rezumă de obicei la îndeplinirea unor sarcini specifice. De exemplu, în Jira. Aceste sarcini nu sunt întotdeauna descrise clar și în detaliu. Descrierile sarcinilor sunt de obicei scrise de liderii de echipă, care sunt, de asemenea, simpli muritori. Este posibil să uite să adauge ceva sau să nu țină seama de faptul că nu ești familiarizat cu această sau cutare funcționalitate. Sau poate nu aveți acces la proiect (de exemplu, acces la baza de date, serverul de jurnal și așa mai departe). Și acum, ați primit sarcina, ați studiat-o mai mult de câteva ore, dar încă stați acolo, uitându-vă la ecran uluit. În loc să continuați să încercați fără succes să înțelegeți acest lucru, ar trebui să începeți să cereți clarificări sau îndrumări de la cel care a creat sarcina. De exemplu, în aplicația pe care echipa ta o folosește pentru comunicare (de exemplu, Microsoft Teams), poți să pui întrebări sau să faci un comentariu direct cu privire la sarcină. Pe de o parte, dacă îți scrii întrebarea într-un mesaj personal, probabil vei primi un răspuns mai repede, deoarece persoana va vedea întrebarea ta imediat. Pe de altă parte, punând o întrebare în Jira, stabilești dovada că faci ceva, și anume, analizezi problema. Există o modalitate de a accelera acest proces: adresați-vă întrebarea într-un comentariu în Jira și apoi într-un DM, lăsați un link către comentariul dvs. și cereți să aruncați o privire.

6. Plasarea așteptărilor nereal de mari asupra conducerii echipei

Din nou, aceasta este reversul punctului anterior. Conducătorul echipei este șeful unei echipe de dezvoltare. De regulă, liderul echipei dumneavoastră își petrece cea mai mare parte a timpului pe diverse tipuri de comunicare. Cu toate acestea, el sau ea scrie și cod pentru a nu uita totul despre programare. După cum puteți înțelege, viața unui lider de echipă este foarte ocupată. Să tragi de mâneca liderului echipei de fiecare dată când trebuie să strănuți, evident, nu va fi plăcut. Imaginați-vă că fiecare membru al echipei bombardează liderul cu o grămadă de întrebări. Asta ar putea înnebuni pe oricine, nu? Și dacă adunați o mulțime de întrebări, atunci liderul echipei dvs. va trebui să petreacă mult timp răspunzându-vă. Ce se poate face pentru a reduce numărul de întrebări adresate liderului echipei:

• Explorați documentația proiectului mai detaliat pentru a reduce numărul de puncte moarte.
• Dirijați întrebările către ceilalți membri ai echipei. Ei pot fi la fel de familiarizați cu această funcționalitate precum este liderul sau poate chiar mai mult, deoarece funcționalitatea a fost cel mai probabil scrisă de unul dintre ei.

Alternativ, puteți să vă uitați la adnotările din IDE pentru cine și când a fost modificat ultima dată codul dintr-o anumită linie. Tocmai așa poți afla cine este persoana cea mai potrivită pentru a-ți pune întrebarea. După cum probabil îți dai seama deja, atunci când vine vorba de întrebările adresate șefului echipei, la fel ca și în cazul întrebărilor adresate colegilor, trebuie să încerci să găsești un mediu fericit - nu-ți fie teamă să pui întrebări, dar nici prea multe dintre ei.

7. Frica de recenzii de cod

O revizuire a coduluieste o astfel de etapă care are loc înainte de a trimite codul la o aplicație comună (la o ramură partajată, de exemplu, master sau dev). Această verificare este efectuată de un dezvoltator care nu este implicat în sarcină, ai cărui ochi proaspeți pot detecta erori, inexactități sau defecte în stilul dvs. de cod care au trecut neobservate atunci când ați scris inițial codul. Dacă există critici, acestea sunt lăsate ca comentarii asupra anumitor părți ale codului. În acest caz, dezvoltatorul care a scris codul trebuie să corecteze erorile identificate în recenzie (sau să discute deciziile sale cu examinatorul, eventual convingându-l că sunt corecte). Apoi codul este trimis spre revizuire din nou și din nou, până când examinatorul nu mai are comentarii. Revizorul acționează ca un „gateway” înainte ca codul să fie comis. Provocarea este că mulți programatori începători percep revizuirea codului ca o critică și condamnare. Nu apreciază recenziile de cod și se tem de ele. Nu ar trebui. Recenziile de cod sunt exact ceea ce ne permite să ne îmbunătățim codul. La urma urmei, primim informații importante despre ceea ce facem greșit și la ce merită să fim atenți. Ar trebui să considerați fiecare revizuire a codului ca parte a curbei de învățare, ceva care vă poate ajuta să vă îmbunătățiți. Când cineva comentează codul dvs., el sau ea vă împărtășesc experiența și cele mai bune practici. Eu personal nu cred că poți deveni un programator bun fără a primi recenzii de cod. Pentru că nici măcar nu ești conștient de calitatea codului tău și dacă un străin experimentat ar indica greșeli. nu apreciez recenziile de cod și mi-e frică de ele. Nu ar trebui. Recenziile de cod sunt exact ceea ce ne permite să ne îmbunătățim codul. La urma urmei, primim informații importante despre ceea ce facem greșit și la ce merită să fim atenți. Ar trebui să considerați fiecare revizuire a codului ca parte a curbei de învățare, ceva care vă poate ajuta să vă îmbunătățiți. Când cineva comentează codul dvs., el sau ea vă împărtășesc experiența și cele mai bune practici. Eu personal nu cred că poți deveni un programator bun fără a primi recenzii de cod. Pentru că nici măcar nu ești conștient de calitatea codului tău și dacă un străin experimentat ar indica greșeli. nu apreciez recenziile de cod și mi-e frică de ele. Nu ar trebui. Recenziile de cod sunt exact ceea ce ne permite să ne îmbunătățim codul. La urma urmei, primim informații importante despre ceea ce facem greșit și la ce merită să fim atenți. Ar trebui să considerați fiecare revizuire a codului ca parte a curbei de învățare, ceva care vă poate ajuta să vă îmbunătățiți. Când cineva comentează codul dvs., el sau ea vă împărtășesc experiența și cele mai bune practici. Eu personal nu cred că poți deveni un programator bun fără a primi recenzii de cod. Pentru că nici măcar nu ești conștient de calitatea codului tău și dacă un străin experimentat ar indica greșeli. faci greșit și la ce merită să fii atent. Ar trebui să considerați fiecare revizuire a codului ca parte a curbei de învățare, ceva care vă poate ajuta să vă îmbunătățiți. Când cineva comentează codul dvs., el sau ea vă împărtășesc experiența și cele mai bune practici. Eu personal nu cred că poți deveni un programator bun fără a primi recenzii de cod. Pentru că nici măcar nu ești conștient de calitatea codului tău și dacă un străin experimentat ar indica greșeli. faci greșit și la ce merită să fii atent. Ar trebui să considerați fiecare revizuire a codului ca parte a curbei de învățare, ceva care vă poate ajuta să vă îmbunătățiți. Când cineva comentează codul dvs., el sau ea vă împărtășesc experiența și cele mai bune practici. Eu personal nu cred că poți deveni un programator bun fără a primi recenzii de cod. Pentru că nici măcar nu ești conștient de calitatea codului tău și dacă un străin experimentat ar indica greșeli.

8. Înclinația pentru decizii arcane

Diverse sarcini/probleme pot avea adesea mai multe soluții diferite. Și dintre toate soluțiile disponibile, începătorii tind să le folosească pe cele mai complexe și mai arcane. Și asta are sens: programatorii începători au învățat chiar ieri o mulțime de algoritmi, modele și structuri de date diferiți, așa că mâinile le mâncărime să implementeze unii dintre ei. Crede-mă, așa eram, așa că știu despre ce vorbesc :) Am avut o situație în care implementam o anumită funcționalitate de mult timp. S-a dovedit a fi foarte, foarte complicat. Apoi, dezvoltatorul senior mi-a rescris codul. Desigur, eram foarte interesat să văd ce și cum a schimbat-o. M-am uitat la implementarea lui și am fost uimit de cât de simplu a fost. Și era de trei ori mai puțin cod. Și, de asemenea, uimitor, testele automate pentru această funcționalitate nu au fost eliminate sau modificate! Cu alte cuvinte, logica generală a rămas aceeași. De aici am ajuns la concluzia căcele mai ingenioase solutii sunt intotdeauna simple . După această realizare, codarea a devenit mult mai ușoară, iar calitatea codului meu a sărit la un nivel semnificativ mai ridicat. Atunci când merită să aplicați modele de design și algoritmi fantezi, vă întrebați? La aplicarea acestora va fi cea mai simplă și mai compactă soluție.

9. Reinventarea roții

Roata este o soluție durabilă care a fost inventată cu mult timp în urmă. În acest anti-model, dezvoltatorul implementează propria soluție proprietară pentru o problemă care a fost deja rezolvată. Uneori, aceste soluții existente sunt mai bune decât ceea ce vine programatorul. De regulă, reinventarea roții va duce la pierderea timpului și la scăderea productivității, deoarece soluția pe care o găsiți poate fi departe de cea mai bună sau, ei bine, s-ar putea să nu găsiți deloc una. Acestea fiind spuse, nu putem exclude posibilitatea de a ne crea propria soluție independentă: dacă am face-o, atunci tot ce ar mai rămâne este programarea copy-and-paste. Programatorul trebuie să fie ghidat în mod corespunzător de sarcinile specifice de programare care apar pentru a le rezolva în mod competent și prompt, fie prin utilizarea de soluții gata făcute, fie prin crearea de soluții personalizate. Pe de o parte, la universități și la cursurile online, suntem bombardați cu diverse tipuri de sarcini care par concepute pentru a ne ajuta să reinventăm roțile. Dar doar la prima vedere: scopul real aici este dezvoltarea gândirii algoritmice și o stăpânire mai profundă a sintaxei limbajului. Astfel de sarcini vă ajută, de asemenea, să înțelegeți mai bine algoritmii și structurile de date și vă oferă abilități de a implementa omologi mai sofisticați, dacă este necesar (acest lucru este uneori necesar, dar este extrem de rar). În viața reală, nu trebuie să-ți inventezi propria roată în majoritatea covârșitoare a cazurilor, deoarece roțile care corespund nevoilor tale există de mult timp. Poate că lipsa ta de experiență te împiedică să știi despre existența unor implementări ale funcționalității de care ai nevoie. Aici trebuie să luați sfatul dat în primul punct al acestui articol, și anume, cere ajutor colegilor mai experimentați. Aceștia vă vor putea ghida (de exemplu, vă vor indica direcția corectă în căutarea dvs. pe Google) sau vă vor sugera o implementare specifică (de exemplu, o bibliotecă).

10. Nescrierea testelor

Tuturor începătorilor nu le place să scrie teste. Dar de ce ar trebui să îi evidențiem pe începători, aici? De asemenea, dezvoltatorilor mai experimentați nu le place să scrie teste, dar înțeleg mai bine de ce sunt necesare teste. Când ești complet verde, te întrebi de ce ar trebui să le scrii. Totul funcționează, așa că nu pot fi greșeli. Dar cum vă asigurați că modificările dvs. nu vor sparge ceva în altă parte a sistemului? Colegii tăi nu vor aprecia dacă faci schimbări care provoacă mai mult rău decât bine. Aici ne vin în ajutor testele. Cu cât codul unei aplicații este acoperit mai mult de teste, cu atât mai bine (aceasta se numește acoperire de cod sau acoperire de test). Dacă aplicația are o acoperire bună de testare, atunci puteți rula toate testele pentru a găsi locuri care vor fi sparte de codul dvs. Și așa cum am spus în exemplul de mai sus, când dezvoltatorul senior a refactorizat codul, testele nu au eșuat. Asta pentru că logica generală nu s-a schimbat. Folosim teste pentru a demonstra dacă logica anumitor funcționalități s-a schimbat sau nu. Deci, chiar dacă nu vă place să scrieți teste, acestea sunt cu siguranță utile și merită din plin timpul petrecut cu ele.

11. Comentarii excesive

Mulți dezvoltatori suferă de perfecționism, iar începătorii nu fac excepție. Ei manifestă uneori doar o fațetă a acestei înclinații atunci când încep să comenteze asupra tuturor și asupra tuturor. Chiar și a face comentarii care nu sunt necesare, deoarece codul este atât de evident:

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

Nu toți programatorii începători realizează imediat că comentarea codului nu este întotdeauna bună, deoarece comentariile de prisos îngrădesc codul și îl îngreunează de citit. Și dacă codul se schimbă, dar comentariile vechi nu sunt actualizate? Atunci nu vor face decât să ne inducă în eroare și să ne încurce. Atunci de ce să faci un astfel de comentariu? De obicei, codul bine scris nu trebuie comentat , deoarece totul în el este deja evident și lizibil. Dacă trebuie să scrieți un comentariu, atunci ați stricat deja lizibilitatea codului și încercați să remediați cumva situația. Cea mai bună abordare este să scrieți cod care poate fi citit de la început, adică cod care nu are nevoie de comentarii. De asemenea, nu pot să nu menționez necesitatea de a respecta convențiile corecte de denumire pentru metode, variabile și clase. Iată regula mea: Cel mai bun comentariu este fie niciun comentariu, fie denumirea corectă care descrie clar funcționalitatea aplicației dvs.

12. Denumirea proastă

Începătorii se joacă rapid și liber în denumirea claselor, variabilelor, metodelor etc. De exemplu, prin crearea unei clase al cărei nume nu descrie deloc scopul ei. Sau declară o variabilă cu un nume scurt, ceva de genul x . Ei când încă două variabile numite n și ysunt create, amintirea de ce este responsabil x devine foarte dificilă. În fața acestei situații, trebuie să te gândești cu atenție la cod, analizându-l la microscop (poate folosind un depanator), studiind funcționalitatea pentru a înțelege pur și simplu ce se întâmplă. Aici ne vin în ajutor convențiile corecte de denumire pe care le-am menționat mai sus. Numele corecte îmbunătățesc lizibilitatea codului, reducând astfel timpul necesar pentru a vă familiariza cu codul, deoarece utilizarea unei metode este mult mai ușoară atunci când numele acesteia descrie aproximativ funcționalitatea acesteia. Totul în cod constă din nume (variabile, metode, clase, obiecte, fișiere etc.), așa că acest punct devine foarte important atunci când se creează cod corect și curat. Trebuie să vă amintiți că numele ar trebui să transmită sens, de exemplu, de ce există variabila, ce face, si cum se foloseste. Voi observa de mai multe ori că cel mai bun comentariu pentru o variabilă este să îi dai un nume bun. Pentru un studiu mai profund al comentariilor și denumirea corectă, vă recomand să citiți clasicele atemporale:„Cod curat: un manual de artizanat software agil” de Robert Martin . În această notă, prima parte a acestui articol (reflecțiile mele) a ajuns la sfârșit. Va urma...