Code Reviews que Milloren el Codi sense Destruir la Moral de l'Equip

Les code reviews haurien de ser el lloc on el teu equip millora com a enginyers. On es comparteix coneixement, es detecten errors abans de producció i es construeix una cultura de qualitat col·lectiva.

A molts equips, són exactament el contrari. Són el lloc on els egos xoquen, on els juniors aprenen a témer fer push del seu codi, on un senior demostra com de llest és destrossant el PR d'un company amb quinze comentaris d'estil que un linter hauria detectat. He vist bons developers deixar empreses no pel salari ni pel producte — sinó perquè cada code review es sentia com un examen oral on la resposta sempre era "insuficient".

I el pitjor: aquests equips creuen que tenen una cultura d'"alts estàndards". No la tenen. Tenen una cultura de por.

Anem a veure com fer code reviews que realment millorin el codi i construeixin equip en comptes de destruir-lo.

Per què les code reviews importen

Abans de parlar del com, alineem el per què. Les code reviews ben fetes aconsegueixen quatre coses:

Detectar bugs abans de producció. Un segon parell d'ulls veu coses que l'autor no pot veure. No perquè sigui millor enginyer, sinó perquè no té els mateixos punts cecs. Aquell race condition, aquell edge case que només passa amb dades buides, aquella query N+1 — un reviewer fresc els detecta perquè no està submergit en el context del problema.

Compartir coneixement. Quan revises codi d'una altra part del sistema, aprens com funciona. Quan algú revisa el teu codi, aprèn el teu context. Amb el temps, això distribueix el coneixement i elimina els sitges de "només la Maria sap com funciona el mòdul de pagaments".

Mantenir consistència. Sense reviews, cada developer implementa a la seva manera. Amb reviews, l'equip convergeix cap a patrons comuns, convencions compartides i un estil reconeixible. Això fa el codi més mantenible i redueix la càrrega cognitiva de tothom.

Mentoria contínua. Cada review és una oportunitat d'ensenyar i aprendre. No només de senior a junior — en les dues direccions. Un junior que revisa el codi d'un senior guanya confiança, fa preguntes que ningú més fa, i de vegades detecta coses que el senior donava per fetes.

La forma incorrecta: com destruir la moral del teu equip

Aquests són els patrons tòxics que veig un cop i un altre. Si en reconeixes algun al teu equip, tens un problema per resoldre.

Nitpicking d'estil que un linter hauria de detectar. "Falta un espai aquí." "Fes servir const en comptes de let." "El punt i coma va dins de la cometa." Si estàs deixant aquests comentaris manualment, no tens un problema de code review — tens un problema de tooling. Cada comentari d'estil és soroll que distreu del review real i li diu a l'autor que el seu reviewer es fixa en el trivial.

"Jo ho hauria fet diferent" sense explicar per què. Que tu ho faries d'una altra forma no és un argument. La pregunta rellevant és: l'enfocament actual té un problema concret? És menys performant? És menys llegible? És menys mantenible? Si no pots articular un problema específic, la teva preferència personal no hauria de bloquejar un PR.

Bloquejar PRs durant hores o dies. Un PR que s'obre dilluns i no rep review fins dimecres és un developer bloquejat durant dos dies. I quan per fi arriba el review amb 20 comentaris, el developer ha canviat de context i necessita reconstruir tot l'estat mental del canvi. És un malbaratament brutal de temps i energia.

Només els seniors revisen, mai al revés. Això crea una jerarquia implícita on el review és un acte d'autoritat, no de col·laboració. Els juniors mai desenvolupen el múscul de revisar codi. Els seniors mai reben perspectives fresques. I quan un junior finalment ha de revisar alguna cosa, no s'atreveix a comentar perquè "qui soc jo per qüestionar un senior".

Fer servir reviews per demostrar superioritat. El reviewer que deixa comentaris com "això és òbviament incorrecte" o "qualsevol sap que això no es fa així" no està fent review — està actuant per a una audiència. El resultat: l'autor es posa a la defensiva, l'equip associa les reviews amb conflicte, i la gent comença a fer PRs més petits no per bona pràctica sinó per minimitzar la superfície d'atac.

