Hazlos fáciles de realizar …
En mi grupo, hemos hecho un “juego”. Está completamente basado en la web, de principio a fin. Revisar la generación de paquetes con unos pocos clics. Las revisiones requieren solo dos roles, “autor” y “revisor”. El rol de “autor” lo desempeña quien realizó el cambio, y el rol de “revisor” lo desempeña cualquier otra persona en el equipo. Los roles pueden flip-flop tantas veces como sea necesario. La única estipulación es que el rol de “autor” y “revisor” nunca son la misma persona en ninguna revisión. Las revisiones no son monitoreadas. Los comentarios de revisión, las conversaciones y cualquier intercambio se reflejan en los compromisos de gestión del cambio por parte del “autor” en base a las aportaciones del “revisor”. La entrada del revisor, las disposiciones y cualquier sinsentido métrico no se registran. La mayoría de las veces revisamos artefactos directamente en el sistema de gestión de cambios y proporcionamos comentarios por correo electrónico. La finalización de la revisión es unos pocos clics más en la interfaz web, una impresión a PDF del paquete de revisión completo con una lista de verificación, una firma de código del paquete y una confirmación del paquete de revisión para la gestión del cambio. Son tan simples que a veces hay varias revisiones por día.
Resista todos los intentos de medirlos …
No hay absolutamente ningún beneficio reunir cualquiera de los siguientes en una revisión de código:
- SLOC de material revisado
- Número de defectos encontrados (por revisor, ¡peor aún!)
- Tiempo dedicado a revisar (por revisor, ¡peor aún!)
- Detalles de defectos subjetivos como “impacto”, “tipo”
- Detalles de defectos objetivos como “ubicación”, “disposición”
La única métrica que importa es que se produce una revisión. Cualquiera de los anteriores son barreras para que esto suceda de manera eficiente e implica una falta de confianza.
- ¿En cuánta gestión de proyectos debe participar un programador?
- ¿Debo dejar mi trabajo de desarrollo de software y hacer freelance a tiempo completo?
- ¿Cómo ha evolucionado el trabajo de prueba de control de calidad en los últimos 10 años de la industria del software?
- ¿Por qué el software se llama software?
- ¿Aproximadamente cuántos ingenieros de software hay en el área metropolitana de Seattle? ¿'Ingeniero de software' puede definirse como cualquier persona con un título de CS que trabaje dentro de la ingeniería en un contribuyente individual o capacidad de liderazgo?
Haga que el proceso sea fácil de seguir …
Como mencioné anteriormente, hacemos nuestras revisiones en un “juego” basado en la web. En realidad es tan fácil de seguir que es divertido seguirlo. Desea que las revisiones de código sean de esta manera. Cualquier otra forma conduce a críticas mediocres. ¿Por qué? Porque la gente teme reunir detalles mundanos sobre las revisiones que entran en un cubo que nadie consulta nunca más.
Resista todos los intentos de “rolecizarlos” …
Estás en la oficina a altas horas de la noche tratando de sacar un paquete de códigos por la puerta. Antes de poder hacer esto, necesita una revisión. Por supuesto, ¿a quién no le gustaría que hicieras una reseña? Ciertamente lo quieres. Pero hay un problema. Su proceso de revisión requiere una reunión de revisión con todos los siguientes asistentes :
- Un “líder de revisión”: una persona que abrirá, supervisará y cerrará la revisión.
- Un “moderador”: una persona que supervisará la revisión de los egos fuera de control.
- Un “autor”, por supuesto.
- Al menos dos revisores, porque un par de ojos adicionales no es suficiente, ¡maldita sea!
- Un control de calidad: porque la calidad no es calidad a menos que esté sellada por el control de calidad.
- etc.
Problema … todos se han ido a casa por el día. Llamarías a una reunión, pero es probable que nadie se presente porque … están en casa … con sus esposas / familias … sin pensar en el día infernal que tuvieron que pasar ni una sola crítica. ¡Cristo, ten piedad si interrumpes su velada por otra!
Esto puede parecer incongruente con mi descripción anterior de nuestro proceso. Claramente tenemos roles. “Autor” – duh. “Revisor” – duh. También tenemos control de calidad. ¡Pero el control de calidad está indirectamente involucrado en que son libres de auditar nuestros paquetes de revisión para el cumplimiento del proceso en cualquier momento ! No es necesario que formen parte ni que se les notifique de ninguna revisión en particular. Cualquiera puede iniciar una revisión por cualquier motivo. Podríamos, si así lo desea, iniciar una revisión solo para obtener un par de ojos adicionales en el código que ya ha sido revisado. Nada lo impide.
Estoy muy orgulloso del proceso que seguimos. No puedo reclamar ningún crédito por proponerlo. Eso sucedió antes de que yo entrara en escena, por gigantes intelectuales que ya no son parte de la compañía. No puedo reclamar ningún crédito por las innumerables veces que se ha exhibido frente a personas como FAA, EASA, etc., y aceptado como apropiado para dispositivos críticos de seguridad. Sin embargo, puedo reclamar crédito por ser uno de sus principales defensores, incluso cuando la compañía intenta tragárselo y escupirlo completamente a favor de un proceso de revisión que viola completamente todos los puntos de discusión anteriores, ¡y eso es atroz!