¿Es una buena práctica cometer / verificar el código todos los días?

No estoy de acuerdo con esta regla y estoy de acuerdo con lo que dijo Mason Wheeler . me gustaría Me gusta añadir algunas ideas.

Intento comprometerme cada vez que tengo un significativo cambio para confirmar: esto puede ser varias veces al día si soluciono varios errores pequeños, o una vez a la semana si estoy trabajando en un software más grande que no puede ser utilizado por el resto del código de manera significativa hasta que alcance un estado consistente.

También, interpreto a cometer como publicar una revisión significativa que Aporta nueva funcionalidad a la base de código. Creo que uno debería tratar de limpiar el código antes de comprometerse para que Otros desarrolladores pueden entender el significado y el propósito del cambio. Cuando miran el historial de revisiones. Cuantos menos cambios tengan otros desarrolladores. ver en la historia, mejor: cuando miro el historial de revisiones quiero para ver incrementos que agreguen alguna funcionalidad significativa; No me interesa En cada pequeña idea que cada desarrollador tenía y quería probar antes de llegó a la solución.

Además, no creo que sea una buena idea usar el servidor SVN (o cualquier sistema de control de versiones) como una instalación de copia de seguridad a la que la instantánea actual del código se confirma (siempre que se compile): puede utilizar una memoria USB o una unidad USB externa o un disco de red para reflejar su código actual para que no se pierda si su la computadora se descompone El control de revisión y la copia de seguridad de datos son dos diferentes cosas. Publicar una revisión no es lo mismo que guardar una instantánea de tu código.

Finalmente, creo que no debería ser un problema cometer de vez en cuando y luego (es decir, solo cuando uno está realmente satisfecho con el estado actual de El código) y evitar conflictos de fusión no es una buena justificación para cometer (demasiado) a menudo. Muchos conflictos de combinación ocurren cuando diferentes personas trabajan en los mismos archivos al mismo tiempo, lo que es una mala práctica (consulte, por ejemplo, este artículo , señale 7). Los conflictos de fusión deben reducirse dividiendo un proyecto en módulos con interfaces claras y tan pocas dependencias como sea posible, y coordinando El trabajo de los desarrolladores para que el código en el que trabajan se solape tan poco. como sea posible.

Sólo mis 2 centavos.

EDIT

Otra razón contra los compromisos prematuros que vinieron a mi mente es que Una versión (muy) con errores no puede ser probada. Si estás cometiendo en el maletero. y su equipo de pruebas está probando todos los días, es posible que no tengan una versión comprobable Por unas horas (o por un día). Incluso si no intenta solucionar el error y simplemente revertir los cambios, una reconstrucción puede tardar un par de horas. Con, digamos, cinco evaluadores que trabajan en tu equipo, has perdido 5 x 2 = 10 horas de El tiempo del equipo por inactividad. Me pasó una vez, así que realmente lo intento. para evitar compromisos prematuros en nombre de cometer lo antes posible .

Comprometo el código varias veces al día . Cuando llego a un punto en el que el código está lo suficientemente completo para compilar y no rompe otras cosas, entra.

Debería mirar a dividir su trabajo para que pueda registrarse de manera segura varias veces al día.

Las razones para esto son dos:

1. Cualquier trabajo que no esté registrado puede perderse: su computadora puede tener una falla catastrófica. En este caso, cuanto más espere, más trabajo perderá.
2. Mientras más trabajo realice sin registrarse, más código deberán integrar otros cuando finalmente decida que se hornea. Esto introduce más posibilidades de conflictos y problemas de fusión.

Nunca es una buena idea adherirse a cualquier metodología o práctica sin entender las razones detrás de ella. De ahí proviene la programación de carga-culto.

Por lo tanto, "debería comprometerme todos los días porque Martin Fowler lo dijo" es una estupidez. Y a veces es impráctico también. Si está trabajando en una nueva función complicada, es posible que no llegue a un punto en el que valga la pena registrarse hasta que haya trabajado en ella durante unos días.

Esto no significa que debas asegurarte de que todo esté perfecto antes de registrarlo. Es una buena manera de perder el trabajo si algo sale mal. Lo correcto es desarrollar y utilizar un buen juicio sobre el tema. Las reglas generales solo pueden ayudarlo mucho.

Oded dio dos razones importantes para cometer código con la mayor frecuencia posible. Agregaré un poco más:

1. Mientras trabajas en tu parte del código, otras podrían necesitar algunas funciones en ese código. No deben esperar 6 días para conseguirlo. En este caso, mis colegas suelen crear un prototipo en mi código, cometerlo, agrego el cuerpo y lo vuelvo a cometer. Y esto suele hacerse en unas pocas horas.

2. El código 'común' es para que todos vean cada cambio lo antes posible. Si el fragmento de código en el que está trabajando está totalmente separado del trabajo de otros y no los hará esperar, se recomienda crear una rama en la que pueda trabajar, y luego, si todo tiene éxito, combínelo para la línea principal.

Soy un firme creyente en cometer cada cambio lógico que vale la pena mantener. Comprométase a menudo, y si no vale la pena mantener el código, vuelva a un estado limpio. Cuanto más espere para volver a enviar / publicar su código, más difícil será su implementación y más problemas tendrá. También recibirá comentarios sobre sus contribuciones mucho más rápido:

• ¿rompen la construcción?
• ¿estás duplicando los esfuerzos de otro miembro del equipo?
• ¿estás haciendo algo incorrecto?
• ¿O hay personas que esperan cosas de usted?

