La revisión de código requiere lectura
(hauleth.dev)- La revisión de código no es un trámite formal previo al despliegue, sino un proceso que traslada de una sola persona a una responsabilidad de equipo la carga por fallas, problemas de seguridad y eliminación de datos.
- Mejores evaluaciones, pruebas, feature flags, guardrails y observabilidad pueden ser respuestas para reducir la ansiedad de desplegar código no leído, pero aquí se critica ese enfoque por perder de vista el objetivo de la revisión: distribuir la responsabilidad.
- Pedir que se apruebe sin leer equivale a hacer que una persona pulse un botón sin pensar, lo que lleva a la sátira de la button roulette, donde se fusiona un PR aleatorio con todo el CI en verde.
- La revisión de código hace que integrantes del equipo vean distintas partes de una base de código grande, reduciendo el bus factor, y funciona como un mecanismo de aprendizaje para que quienes se integran al equipo conozcan el código y la cultura de código.
- La conclusión es que, para imponer despliegues a producción de código no leído, haría falta una exención escrita de responsabilidad por bugs, problemas de seguridad, caídas del servicio, etc., y que conseguir esa exención sería difícil.
El propósito de la revisión es distribuir responsabilidad, no solo aprobar
- El punto de partida es la pregunta “¿Qué se necesita para sentirse cómodo desplegando a producción código que no has leído?” planteada en el texto de Charity Majors “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy”.
- Respuestas como mejores evals, pruebas, feature flags, guardrails, observabilidad, separación de dependencias, reducción del blast radius y empezar por cambios pequeños fuera del camino crítico se presentan como formas de esquivar el punto central de la revisión.
- El propósito de la revisión es no dejar en una sola persona la carga por fallas, problemas de seguridad o eliminación accidental de datos, sino repartirla como responsabilidad de equipo entre quien escribe y quienes revisan.
- Si se exige “aprobar sin leer”, entonces se debilita la razón para hacer que una persona pulse manualmente un botón, y aparece la sátira llamada
button roulette, que consiste en fusionar al azar uno de los PR asignados con todo el CI en verde.
Lo que se pierde en una revisión que no lee
- La revisión de código obliga a que integrantes del equipo vean otras partes de la base de código, compensando la limitación de que en sistemas demasiado grandes nadie puede conocer siempre todas sus partes.
- El proceso de revisión ayuda a reducir el bus factor y a que varias personas del equipo se familiaricen más con la base de código y con la cultura de código.
- Si todos aprueban sin leer, se pierde ese efecto de aprendizaje, el bus factor sube a 1 y además aparece el problema de externalizarlo a un tercero.
- La respuesta se resume en que, para aceptar la exigencia de desplegar a producción código no leído, la persona que da esa instrucción tendría que ofrecer una exención escrita de responsabilidad por bugs, problemas de seguridad, caídas del servicio, etc.
1 comentarios
Opiniones en Lobste.rs
Me genera un fuerte rechazo la idea de que el propósito del review sea repartir la responsabilidad
Si el código mergeado a main rompe producción, es responsabilidad de quien lo escribió, no mía ni de todo el equipo
Como profesional, es un trabajo con tu firma; si el diseño de un puente sellado con una licencia P.E. de ingeniería civil mata a alguien, también es su trabajo y su responsabilidad
La responsabilidad del equipo, como desarrolladores y administradores del codebase, está en hacer que nadie pueda romper producción
Hacer merge a main significa que alguien lo revisó, evaluó los cambios, discutió el diseño, pidió varias correcciones y luego lo aprobó
Nadie construye la Torre Eiffel solo, y culpar a una persona en el trabajo solo genera resentimiento y una cultura tóxica
Si es un patrón de conducta repetido, entonces eso le corresponde a HR
Si la responsabilidad es 0, el reviewer no sirve para nada y no hay razón para hacer review
Repartir la responsabilidad es más bien un resultado; el objetivo central es detectar errores que solo es fácil pasar por alto, pero que entre dos o más personas cuesta más que se escapen
Aun así, creo que en software el review se usa en exceso, y que el review no puede ser un sustituto de la ingeniería
No me parece preciso equiparar “aprobar sin leer el código” con “aprobar sin pensar”
Por ejemplo, ¿qué pasa si el programa viene con una prueba de corrección, en el PR se pueden leer las definiciones y teoremas, el CI verifica con una herramienta determinista que el programa y la prueba coinciden, y además revisa requisitos no funcionales como relación de contraste, benchmarks de rendimiento y latencia de cola, mientras que los cambios de UI se pueden probar fácilmente con un prototipo?
Incluso en un mundo así, queda la duda de si habría que obsesionarse tanto como ahora con leer el código línea por línea
Incluso hoy, la mayoría escribe SQL sin verificar una por una que el plan de ejecución coincida exactamente con lo que quería
El texto original se lee más como “definamos un mundo ideal en el que sintamos que se puede desplegar sin leer literalmente el código” y luego pregunta “¿cómo podríamos movernos con suavidad desde el presente hacia ese mundo?”
Se puede discutir qué tan lejos está la industria, o una empresa o codebase en particular, de ese punto, pero si uno imagina en serio ese mundo ideal, la mayoría probablemente pensará en varios criterios
Entiendo que, por la dirección actual de la industria, mucha gente lo interprete como “sin pensar”, pero no creo que eso sea lo que Charity quiso decir
Eso solo es posible leyendo el código, por buenos que sean los tests
Si Alice mete código, Bob lo revisa y luego Alice se va de vacaciones, Bob debería conocer suficientemente esa parte y sentirse responsable como para corregirla o agregar nuevas funciones
Si Bob solo le pone un sello a la prueba de corrección, después no queda preparado para trabajar con ese codebase
Aunque haya participado en el proceso del commit, si no aumentó su conocimiento ni su sentido de pertenencia, en la práctica es como si no hubiera participado
La diferencia es que el compilador es determinista, mientras que un LLM es una herramienta no determinista que potencialmente genera tests dudosos
Ya tenemos programas que convierten instrucciones o código escritos por humanos en código legible por máquinas o en una representación intermedia, y como garantizan cierta relación entre la entrada y el resultado generado, podemos confiar en la salida sin necesidad de inspeccionarla
A veces se lee la salida del compilador con herramientas como Godbolt para optimización, pero fuera de eso por lo general no hace falta
Intentar esto en otro nivel de abstracción no determinista puede parecer plausible, pero no deja de ser una imitación de las garantías de corrección que ofrece un compilador, y al final va a fallar
Creo que el debate sobre los LLM, en un sentido más fundamental, es un síntoma de que los lenguajes de programación deterministas existentes no son lo bastante expresivos y las herramientas no son lo bastante eficaces
Puede sentirse como si los LLM resolvieran ese problema, pero en realidad no son la solución; más bien agregan otra capa de indirección y costo de rendimiento sobre una base que ya es demasiado limitada
Se parece más a un pseudo-compilador caro y lleno de bugs que corre sobre un intérprete y, a su vez, sobre código máquina compilado
Por eso me parece un callejón sin salida técnico
Para las empresas puede ser una vía de ganancias a corto plazo, pero no creo que mejore el software ni la relación entre los humanos y la forma en que usan y construyen software
El software es más que una tecnología para lanzar productos
Pensarlo por casos de uso ayuda
Si solo se trata de subir nuevo JavaScript para la UI de una aplicación interna, me parece bien no revisar necesariamente hasta el CSS