În primele două părți ale seriei noastre am vorbit despre primii pași în meseria de programator și despre ce merită, de fapt, învățat la începutul carierei.
Acum ajungem la momentul de care se teme aproape orice Junior.
Primul Code Review. Primele comentarii la cod. Primele corecturi.
Și primul gând: "Chiar am scris atât de prost acest cod?"
Liniște.
Fiecare dintre noi a trecut la un moment dat prin asta.
Code Review nu e un examen
Cred că acesta este cel mai mare neînțeles printre programatorii începători.
Mulți Juniors iau comentariile la cod foarte personal. Apare stresul. Nesiguranța. Uneori chiar frustrarea.
Și totuși, scopul Code Review-ului nu este să dovedești cuiva că a greșit. Dimpotrivă. Este unul dintre cele mai importante elemente ale procesului de creare a unui software bun.
Datorită Code Review-ului:
- reducem riscul erorilor,
- îmbunătățim lizibilitatea codului,
- învățăm unii de la alții,
- avem grijă de coerența întregului proiect,
- transferăm cunoștințe între membrii echipei.
Cele mai bune echipe nu tratează Code Review ca pe un control. Îl tratează ca pe un schimb zilnic de experiențe.
„Ai 37 de comentarii”
Sună amenințător? La început, da.
Primul Pull Request arată adesea exact așa:
- Comentariu.
- Corectură.
- Încă un comentariu.
- Altă corectură.
După o oră ai impresia că tot codul trebuie aruncat. E normal.
Amintește-ți doar un lucru. Seniorul nu corectează codul pentru a-și demonstra superioritatea. O face pentru că peste câteva luni vei scrie cod mult mai bun.
Și despre asta e vorba.
Un Senior bun nu spune doar „prost”
Cei mai buni programatori cu care am lucrat întotdeauna explicau:
- de ce merită făcut ceva altfel,
- care vor fi consecințele soluției curente,
- ce alternative există,
- care soluție va fi mai ușor de întreținut peste un an sau doi.
E o diferență uriașă.
Pentru că poți spune: "Asta e greșit."
Sau poți spune: "Asta va funcționa, dar dacă peste jumătate de an vom extinde modulul, va fi mult mai ușor de întreținut într-o astfel de structură."
În al doilea caz înveți ceva mult mai valoros decât corectura în sine. Învățături despre modul de gândire.
Clean Code nu înseamnă cod frumos
Este un alt concept adesea înțeles greșit.
Clean Code nu înseamnă cod care arată spectaculos. Nu e vorba de numărul liniilor goale. Nu e vorba de lungimea funcțiilor. Nu e vorba nici măcar de anumite pattern-uri.
E vorba despre ceva mult mai simplu - codul ar trebui să fie lizibil.
Dacă peste jumătate de an deschizi propriul proiect și nu-ți amintești ce ai vrut să faci...
...probabil codul nu a fost suficient de lizibil.
Există un zicală: Scriem cod pentru oameni. Compilatorul doar verifică sintaxa.
Și e mult adevăr în asta.
Nu te îndrăgosti de propriul cod
Aceasta e una dintre cele mai importante lecții.
Codul nu e o operă de artă. Nu e un tablou. Nu e o sculptură.
E un instrument pentru a rezolva o problemă concretă.
Dacă cineva propune o soluție mai bună...
...merită să o iei în considerare.
Nu pentru că persoana are mai multă autoritate, ci pentru că poate chiar e mai bună.
Cei care învață cel mai mult sunt cei care pot spune: "Ai dreptate. Să facem altfel."
"La mine funcționează"
Bine. Trebuia să ajungem până la celebra expresie. Fiecare software house are versiunea sa a acestui glumă...
Imaginează-ți situația.
Testerul raportează un bug.
Programatorul răspunde: "La mine funcționează."
Testerul verifică din nou. - Nu funcționează.
Project Manager-ul verifică. - Nu funcționează.
Clientul verifică, la fel. - Nu funcționează.
Dar... la autorul codului încă funcționează.
Sună cunoscut?
De cele mai multe ori problema nu stă în codul însuși.
Cauzele pot fi foarte multe:
- versiune diferită de date,
- mediu diferit,
- cache,
- configurație,
- permisiuni,
- browser,
- sistem de operare,
- un caz pe care nimeni nu l-a prevăzut.
De aceea un programator profesionist nu se oprește la propoziția: "La mine funcționează."
Pune o întrebare următoare.
De ce la mine funcționează, iar în altă parte nu?
Și abia atunci începe adevăratul debugging.
"E doar o mică schimbare"
O altă frază care stârnește un zâmbet ușor în majoritatea software house-urilor.
Clientul spune: "E doar o corectură mică."
Programatorul deja știe că în curând va deschide un fișier pe care nimeni nu l-a mai atins de șase ani.
Iar acea „corectură mică” se poate dovedi a fi o schimbare în cinci module, trei integrări și două baze de date.
De aceea programatorii experimentați tratează cu multă precauție cuvântul „doar”.
Cele mai cunoscute expresii din industrie
Fiecare meserie are propriile ziceri. Programatorii la fel.
Câteva dintre ele probabil le cunoaște aproape toată lumea:
- "La mine funcționează."
- "E doar cinci minute."
- "Nu e bug. E feature."
- "Păi nu am schimbat nimic."
- "Pe producție s-a prăbușit."
- "Doar încă un deploy."
- "Sigur e cache."
- "O corectură rapidă înainte de weekend."
- "Ar trebui să meargă."
Și probabil cel mai periculos: "Punem asta pe producție vineri după 16:00."
Dacă lucrezi în IT...
...probabil tocmai ai zâmbit.
Programatorul nu lucrează singur
E un subiect adesea trecut cu vederea. În realitate, majoritatea proiectelor sunt muncă de echipă.
Programatorul colaborează cu:
- UX Designeri,
- UI Designeri,
- Project Manageri,
- Testeri,
- DevOps,
- Administratori,
- Analiști,
- Clienți.
De aceea la fel de importante ca cunoașterea tehnologiilor sunt:
- comunicarea,
- abilitatea de a asculta,
- transferul de cunoștințe,
- responsabilitatea,
- respectul reciproc.
Cel mai bun cod nu va salva un proiect dacă echipa nu știe să colaboreze.
Glosar de termeni
Code Review
Procesul de revizuire a codului de către alți programatori înainte de a fi integrat. Scopul este îmbunătățirea calității codului, detectarea erorilor și schimbul de cunoștințe.
Pull Request (PR)
Propunere de introducere a schimbărilor în proiect. Tot atunci are loc, de regulă, Code Review-ul.
Clean Code
Abordare de scriere a codului al cărei scop principal este lizibilitatea, simplitatea și ușurința mentenanței, nu numărul de pattern-uri folosite.
Debugging (Debuggare)
Procesul de găsire și eliminare a cauzelor erorilor din aplicație.
Cache
Mecanism care stochează temporar date pentru a accelera aplicația. Poate fi și sursă a multor probleme misterioase în timpul testării.
Concluzie
Cu cât lucrăm mai mult ca programatori, cu atât ajungem la o concluzie. Cei mai buni developeri nu sunt cei care comit cele mai puține erori.
Cei mai buni developeri sunt capabili să:
- găsească mai rapid cauza unei probleme,
- să tragă concluzii,
- să învețe de la alții,
- să accepte critica constructivă,
- să-și dezvolte constant meșteșugul.
Code Review nu este, așadar, un obstacol. Este una dintre cele mai prețioase lecții pe care le poți primi la începutul carierei.
În ultima parte a seriei noastre vom discuta despre traseul de la Junior la Senior. Vom explica de ce Senior Developer nu e neapărat cineva cu zece ani vechime, ci persoana care poate să își asume responsabilitatea pentru proiect, să gândească business și să ajute ceilalți membri ai echipei să crească.
