La calificación de las personas en una revisión es contraria a los sistemas más exitosos con los que he trabajado, tal vez todos. Pero el objetivo que he tratado de alcanzar durante más de 20 años es menos errores y una mayor productividad por hora de ingeniero. Si calificar a las personas es un objetivo, supongo que se podrían utilizar las revisiones. Nunca he visto una situación en la que se requiera, como trabajador o como líder.
Algunos estudios objetivos (Fagan, etc.) y mucha sabiduría popular sugieren que las relaciones entre pares facilitan las revisiones de código destinadas a reducir errores y aumentar la productividad. Los gerentes de trabajo pueden participar como trabajadores, pero no como gerentes. Se observan puntos de discusión, los cambios para satisfacer a los revisores generalmente son algo bueno pero no obligatorio. De ahí la relación entre pares.
Cualquier herramienta automatizada que pueda ser aceptada sin más análisis o juicio es buena - pelusa en C, C ++, Java. Recopilación regular. Los compiladores son REALMENTE buenos para encontrar errores de compilación. Documentar las desviaciones en los controles automáticos suena como una sutil acusación de los controles automáticos. Las directivas de código (como lo hace Java) que permiten las desviaciones son bastante peligrosas, en mi humilde opinión. Excelente para depurar, para permitirle entender el problema rápidamente. No es tan bueno de encontrar en un bloque de código de 50,000 líneas sin comentarios y mal documentado del que te has hecho responsable.
Algunas reglas son estúpidas pero fáciles de hacer cumplir; valores predeterminados para cada declaración de cambio, incluso cuando son inalcanzables, por ejemplo. Entonces es solo una casilla de verificación, y no tiene que gastar tiempo y dinero probando con valores que no coinciden con nada. Si tienes reglas , tendrás necedad , están inextricablemente unidas . El beneficio de cualquier regla debe valer la tontería que cuesta, y esa relación debe verificarse a intervalos regulares.
Por otro lado, "Corre" no es una virtud antes de la revisión, ni una defensa en revisión. Si el desarrollo siguió el modelo en cascada , le gustaría hacer la revisión cuando la codificación esté completa en un 85%, antes de encontrar y resolver errores complicados, porque la revisión es una forma más económica de encontrarlos. Dado que la vida real no es el modelo de cascada, cuándo revisar es algo así como un arte y equivale a una norma social. Las personas que realmente leerán su código y buscarán problemas en él son oro sólido. La administración que respalda esto de manera continua es una perla por encima del precio. Las revisiones deben ser como registros, temprano y con frecuencia .
He encontrado estas cosas beneficiosas:
1) No hay guerras de estilo . Donde van las llaves abiertas solo debe estar sujeto a una verificación de consistencia en un archivo dado. Todos iguales. Eso está bien, entonces. Ídem profundidad de sangría ** sy ** anchos de tabulación . La mayoría de las organizaciones descubren que necesitan un estándar común para la pestaña, que se utiliza como un gran espacio.
2) `Harapiento
looking
texto que no
line up is hard to read
por contenido.`
Por cierto, K&R sangró cinco (CINCO) espacios, por lo que las apelaciones a la autoridad no tienen valor. Solo sé consistente.
3) Debe señalarse una copia del archivo que se revisará, numerada en línea, sin cambios y disponible públicamente, durante 72 horas o más antes de la revisión.
4) Sin diseño sobre la marcha. Si hay un problema o un problema, tenga en cuenta su ubicación y siga avanzando.
5) Las pruebas que atraviesan todos los caminos en el entorno de desarrollo son una muy, muy, muy buena idea. Las pruebas que requieren datos externos masivos, recursos de hardware, uso del sitio del cliente, etc., son pruebas que cuestan una fortuna y no serán exhaustivas.
6) Un formato de archivo no ASCII es aceptable si existen herramientas de creación, visualización, edición, etc., o si se crean al principio del desarrollo. Este es un sesgo personal mío, pero en un mundo donde el sistema operativo dominante no puede salir de su propio camino con menos de 1 gigabyte de RAM, no puedo entender por qué los archivos de menos de 10 megabytes deberían ser algo que no sea ASCII o algún otro formato comercialmente compatible. Existen estándares para gráficos, sonido, películas, ejecutables y herramientas que los acompañan. No hay excusa para un archivo que contiene una representación binaria de cierto número de objetos.
Para el mantenimiento, refactorización o desarrollo del código publicado, un grupo de compañeros de trabajo que utilicé revisó por otra persona, sentado en una pantalla y mirando un diferencial de lo antiguo y lo nuevo , como una puerta de entrada para el registro de sucursales. Me gustó, fue barato, rápido, relativamente fácil de hacer. Los recorridos para personas que no han leído el código por adelantado pueden ser educativos para todos, pero rara vez mejoran el código del desarrollador.
Si está distribuido geográficamente, mirar diferencias en una pantalla mientras habla con otra persona que mira lo mismo sería relativamente fácil. Eso cubre a dos personas que miran los cambios. Para un grupo más grande que ha leído el código en cuestión, múltiples sitios no es mucho más difícil que todos en una sola habitación. Varias habitaciones conectadas por pantallas de computadora compartidas y cajas de squak funcionan muy bien, en mi humilde opinión. Cuantos más sitios, más gestión de reuniones se necesita. Un gerente como facilitador puede ganarse la vida aquí. Recuerde seguir sondeando los sitios en los que no se encuentra.
En un momento, la misma organización tenía pruebas unitarias automatizadas que se usaban como pruebas de regresión. Eso estuvo muy bien. Por supuesto, luego cambiamos las plataformas y las pruebas automatizadas se quedaron atrás. La revisión es mejor, como señala el Manifiesto Ágil , las relaciones son más importantes que el proceso o las herramientas . Pero una vez que hayas revisado, las pruebas unitarias automatizadas / pruebas de regresión son la siguiente ayuda más importante para crear un buen software.
Si puede basar las pruebas en los requisitos , bueno, como dice la señora en "Cuando Harry conoció a Sally" , ¡tendré lo que está teniendo!
Todas las revisiones deben tener un estacionamiento para capturar los requisitos y los problemas de diseño en el nivel superior a la codificación. Una vez que se reconoce que algo pertenece al estacionamiento, la discusión debe detenerse en la revisión.
A veces creo que la revisión de código debería ser como revisiones esquemáticas en el diseño de hardware: completamente público, exhaustivo, tutorial, el final de un proceso, una puerta de enlace después de la cual se construye y se prueba. Pero las revisiones esquemáticas son pesadas porque cambiar los objetos físicos es costoso. Las revisiones de arquitectura, interfaz y documentación para el software probablemente deberían ser pesadas. El código es más fluido. La revisión del código debe ser más ligera.
En muchos sentidos, creo que la tecnología tiene que ver tanto con la cultura y las expectativas como con una herramienta específica. Piense en todas las improvisaciones de " Swiss Family Robinson " / Flintstones / McGyver que deleitan el corazón y desafían la mente. Queremos que nuestras cosas funcionen . No hay un solo camino para eso, al igual que no hubo "inteligencia" que de alguna manera podría ser abstraída y automatizada por los programas de inteligencia artificial de la década de 1960 .