TSM - Code review

Mădălin Ilie - Cluj Java Discipline Lead

Code Review-ul este o examinare sistematică a codului sursă. Scopul acestui proces este identificarea și corectarea problemelor trecute cu vederea în faza inițială de scriere a codului, îmbunătățind în același timp calitatea codului cât și abilitățile dezvoltatorilor.

De ce este Code Review-ul important

Steve McConell prezintă în cartea sa Code Complete (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) câteva argumente foarte bune despre eficiența procesului de Code Review:

Testarea softului în sine are eficacitate limitată - rata medie de detectare a defectelor este de 25% pentru unit testing, 35% pentru testarea funcțională și 45% pentru integration testing. În opoziție, eficacitatea Code Review-ului si Design Review-ului este între 55%-60%. Studiile de caz pentru revizuirea rezultatelor aplicării Code Review-ului au fost impresionante:

Motivele principale pentru care se face Code Review-ul sunt:

Pentru a înțelege cât de important este să fixăm cat mai multe defecte încă din faza de dezvoltare, aveți mai sus un grafic despre costurile unui defect în diferite faze ale produsului:

Ariile principale pe care se concentrează Code Review-ul:

Roluri și responsabilități

Dezvoltatorul: este persoana care a scris codul ce urmează a fi revizuit și este cel care inițiază cererea pentru Code Review.

Reviewer/s: sunt persoanele care vor revizui codul și vor raporta problemele găsite devoltatorilor.

La fel ca orice altă abilitate, reviewer-ii devin mai buni făcând foarte multă practică. Iată câteva ponturi care vă vor ajuta să porniți pe drumul cel bun.

Sfaturi pentru Dezvoltarori

Sfaturi pentru Revieweri

Security Code Review

Dacă aplicația necesită o atenție deosebită asupra părții de securitate, vă recomand www.owasp.org. Există și un document de Code Review foarte bun: https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf.

Pentru determinarea severității problemelor găsite în timpul code review-ului vă recomandăm nivele de severitate de mai jos:

Reviewerii ar trebui să se concentreze pe nivelele High și Medium.

Checklist-uri pentru dezvoltatori și reviewer

Checklist-urile sunt o unealtă foarte bună atunci când vrei să nu omiți anumite aspecte și sunt foarte utile atât pentru dezvoltatori cât și pentru revieweri. Omisiunile sunt defectele cele mai greu de reparat - clar că nu ai cum să faci review la ceva ce nu există. Un checklist e cel mai simplu mod prin care poți combate asta.

Un alt concept foarte folositor este checklist-ul personal. O persoană face în medie cam aceleași 15-20 de greșeli. Pentru a preveni repetarea, încearcă să ții o listă cu problemele cele mai întâlnite. Aceasta te va ajuta și pe tine ca dezvoltator să îți însușești conceptele respective.

Checklist pentru Dezvoltatori

Description Confirmed?
Codul se compilează  
Codul a fost testat de mine și include unit teste  
Codul include javadoc  
Codul este ordonat (spațiere, greșeli de ortografie, nu există cod comentat, etc)  
Am considerat utilizarea corectă a excepțiilor  
Am utilizat adecvat logging-ul  
Am eliminat importurile nefolosite  
Am eliminat warning-urile raporte de Eclipse/Netbeans/IntelliJ  
Am luat în considerare potențiale NPEs  
Codul urmează standardele de codare  
Am eliminat orice cod redundant sau clase care nu mai sunt folosite  
Am eliminat orice hardcodări sau development-only code?  
Perfomanța a fost luată în considerare?  
Securitatea a fost luată în considerare?  
Codul eliberează resursele? (HTTP connections, DB Connections, files, etc)?  
Cazurile particulare au fost bine documentate? La fel orice workaround sau limitare  
Codul poate fi înlocuit cu apeluri către componente externe resutilizabile?  
Thread safety și posibile deadlocks  

Checklist pentru Revieweri

Description Confirmed?
Comentarile sunt comprehensibile și aduc valore mentenabilității codului  
Comentariile nu sunt foarte multe și nici foarte amănunțite  
Tipurile de date au fost generalizate acolo unde a fost posibil  
Tipurile parametrizate au fost folosite corespunzător  
Excepțiile au fost folosite corespunzător  
Codul duplicat a fost eliminat  
Frameworkurile au fost folosite corespunzător  
Clasele de tip comand sunt concentrate pe un singur task  
JSP-urile nu conțin logică de business  
Unit test-ele există și sunt corecte  
Sunt verificări pentru erorile comune  
Potențiale probleme de multi-threading au fost eliminate pe cât posibil  
Eventuale probeme de securitate au fost adresate  
Performanța a fost luată în considerare  
Funcționalitate se încadrează în design-ul/arhitectura curentă  
Codul este unit testable  
Codul nu folosește nejustificat elemente statice  
Codul urmează standardele de codare  
Logging-ul a fost folosit corespunzător  
NPEs și AIOBs  

Automatizarea procesului de Code Review

Pornind de la un document cu standarde de codare, o parte din procesul de Code Review poate fi automatizat. Asta nu înseamnă că rolul de Reviewer nu mai există. Tool-urile care automatizează Code Review-ul, vor elimina mare parte din problemele legate de styling, convenții de denumire, complexitate ciclomatică a claselor, metodelor, cod duplicat, cât de mult acperă unit testele codul scris, probleme minore de design, etc. Nu pot detecta însă probleme majore de design, arhitectură, funcționalitate care sunt specifice proiectului. Voi prezenta mai jos cele mai folosite tool-uri pentru Java.

PMD

Pagina oficială: http://pmd.sourceforge.net/.

Este un analizor de cod sursă. Detectează variabile neutilizate, probleme de styling, denumire, blocuri goale, complexitte ciclomatică, etc. Are integrare cu tool-urile populare de building: Maven și Ant, precum și cu cele mai populare IDE-uri: Eclipse, Netbeans.

Findbugs

Pagina oficială: http://findbugs.sourceforge.net/.

Folosește analiza statică a codului pentru identifiare bug-urilor din cod. La fel ca si PMD are integrare cu cele mai populare tool-uri de building si IDE-uri.

Checkstyle

Pagina oficială: http://checkstyle.sourceforge.net/

Este concentrat în principal pe styling, denumiri, cod duplicate, cod duplicat, etc. La fel ca și PMD are integrare cu cele mai populare tool-uri de building și IDE-uri.

Code Coverage

Pentru a verifica gradul de acoperile al codului cu unit teste cele mai populare tooluri sunt: Jacoco, Cobertura și Clover.

Sonar

Sonar este un tool care agregă datele prezentate de toolurile de mai sus și le afișează într-o interfață foarte ușor de folosit, oferind diverse rapoarte, grafice, evoluția codului de-a lungul timpului. Pe lângă toolurile prezentate mai sus, Sonar oferă și multe alte pluginuri care ajută la procesul de Code Review.

Sonar oferă integrare cu cele mai populare IDE-uri și tool-uri de building și oferă suport out-of-the-box pentru Java. Poate fi configurat și pentru alte limbaje de programare precum PHP, C++ sau .NET dar cu puțin mai mult efort.

Aveți în partea de jos a paginii o diagramă care prezintă arhitectura Sonar-ului. (Server se referă la serverul de Sonar).

Controlarea procesului de Code Review

Până acum am prezentat sfaturi despre ce anume se urmărește într-un proces de code review și cum se poate automatiza o parte din code review pentru a permite Reviewer-ului să se concentreze asupra lucrurilor importante și să nu își piardă timpul verificând cât de lungi sunt liniile de cod sau dacă există spații între operatori și operanzi.

Cum e cel mai bine să urmărim progresul: prin email, printr-un fișier excel, doar discutând, folosind tooluri specilizate? Deși răspunsul cel mai evident este folosirea tool-urilor specializate, fiecare echipă și proiect are particularitățile sale. De obicei, fiecare echipă își găsește propria mecanică care va avea diverse particularități:

Dacă sunteți într-un mediu în care folosiți tool-uri de la Atlassian (JIRA, Confluence, Fisheye), alegerea cea mai evidentă este Crucible datorită integrării cu celelalte produse. În momentul de față cred că este cel mai bun tool pentru monitorizarea procesului de code review. Alte alegeri ar mai fi: Gerrit (dedicat proiectelor ce folosesc Git) sau ReviewBorad.