Maira e Brandán traballan nun proxecto de software que practica a revisión do código. Cando Brandán quere incorporar un cambio no programa, envíallo a Maira para que lle bote unha ollada. Moitas veces, Maira ten comentarios e suxestións, e Brandán fai modificacións no cambio de acordo con estes comentarios. Cando, finalmente, Maira aproba o cambio, Brandán pode facer o “commit” no sistema de control de versións.
Hoxe en día hai moitas empresas e proxectos que traballan desta maneira, porque a práctica da revisión de código ten moitos beneficios.
Primeiro de todo, dá máis oportunidades de cachar un erro antes de que entre no programa. Dous pares de ollos ven máis que un só. Ademais, o revisor ten a mente “fresca” (non pasou varios días ollando o mesmo código) e distintos coñecementos e experiencias que o programador do cambio, así que é probable que se fixe en distintas cousas.
Outro beneficio é que espalla os coñecementos sobre como funciona o programa. Hai empresas nas que só Pepiño sabe como funcionan certas partes do programa e defende ese coñecemento como un dragón. Con revisións de código, cada cambio é feito por dúas persoas, así que hai menos risco de que alguén se faga indispensable por accidente ou adrede.
A revisión de código tamén é unha boa maneira de incorporar a unha nova persoa no equipo. No lugar de dicirlle “fai un cambio, boa sorte, LOL”, podes dicirlle “revisa este cambio”. Revisar un cambio xa feito é máis doado que facer un cambio novo se un non traballou nunca nese programa, e tamén é menos frustrante porque dá a impresión de estar a facer traballo produtivo máis rapidamente.
Hai outra maneira na que a revisión de código espalla coñecementos. Moitas veces, o revisor suxire unha maneira mellor de facer o cambio — ou, ao ver o cambio, aprende unha nova maneira de facelo. É así como un dos meus compañeiros aprendeu a maneira correcta de facer aplicacións CRUD.
A práctica da revisión do código tamén axuda á cohesión do equipo. No canto de traballar en solitario na súa parte do programa, cada persoa ten que buscar un revisor e colaborar con el ata que o cambio sexa aceptado. Iso axuda a que cada un se afaga á maneira de traballar dos outros e a falar, discutir as súas diferenzas e aceptar unha solución aceptable para os dous.
Finalmente, a revisión do código fai que o software sexa máis seguro. En programas que tratan datos persoais, médicos ou financeiros, é importante (e ás veces é obrigatorio) que sempre haxa unha segunda persoa que revise cada cambio para poder asegurar que ninguén introduciu código maligno pola súa conta.
Se no voso proxecto non facedes revisión de código, recoméndovos que comecedes — supoñendo que sexades máis dunha persoa no proxecto, claro. Hoxe en día hai moitísimas ferramentas de revisión de código, moitas delas gratuítas (e, facendo falta, pódese facer revisión de código por email, coma o kernel de Linux, pero non o recomendo). Todas estas ferramentas funcionan controlando o acceso ao sistema de control de versións para que só se poida facer “commit” dos cambios aprobados por un revisor, así que se non usades un sistema de control de versións, comezade con iso.
Usade a revisión de código para mellorar a calidade do voso software. Non é só unha maneira de evitar erros — é unha maneira de facer que todo o voso equipo participe na escritura de todo o código. Para iso, os autores do código deben estar dispostos a aceptar as críticas e defender as súas ideas con graza, e os revisores deben saber facer crítica construtiva e non levar as discusións alén do necesario.
A ilustración desta Folla procede dun gravado de William Sharp.
1 comentario