Aquí vamos de nuevo: ves la notificación, y sientes esa resistencia familiar. La revisión del código a menudo se siente cognitivamente pesada y no determinista: demasiados caminos a seguir, demasiada ambigüedad, demasiadas opiniones. Pero ¿cómo maximizar el valor de una revisión sin agotar a los revisores o atrapar al equipo en debates interminables? He destilado un proceso de revisión saludable y sostenible en un acrónimo: Prioriza lo que realmente importa - desde la lógica empresarial y los casos de punta a la fiabilidad y la legibilidad - mientras mantiene las opiniones subjetivas en control. PERFECT ¿Qué es la Revisión de Código? La revisión de código es un proceso de verificación de que el código cumple con un conjunto definido de requisitos. puede ser realizada por otro desarrollador, por el propio autor, o con la ayuda de herramientas automatizadas. Estos requisitos se definen por necesidades empresariales o técnicas.En el desarrollo de productos o software personalizado, siempre se impulsan en última instancia por los objetivos empresariales.Tales requisitos pueden incluir calidad de código, prevención de problemas críticos, ciclos de desarrollo más rápidos, crecimiento del equipo y otros factores. Por ejemplo, el deseo personal de un desarrollador de escribir código perfectamente limpio no es, por sí solo, una razón válida para la revisión del código. Sin embargo, cuando se demuestra que el código limpio reduce los errores de producción, mejora la calidad general del software, o impacta positivamente en la motivación del equipo y la sostenibilidad, se convierte en un propósito legítimo de la revisión del código. ¿Realmente necesitas una revisión de código? La revisión del código puede llevar hasta el 20-30% del tiempo de trabajo de un desarrollador, incluyendo tanto la revisión del código como la espera de revisiones. Idealmente, debe analizar el equilibrio entre el tiempo y el esfuerzo gastado en la revisión de código y el valor empresarial que proporciona, preferiblemente utilizando métricas, y decidir si las mejoras resultantes justifican ese coste. Cada proyecto debe encontrar su propio equilibrio aceptable. La respuesta corta es casi siempre Incluso una revisión ligera pero estructurada suele costar poco y proporcionar un valor significativo, lo que hace que sea razonable de usar en la mayoría de los proyectos. Sin embargo, si la revisión del código se convierte en un "culto de carga", cuando las revisiones solo existen formalmente, las aprobaciones ocurren sin una discusión real, y no se evitan problemas reales, entonces simplemente no necesita una revisión peer-to-peer en esta forma. yes Si un proceso de revisión de código expone problemas de comunicación o ralentiza significativamente la entrega, los equipos pueden verse tentados a abandonarlo por completo.Aunque esto puede traer alivio a corto plazo, el resultado a largo plazo suele ser negativo.Un enfoque más eficaz es abordar los problemas subyacentes, como las brechas de comunicación o un proceso de revisión no estructurada, en lugar de eliminar la revisión de código por completo. Principios de Revisión del Código Perfecto A continuación, describo un conjunto de principios de revisión de código ordenados por su importancia.Estos principios describen un proceso ideal de revisión de código que cubre todos los aspectos esenciales.Representan un enfoque general y estandarizado y pueden adaptarse al contexto de un proyecto específico. Para hacerles más fáciles de recordar, uso el acrónimo , donde cada letra corresponde a la primera letra de un principio. PERFECT   Important: Los revisores siempre deben tener en cuenta que sólo porque no les gusta una pieza de código, no significa que el código sea malo. Si tiene algo que comentar, describa claramente lo que está mal y por qué, apoye su feedback con argumentos concretos, y proponga una alternativa - al menos a un nivel alto. Es importante: 1 Objetivo ✔️ Code solves the task. Este es el requisito primario y no negociable. Si el código no resuelve ninguna tarea, no tiene valor y probablemente no debe fusionarse en absoluto. Para un revisor, el primer paso es comprender qué es la tarea y qué resultado se espera que produzca el código. Esta información puede provenir de un boletín de seguimiento del trabajo, la descripción de la revisión o incluso una discusión directa con colegas. Una vez que la tarea está clara, el revisor debe verificar que el código realmente la resuelve.Una técnica útil es delinear aproximadamente cómo se abordaría la solución y compararla con el código implementado. Sin esto, el valor de la revisión se acerca a cero.No importa cuán limpio o legible sea el código, tiene poco sentido si no resuelve la tarea pretendida. Casos de Edge ✔️ Edge cases are handled. Trate de identificar los casos de esquina de negocios y técnicos y verificar que el código los maneja correctamente. Esto incluye entradas inesperadas, resultados de cálculo inusuales, requisitos o condiciones omitidos, valores límite, límites de tipo, nulidad y muchos otros. Para un proyecto específico, puede ser útil mantener una lista de verificación dedicada. Una parte significativa de los errores de producción son causados por los casos de borde olvidados.Si al menos una otra persona identifica incluso algunos de ellos, la probabilidad de problemas de producción se puede reducir drásticamente. Uno de los tipos interesantes de casos de borde que vale la pena prestar atención es "casos imposibles". Estas son situaciones que son intrínsecamente peligrosas pero parecen inaccesibles en el estado actual del código. Por ejemplo, acceder a un valor de una opción o tal vez tipo sin verificar explícitamente su presencia. Esto puede ser seguro en el estado actual del código, pero a menudo es difícil predecir cómo los cambios futuros, especialmente aquellos realizados sin tener plena conciencia de las suposiciones existentes, afectarán a esta lógica. En la práctica, tales casos tienden a acumularse. Mientras que una sola instancia puede no causar problemas, un mayor número de ellos aumenta significativamente el riesgo en general. Una buena práctica es usar las características del lenguaje como se pretendía, imponer controles explícitos, manejar estados inesperados explícitamente 3 Fiabilidad ✔️ Code does not have performance and security issues. Cualquier proyecto relacionado con el comercio o crítico con la misión debe tener requisitos de rendimiento y seguridad estrictos. Incluso si un proyecto no está directamente relacionado con el dinero o la seguridad humana, a menudo es difícil predecir cómo puede ser reutilizado, integrado en otros sistemas o evolucionar a lo largo del tiempo. Por esta razón, es una buena práctica verificar siempre que el código cumple al menos las expectativas básicas de rendimiento y seguridad. Por ejemplo, que no introduce barreras evidentes en el rendimiento y que las interfaces públicas están correctamente protegidas. Incluso las comprobaciones simples ayudan a prevenir una gran clase de problemas que de otro modo costarían mucho más para corregir más tarde, cuando aparecen problemas reales en la producción. Desde una perspectiva de fiabilidad, la revisión del código suele centrarse en las áreas en las que es más probable que ocurran fallos, comportamientos inseguros o rendimiento degradado. Esto incluye la complejidad del tiempo y la memoria (apropiada para el volumen de datos esperado, el tiempo de ejecución y el uso de la memoria), la validación de entrada y salida, el almacenamiento de credenciales, las integraciones rotas, la invalidación del cache y preocupaciones similares. 4 Forma ✔️ Code aligns with design principles. Este alineamiento ayuda a estandarizar la representación del código, haciendo que sea más fácil de leer y entender, tanto para otros desarrolladores como para el autor original en el futuro. A diferencia de la corrección comercial, el rendimiento o la seguridad, las preguntas de diseño tienden a ser más subjetivas.Por esta razón, los argumentos claros y los acuerdos compartidos son esenciales para minimizar las discusiones y los conflictos no constructivos durante la revisión. Hay muchos principios bien conocidos que pueden ser aplicados, como SOLID, KISS, DRY, y otros. Algunos de ellos siguen siendo en gran medida subjetivos, mientras que otros proporcionan criterios y orientaciones más concretos. Sin embargo, independientemente del principio específico, la mayoría de las discusiones de diseño terminan en gestionar la cohesión y el acoplamiento. Por esta razón, recomiendo desarrollar una comprensión sólida de estos conceptos y aplicar el Principio en el contexto de su proyecto, tratando otros principios de diseño como ejemplos o interpretaciones específicas de esta idea central. High Cohesion / Low Coupling 5 La evidencia ✔️ Tests and CI pipelines pass. Las pruebas facilitan el desgaste, la refactorización y la introducción de nuevos cambios, al tiempo que reducen el número de errores de producción y mejoran la estabilidad general.Pipelines de CI automatizados ayudan a automatizar parcialmente la revisión del código y garantizan que el código esté en un estado correcto y desplegable. Si existen pruebas, tuberías de construcción u otras verificaciones automatizadas, deben pasar. De lo contrario, toda la revisión de código puede perder su valor, ya que la reparación de tuberías rotas puede introducir cambios significativos que requieren la revisión del código. Además, si las pruebas o tuberías se rompen o se ignoran permanentemente, generalmente significa que ya no se utilizan activamente, contienen comportamientos desactualizados y pueden causar más confusión que beneficio. Si hay acuerdos establecidos en torno a las pruebas de escritura, los cambios deben ser cubiertos por las pruebas en consecuencia. Estas pruebas también necesitan ser revisadas utilizando los mismos principios que el código de producción. Al menos, deben validar la lógica prevista, seguir la estructura y las convenciones acordadas, y tener un rendimiento aceptable. Idealmente, el código de producción no debe incluir lógica especial escrita sólo para la prueba. 6 Claridad ✔️ Code clearly communicates its intent. Diferentes personas tienen diferentes maneras de leer y entender el código, diferentes antecedentes y diferentes niveles de experiencia. Como resultado, la claridad del código es a menudo subjetiva, y es difícil escribir código que sea igualmente fácil de entender para todos. Sin embargo, deberíamos esforzarnos por hacer la intención del código lo más clara posible. Idealmente, el código debe ser comprensible sin leer cada línea - debe ser posible leerlo diagonalmente. Esto simplifica y reduce significativamente el coste de revisión, mantenimiento, borrado y introducción de nuevos cambios. Pueden incluir convenciones para nombrar, estructura de archivos (un buen criterio es la capacidad de encontrar cosas sin buscar), longitud de bloque, nicho, orden de declaraciones, documentación, uso de comentarios y otros. Si no hay criterios objetivos acordados y el código no es explícitamente inexplicable, prefiero dejar estas decisiones al autor, incluso si personalmente no estoy de acuerdo con algunas opciones.En la práctica, tales detalles rara vez son críticos, pero empujando una opinión personal demasiado duro a menudo crea tensión innecesaria durante la revisión. 7 El sabor ✔️ Personal preferences are noted but do not block changes. Cada revisor trae sus propios hábitos de desarrollo y preferencias personales.Cuanto menos acuerdos de revisión escrita tiene un equipo, más comentarios de revisión opinados tienden a aparecer.Tales comentarios ralentizan el proceso de revisión, crean fricción innecesaria y pueden eventualmente conducir a la inconsistencia del código. Al mismo tiempo, muchos de estos comentarios todavía tienen sentido y pueden apuntar a problemas reales. No deben ser ignorados por completo. Sin embargo, es importante establecer expectativas claras: si el comentario de un revisor no está respaldado por un razonamiento claro y una propuesta constructiva, el autor puede optar por no abordarlo. Opiniones valiosas pueden ser revisadas más tarde y convertidas en acuerdos compartidos. Una vez que algo se convierte en un acuerdo, no tiene que ser completamente objetivo - simplemente se convierte en una parte de cómo funciona el equipo. Cómo hacer que realmente funcione Conocer los principios adecuados de revisión de código y actuar de forma consistente sobre ellos son dos cosas muy diferentes.Aunque no hay una receta universal que funcione para cada equipo, puedo proporcionarle varias recomendaciones básicas pero efectivas. El objetivo principal es hacer que la revisión de código no sea una actividad cognitivamente exigente que drene recursos excesivos de los desarrolladores, sino un proceso claro y rutinario. Idealmente, los revisores deben seguir un conjunto de convenciones predefinidas en lugar de sobrepensar o procrastinar, prestando más atención a los problemas reales y logrando una calidad general aún mayor de la revisión. 
 
 
 
 
 
 
 
 
 
 
 Establish written review conventions. These should include the principles described above, their concrete implementation in the context of your project, and any other aspects you want reviewers to pay attention to. 
 
 
 Keep conventions up to date and actionable. All criteria should be usable during review at any moment. Whenever you notice a recurring review pattern (comment → discussion → fix), turn it into a convention. 
 
 
 Require self-review before peer review. Everyone should perform self-review using the same conventions before sending code for review by others. This saves time for all participants and helps reviewers build experience and efficiency over time. 
 
 
 Integrate code review into the development process. Define clear rules for selecting reviewers, the number of reviewers, how comments are written and resolved, how updates are communicated, approval rules, review status visibility, and review SLAs. There should be a clear answer to common questions around code review, instead of uncertainty, anxiety, and unnecessary stress. 
 
 Automate everything that can be automated. 
 
 
 Stop approving with "LGTM". "LGTM" (Looks Good To Me) often signals that the reviewer did not fully understand the changes and simply wants to move on. While reviewers are not responsible for the final outcome of approved code, such approvals reduce the value of the review itself. 
 
 
 Practice code review whenever possible. Code review is a skill that improves through deliberate practice. The more experience reviewers gain, the less effort reviews require and the more effective they become. This can be supported through attention to structure, constructive feedback, short workshops, and other focused practices. ¿Realmente necesitas todos los principios? Incluso si no tiene la intención de utilizar todos estos principios en la práctica, comprenderlos sigue siendo útil.Ellos ayudan a dar forma a una visión técnica, apoyar discusiones informadas, y traer estructura al proceso de revisión de código al aclarar cuando diferentes enfoques tienen sentido. Como se mencionó anteriormente, la revisión de código no es una única técnica sino un espectro de prácticas. Los principios descritos anteriormente ayudan a maximizar los beneficios de la revisión de código en general. Sin embargo, en un proyecto específico, algunos enfoques pueden requerir más esfuerzo que el valor que aportan. En tales casos, es razonable aplicar selectivamente solo aquellas prácticas que son verdaderamente beneficiosas en el contexto de su proyecto.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Un proceso de revisión de código sostenible para equipos ocupados (PERFECT)

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una breve introducción a la teoría del cerebro de Boltzmann

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Una breve introducción a la teoría del cerebro de Boltzmann

El modelo Bitcoin UTXO, impulsando un ecosistema único

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps