Martin (arp242) acaba de heredar un proyecto legacy. Lo primero que hizo —antes siquiera de leer el código— fue ejecutar esto:
git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -lResultado: 295. En 13 años, todos los mensajes de commit del proyecto suman 295 líneas. Si quitas los commits automáticos de dependabot, los «revert commit» y los «fix typo», quedan 167. Una línea al mes de media.
No hay documentación. Prácticamente no hay comentarios. Y las tres semanas de handover con el desarrollador anterior tuvieron la misma calidad comunicativa que el historial de commits. «Nunca había entendido tan bien a Jack Bauer y sus métodos extremos para obtener información», escribe Martin. «Lamento no haberlo intentado».
Las dos caras de la valla
El principio de la valla de Chesterton lleva años circulando en ingeniería de software: ves un fragmento de código extraño, quieres borrarlo, pero antes deberías averiguar por qué está ahí —quizá protege contra un peligro que no alcanzas a ver—. Es la cara amable. La cita original de G.K. Chesterton dice que un reformador, antes de derribar una valla, debe poder responder a la pregunta de «por qué se construyó ahí».
Martin nos muestra la cara oculta: el dedo medio de Chesterton.
«Sí, hicimos todas estas cosas raras, pero no pensamos contarle a nadie por qué. Que os den.»
El significado de una valla depende del contexto. Cuando el contexto desaparece junto con los mensajes de commit, los comentarios y la documentación, la valla deja de ser protección y se convierte en maldición. El desarrollador que llega después se enfrenta a una ruina sin inscripciones: un montón de trastos indescifrables que le obligan a elegir entre meses de arqueología o derribarlo todo y rezar.
Tres tipos de commit tóxico
Martin no hace una taxonomía sistemática, pero de su descripción se desprenden tres patrones de commit letales:
«fix page A» — el título hueco. Incluso cambios masivos llevan un título que no dice nada. El cuerpo, vacío. Quien venga detrás tendrá que hacer ingeniería inversa del diff línea a línea para adivinar la intención. Precisión: más o menos la de leer huesos.
Commit WIP — la obra a medio hacer. Refactorizaciones inacabadas esparcidas por el código. Cadáveres de funcionalidades viejas que nadie limpió. Features añadidas que nunca se enlazaron ni fueron usadas por nadie, durmiendo en las profundidades del repo. No son bugs, pero son peores: un bug al menos alguien lo reporta.
«No hacía falta» — el Gap de Chesterton. Martin introduce un concepto simétrico: si la valla de Chesterton es «alguien construyó un muro y no te dice por qué», el Gap de Chesterton es «alguien construye un muro donde no había ninguna necesidad» —capas de abstracción superfluas, sobreingeniería, arquitecturas para una necesidad futura que jamás llegará—.
Los tres patrones juntos crean un desastre arqueológico: el que hereda el código no solo tiene que entender qué hace, sino inferir por qué lo hicieron y qué pretendían hacer cuando lo dejaron a medias.
Tres preguntas
Martin propone un marco para mensajes de commit con los pies en la tierra: tres preguntas.
- ¿Qué has cambiado?
- ¿Por qué lo has cambiado?
- ¿Por qué esta solución es buena?
«Implement new feature X» a veces basta, pero casi siempre hay algo que contar —aunque solo sea explicar la elección de un parámetro, la procedencia de una condición de contorno, una alternativa que se descartó—.
No hace falta un inglés impecable. No hace falta escribir un paper de filosofía. Olvidar algún detalle no es ideal pero se acepta (aunque contarlo es mejor). El mínimo es: que haya algo. Cualquier intento a medias es infinitamente mejor que el vacío.
El juicio de Martin es tajante: «Escribir mensajes de commit no es un extra opcional. Es parte del trabajo. No escribirlos es no hacer tu trabajo».
El consenso en Lobsters
El artículo sumó 106 puntos en Lobsters y los comentarios apenas registran disenso. Un usuario escribe: «Me he pasado cinco años recorriendo el mundo reparando este tipo de bases de código. Duermo con el Working Effectively with Legacy Code en la mesilla».
Otro, david_chisnall, da en el clavo del valor del code review: «El mayor beneficio del code review es que te obliga a escribir todo ese contexto que no habías verbalizado. Lo que tú mismo no sepas explicar, lo que el revisor no entienda, va a los comentarios».
Un escenario se repite en los testimonios: heredar el código de un compañero que se ha ido. Cuando no puedes preguntarle a nadie, el historial de commits es la última fuente de información. Si está vacío, lo que tienes delante no es código: es un yacimiento arqueológico donde todas las inscripciones han sido borradas a conciencia.
Por qué esto importa más que nunca ahora
Las herramientas de codificación con IA (Codex, Claude Code, Copilot) están acelerando la producción de código en un orden de magnitud, pero los mensajes de commit no se generan solos —o peor aún, los que se autogeneran («Add files via upload», «Update code») son más dañinos que el silencio porque crean la ilusión de que «hay documentación»—.
Un proyecto con 13 años y solo 295 líneas de commit será más común en la era de la programación asistida por IA, no menos. Porque producir código es más rápido que escribir un comentario, y la IA aún no tiene el criterio para pensar «aquí debería explicar por qué elegí esta estructura de datos y no la otra».
Martin cierra con esto: «Si no escribes nada, le estás levantando el dedo medio a cada persona que venga detrás». La metáfora es brusca, pero precisa. Un commit message no es una nota para ti mismo: es para el tú de dentro de tres años, para el colega que herede tu trabajo, para el que está de guardia a las tres de la mañana rastreando una regresión.
Este artículo se basa en información pública y discusiones de la comunidad. Si tienes experiencia directa en este ámbito, no dudes en señalar carencias o imprecisiones.