¿Cuándo comprometer el código?

Cuando se trabaja en un proyecto, el código puede desarrollarse razonablemente rápido en un solo día o poco a poco durante un período prolongado de pocas semanas / meses / años. Como las confirmaciones de código se están considerando como una medida del desarrollo del proyecto, en realidad no significa que tenga más código escrito que un proyecto que tenga menos confirmaciones.

Entonces, la pregunta es cuándo realmente hacer un compromiso con el repositorio para que el compromiso sea justificable.

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

Se compromete cuando ha alcanzado un estado de base de código que desea recordar. Hay muchas razones por las que es posible que desee recordar un estado de base de código particular, por lo que no puede haber reglas estrictas sobre cuándo comprometerse. 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 ancla que plantó es el punto que lo asegura, por lo que nunca caerá más de unos pocos metros. Lo mismo con el control de fuente; codifica un poco, y cuando alcanza una posición algo estable, confirma una revisión. Si alguna vez fallas horriblemente, siempre puedes volver a esa última revisión, y sabes que es estable.

Dicho esto, si trabaja en un equipo, es costumbre asegurarse de que todo lo que comete sea completo, tenga sentido, se construya de manera limpia y no rompa las cosas de nadie más. Si necesita hacer cambios más grandes que puedan interferir con el trabajo de otras personas, haga una rama para que pueda comprometerse sin molestar a nadie más.

También depende del sistema SCM que esté utilizando. Los sistemas distribuidos generalmente hacen que la fusión y la bifurcación sean indoloras y rápidas, y puede comprometerse localmente; Esto significa que debe comprometerse mucho e impulsar / fusionar cuando haya realizado una cantidad considerable de trabajo. Con sistemas centralizados como svn o cvs, el compromiso es más costoso y afecta a todos. La ramificación resuelve parcialmente este problema, pero debido a que ocurre en el servidor, puede ser muy lento y la fusión puede ser engorrosa. Entonces, con los SCM centralizados, a menudo hay una cultura más cuidadosa, donde 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 medidas muy malas de calidad o incluso cantidad.

Si está utilizando DVCS como Mercurial o Git, debe comprometerse con su repositorio local cada vez que haya realizado una gran cantidad 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 distribuidos (como, por ejemplo, SVN), se aplica la misma lógica, en lugar del repositorio local, use una rama privada, en lugar de push - merge a la rama principal.

Debes comprometerte temprano y con frecuencia.

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

¿Con qué frecuencia deberías comprometerte? Difícil de decir, pero probablemente con más frecuencia de lo que eres ahora. Siga comprometiéndose cada vez más a menudo, encuentre un punto que parezca absurdamente demasiado frecuente y luego retroceda un poco. Lo más probable es que termines con algo razonable.

Usted mide el desarrollo de un producto en función del valor entregado a sus usuarios. No hay otra medida precisa.

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

• Agregar una nueva pieza de datos o función
• Arregle uno o más errores (un commit para cada arreglo si es posible) donde el arreglo puede ser:
  • Mejora del rendimiento
  • Corregir el comportamiento incorrecto del código
  • Eliminar errores tipográficos
• Refactorizar código o datos sin cambiar la semántica. Esto incluye:
  • Reescribiendo el código que se comporta idéntico al original
  • Cambiar la representación de datos a un formato diferente
  • Código de formato o datos para cumplir con las pautas de formato del proyecto
• Fusionar cambios desde otra rama (ya sea ascendente / descendente)

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

Si los confirmadores siguen la regla anterior, se vuelve trivial:

• Revertir un cambio particular sin efectos secundarios
• Identificar el comportamiento que altera el cambio de código de los cambios de formato de código
• Fusionar entre diferentes ramas evitando la mayoría de los conflictos
• Colabora con otros desarrolladores que pueden sacar tu cambio con facilidad

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

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

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

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

No. Hubo un WTF diario sobre por qué esa es una idea horrible.

Mi regla general sobre la confirmación del código es verificar cuando he completado un fragmento de código y se compila. Chunk no está realmente definido. Si es una tarea pequeña, es posible que no me registre hasta que lo haya hecho. Si es más grande, podría registrarme después de completar cada parte lógica.

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

Realice una confirmación cuando el código esté listo para ser compartido con otros usuarios del código, cuando sea relativamente estable, seguro y probado adecuadamente.

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

Tan pronto como se realice 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á debidamente documentado y
• El código está comprometido.

Puede tener una definición diferente de hecho .

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

Comete cada cambio significativo que no creas que rompa algo. Lo único que no debe confirmar 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 commits, más detallado podrá documentar el proceso de pensamiento, que es un aspecto de un buen registro de commit. Una buena revisión del código no solo debe ser sobre el resultado del código sino también sobre el proceso de pensamiento.

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

Biseccionando en resumen; Descubre un problema en la base de código actual. Luego, elija una confirmación en el registro de cambios donde esté seguro de que el problema específico no existía. Comienza revisando el commit justo 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 atrás, en el medio del "bueno" y el compromiso previamente probado. Si el problema desaparece, se introdujo después de este cambio específico, por lo que debe verificar el punto medio entre el "mal" y el compromiso previamente probado. Repetir. Eventualmente terminarás con el commit que introdujo el problema. Pero solo si tiene pequeñas confirmaciones, de lo contrario solo sabrá en qué gran cantidad de cambios surgió el problema.

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

Cuando:

• se construye (SIEMPRE)
• las pruebas unitarias pasan
• funciona (a menos que esté claramente marcado como "trabajo en progreso")
• Los beneficios de salvar 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 fusión durante el proceso de confirmación.