¿Cuándo cometer código?

Confirma cuando ha alcanzado un estado de código base que desea recordar. Hay muchas razones por las que puede querer recordar un estado de base de código particular, por lo que no puede haber reglas duras y rápidas sobre cuándo cometer. Sin embargo, el número de confirmaciones definitivamente no es una medida de calidad o progreso.

Me gusta pensar en la codificación como escalada en este contexto. Subes un poco, y luego pones un ancla en la roca. Si alguna vez se cae, el último anclaje que plantó es el punto que lo protege, por lo que nunca caerá más de unos pocos metros. Lo mismo con el control de la fuente; se codifica un poco y, cuando se alcanza una posición estable, se realiza una revisión. Si alguna vez fracasas horriblemente, siempre puedes volver a la última revisión y sabes que es estable.

Dicho esto, si trabajas en un equipo, es habitual asegurarte de que todo lo que cometas sea completo, tenga sentido, se desarrolle de manera limpia y no rompa las cosas de los demás. Si necesita realizar cambios más grandes que puedan interferir con el trabajo de otras personas, cree una sucursal para que pueda comprometerse sin molestar a nadie más.

También depende del sistema SCM que estés usando. Los sistemas distribuidos por lo general hacen que la combinación y el forking sean indoloros y rápidos, y puede comprometerse localmente; esto significa que debe comprometerse mucho y presionar / fusionar cuando haya realizado una cantidad sustancial de trabajo. Con sistemas centralizados como svn o cvs, comprometerse es más costoso y afecta a todos. La bifurcación resuelve parcialmente este problema, pero como ocurre en el servidor, puede ser muy lento y la combinación puede ser complicada. Así que con los SCM centralizados, a menudo hay una cultura más cuidadosa, en la que solo se compromete una vez que ha realizado una cantidad significativa de trabajo.

En cuanto al complemento: por favor, no hagas eso. Las líneas de código, el número de confirmaciones, el número de errores encontrados / resueltos, etc., son todas muy malas mediciones de calidad o incluso cantidad.

Si está utilizando DVCS como Mercurial o Git, debe comprometerse con su repositorio local siempre que haya realizado una cantidad significativa de trabajo. Sin embargo, solo empújelo al repositorio compartido solo después de que esté funcionando, un cambio autónomo que se haya probado.

Para VCS no distribuido (como, por ejemplo, SVN), se aplica la misma lógica, en lugar de que el repositorio local utilice una rama privada, en lugar de un empuje - fusionar con la rama principal.

Debes comprometerte temprano y con frecuencia.

Sé de personas que se comprometen cada 90 segundos. Seriamente. Parece que funciona para ellos. He experimentado con la confirmación cada vez que guardo un archivo, lo que probablemente sea más de 90 segundos. Hoy, probablemente me comprometo cada 15 minutos. Un VCS que te permite aplastar múltiples confirmaciones en una sola y que permite confirmaciones locales (como git) hace que esto sea mucho más fácil.

¿Con qué frecuencia debes comprometerte? Es difícil de decir, pero probablemente más a menudo de lo que eres ahora. Sigue cometiendo más y más a menudo, encuentra un punto que parezca absurdo con demasiada frecuencia y luego retrocede un poco. Es probable que termines con algo razonable.

Mide el desarrollo de un producto basado en el valor entregado a sus usuarios. No hay otra medida precisa.

Comprométase solo cuando haya probado satisfactoriamente la función / módulo / funcionalidad dada y esté razonablemente seguro de que está listo para la integración o la prueba del sistema.

Y para responder a tus preguntas adicionales - ¡NO! la medida de dónde se encuentra el proyecto nunca debe determinarse por la cantidad de compromisos ... ¿quién sabe qué se ha cometido realmente? ¿Se ha probado con éxito el sistema o incluso se ha probado la unidad? Solo porque está comprometido, no significa que esté listo para la producción.

Los compromisos son los componentes básicos de cualquier código / datos controlados por versión. Cada confirmación debe hacer exactamente uno de los siguientes:

• Agregar un nuevo dato o función
• Solucione uno o más errores (una confirmación para cada corrección si es posible) donde la corrección puede ser:
  • Mejora del rendimiento
  • Corrigiendo el comportamiento incorrecto del código
  • Eliminando errores tipográficos
• Código o datos de refactorización sin cambiar la semántica. Esto incluye:
  • Código de reescritura que se comporta idéntico al original
  • Cambio de representación de datos a un formato diferente
  • Código o datos de formato para cumplir con las directrices de formato del proyecto
