¿Cuál es el propósito de una revisión de código?

76

Estoy en el proceso de intentar vender a mi organización el valor de las revisiones de código. He trabajado en varios lugares donde estaban empleados. Los he visto acostumbrados a elegir opciones de estilo y decisiones funcionales, y los he visto como nada más que una verificación intestinal para asegurarme de que no se implemente nada peligroso. Mi intuición es que el propósito más efectivo está en algún lugar entre las dos opciones.

Entonces, ¿cuál es el propósito de una revisión de código?

code-reviews  theory 
— SoylentGray
fuente
16
Relacionados (desbordamiento de pila): El propósito del Código Opiniones
— Yannis
16
- ¿Cómo saber si ha escrito un código legible y fácil de mantener? - Tu compañero te lo dice después de revisar el código. Justificación: No puede determinar esto usted mismo porque sabe más como autor que lo que el código dice por sí mismo. Una computadora no puede decirle, por las mismas razones que no puede decir si una pintura es arte o no. Por lo tanto, necesita otro ser humano, capaz de mantener el software, para ver lo que ha escrito y dar su opinión. El nombre formal de dicho proceso es "Revisión por pares" .
— mosquito
3
"¿Cuál es el propósito de una revisión de código?" para evitar que los desarrolladores escriban código terribad y guiarlos en la dirección correcta.
— zzzzBov
77
Parece revisión de código podría tener una respuesta indirecta a esta pregunta .. simplemente navegar en las preguntas y respuestas allí, con el propósito de una revisión de código se vuelve bastante evidente :)
— Mathieu Guindon
3
Me pregunto cuántas veces los programadores han descubierto errores en su propio código simplemente a través del simple proceso de explicar su código durante una revisión.
— inactivo el

Respuestas:

75

Existen varias razones por las que desearía realizar una revisión del código:

  • Educación de otros desarrolladores. Asegúrese de que todos vean la modificación asociada con una corrección o mejora de defectos para que puedan entender el resto del software. Esto es especialmente útil cuando las personas trabajan en componentes que necesitan integrarse o en sistemas complejos donde una persona puede pasar largos períodos sin mirar ciertos módulos.
  • Encontrar defectos u oportunidades de mejora. Tanto el código entregable como el código de prueba y los datos se pueden examinar para encontrar debilidades. Esto garantiza que el código de prueba sea robusto y válido y que el diseño y la implementación sean consistentes en toda la aplicación. Si es necesario realizar cambios adicionales, aprovecha la oportunidad más cerca del punto de entrada.

Existen varios casos comerciales para realizar revisiones:

  • Encontrar defectos o problemas que tendrían que modificarse más cerca de su inyección. Esto es mas barato.
  • Conocimiento compartido del sistema y entrenamiento cruzado. Menos tiempo para que un desarrollador se ponga al día para realizar cambios.
  • Identificación de posibles mejoras al sistema.
  • Abrir la implementación para garantizar que los evaluadores brinden una cobertura adecuada. Convertir una caja negra en una caja gris o blanca desde una perspectiva de prueba.

Si está buscando una discusión exhaustiva sobre los beneficios y las estrategias de implementación para las revisiones por pares, le recomiendo que revise las revisiones por pares en software: una guía práctica de Karl Wiegers .

— Thomas Owens
fuente
77
+1, creo que viste bien los puntos principales, con las prioridades correctas. Mantener el diseño coherente cuando se trata de compañeros de trabajo que constantemente encuentran soluciones "WTF" muy creativas solo se puede lograr mediante revisiones periódicas del código.
— Doc Brown
Hacemos revisiones de código en nuestro código JavaScript, principalmente para garantizar que los desarrolladores se adhieran a los estándares descritos, usando el patrón establecido al diseñar módulos, usando los componentes provistos y no comiencen a codificar ninja (intencionalmente o no) alrededor de problemas que ya tenemos soluciones. para. También son geniales para detectar a alguien que sobrescribe accidentalmente el thiscontexto, no lo usa .hasOwnPropertyen lugares donde debería estar, etc., etc. - Por lo tanto, principalmente para los estándares. En un lenguaje administrado como C #, por supuesto, tiene varias razones menos que las de los lenguajes dinámicos.
— No
1
Hasta ahora, su respuesta solo alude a mejoras en la corrección del código. No aborda la legibilidad / mantenibilidad del código, que rara vez puede ser cuantificado con precisión por el desarrollador en desarrollo.
— ArTs
51

Las revisiones de código son una herramienta para la transferencia de conocimiento .

  • Cuando los desarrolladores revisan el código de los demás, se familiarizan en todas las áreas del sistema. Esto reduce el factor de bus de un proyecto y hace que los desarrolladores sean más eficientes cuando tienen que hacer mantenimiento en una parte del sistema que no escribieron.

  • Cuando un programador junior revisa el código de un senior, el programador junior puede aprender trucos, de lo contrario solo se aprende a través de la experiencia. Esto también puede funcionar como un correctivo contra código demasiado complicado.

    Una revisión exhaustiva del código requerirá verificaciones frecuentes de diversos documentos. Es una excelente manera de aprender un idioma o API.

  • Cuando un programador senior revisa el código de un junior, esta es una oportunidad para resolver los problemas antes de que se traduzcan en deudas técnicas. Una revisión del código puede ser un buen escenario para guiar a los programadores junior.

Las revisiones de código no son sobre:

  • ... encontrando errores. Para eso están las pruebas. Todavía ocurrirá con frecuencia que una revisión de código encuentra algún problema.

  • ... quisquilloso en cuestiones de estilo: conformarse con un estilo y utilizar formateadores automáticos para imponerlo. Pero hay muchas cosas que una herramienta automatizada no puede verificar. Las revisiones de código son un buen lugar para asegurarse de que el código esté suficientemente documentado o autodocumentado.

— amon
fuente
2
su último punto sobre los problemas de estilo con los que no estoy totalmente de acuerdo: acabamos de tener una experiencia desgarradora revisando el código de un desarrollador junior y la queja más evidente fue en realidad sobre el estilo, pero no el tipo de problemas de estilo que son fácilmente programáticos forzado ... waaaaaay demasiados if para declaraciones de edgecases, etc; problemas que sí podría hacer que una computadora encuentre en algunos casos, pero la mayoría no fueron problemas que valga la pena encontrar genéricamente por script. Nos lleva 30 segundos de lectura comenzar a verlo, otros 30 para explicarle al desarrollador y, con suerte, enmendar el problema. Todavía en estado de shock: /
— pacifista
77
@pacifist Ese no es el tipo de estilo que el respondedor está describiendo. El estilo se trata de ubicaciones de llaves, sangrado, etc. Si su desarrollador junior está usando demasiadas declaraciones if, tiene un problema completamente diferente del estilo; Un atributo general de la codificación ESTILO es que no afecta el rendimiento. Y creo que una cantidad significativa de declaraciones if afectará el rendimiento.
— Pimgd
12
Al hacer una revisión, a menudo veo cosas en las que pienso "esto parece un error", luego escribo un caso de prueba específico para demostrar que es un error. Entonces, uno de los muchos objetivos de las revisiones de código es encontrar errores. Es por eso que creo que el punto de vista "revisión de código o pruebas" es un poco demasiado simple.
— Doc Brown
2
Además de @DocBrown, hay casos que no pueden ser fácilmente comprobables: carreras de datos, algunos tipos de puntos muertos, bloqueos en vivo, comportamientos / valores indefinidos (principalmente en C / C ++ pero el orden de los elementos en las tablas hash también en indefinido) o puerro de recursos (abrir un archivo en un bucle podría ser una mala idea incluso con GC). Algunas de esas cosas se pueden detectar mediante un análisis estático suficientemente inteligente del compilador .
— Maciej Piechotka
2
@pacifist su ejemplo específico sería totalmente criticado en una revisión de código. También sería una señal de alerta para cualquier analizador de código estático (¡Complejidad ciclomática 17!). Una revisión de código identificaría rápidamente esta función como un problema en el estilo semántico (¡o incluso el algoritmo!). Sin embargo. Este tipo de problema no es solo un problema de "estilo". Si lo trata como tal, tendrá un código realmente desagradable en su repositorio muy pronto; es solo "estilo", después de todo.
— Pimgd
12

Lo más valioso que personalmente obtengo de una revisión de código es la confianza de que el código es claro para otra persona. ¿Las variables están claramente nombradas? ¿El propósito de cada fragmento de código es razonablemente obvio? ¿Se aclara algo ambiguo con un comentario? ¿Los casos límite y los valores válidos para los parámetros se describen en los comentarios y se verifican en el código?

2
Esto no parece ofrecer nada sustancial sobre las 4 respuestas anteriores
— mosquito
2
@gnat: Las otras respuestas abordan la transferencia de conocimiento y la detección de errores. Estos son importantes, pero hay más en una revisión de código.
1
Por lo que puedo decir, hay más partes que se abordan razonablemente en esta respuesta : "Si está buscando una discusión exhaustiva sobre los beneficios y las estrategias de implementación para las revisiones por pares, le recomiendo que revise las revisiones por pares en el software: Una guía práctica de Karl Wiegers ". Esta respuesta también lo cubre: "un correctivo contra un código demasiado complicado"
— mosquito
2
@gnat Enfatiza un aspecto diferente de los puntos planteados en otras respuestas. ¿Alguna vez te ha intrigado tu propio código que escribiste hace seis meses? La revisión de código le permite acelerar ese proceso. Si su colega está desconcertado por su código, aún puede aclararlo mientras el problema aún está fresco en su memoria.
— 200_success
1
@ 200_success quizas. Pero este punto, si está allí, se ve muy mal presentado. Incluso su comentario logra comunicarlo mejor que esta "respuesta". Sin mencionar que solo repite lo que se señaló en un comentario anterior que se refiere a una respuesta canónica que explica esto en una pregunta relacionada
— mosquito el
7

Me gustaría agregar dos áreas que no están cubiertas por las otras excelentes respuestas:

Una gran razón para las revisiones de código es el efecto Hawthorne, que en nuestro caso se traduce en: Si sabe que alguien va a mirar su código después, entonces es mucho más probable que lo escriba mejor en primer lugar.

Otra gran razón es para mejores prácticas de desarrollo seguras. Solo hay que mirar el error de Goto de Apple (una línea de código duplicada accidental) o el error Heartbleed (un error básico en la validación de entrada) para comprender la importancia de las revisiones de código adecuadas en un ciclo de vida de desarrollo seguro.

— Chris Knight
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.