Nunca he encontrado la forma ideal de realizar revisiones de código y, sin embargo, a menudo mis clientes las requieren. Cada cliente parece hacerlos de una manera diferente y nunca me he sentido satisfecho con ninguno de ellos.
¿Cuál ha sido la forma más efectiva para realizar revisiones de código?
Por ejemplo:
- ¿Se considera a una persona como el guardián de la calidad y revisa el código, o el equipo posee el estándar?
- ¿Revisas el código como un ejercicio de equipo usando un proyector?
- ¿Se hace en persona, por correo electrónico o con una herramienta?
- ¿Evita las revisiones y utiliza cosas como programación de pares y propiedad de código colectivo para garantizar la calidad del código?
code-quality
code-reviews
Paddyslacker
fuente
fuente
Respuestas:
En mi trabajo tenemos una regla muy simple: los cambios deben ser revisados por al menos otro desarrollador antes de una fusión o confirmación en el tronco . En nuestro caso, esto significa que la otra persona se sienta físicamente con usted en su computadora y revisa la lista de cambios. Este no es un sistema perfecto, pero ha mejorado notablemente la calidad del código.
Si sabe que su código será revisado, eso lo obliga a revisarlo primero. Muchos problemas se hacen evidentes entonces. Según nuestro sistema, debe explicar lo que le hizo al revisor, lo que nuevamente le hace notar problemas que puede haber pasado por alto. Además, si algo en su código no está claro de inmediato para el revisor, es una buena indicación de que se requiere un mejor nombre, un comentario o una refactorización. Y, por supuesto, el revisor también puede encontrar problemas. Además, además de mirar el cambio, el revisor también puede notar problemas en el código cercano.
Hay dos inconvenientes principales para este sistema. Cuando el cambio es trivial, tiene poco sentido que se revise. Sin embargo, debemos cumplir estrictamente las reglas, para evitar la pendiente resbaladiza de declarar que los cambios son "triviales" cuando no lo son. Por otro lado, esta no es una muy buena manera de revisar cambios significativos en el sistema o la adición de nuevos componentes grandes.
Hemos intentado revisiones más formales antes, cuando un desarrollador enviaba un código por correo electrónico para ser revisado al resto del equipo, y luego todo el equipo se reunía y lo discutía. Esto tomó mucho tiempo de todos y, como resultado, estas revisiones fueron pocas y distantes, y solo se revisó un pequeño porcentaje de la base del código. La "otra persona revisa los cambios antes de confirmar" nos ha funcionado mucho mejor.
fuente
Me gustan las revisiones de códigos, aunque pueden ser un fastidio. La razón por la que me gustan es que tienen más ojos en el código y una perspectiva diferente. Creo que incluso con la programación de pares, el código debe revisarse. Es bastante fácil para dos personas que trabajan en el mismo código cometer colectivamente el mismo error que un par de ojos diferente no puede pasar por alto.
Si se realiza en grupo con un proyector, realmente debe revisarse individualmente antes de la reunión. De lo contrario, es solo una molesta pérdida de tiempo.
Solo he realizado revisiones de código por correo electrónico y en grupo. En general, no creo que deberían hacerse en persona. Sientes un poco más de presión para apresurarte a leer el código con alguien mirando por encima de tu hombro. Creo que una herramienta diseñada para la revisión de código sería un buen activo, ya que puede ayudar con algunos de los aspectos mundanos y debería facilitar la identificación de fragmentos de código problemáticos, entonces es por correo electrónico.
El problema de que una persona haga todas las revisiones de código es que puede ser un cuello de botella. Con estándares de codificación bien documentados y diseñados, no debería ser necesario. Dependiendo del entorno / programa de lanzamiento, puede ser una buena idea tener siempre a alguien como revisor de código en espera.
Creo que la propiedad del código es una buena idea, ya que esta persona puede hacer que sea su prioridad entender ese código y potencialmente desempeñar un papel de guardián.
fuente
En SmartBear no solo hacemos una herramienta de revisión de código , sino que también la usamos día a día. Es una parte esencial de nuestro proceso de desarrollo. Revisamos cada cambio que se registra.
Creo que es una mala idea tener un único revisor de código de gatekeeper por muchas razones. Esa persona se convierte en un cuello de botella y tiene que hacer demasiadas revisiones de código (solo para mantener el proyecto en movimiento) para ser realmente efectivo (60-90 minutos a la vez es el límite de efectividad). Las revisiones de código son una excelente manera de compartir ideas y conocimientos. No importa qué tan superestrella sea tu guardián, ellos pueden aprender de otros en el equipo. Además, hacer que todos hagan revisiones de código también crea un entorno de "propiedad de código colectivo", donde las personas sienten que poseen la calidad del código (no es solo control de calidad o el guardián).
Tenemos un documento técnico gratuito sobre " Mejores prácticas para la revisión de código de pares " que tiene 11 consejos para hacer efectivas las revisiones de código. Gran parte de esto es el mismo contenido del libro que John mencionó en una forma más destilada.
fuente
Sin excusas. Practica la programación en pareja. Es la mejor revisión de código posible. Cualquier otro mecanismo da como resultado el juego de la culpa. La programación en pareja induce espíritu de equipo y propiedad colectiva. Además, debate sus ideas con su par, falla rápidamente, toma medidas correctivas y solo el código codificado y revisado del par se compromete en el Sistema de gestión de configuración (CMS). ¡Feliz programación de pareja!
fuente
Si está trabajando en un proyecto en el que varias personas contribuirán a la base del código, se debe establecer un estándar.
En este punto, en mi experiencia, lo mejor es designar a una persona como el "rey" de la revisión del código si lo desea y lo que él / ella dice va. En este sentido, si un usuario no cumple con los estándares, el rey se encargará de ello.
Como desarrollador, reviso mi propio código muchas veces para que sea legible, sensible y todo lo demás. Usualmente usamos javadoc o similar en los idiomas con los que codificamos y usamos la etiqueta @author para adjuntar la propiedad a funciones, clases, etc.
Si una función no es correcta, hablamos con el propietario, lo mismo con la clase, etc.
fuente
En mi empresa, a cada tarea se le asigna un probador para probar la tarea, y también un revisor de código para revisar el código.
Si su producto ya se lanzó y desea asegurarse de que no está haciendo nada incorrecto (como una pérdida de memoria o una pérdida de memoria), las revisiones de código son una gran cosa. Creo que durante el desarrollo inicial antes de lanzar su producto, las revisiones de código pueden ser demasiado trabajo.
Si su equipo tiene todos los desarrolladores senior, la revisión por pares sigue siendo útil. Todos cometen errores a veces. Si su equipo tiene algunos seniors y algunos juniors, entonces deje que los desarrolladores senior hagan las revisiones de código, pero aún así también tengan revisiones de código para el código de senior.
Una cosa importante sobre la revisión de código es que puede detectar los errores que cometemos, pero no es un reemplazo para las pruebas.
fuente
Recomiendo usar revisiones de código si no está haciendo programación de pares.
No para discutir los pros y los contras con el emparejamiento, pero es difícil disputar los efectos positivos de que su código sea revisado constantemente por (al menos) otra persona. El código incluso está escrito y diseñado por (al menos) dos programadores; difícilmente puede ser mejor que eso. Estoy diciendo "al menos" porque, en mi opinión, deberías intentar cambiar mucho los pares para que todos tengan la oportunidad de trabajar con el código.
fuente
Una de las cosas que trato de hacer en las revisiones de código en las que participo es después de revisar el código yo mismo, hago un análisis estático del código, utilizo herramientas como Findbugs, PMD, JavaNCCP y otros, y miro cualquier problema que estas herramientas encuentren dentro El código a revisar. En particular, quiero ver cualquier cosa que tenga niveles de complejidad inusualmente altos, pidiéndoles que expliquen por qué ese nivel de complejidad es necesario o por qué la vulnerabilidad sugerida no es importante.
YMMV
fuente
Donde actualmente trabajo, producimos dispositivos de hardware y el software que interactúa con ellos que entra en infraestructura crítica. En consecuencia, tenemos un enfoque muy alto en la calidad de lanzamiento. Utilizamos una variante de Fagan Inspection y tenemos un proceso de revisión formal. Contamos con la certificación ISO 9001, entre otras certificaciones.
La industria de infraestructura crítica está muy interesada en la confiabilidad y la repetibilidad de la misma. :-)
fuente
En mi empresa tenemos revisiones obligatorias de códigos para programadores junior y revisiones voluntarias para personas mayores. No hay un revisor de código designado, las solicitudes de revisión se envían a todos los desarrolladores.
Este sistema funciona bien: las revisiones se realizan cuando el tiempo lo permite y los cambios pueden ser revisados por varios conjuntos de globos oculares.
La herramienta excelente y gratuita de la Junta de Revisión funciona realmente bien para nosotros, y ha demostrado ser una excelente manera de comunicar las revisiones.
fuente
En mi empresa, nunca realizamos revisiones formales de códigos antes de los registros, a menos que modifiquemos una producción muy crítica y no tengamos el tiempo para realizar nuestro proceso de control de calidad estándar.
Lo que hacemos es que cada vez que sentimos que una revisión de código sería útil, agregamos un comentario "// todo: revisión de código por Joe" al código modificado. Por lo general, seleccionamos a Joe porque posee el código modificado, pero si este criterio de selección no se aplica (por lo general, sí lo hace), simplemente elegimos a otra persona al azar. Y, por supuesto, si Joe está disponible en ese momento, usamos el viejo método de revisión sobre el hombro.
Como revisor, lo único que debe hacer es buscar periódicamente todo el código para "// todo: revisión de código por mí" , revisar los cambios y volver a ingresar el código sin el comentario "todo ..."
Si hay un problema, volvemos a los métodos de comunicación tradicionales (correo / chat / etc.).
Este método nos proporciona las dos cualidades principales que estamos buscando en un sistema de revisión:
fuente
Encontramos que la forma más efectiva de hacer revisiones de código es 1-a-1 usando github para mostrar las diferencias en la rama.
¿Se considera a una persona como el guardián de la calidad y revisa el código, o el equipo posee el estándar?
¿Revisas el código como un ejercicio de equipo usando un proyector?
¿Se hace en persona, por correo electrónico o con una herramienta?
¿Evita las revisiones y utiliza cosas como programación de pares y propiedad de código colectivo para garantizar la calidad del código?
Al igual que con todos los elementos de codificación, la respuesta correcta debe tener en cuenta:
fuente
He trabajado en muchas empresas y he visto muchos procesos. Mi equipo actual maneja esto lo mejor que he visto hasta ahora.
Utilizamos un proceso de desarrollo ágil y, como parte de eso, tenemos puertas por las que tiene que pasar cada historia. Una de esas puertas es la revisión del código. La historia no se mueve para probar hasta que se realiza la revisión del código.
Además, almacenamos nuestro código en github.com. Entonces, después de que un desarrollador finaliza su cambio, publican el enlace a los commits en la historia.
Luego etiquetamos a un desarrollador desarrollador para que lo revise. Github tiene un sistema de comentarios que permite que alguien comente directamente en la línea de código en cuestión. Github luego envía un correo electrónico a la distribución, por lo que a veces recibimos ojos adicionales de algunos de nuestros otros equipos.
Este proceso nos ha funcionado muy bien. Utilizamos una herramienta de proceso ágil que facilita la publicación de los compromisos y facilita la comunicación.
Si un problema es particularmente difícil, nos sentaremos y lo discutiremos. Esto funciona porque es parte integral de nuestro proceso y todos han comprado cómo funciona el proceso. Podemos volver a colocar los tickets en progreso si la revisión del código resulta en un reprocesamiento necesario y luego se puede revisar nuevamente después de realizar los cambios, o el revisor puede notar en la historia que arreglar los artículos es suficiente y no necesita revisarse nuevamente.
Si las pruebas devuelven algo, se remonta al progreso y cualquier cambio adicional también se revisa.
fuente