• Combinar cambios de otra rama (ya sea ascendente / descendente)

También cuando se trabaja en sucursales, las confirmaciones deben ir a una sucursal que sea más adecuada. Dos confirmaciones no deben tener el mismo mensaje de confirmación (lo que implica cambios similares) sino en diferentes ramas, ya que confunde a los colaboradores. Una mejor manera es comprometerse con la rama principal y fusionarse con la rama de características.

Si los comprometidos siguen la regla anterior, se vuelve trivial a:

• Revertir un cambio en particular sin efectos secundarios
• Identifique el comportamiento que modifica el cambio de código de los cambios de formato de código
• Combinar entre diferentes ramas evitando la mayoría de los conflictos
• Colabore con otros desarrolladores que pueden impulsar su cambio con facilidad

Con respecto a la medición del progreso del proyecto basado en confirmaciones, es posible si no se tienen en cuenta las confirmaciones de refactorización y las correcciones de errores.

  

Como complemento: ¿Es una práctica correcta?   para medir el desarrollo de un proyecto   basado en sus compromisos?

No. Allí había un WTF diario sobre por qué es una idea horrible.

Mi regla general de oro para confirmar el código es verificar cuando haya completado un fragmento de código y este se compile. Chunk no está realmente definido. Si es una tarea pequeña, es posible que no me registre hasta que termine. Si es más grande, podría registrarme después de que se complete cada parte lógica.

Pero nunca compruebe si no se compila. Sé que parece una estupidez decirlo en voz alta, pero antes tuve que explicárselo a la gente.

Haga un compromiso cuando el código esté listo para compartirlo con otros usuarios del código, cuando sea relativamente estable, seguro y esté debidamente probado.

Y no, no creo que los compromisos sean una gran métrica para el desarrollo de un proyecto, porque conozco a algunos desarrolladores que realizarán cada cambio pequeño y pequeño, y otros que solo harán grandes cambios importantes en la funcionalidad. ¿Cómo se mide cuantitativamente el valor de un compromiso sobre otro?

Tan pronto como se complete la tarea correspondiente . Una tarea es parte de una historia de usuario .

Se realiza una tarea cuando:

• la unidad correspondiente prueba passe,
• el código está correctamente documentado y
• el código está comprometido.

Puede tener una definición de hecho diferente. p>

No veo el valor en la medición del número de confirmaciones. Sin embargo, si ves a alguien trabajando durante un largo período de tiempo en la misma historia de usuario (o, peor aún, en historias), esto es un olor.

Confirma cada cambio significativo que crees que rompe algo. Lo único que no debe cometer son los cambios de estilo porque no incorporan cambios en la lógica. Pero de lo contrario, cuanto más pequeños sean los cambios que cometas, mejor.

Cuanto más pequeños sean los compromisos, más detallado podrá documentar el proceso de pensamiento, que es un aspecto de un buen registro de compromisos. Una buena revisión del código no debe ser solo sobre el resultado del código, sino también sobre el proceso de pensamiento.

Además, tener muchas confirmaciones pequeñas hace que sea fácil de dividir, una característica muy poco utilizada del control de versiones, una que me ahorró muchas horas de búsqueda de errores de agujas en las bases de código de pajar.

Bisecar en breve; Descubre un problema en el código base actual. Luego, seleccione una confirmación en el registro de cambios donde esté seguro de que el problema específico no existió. Comience con la comprobación del derecho de compromiso en el medio entre la versión "buena" y la "mala". Prueba para ver si el problema sigue presente. Si es así, debe mirar más hacia atrás, en medio de la "buena" y la confirmación previamente probada. Si el problema desaparece, se introdujo después de este cambio específico, por lo que debe revisar el punto intermedio entre el "malo" y el compromiso previamente probado. Repetir. Eventualmente terminarás con la confirmación que introdujo el problema. Pero solo si tiene confirmaciones pequeñas, de lo contrario, simplemente sabrá en qué gran pila de cambios surgió el problema.

Aquí es cómo funciona con Git, pero el principal se aplica a cualquier control de versión.

Cuando:

• construye (SIEMPRE)
• pruebas unitarias aprobadas
• funciona (a menos que esté claramente marcado como "trabajo en progreso")
• los beneficios de guardar el estado del código superan la molestia de ejecutar las pruebas, pensar en un buen mensaje de confirmación y resolver cualquier conflicto de combinación durante el proceso de confirmación