Estándares que no dependan de vos
Un estándar que vive en la cabeza de una persona y se aplica en las revisiones de código no es un estándar: es un cuello de botella con buena intención. La regla para saber si vale la pena: si se puede automatizar, no se discute; si no se puede, se escribe con su porqué.
Todo equipo que crece llega al mismo lugar: alguien revisa todo. Al principio funciona —el criterio es bueno y la persona es rápida—, hasta que esa persona se toma vacaciones y se nota que era la única que sabía dónde estaba la línea.
El problema no es tener criterio. Es que el criterio sea una persona en lugar de algo que el equipo pueda aplicar solo. La pregunta que ordena todo este tema: si mañana no estás una semana, ¿qué se degrada y qué sigue igual?
Tres formas de sostener un estándar
Cada regla del equipo vive en uno de tres lugares, y el lugar define cuánto cuesta sostenerla:
| Dónde vive | Cuánto cuesta por vez | Qué pasa si falta la persona | Para qué sirve |
|---|---|---|---|
| En una herramienta | Cero: falla el build | Nada: sigue funcionando | Formato, reglas de linter, cobertura mínima, dependencias vulnerables |
| En un documento corto, con su porqué | Un enlace en una revisión | Se sostiene si el documento se usa | Criterios que requieren juicio: cuándo partir un módulo, cómo se manejan los errores |
| En la cabeza de alguien | Una discusión por vez | Se degrada en una semana | Nada que quieras sostener |
Lo que se automatiza primero
No todo se automatiza el mismo día. El orden que más devuelve por el esfuerzo:
En este orden
- Formato. Un formateador automático, corriendo solo. Elimina de un saque la categoría entera de comentarios que más ruido hace y menos valor aporta.
- Errores reales. Un linter con reglas que atrapen bugs, no preferencias: variables sin usar, promesas sin esperar, comparaciones sospechosas.
- Tipos. La verificación más barata que existe para toda una clase de errores.
- Dependencias vulnerables. Un escaneo en la integración continua que falle cuando aparece algo crítico con arreglo disponible.
- Umbrales acordados. Cobertura mínima que no baje, tamaño del paquete que no crezca sin que alguien lo note.
Antes de seguir, predecí
Lo que sí necesita juicio
Queda una franja que ninguna herramienta cubre: cuándo un módulo se parte, cómo se manejan los errores de un servicio externo, qué se registra y qué no, cuándo algo va a una cola. Para esa franja sirve un documento corto con una forma específica.
Plantilla
Una regla del equipo
La regla, en una frase
Qué se hace, en imperativo y sin ambigüedad. Por ejemplo: los errores de servicios externos se traducen a un error propio del dominio antes de salir del módulo que los llama.
Si no entra en una frase, probablemente sean dos reglas.
Por qué
El problema concreto que causó la regla, idealmente con el caso real que la originó.
Es lo que permite que alguien la aplique a una situación nueva, y lo que permite discutirla cuando ya no aplica.
Cómo se verifica
Herramienta, revisión o nada. Si es nada, decirlo.
Una regla sin verificación es una intención; que esté escrito evita creer que está cubierta.
Cuándo no aplica
Las excepciones conocidas y qué hacer si aparece una nueva.
Una regla sin excepciones previstas genera dos comportamientos malos: cumplirla donde hace daño, o ignorarla en silencio.
Cómo salir del camino crítico
El objetivo no es revisar menos: es que tu revisión deje de ser obligatoria.
La salida, en cuatro pasos
- Mirá tus últimos cincuenta comentarios de revisión. Agrupalos. Lo que se repite es candidato a herramienta o a documento; el resto es lo que sólo podés aportar vos.
- Bajá de nivel todo lo que se pueda. Cada comentario repetido que se convierte en regla automática es una discusión que no vuelve a existir.
- Dejá de ser revisor obligatorio. Empezá por las zonas con dueño claro. Si algo no puede avanzar sin vos, esa área no tiene dueño todavía.
- Revisá las revisiones, no todos los cambios. Una vez por semana, mirá algunas revisiones hechas por otros. Corregís el criterio donde se forma, no cambio por cambio.
Más a fondo · nivel seniorCuando el estándar tiene que ceder
Hay dos momentos en los que sostener el estándar es el error. El primero es un incidente en curso: ahí lo que importa es restablecer el servicio, y se anota la deuda que eso genera para pagarla después, con nombre y fecha. El segundo es un experimento con fecha de muerte: código que existe para responder una pregunta y que se borra en dos semanas, y que no merece el mismo rigor que lo que va a vivir tres años.
Las dos excepciones tienen la misma condición para no volverse veneno: explícitas y con vencimiento. Lo que degrada un estándar no es la excepción, es la excepción silenciosa, que al mes ya es un precedente y a los seis meses es la forma en que se hacen las cosas.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica