¿Qué debería venir primero: prueba o revisión de código?

Soy bastante nuevo en la programación de patrones de diseño y ciclos de vida y me preguntaba, ¿qué debería venir primero, la revisión de código o las pruebas, en relación con que son realizadas por personas separadas?

Por un lado, ¿por qué molestarse en revisar el código si nadie verificó si incluso funciona? Del otro, algunos errores se pueden encontrar temprano, si realiza la revisión antes de la prueba.

¿Qué enfoque se recomienda y por qué?

La prueba de la unidad del desarrollador primero, luego la revisión del código, luego la prueba de control de calidad es cómo lo hago. A veces, la revisión del código ocurre antes de la prueba de la unidad, pero generalmente solo cuando el revisor del código está realmente abrumado y esa es la única vez que puede hacerlo.

Nuestro estándar es hacer la revisión del código antes de que el producto pase al control de calidad. La razón de esto es que una vez que el producto ha sido probado y verificado, hay menos incentivos para refactorizar y modificar el código interno. Entonces tendría que volver a probarse todo. Tenga en cuenta que también hacemos pruebas unitarias en la mayoría de los casos.

Idealmente, en un mundo ágil, ambos :)

El desarrollo basado en pruebas es un método que fomenta el desarrollo de pruebas unitarias antes de escribir el código real; de esta manera, puede capturar la especificación en el código y escribir las pruebas que pasan las pruebas. Después de eso, las pruebas de integración automatizadas que aseguran que todos los diferentes componentes encajen entre sí son una buena cosa para garantizar aún más que la funcionalidad de su aplicación coincida con lo que se espera.

En cuanto a las revisiones de código, la programación de pares es una forma útil de tener otra mente pasando por alto su código mientras lo está escribiendo. Sin embargo, ese no es necesariamente un enfoque práctico. La forma en que funciona en mi compañía actual es que el código se revisa después de haber sido probado en la máquina personal del desarrollador, pero antes de que se haya implementado en un servidor de desarrollo compartido.

La revisión del código se realiza para "pulir" las cosas que ya funcionan, para asegurar que el código tenga el nivel de calidad deseado y cumpla con las pautas del código definidas por la compañía.

La revisión del código también puede ocurrir como parte de la futura actividad de optimización general en la que refactoriza y mejora el código anterior.

Si practica la revisión de código antes de hacer un check-in, la revisión de código se divide entre dos etapas de prueba: usted, como desarrollador, prueba primero su código, su par realiza la revisión de código, lo registra, luego los probadores dedicados realizarán pruebas individuales y más exhaustivas. pruebas de integraciones.

Prueba primero. Prueba al final. Prueba, prueba, prueba.

La revisión de código es agradable de tener. Pero difícil: puede ser un proceso doloroso si hay personalidades involucradas u opiniones diferentes.

Las pruebas son muy claras: o funciona o no funciona. ¡Así que prueba, prueba, prueba! Y revisión de código si es posible.

En mi último trabajo tuvimos tres tipos diferentes de revisiones de código que haríamos en diferentes etapas del ciclo de vida del producto. El primer tipo lo llamamos Sanity Review, y sucedería antes de que un desarrollador haya realizado pruebas unitarias; de hecho, Sanity Reviews se realizó incluso antes de que se completaran las funciones. La idea era que un par de miembros del equipo se sentaran y simplemente revisaran algunas secciones de código al azar tal como estaban en el proceso de desarrollo, para asegurarse de que el desarrollo iba bien y que no íbamos a terminar con un gigante Entrada de TDWTF una vez que la función estaba lista para fusionarse. Esto se hizo principalmente para personas que necesitaban orientación adicional (desarrolladores junior, nuevas contrataciones y personas asignadas para trabajar en algo con lo que estaban menos familiarizados que otros miembros del equipo), y en general mantuvo una breve reunión que solo abordó problemas atroces.

Luego tuvimos revisiones de la unidad. En general, esto se hizo con tres desarrolladores y se haría cuando una unidad / característica se hubiera probado y estuviera lista para fusionarse en el árbol principal. Esta fue la revisión más carnosa y entraría en bastante detalle. Teníamos tres desarrolladores para esto porque teníamos el autor original del código, el responsable del árbol que tenía que cerrar sesión en el código antes de que pudiera fusionarse y un tercer desarrollador que había sido seleccionado para ser la copia de seguridad del desarrollador original. (la idea es que una vez que se haya completado una sección del código, debe haber una transferencia completa de conocimiento a otro miembro del equipo, por lo que siempre había al menos 2 personas en el equipo que se sentían completamente cómodas con cualquier parte de la base del código).

Por último, tuvimos revisiones de proyectos. Esto abarcaba a todo el equipo y tomaría aproximadamente una semana, y se realizó después del control de calidad y el lanzamiento del producto, y el objetivo era que todos se sentaran y analizaran todos los cambios en toda la base de código durante el último ciclo de lanzamiento, donde todos pudieran hable acerca de los cambios arquitectónicos, las trampas y decida qué necesita ser refactorizado y reparado antes de comenzar el desarrollo de la próxima versión del proyecto.

Primero, escriba pruebas automatizadas para el código a desarrollar. Revise las pruebas para asegurarse de que se estén probando todos los requisitos conocidos. Escribe el código. Revise con la frecuencia que desee.

Si se requiere alguna prueba manual, es fundamental revisar el código antes de realizar cualquier prueba manual. De lo contrario, las mejoras de diseño sugeridas en la revisión del código serán rechazadas porque las pruebas manuales deberán volverse a ejecutar.

¿Cuál es primero, el huevo o el pollo?
Depende.

Si eres nuevo y no estás seguro de lo que haces, entonces, por supuesto, pídele a un compañero que te ayude. Esta es una revisión informal pero muy seria y valiosa del código.

En general, aunque sugeriría que primero haga su propio trabajo sucio, asegúrese de haber resuelto el código, comentado bien en los lugares correctos (es decir, los bits difíciles, no los obvios), al menos básicamente funciona (tiene probado en los casos generales mínimos y algunos casos límite o excepciones). Luego se lo llevas a tu compañero.

Hacer revisar su código demasiado pronto podría terminar en una terrible pérdida de tiempo de su compañero. Hacer que se revise demasiado tarde podría terminar en una terrible pérdida de tiempo. Necesita encontrar el equilibrio adecuado para obtener la mayor eficiencia. Entonces algunas pruebas van primero, luego la revisión, luego más pruebas. Potencialmente, puede tener varias revisiones de código, dependiendo de la complejidad y las iteraciones, con diferentes propósitos y enfoques.

Cuanto menos seguro esté de más revisiones (cuando está en su fase de aprendizaje temprano, esto es normal). Cuanto más seguro esté, más revisiones también (nunca es bueno estar demasiado seguro de sí mismo, lo que significa que generalmente no es tan buen jugador de equipo y podría causar problemas a los demás, debe asegurarse de que su código se pueda entender y usado por otros). Es cuando estás en el medio que las revisiones se pueden espaciar.

Solo mis dos centavos.

Capers-Jones, que ha estudiado y medido la eficiencia y la calidad resultantes de los procesos de desarrollo de software más que nadie, recomienda la siguiente secuencia de actividades de eliminación de defectos:

• Inspecciones de diseño
• Inspecciones de código
• Pruebas unitarias
• Nuevas pruebas de función
• Pruebas de regresión
• Pruebas de rendimiento
• Pruebas del sistema
• Pruebas beta externas

Una de las razones para llevar a cabo la inspección del código antes de la prueba es para que la revisión pueda considerar no solo el código en sí, sino también la capacidad de prueba del código.