La forma correcta: reviews que construeixen 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 trivial. Linting, formateig, type checking, anàlisi estàtica — tot això hauria d'executar-se a CI abans que cap humà toqui el PR. Eines com ESLint, Prettier, TypeScript strict mode, 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 del mecànic, l'humà pot enfocar-se en el que importa: lògica, arquitectura, casos edge.

Comenta amb el PER QUÈ. La diferència entre un comentari útil i un de tòxic és l'explicació. "Això pot causar un memory leak perquè l'event listener mai s'elimina quan el component es desmunta" li ensenya alguna cosa a l'autor. "No facis això" no li ensenya res i el posa a la defensiva. Cada comentari hauria de deixar l'autor sabent alguna cosa que no sabia abans.

Fes preguntes en comptes de donar ordres. "Què passa si aquest valor és null?" és infinitament millor que "Afegeix un null check". La pregunta convida l'autor a pensar i a arribar a la solució per si mateix. L'ordre el converteix en un executor de la teva voluntat. A més, de vegades la resposta és "no pot ser null perquè X" — i tu aprens alguna cosa.

Reconeix les bones decisions. "Bon ús del patró strategy aquí, simplifica molt l'extensió futura." "M'agrada com has separat la lògica de validació — fa que els tests siguin molt nets." Això no és ser tou. És reforç positiu que senyala a l'equip quines pràctiques valoreu. Si només comentes el que està malament, el missatge implícit és que el millor que pots fer és no cometre errors.

Limita la mida i el temps. PRs de més de 400 línies són difícils de revisar bé. La qualitat del review cau dràsticament passades les 200-400 línies — el teu cervell es cansa i comences a fer skim en comptes de review. Estableix com a norma: PRs petits i enfocats, i resposta en menys de 24 hores. Si no pots fer un review complet ara, deixa un comentari dient quan podràs fer-ho per no bloquejar l'autor.

Tothom revisa. Juniors revisen seniors. Backend revisa frontend. El nou de l'equip revisa el que porta dos anys. Els beneficis són enormes: distribució de coneixement, perspectives fresques, eliminació de jerarquies tòxiques, i juniors que desenvolupen criteri tècnic molt més ràpid. El senior que se sent incòmode sent revisat per un junior té un problema d'ego, no de procés.

Templates de PR: estructura que estalvia temps

Un bon template de PR redueix les preguntes del reviewer i accelera el cicle:

• Context: Quin problema resol aquest PR? Enllaç al ticket o issue.
• Canvis: Resum del que s'ha modificat i per què s'ha triat aquest enfocament.
• Screenshots/vídeos: Si hi ha canvis visuals, mostra'ls. Un GIF de 10 segons estalvia 10 minuts de "deixa'm arrencar el projecte per veure-ho".
• Pla de testing: Com s'ha validat que funciona. Tests automàtics, prova manual, tots dos.
• Pla de rollback: Si alguna cosa surt malament en producció, com es reverteix? En features grans, això no és opcional.

No necessites un template de 30 camps. Necessites el context suficient perquè el reviewer entengui què està mirant sense haver de llegir cada línia de diff.

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: des del primer review fins al merge. Objectiu: menys de 24 hores per a PRs normals.
• Nombre de rondes abans del merge: si la mitjana és més de 3, els teus PRs són massa grans o els teus reviews són massa nitpicky.

No facis servir aquestes mètriques per jutjar individus. Fes-les servir per detectar problemes sistèmics: colls d'ampolla en reviewers, PRs que es podreixen al backlog, cicles de review excessius que indiquen problemes de comunicació.

Code reviews en equips distribuïts

Tot l'anterior s'amplifica quan el teu equip està distribuït. Si el reviewer i l'autor estan en zones horàries diferents, cada ronda de review afegeix un dia de latència en comptes d'una hora.

La solució no és eliminar reviews — és dissenyar el procés per minimitzar rondes. PRs petits, templates clars, linting automàtic, i cultura d'"aprova amb comentaris menors" en comptes de "request changes per 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 llencen codi per sobre del mur — són membres de l'equip que participen en reviews, aprenen els teus patrons, i aporten els seus. Perquè la qualitat del codi no s'aconsegueix amb regles estrictes. S'aconsegueix amb persones que tenen criteri i 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 a 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 senior de LATAM no només escriuen bon codi, contribueixen a que tot l'equip millori.