Cum a fost organizată procedura de revizuire a codului în echipa ta?

Am folosit dezvoltarea comună cu ajutorul sistemului de control al versiunilor Git și platformelor pentru gestionarea depozitelor (de exemplu, Bitbucket sau GitLab). Procesul de revizuire a codului a fost organizat astfel:

1. Crearea unei ramuri: Dezvoltatorul creează o ramură separată pentru o nouă funcție sau corectare de erori (git checkout -b feature/my-new-feature).
2. Dezvoltare și commit-uri: Se fac modificări în ramură, care sunt înregistrate prin commit-uri (git add ., git commit -m "Implementare inițială a funcției").
3. Push în depozitul remote: Ramura este trimisă în depozitul remote (git push origin feature/my-new-feature).
4. Crearea unui Pull/Merge Request: Dezvoltatorul creează un Pull Request (pe Bitbucket) sau Merge Request (pe GitLab), indicând ramura țintă (de exemplu, develop sau main). În descriere se include un rezumat al modificărilor, link-uri către sarcini în tracker (Jira, Trello etc.) și fișiere atașate (capturi de ecran, videoclipuri, diagrame).
5. Atribuirea revizorilor: Se atribuie unu sau doi dezvoltatori din echipă pentru a realiza revizuirea.
6. Procesul de revizuire: Revizorii examinează modificările din Pull/Merge Request. Ei pot lăsa comentarii, propune îmbunătățiri, adresa întrebări.

   // Exemplu de comentariu în timpul revizuirii
   function fetchData() {
     // Poate ar trebui adăugat aici gestionarea erorilor
     return fetch('/api/data');
   }
   

7. Modificări după revizuire: Dezvoltatorul face modificările necesare pe baza comentariilor revizorilor și face noi commit-uri.
8. Actualizarea Pull/Merge Request: Modificările apar automat în Pull/Merge Request după push în depozitul remote.
9. Revizuire repetată: Revizorii revizuiesc din nou modificările și aprobă.
10. Fuzionarea ramurii: După obținerea aprobării, ramura se fuzionează în ramura țintă (de obicei automatizat de platformă după trecerea prin pipeline-ul CI/CD).

De asemenea, am folosit pipeline-uri CI/CD pentru a rula automat teste unitare, analize statice de cod (ESLint, Prettier) și construcția proiectului înainte de fuzionare, ceea ce a ajutat la identificarea erorilor în faze timpurii.

Criteriile pentru o revizuire de succes includeau:

• Conformitatea cu cerințele sarcinii.
• Respectarea stilului de cod al echipei.
• Prezența testelor unitare pentru logica critică.
• Lipsa erorilor evidente și "soluțiilor temporare".
• Claritatea codului pentru ceilalți membri ai echipei.