¿cuál es la mejor manera de garantizar la responsabilidad en los controles de código?

7

Nota: después de escribir esto, me doy cuenta de que esta pregunta es quizás filosófica, pero estoy interesado en cómo la industria maneja este escenario independientemente.

Recientemente he estado trabajando con una base de código que aún no es tan comprobable como debería ser. He visto a algunos desarrolladores junior verificar el código que rompe los casos de uso, que generalmente es identificado por otro desarrollador unos días después del check-in.

Suponiendo que todavía no podemos lograr la cobertura del código, ¿existen soluciones técnicas para responsabilizar a los desarrolladores por los chequeos incorrectos además de un enfoque no técnico; discutiendo el compromiso y haciendo que el dev aborde el problema en un nuevo compromiso.

    
pregunta user376456 27.12.2012 - 23:06

6 respuestas

3

Dos medidas simples:

  1. Revisiones de código (ya mencionadas por otros) antes de cada registro. No es necesario que explique todos los detalles de su registro, pero el revisor debe tener una idea de los cambios que se están registrando. Puede programar su RCS rechazará los registros de entrada cuyo texto de registro no contenga la etiqueta "REVISADO POR: ...".
  2. De acuerdo con el resto del equipo, si el check-in rompe las pruebas unitarias, el desarrollador que realizó el check-in debe corregir el código hasta que esas pruebas de unidad vuelvan a ser verdes (posible medida: escriba un error y asigne a él / ella). Como alternativa: si un miembro del equipo detecta un check-in que rompe las pruebas de unidad, puede revertir los cambios. El autor del check-in incorrecto no puede volver a ingresar siempre que el problema no se resuelva localmente (las pruebas unitarias son verdes a nivel local).

NOTA

El punto 2 se ha editado teniendo en cuenta el comentario de gnat.

    
respondido por el Giorgio 28.12.2012 - 12:18
3

Si usas git para el control de versiones, comprueba gerrit. Claro que puede ser un dolor en el culo, pero requiere que se realicen revisiones de código antes de fusionar un compromiso en el repositorio.

    
respondido por el toomanyjoes 27.12.2012 - 23:21
3

Necesita implementar un sistema de integración continua (CI) como TeamCity. No debería ser un desarrollador unos días más tarde, notando el problema. Con un sistema de CI tan pronto como se produce un check-in, el código se crea automáticamente y se ejecutan las pruebas automatizadas. A los pocos minutos de la verificación, el sistema de CI alertará a todos que la compilación se ha roto y quién realizó la verificación que la causó.

De esta manera, todo es completamente objetivo y no hay un dedo que señale quién tiene la culpa. A diferencia de los desarrolladores, el sistema de CI está usando solo el último código del control de origen para realizar sus pruebas. No hay cambios locales y no hay diferencias de configuración funky. La mayoría de los sistemas tienen un icono de bandeja que se vuelve rojo cuando se rompe la construcción. Todos los desarrolladores deben tener ese ícono instalado y realizar un seguimiento si la compilación es correcta o está dañada.

    
respondido por el JoelFan 28.12.2012 - 15:41
1

Creo que tu equipo necesita asistir a un curso de scrum ágil y hacer un pacto para seguir la metodología.

Cuando los desarrolladores controlan pequeños cambios de código asignados a pequeñas tareas, se reduce la posibilidad de que los desarrolladores se salgan de la vía y registren el código conflictivo. Esto aumenta la integración continua.

  

"He visto a algunos desarrolladores junior verificar el código que rompe los casos de uso,   que normalmente es identificado por otro desarrollador unos días después de la   check-in. "

Incluso en un mundo perfecto esto todavía sucede. Si encuentra que ocurre con frecuencia y / o después de varios días de desarrollo, entonces tiene un problema.

Creo que encontrará que el equipo trabajará en conjunto de manera más efectiva con una iteración planificada. Te sugiero que pruebes un sprint de 2 semanas. Comienza el sprint con una reunión de scrum en profundidad. Ir a través de la acumulación de errores y elementos de trabajo, aceptar las prioridades principales y escribirlas en notas post-it con unidades / estimaciones de tiempo utilizando las cartas de planificación de póquer .

Alinee un tablero de scrum o tablero blanco y asegúrese de que las personas solo trabajen en una cosa a la vez. Una vez que hayan terminado la tarea, necesitan escribir una prueba de unidad para ello. Una vez que escriban una prueba de unidad de trabajo, deberán obtener una Revisión del Código. Las revisiones de código constructivas son una de las mejores técnicas para evitar que los desarrolladores registren accidentalmente conflictos de código.

Después de que el Revisor de códigos haya cerrado la sesión, el desarrollador hace el Baile de registro:

  • Hágale saber al resto del equipo que se avecina un cambio si se trata de una actualización significativa.
  • Obtenga el último código del control de código fuente.
  • Haz una fusión en cualquier conflicto.
  • Ejecute la compilación localmente y solucione los problemas encontrados.
  • Ejecute las pruebas unitarias localmente y solucione los problemas encontrados.
  • Confirme los cambios en el control de origen.
  • Detener la codificación hasta que la compilación pase.

Si la compilación se rompe, suelta todo lo demás y arregla la compilación.

Team Foundation Server (TFS) facilita todo esto fuera de la caja.

Debes arreglar las pruebas antes de seguir adelante. Pero solo porque el 80% del código es una unidad probada, no significa que esté a prueba de errores. Los desarrolladores tienen que ser activos en probar la sociabilidad de su código. Esta integración de código es mucho más fácil de lograr utilizando metodologías sin cascada.

    
respondido por el Jeremy Thompson 28.12.2012 - 03:30
0

Segundo código revisa. Algunas herramientas le permiten hacer revisiones antes de que se confirme el código como solicitudes de extracción de Github. Otras le permiten ver quién tocó Cada línea tiene la culpa de SVN.

Personalmente, prefiero que los miembros de mi equipo ingresen código en el troncal con frecuencia, incluso si no es perfecto. Aumenta las posibilidades de que alguien más note un problema y permite los beneficios de la integración continua.

Realizamos revisiones de código formales al final de una tarea. También hago revisiones de código "aleatorias" a medida que las personas trabajan y se comprometen. El azar está entre comillas, porque al principio reviso más a fondo para entrenar bien a las personas sobre cómo realizar pruebas. También ofreceré parear para probar para que los desarrolladores adquieran las habilidades. El azar también está entre comillas porque las personas que escriben código / pruebas peores se eligen más a menudo para las revisiones al azar. Mantengo las revisiones aleatorias anónimas; la gerencia nunca se entera de ellas, son una práctica puramente de equipo.

    
respondido por el Jeanne Boyarsky 28.12.2012 - 03:13
0

Cualquiera de los siguientes debe reducir drásticamente el riesgo de que un junior cometa un código incorrecto:

  • Programación por pares , preferiblemente con un desarrollador senior como navegador

  • Pre-commit revisiones de código por un desarrollador senior

Lo bueno de estos es que están orientados a la colaboración, no a los culpables, que la OMI es definitivamente algo que debería favorecer al integrar programadores junior.

    
respondido por el guillaume31 28.12.2012 - 16:51

Lea otras preguntas en las etiquetas