¿Revisión de código vs. Check in a menudo?

Question

Siguiendo el artículo de Jeff sobre checking in often, algunos comentaristas no pudieron resistirse a escupir "¡Bienvenido a tierra obvia!" tipo de comentarios. Eso es comprensible, en la mayoría de las situaciones es obvio que el check-in tan pronto como se termine algo antes de pasar a la siguiente característica es el camino a seguir.

Pero, ¿qué pasa con los lugares con una política de revisión de código obligatorio estrictamente obligatoria? Pedirle a un compañero de trabajo una revisión cada 30 minutos es un asesino de productividad.

Me interesaría una solución, o al menos un posible compromiso que nos permita hacer ambas cosas sin afectar la productividad del equipo.

Answer 1

Depende de qué branching strategy utilice. Si su repositorio está trabajando en la bifurcación de la versión, el tronco es significa inestable, pero tal vez su política provenga de alguna experiencia realmente mala en el pasado. Si está realizando una bifurcación de funciones, puede tener una regla que diga que no se fusione nuevamente al enlace troncal sin revisión por pares. Hacer diffs en ese punto debería ser bastante eficiente para revisar con un colega y debería eliminar el cuello de botella.

Pero cambiar su estrategia de ramificación no es poca cosa. Buena pregunta ...

Answer 2

¿Qué tal si emparejas el programa? Entonces la teoría es que no necesitará una revisión por pares. El par de programación es la revisión por pares

Answer 3

No sé si hay una solución a su problema. Para mí, parece que tu situación cae en el campo de concentración agil. Parece que su productividad ya está paralizada si ni siquiera puede registrar (por ejemplo) un cheque nulo para arreglar un bloqueo sin que alguien lo mire por usted.

Answer 4

¿No hay código o no hay código en el maletero sin reseña? Creo que usar la bifurcación (¡afortunadamente es , no usando VSS!) Podría funcionar: es decir, solo los cambios troncales necesitan la revisión por pares.

Answer 5

Eso es tonto. Incluso si requiere la revisión del código no significa que no se pueda registrar. ¡Para eso sirve el control del código fuente! Especialmente si la revisión tiene un cuello de botella, el procesamiento por lotes es el único camino a seguir.

Answer 6

En la mayoría de los casos, lo que está en el control de la fuente no es lo que va a ser inminentemente lanzado al cliente. Por lo tanto, realizaría las revisiones una vez que se haya registrado la función completa, lo que le permitirá editar y/o deshacer, según sea necesario, más adelante.

Answer 7

No todos los sistemas de control de origen facilita esto, pero he utilizado este proceso cuando se trabaja en un gran proyecto:

• Cada desarrollador tiene su propio flujo.
• Los desarrolladores entregan funciones completadas de su transmisión a una secuencia de integración principal después de la revisión del código.
• Los desarrolladores actualizan su flujo de la secuencia de integración con frecuencia.

El uso de transmisiones de desarrollador significa que los desarrolladores pueden permanecer visibles y tener copias de seguridad de su trabajo en el sistema. Es relativamente fácil colaborar con alguien más; simplemente pueden consultar su transmisión. Al crear una nueva rama de desarrollador por función/defecto, puede aislar los cambios con bastante facilidad: digamos que debe dejar de trabajar en una nueva función para solucionar un error urgente.

Answer 8

Mi empresa sigue procesos algo dispares entre divisiones. Uno de ellos (que recientemente me fui) adoptó la programación de los pares y los comentarios de los comentarios dicen que el código fue "revisado por pares". Sin embargo, el producto en el que se está trabajando es algo maduro y el proceso de desarrollo puede tolerar una productividad más lenta.

La división en la que actualmente trabajo sigue el check-in temprano, el modelo de check-in a menudo. Estamos desarrollando un nuevo producto con relativamente pocos ingenieros. Cada uno de nosotros monitorea el check-in a través de notificaciones por correo electrónico y revisa las partes interesantes de forma ad-hoc. Sin embargo, mi equipo actual está bastante experimentado y creo que podemos escapar sin revisiones formales debido a la calidad de los ingenieros que trabajan en el proyecto.

Para responder a su pregunta, como sugirió el poster anterior, la programación de pares es probablemente el mejor compromiso. Personalmente, prefiero reunir un buen equipo y dejar que ingresen el código lo más rápido posible. (En mi opinión, el "sin código en el repositorio sin revisión" es un intento de la gerencia para aumentar la calidad sin contratar ingenieros de calidad. Por favor, tómenlo con un grano de sal, estoy un poco hastiado por mi empleador actual.)

Answer 9

Prefiero mantener un tronco y una rama estables para los lanzamientos, volviendo a unirme al tronco después de la producción. Las etiquetas se usan para indicar la disponibilidad del código y PODRÍAN emparejarse con una estrategia de revisión de código. Las versiones de SIT/UAT obtienen su propia etiqueta especial.

En el equipo en el que actualmente formo parte somos solo 3 de nosotros que escribimos, por lo que las evaluaciones entre pares son constantes y brutalmente entretenidas, educativas, & honestas. No soy alguien que se apegue emocionalmente al código que he escrito, así que me encanta una buena reseña. He aprendido mucho en un corto período de tiempo de ellos. Dicho esto, no son necesarios; en cierto modo suceden orgánicamente.

Si se requieren evaluaciones por pares, no hay motivo para suspender los registros. Simplemente haga una etiqueta que indique que la revisión ha tenido lugar y que sea responsabilidad del revisor aplicar esa etiqueta al código una vez que haya pasado la revisión.

Answer 10

Hacemos revisiones de código en un nivel de historia (tienda ágil aquí) así que una vez que haya terminado una tarea relacionada con una historia que hace una revisión de código y después del registro de entrada.

Answer 11

Algunos sistemas de control de revisiones hacer esto fácil (aquellos con una estrategia descentralizada). He experimentado con el uso de varias capas intermedias locales en un servidor de subversión de la compañía.

He usado svk para mantener un repositorio local de subversión al que me pueda comprometer a menudo, luego envío cambios (individualmente o como una única confirmación combinada) al repositorio principal.

svk mirror 
svk pull 
svk push 

Esto funciona bastante bien, pero el desarrollo de svk parece ser esporádica.

He comenzado a probar lo mismo usando git. He hecho un clon local, pero todavía tengo que ser lo suficientemente valiente como para intentar impulsar las confirmaciones locales. Estoy seguro de que es posible sin embargo.

git svn clone 
git svn fetch 
git svn dcommit 

Con este depósito privado, local, puede comprometer todo lo que quiera, a continuación, haz o cereza-escoge cambios para empujar al repositorio principal. (O cree un parche que pueda ser revisado por pares.)

¿Lo mejor de los dos mundos quizás?No es probable que estas herramientas alternativas de control de revisiones ganen tracción en el trabajo, pero son realmente útiles para las confirmaciones locales o para poder comprometerse cuando el repositorio de trabajo es inaccesible (estoy fuera de línea, viajando, etc.) y aún así sincronizar con el repositorio padre.

Answer 12

Hay muchas buenas respuestas. La mayoría tiende a proponer una rama de características para cada desarrollador que requiera una revisión para fusionarse en el enlace troncal. Sin embargo, esto reduce el control de la fuente a una tecnología de respaldo en lugar de algo que hace que los códigos entre varios programadores se puedan compartir fácilmente tan pronto como se escriben.

Como mencionó flubba, la mejor solución probablemente requeriría cambiar la estrategia de bifurcación a la más apropiada para el equipo, pero me temo que la inercia en nuestra compañía es tan fuerte que esto me requerirá gastar muchos puntos de influencia probablemente sin éxito.

Haré todo lo posible.

Answer 13

Tratando de resumir las respuestas, es posible:

1. uso apropiado branching strategy en cualquier SVC:

   • cajón de la rama personal
   • registro menudo
   • revisar todos los cambios
   • fusionar todo el código revisado de vuelta al tronco (ver t sus example)

   pros: SVC neutros

   callos: fusión puede ser doloroso en algunas implementaciones SVC (buena visión general de Linus Torwald's opinion) rama personales deben estar sincronizados con el tronco cambia

   • uso Métodos específicos de SVC:

   • SVC distribuido

     • crear una copia local de "rama de desarrollador"
     • registro menudo a repo local de
     • exponerlo a (para una revisión) conjuntos de cambios públicos con características más completas
     • fusionar los cambios revisados ​​a repositorio remoto

     pros: beneficio de SVC incluso fuera de línea, se adapta bien.

     callos: gran curva de aprendizaje, fácil de olvidar algunas cosas de la línea de comandos si no se usa a diario.

   • centralizado SVC con marcas correspondientes de "etiqueta" ver este discussion y esto overview - pueden necesitar alguna aclaración

Por cierto, ¿no deberíamos pensar en hacer respuesta agregado todo el tiempo? tnx.

Answer 14

@Coincoin: No estoy de acuerdo que las ramas individuales reduce control de fuente para una tecnología de copia de seguridad. Creo que las copias de seguridad son una de las razones para utilizar control de código fuente, pero no hay más valor de control de código fuente en un ramal individual:

• Puedo hacer pequeños pasos, documentando cuidadosamente a medida que avanzo, aunque No estoy listo para el horario de máxima audiencia.
• La comprensión de cómo hemos llegado hasta aquí es posible, sobre todo cuando las medidas son muy pequeñas.
• En cuanto a los cambios de la rama común, se puede ver los grandes pasos, a continuación, profundizar para la rama individual para los pequeños pasos que llegamos allí.

Sin embargo, la regla de "si no está comprometido, no existe" aún mantiene, y es más penetrante: "si no está comprometido/fusionado con la rama común, no existe".

Estoy de acuerdo con aquellos que dicen que el check-in a menudo es una gran práctica, y que la programación de pares es la solución para eliminar la latencia de las revisiones de código.