Los cambios pequeños son mucho más fáciles de administrar.

Además, vale la pena señalar la diferencia entre los diferentes sistemas de control de versiones. Algunos, como Git (distribuido), le permitirán confirmar y controlar todo su historial localmente, solo presionando cuando esté listo para publicar. Otros, como SVN (centralizado), combinarán los dos pasos haciendo que los pequeños compromisos sean muy ineficientes.

No olvides que tus compromisos son esencialmente documentación de cambios. Cuando las cosas van mal, te alegrarás de tener más historia que no es suficiente. Un solo compromiso por una semana de trabajo me parece inútil. Acababa de leer cada línea de código cambiada en lugar del resumen de cada fragmento lógico.

Creo que la mayoría de las respuestas aquí pasan por alto uno de los puntos principales de la declaración de Martin Fowlers. Esto está relacionado con la integración continua . El código que no está registrado (insertado / publicado / fusionado) en la línea principal no se ha probado.

Esto no debe interpretarse como un incentivo para cometer cualquier código que tenga en su máquina local cuando sea el momento de abandonar la oficina. Como lo señalaron otros aquí, eso sería malo, rompería la construcción y causaría una línea principal inestable.

Sin embargo, es un incentivo intentar realizar cambios en pequeños pasos que se pueden registrar en la línea principal sin causar problemas. Esto fomenta la evolución del código en lugar de rasgarlo todo y volver a escribir.

Ahora, ¿qué tiene de bueno esta forma de trabajar?

1. No cometer grandes trozos de código o cambios revolucionarios reduce la posibilidad de romper la compilación.
2. Si su compromiso rompe la compilación, es bastante trivial identificar cuáles son los problemas, revertirlo y luego confirmar una versión fija rápidamente.
3. Al asegurarse de que todas las pruebas se ejecuten en cada pequeño cambio en el código, se asegura de no introducir errores sutiles o regresiones que puedan surgir si el código crece fuera del esquema de integración continua.

Por supuesto, no todos los cambios se prestan a este enfoque. Como otros lo señalaron, ninguna regla es absoluta. Sin embargo, para los cambios que se espera que permanezcan fuera de la línea principal durante mucho tiempo, establezca una línea principal alternativa con su propio esquema de integración continua y siga el mismo enfoque hacia ella. Con los VCS distribuidos de hoy eso es algo bastante fácil de hacer.

Argumentos para registrarse todos los días:

• El código se almacena y se realiza una copia de seguridad contra una falla del disco duro
• La actividad se puede registrar en las notas de confirmación ( ¿Qué hice el jueves ...? )
• La integración con la base de código existente ocurre antes y en partes más pequeñas, con suerte identificando conflictos o fusionando problemas antes
• Su equipo tiene visibilidad de lo que ha estado trabajando
• Sus colegas pueden trabajar contra sus interfaces antes, dándoles más tiempo para integrarse con su 'gran parte compleja de código'
• Su código se probará en el mundo real antes, o al menos se expondrá a un uso mayor que el que usted le dará, lo que llevará a una identificación más temprana de errores u omisiones.

Argumentos contra el check in todos los días:

• No es necesario o no quiere
• Todavía no he 'limpiado' mi código, es un desastre
• No tengo tiempo

No creo que haya ninguna buena razón para registrarse menos que diariamente, aparte de la pereza o la desorganización. Nada peor que ver el código que se ejecuta en el entorno de desarrollo no coincide con el código en la rama de desarrollo porque alguien "aún no ha terminado" y, por lo tanto, no se ha registrado.

Me encantaría equivocarme al respecto, así que hágame saber cualquier argumento legítimo contra el registro diario.

Si quiere decir "cometer" como "fusionarse con la línea principal", entonces definitivamente no debería hacerlo en un proyecto de software que se está entregando a los clientes. Debe fusionar los cambios realizados y probados, de modo que la línea principal siempre esté funcionando y sea liberable, y no en un estado roto con características a medio terminar.

Sin embargo, el lujo de trabajar con el control de versión distribuido de hoy es que ambos pueden mantener la línea principal estable y, al mismo tiempo, hacer git/hg/whatever commit cada vez que crea que desea preservar el estado de las cosas. Hago esto una vez cada pocas horas y definitivamente al final de cada día.

Con DVCS, puede publicar su trabajo, colaborar en él con otros miembros de su equipo y mantenerlo actualizado con los cambios en la sucursal principal. Puede hacer todo esto sin contaminar la estabilidad del código del que dependen sus clientes y / u otros equipos.

En épocas en las que Subversion era la última tecnología y no había forma de dividir y combinar ramas de características sin mayor dolor, tener una línea principal donde varias características diferentes estuvieran en construcción simultánea podría haber sido el mejor enfoque. Pero esta superioridad no va más allá del 2010.

En Team Foundation Server, puedes 'Shelve', que no es lo mismo que un registro, sino que simplemente realiza una copia de seguridad de tu código para que, si tu máquina muere, no hayas perdido los cambios.

También he visto casas de software que tienen una 'línea de desarrollo' y una 'línea principal'. Los desarrolladores tienen la libertad de registrarse en la línea de desarrolladores cuando lo consideren adecuado y solo el líder del equipo tiene acceso a la línea principal, por lo que son responsables de copiar el código de desarrollo a principal cuando esté listo para la producción.