Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Idea principal
Fusionar código que ningún miembro del equipo sabría explicar no es una negligencia de revisión: es un préstamo. El equipo obtiene la funcionalidad de inmediato y se compromete a pagar más tarde en incapacidad de diagnóstico, en el momento en que haya que modificar, asegurar o retomar ese código sin saber por qué está escrito así.
El pasivo permanece invisible mientras nada se rompe: la aplicación funciona, las pantallas responden, las pruebas pasan. Decenas de pull requests abiertas por la noche por un asistente e integradas sin que nadie haya verificado los impactos se parecen a un adelanto; son intereses que corren.
De ahí una regla de merge simple, casi brutal: no integrar código que nadie pueda explicar. No exige una documentación interminable: basta un pequeño presupuesto de comprensión por funcionalidad —el contrato, las pruebas, la decisión de arquitectura, los límites conocidos—. Lo justo para que el razonamiento siga siendo humanamente transmisible.
Por qué es importante
Esto vuelve a poner un precio inmediato a la incomprensión, en el lugar y el momento en que se toma la decisión. Mientras el coste está diferido, cada integración aislada parece razonable, y el pasivo se acumula sin que ningún arbitraje lo haya aceptado.
También da un criterio de revisión que no depende del nivel técnico de quien revisa: la pregunta no es "¿este código es bueno?", sino "¿alguien aquí sabe decir por qué es así?".
Matices y límites
La regla choca con una zona gris: ¿explicar a qué nivel? Nadie explica línea a línea el código de una biblioteca de terceros, y un equipo que exigiera ese grado en todo ya no integraría nada. El objeto de la explicación es la intención y las fronteras, no cada instrucción.
Y solo vale si alguien tiene la autoridad de bloquear una integración. En un equipo donde el plazo manda, se convierte en una formalidad declarativa, y la explicación se reduce a la casilla marcada.
Preguntas abiertas
- ¿Sobre qué perímetro debe recaer la explicación —la funcionalidad, el módulo, la línea— para que la regla siga siendo aplicable sin convertirse en un ritual?