Code reviews que milloren el codi sense enfonsar la moral de l'equip
Les code reviews haurien de ser l'espai on el teu equip creix com a enginyers. On es comparteix coneixement, es cacen els bugs abans que arribin a producció i es construeix una cultura de qualitat col·lectiva.
A molts equips són exactament el contrari. Són on xoquen els egos, on els juniors aprenen a tenir por de pujar el seu codi, on un senior demostra com n'és, de llest, esmicolant el PR d'un company amb quinze comentaris d'estil que un linter hauria caçat. He vist bons developers marxar d'empreses no pas pel sou ni pel producte, sinó perquè cada code review era un examen oral on la resposta sempre era «no n'hi ha prou».
I el pitjor de tot: aquests equips es pensen que tenen una cultura d'«estàndards alts». No. Tenen una cultura de por.
Vegem com fer code reviews que de debò millorin el codi i facin equip en lloc de desfer-lo.
Per què importen les code reviews
Abans d'entrar en el com, deixem clar el perquè. Una code review ben feta aconsegueix quatre coses:
Caçar bugs abans de producció. Un segon parell d'ulls veu coses que l'autor no pot veure. No perquè el reviewer sigui millor enginyer, sinó perquè no comparteix els mateixos punts cecs. Aquella race condition, aquell cas límit que només es dona amb dades buides, aquella query N+1 — un reviewer que hi arriba de nou els caça precisament perquè no està immers en el context del problema.
Compartir coneixement. Quan revises codi d'una altra part del sistema, aprens com funciona. Quan algú et revisa el codi, aprèn el teu context. Amb el temps, això reparteix el coneixement i elimina sitges com ara «el mòdul de pagaments només el coneix la Maria».
Mantenir la consistència. Sense reviews, cada developer implementa les coses a la seva manera. Amb reviews, l'equip convergeix cap a patrons comuns, convencions compartides i un estil reconeixible. El codi resulta més mantenible i la càrrega cognitiva de tothom baixa.
Mentoria contínua. Cada review és una oportunitat d'ensenyar i d'aprendre. I no només de senior a junior: en totes dues direccions. Un junior que revisa el codi d'un senior guanya confiança, fa preguntes que no fa ningú més i, de tant en tant, caça coses que el senior donava per fetes.
La manera equivocada: com destruir la moral de l'equip
Aquests són els patrons tòxics que veig una vegada i una altra. Si en reconeixes cap al teu equip, tens un problema per resoldre.
Nitpicking d'estil que hauria de caçar un linter. «Aquí hi falta un espai.» «Fes servir const en lloc de let.» «El punt i coma va dins de les cometes.» Si deixes aquests comentaris a mà, no tens un problema de code review: tens un problema d'eines. Cada comentari d'estil és soroll que distreu de la revisió de debò i diu a l'autor que el seu reviewer es mira el que és trivial.
«Jo ho hauria fet diferent» sense explicar per què. Que tu ho hauries fet d'una altra manera no és cap argument. La pregunta rellevant és: l'enfocament actual té algun problema concret? És menys eficient? Menys llegible? Menys mantenible? Si no pots articular un problema específic, la teva preferència personal no hauria de bloquejar cap PR.
Tenir PRs bloquejats hores o dies. Un PR que s'obre dilluns i no rep cap review fins dimecres vol dir un developer aturat dos dies. I quan per fi arriba la review amb 20 comentaris, el developer ja ha canviat de context i ha de reconstruir tot l'estat mental del canvi. És un malbaratament brutal de temps i d'energia.
Que només revisin els seniors, mai a la inversa. Això crea una jerarquia implícita en què la review és un acte d'autoritat, no de col·laboració. Els juniors no desenvolupen mai el múscul de revisar codi. Els seniors no reben mai perspectives noves. I quan un junior finalment ha de revisar alguna cosa, no gosa comentar res perquè «qui soc jo per qüestionar un senior».
Fer servir les reviews per demostrar superioritat. El reviewer que deixa comentaris com «això és òbviament incorrecte» o «tothom sap que això no es fa així» no està revisant: està actuant de cara a la galeria. El resultat: l'autor es posa a la defensiva, l'equip associa les reviews amb el conflicte, i la gent comença a fer PRs més petits no per bona praxi, sinó per minimitzar la superfície d'atac.
La manera correcta: reviews que fan equip
Ara, el que funciona. No és teoria: són pràctiques que he vist funcionar en equips distribuïts d'alt rendiment.
Automatitza el que és trivial. Linting, format, type checking, anàlisi estàtica — tot això hauria de passar a la CI abans que cap humà toqui el PR. Eines com ESLint, Prettier, el strict mode de TypeScript i, ara, assistents com GitHub Copilot per a suggeriments automàtics. Si un PR arriba al reviewer amb errors de format, el problema és el teu pipeline, no el developer. Quan la màquina s'encarrega de la part mecànica, l'humà es pot centrar en el que importa: la lògica, l'arquitectura, els casos límit.
Comenta amb el PER QUÈ. La diferència entre un comentari útil i un de tòxic és l'explicació. «Això pot provocar un memory leak perquè l'event listener no s'elimina mai quan el component es desmunta» ensenya alguna cosa a l'autor. «No facis això» no li ensenya res i el posa a la defensiva. Després de cada comentari, l'autor hauria de saber alguna cosa que abans no sabia.
Fes preguntes en lloc de donar ordres. «Què passa si aquest valor és null?» és infinitament millor que «Afegeix-hi un null check». La pregunta convida l'autor a pensar i a arribar a la solució pel seu compte. L'ordre el converteix en un executor de la teva voluntat. I a més, de vegades la resposta és «no pot ser null per X» — i el qui aprèn ets tu.
Reconeix les bones decisions. «Bon ús del patró strategy aquí — simplifica molt l'extensibilitat futura.» «M'agrada com has separat la lògica de validació: els tests queden netíssims.» Això no és ser tou. És reforç positiu que indica a l'equip quines pràctiques valores. Si només comentes el que està malament, el missatge implícit és que el màxim a què es pot aspirar és no equivocar-se.
Limita la mida i el temps de resposta. Els PRs de més de 400 línies són difícils de revisar bé. Passada la franja de les 200-400 línies, he vist com la qualitat de la review cau en picat: el cervell es cansa i comences a llegir per sobre en lloc de revisar. Estableix la norma: PRs petits i acotats, i resposta en menys de 24 hores. Si ara mateix no pots fer una review completa, deixa-hi un comentari amb quan t'hi posaràs, perquè l'autor no quedi bloquejat.
Tothom revisa. Els juniors revisen els seniors. Backend revisa frontend. L'últim d'arribar revisa el qui fa dos anys que hi és. Els beneficis són enormes: el coneixement es reparteix, entren perspectives noves, s'eliminen jerarquies tòxiques i els juniors desenvolupen criteri tècnic molt més de pressa. El senior que se sent incòmode quan el revisa un junior té un problema d'ego, no de procés.
I deixa'm concedir l'objecció òbvia: sí, hi ha PRs que mereixen un bloqueig sense contemplacions. Un forat de seguretat, una migració que pot perdre dades en silenci, un canvi que trenca el contracte d'una API — demana canvis, i explica per què. La qüestió no és abaixar el llistó: és reservar el bloqueig per als casos que ho justifiquen de debò, perquè quan aturis un PR tothom sàpiga que és important.
Plantilles de PR: estructura que estalvia temps
Una bona plantilla de PR redueix les preguntes del reviewer i accelera el cicle:
- Context: quin problema resol aquest PR? Enllaç al ticket o a la issue.
- Canvis: resum de què s'ha modificat i per què s'ha triat aquest enfocament.
- Captures o vídeos: si hi ha canvis visuals, ensenya'ls. Un GIF de 10 segons estalvia 10 minuts de «deixa'm aixecar el projecte per comprovar-ho».
- Pla de proves: com has validat que funciona. Tests automàtics, prova manual o totes dues coses.
- Pla de rollback: si alguna cosa falla a producció, com es reverteix? En les funcionalitats grans, això no és opcional.
No et cal una plantilla de 30 camps. Et cal prou context perquè el reviewer entengui què té davant sense haver de llegir el diff línia per línia.
Mètriques: el que mesures, millora
Si vols millorar el teu procés de code review, mesura:
- Time to first review: des que s'obre el PR fins al primer comentari. Objectiu: menys de 4 hores laborables.
- Review cycle time: de la primera review al merge. Objectiu: menys de 24 hores per a un PR normal.
- Nombre de rondes abans del merge: si la mitjana passa de 3, els teus PRs són massa grans o les teves reviews, massa primmirades.
No facis servir aquestes mètriques per jutjar persones. Fes-les servir per detectar problemes sistèmics: reviewers que fan coll d'ampolla, PRs que es podreixen al backlog, cicles de review interminables que delaten problemes de comunicació.
Els equips distribuïts ho amplifiquen tot
Tot el que hem dit s'amplifica quan l'equip treballa distribuït. Si el reviewer i l'autor són en fusos horaris diferents, cada ronda de review afegeix un dia de latència en lloc d'una hora.
La solució no és eliminar les reviews: és dissenyar el procés per minimitzar les rondes. PRs petits, plantilles clares, linting automàtic i una cultura d'«aprovo amb comentaris menors» en lloc de «demano canvis a cada observació».
A Conectia, els enginyers que incorporem a equips europeus s'integren a la teva cultura de review des del primer dia. No són developers externs que llancen codi per sobre del mur: són membres de l'equip que participen a les reviews, aprenen els teus patrons i hi aporten els seus. Perquè la qualitat del codi no surt de regles estrictes. Surt de persones amb bon criteri que saben comunicar-lo.
Els millors equips que he vist no són els que tenen les regles de review més estrictes. Són els que han construït una cultura on demanar feedback és natural, donar-lo és respectuós i rebre'l és una oportunitat. Això no es configura al Jira. Es construeix amb persones que entenen que el codi és de l'equip, no de l'individu.
Vols enginyers que elevin la qualitat del teu codi i s'integrin a la teva cultura des del dia 1? Parla amb un CTO — els nostres enginyers sènior de LATAM no només escriuen bon codi: ajuden tot l'equip a millorar.
