Code Review

27 de gener de 2014

Autors:

L’inLab està dedicant recursos i esforç per impulsar l’ús de les Metodologies Àgils en la gestió i desenvolupament de projectes. Aquestes metodologies (SCRUM, KANBAN, i XP) tenen cadascuna les seves litúrgies. L’última d’aquestes litúrgies que hem incorporat a l’inLab són les Code Review.

Els Code Review és fer una revisió manual del codi. Si, ho has llegit bé, manual, amb llapis i paper, res d’entorn gràfic, res d’IDE, res d’ordinador.

Motivació

Quina és la motivació per fer revisions de codi? Doncs n’hi ha moltes:

És una bona eina per que el codi sigui col·laboratiu (collective ownership) és a dir tot l’equip es senti “responsable” de tot el codi, no només de la part que ell/a ha desenvolupat.
S’eliminen errors. Quan més ulls mirin el codi més errors es detecten.
S’aprèn. Comentant el codi i mirant quines solucions proposa les resta de l’equip davant dels mateixos problemes en serveix per veure punts de vista nous i aprendre nous idioms.
Es revisa el disseny del codi. Un bon codi té associat un bon disseny. El disseny com a fase d’un projecte ja no s’aplica (segon les Metodologies Àgils que seguim), per tant el codi és a la vegada el disseny i aquest ha de ser SOLID (millor SOLID que STUPID http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/).
Tenir Software de bona qualitat. Tots les millores que apareguin al llarg de la revisió s’han de veure reflectides després en el codi.

Tipus de Code Review

Hi ha 2 tipus de revisions de codi: per esport i per necessitat. En el primer cas (per esport) les classes seleccionades per ser revisades són presentades pels mateixos assistents a la revisió i l’encarregat de moderar la revisió selecciona les classes que formaran part d’aquesta. Aquest tipus de revisió es fa amb totes les persones que estiguin disposades a participar-hi.

En el segon cas (per necessitat) es vol revisar a consciència un codi (ja sigui perquè surt a producció, perquè té molts bugs, perquè és clau dins del projecte,…) . Aquest segon tipus de revisió és fa amb tots els membres de l’equip de desenvolupadors del codi que es vol revisar.

Preparació prèvia de la Code Review

Una revisió de codi s’ha de preparar, cal fer les següents passes abans del dia de la revisió:

Es convoca màxim a 8-10 persones a una revisió de codi (en cas que sigui per esport) o a tot l’equip de desenvolupadors del codi a revisar (en cas que sigui per necessitat).
Els assistents a la revisió presenten les classes que volen revisar i el moderador escull les classes que es revisaran. En cas de necessitat és tot el codi que es vol revisar.
Es fa arribar, a tots els assistents, un PDF amb totes les classes a revisar (a poder ser amb números de línia, a doble cara, a dos pàgines per cara i en format horitzontal).
Aquest document s’ha d’enviar mínim 2 dies laborables abans perquè tots els assistents tinguin temps de revisar-lo.
Tota la gent convocada ha de llegir el codi i anotar totes les coses que vol comentar al document (errors, codi duplicat, millores de codi, millores de disseny,…)

La Code Review

Ja hi som, hem arribat al dia de la revisió! I us preguntareu: i ara que hem de fer?

Doncs molt senzill. Si és una revisió per esport es dedicarà un temps acordat a cada classe presentada, per exemple 30 minuts per classe. Passats aquests 30 minuts es passarà a la següent classe malgrat no haguem finalitzat la revisió de la classe que estem mirant ara. Si es per necessitat es dedicarà el temps que calgui a cada classe.

Tot seguit la persona que presenta la classe comença la seva exposició.

Ara bé aquesta exposició i els comentaris, que es pugin derivar de la resta dels assistents, també tenen les seves bones practiques:

El codi es llegeix línia a línia
Quan s’arriba a un mètode (o funció) no es fa step into, quan arribem al mètode en qüestió ja el revisarem. Ara a partir del nom del mètode suposem el què fa i suposem que ho fa bé (els que veniu als nostres coding dojo,… us sonarà la frase: “els mètodes han de tenir nom apropiats i representatius del que fan”).
No només es llegeix la frase sinó que s’ha de justificar o explicar el perquè d’algunes decisions (sobretot les decisions de disseny).
Si el que exposa la classe creu que una línia (o línies) es poden millorar, ell mateix pot llegir el que hi ha i exposar una possible millora.
Si nosaltres com a assistents volem fer algun comentari hem d’esperar que el que exposa arribi a la línia que volem comentar, que faci tots els comentaris que cregui oportú (justificacions de decisions, possibles millores,…) si amb les justificacions o possibles millores ja ha “sortit” els nostre comentari no cal que diguem res,.. si les justificacions, o possibles millores no ens satisfan o no contemplen el que volem comentar llavors es quan diem el nostre comentari.

Heu de tenir present que a ningú li agrada que li diguin que la seva feina és dolenta o està mal feta per tant tots els comentaris han de ser molt respectuosos i sempre fer comentaris que “aportin” valor, no criticant per criticar.

Conclusions

Per si voleu fer mai una code review 2 petits consells:

El primer consell dedicat a l’equip de desenvolupadors: Heu de tenir present que quan escriviu codi ho feu pensant en els desenvolupadors que el llegiran. Si adopteu aquesta nova litúrgia dins del vostre dia a dia SEGUR que el llegiran, per tan anem a facilitar la feina posant noms entenedors i una indentació que faciliti la comprensió.
EL segon dedicat al moderador: Una code review és molt densa, és a dir, cansa molt. Per tant no les feu més llargues de 3h i, si les heu de fer més llargues per necessitat, contempleu parades obligatòries per donar descans.

I per acabar un punt d’humor. Els experts en la matèria diuen que es pot saber com de bo o dolent és un codi en funció del WTF per minut que hi ha en el code review d’aquest codi.