ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 139
Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 8
Abonament PDF

Code review

Mădălin Ilie
Cluj Java Discipline Lead
@Endava



PROGRAMARE

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.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO