¿Los registros de origen son frecuentes o infrecuentes?

Question

Estaba revisando mi código y me di cuenta de que no tengo ni idea de qué criterio ideal debería cumplir mi código para realizar un check in.

Ayer me registré después de haberlo revisado durante una semana. Hoy volví a registrarme después de hacer pequeñas actualizaciones. A veces me gusta mantener el código en el que estoy trabajando comprobado hasta que pueda pasar un poco de prueba.

Mi jefe suele mostrarse molesto por las personas que mantienen el código desprotegido durante el fin de semana o las vacaciones, así que trato de evitarlo (solo porque me olvido de lo que estoy trabajando).

¿Debería preocuparme si alcanzo una masa crítica de código o si no puedo encontrar los errores porque también hay demasiado código para buscar?

Answer 1

Los registros deben hacerse con frecuencia.

A en cheque debe ser

• Atómica. Contiene todos los cambios necesarios, pero no más. Lo que también significa que
• los cambios en el espacio en blanco entran en su propia confirmación.
• cambiar solo una funcionalidad. Esto podría cambiar varias funciones, pero no debería cambiar la funcionalidad de varias maneras y/o lugares.
• comentado. Un comentario de verificación debería permitirle encontrar rápidamente un compromiso, incluso si tiene 2 años y ya no está trabajando en esa fuente en particular (o incluso proyecto).
• trabajando.Comprométase solo si el código realmente se construye y hace lo que afirma hacer.

Si necesita su patio de juegos personal para comprometerse considere una rama de trabajo o duplicar el repositorio con algo así como git svn. Recuerde fusionar los cambios realizados de manera atómica tanto como sea posible. Esto podría ser más trabajo, pero de inmediato vale la pena si necesita encontrar una confirmación que haya cambiado o posiblemente haya roto algo.

Answer 2

Solo debe verificar el código que está funcionando y no rompe una compilación, no debe intentar verificar todos los códigos para una característica determinada creando un conjunto de cambios agradable y manejable (suponiendo que su sistema de control de versiones admite cambios establecer conceptos).

No estoy seguro de lo que quiere decir por espacio de disco o capacidad de búsqueda.

Answer 3

Si su sistema de administración de código fuente lo permite, prefiero hacer una rama o actividad privada, y realizar comprobaciones a eso al menos diariamente, o más frecuentemente si voy a iniciar algo que es arriesgado. Solo me fusiono o entrego para que sea accesible a los demás después de que el bit en el que estoy trabajando realmente funcione.

Answer 4

Tanto como sea práctico, trato de mantener mis registros lo más granulares posible, con la condición de que no verifique/no compruebe nada que a) no compile, b) se rompa la unidad pruebas, oc) romper la compatibilidad con versiones anteriores (a menos que se solicite/se diseñe de esa manera).

Si me preocupa dejar un código nuevo o actualizado en mi máquina durante un tiempo prolongado, generalmente creo (o solicito haber creado) una rama temporal para mi propio uso, pero solo la uso por tan poco tiempo ya que tengo que antes de que pueda unirse a la rama que estaba trabajando en

Answer 5

puedo recomendar las siguientes directrices:.

• cada entrada debe ser "atómica", lo que significa que sólo cambia una parte de la sistema. No se recomienda un cheque grande que cambie muchas cosas, porque luego se vuelve difícil revertir solo un cambio.
• No ingrese el código hasta que no se haya probado completamente.
• Revise el código tan pronto como esté listo. Es bueno para realizar copias de seguridad y porque su copia de trabajo no se sincroniza con los últimos cambios en el control de la fuente cuanto más tiempo permanezca allí.
• Ya sea que se registre con frecuencia o con poca frecuencia, el espacio en el disco debe ser aproximadamente el mismo.
• Para búsqueda, solo asegúrese de que su check in tenga un comentario adjunto.

Answer 6

Llegue temprano y con frecuencia, al igual que votar.

Una advertencia es que hace una pequeña diferencia cómo funciona su proceso de integración. Si tiene una integración continua, no desea volver a registrar las cosas en el troncal a menos que haya realizado pruebas de unidad y esté seguro de que funcionará.

La forma de conciliar estas dos cosas es crear una rama para su espacio de trabajo, registrar a menudo en la rama y volver a fusionar cuando haya realizado y probado cambios. Las molestias de hacer grandes fusiones sobre muchos cambios lo animarán a dividirlos en pequeños pasos. Lo que es algo bueno.

Answer 7

Si el espacio en disco es una preocupación, realmente necesita discos duros más grandes. Incluso en un entorno redundante y seguro, son lo suficientemente baratos como para que sea ridículo tener que pensar en ellos alguna vez.

En cuanto a la frecuencia con la que se registra, a menudo será una cuestión de política personal. Dentro de mi propio equipo de siete codificadores, tiendo a registrarme una vez por cada boleta de trabajo, mientras que un colega promedia unos seis registros por día.

Es realmente una cuestión de lo que te hace sentir cómodo. La única política oficial es: no rompa la construcción y no rompa las características de trabajo. Si es posible que deba entregar su trabajo a mitad de camino, regístrese más a menudo. Esto funciona para nosotros

Answer 8

Llego con frecuencia.

Dos cosas control de la fuente que da que se pierde por no comprobar en frecuencia son:

• simplificar la colaboración
• seguir el historial de los cambios con el tiempo

Otros desarrolladores tienen que ser conscientes de cambios que están sucediendo en la base de código. Controlar sus cambios anticipadamente les informa sobre lo que está trabajando. Puede ayudar a evitar la duplicación de esfuerzos (ya sea que varias personas implementen lo mismo para corregir el mismo error). Las comprobaciones poco frecuentes pueden llevar a cambios significativos e inesperados en el código, que es mucho más probable que resulte en situaciones difíciles de depuración (no tanto por el código que acaba de registrar, sino por las complejidades de su interacción con el resto del sistema)

Su sistema de control de fuente no puede ayudarle a revertir los cambios si no sabe qué cambios se han realizado. Además, si pierdes los cambios locales en los que has estado trabajando durante la última semana, el daño sería mucho mayor.

No debe limitarse debido al espacio en disco. Los sistemas SCM son bastante inteligentes sobre el uso del disco, pero en cualquier caso el almacenamiento es barato y abundante.

Dicho esto, le sugiero que divida el trabajo que tiene que hacer en trozos pequeños, y regístrese después de haber completado una de esas piezas. Será más fácil para ti y para los otros desarrolladores.

Answer 9

Pregunta: ¿Qué tipo de VCS estás usando? Tu comentario de que tu jefe se quejó cuando dejaste el código durante unas vacaciones parece extraño. Siempre tengo el código desprotegido, usando Subversion, y a nadie le importa.

Si usa un VCS que requiere cajas reservadas, o si necesita falsificar las cajas reservadas, no puede utilizar las mejores prácticas y su organización debe actualizar a Subversion o mejor.

Esto puede no depender de usted, pero si está utilizando un VCS antiguo, eso podría afectar las respuestas dadas.

Answer 10

Este es el procedimiento que utilizamos:

• Un desarrollador obtiene una tarea con un documento de diseño que describe las nuevas características o correcciones de errores.
• Ese desarrollador realiza esos cambios y los prueba.
• El nuevo código es revisado por pares por al menos otros 2 desarrolladores, asegurándose de que las características y errores descritos en el documento de diseño se hayan implementado o reparado.
• Se realizan todos los cambios sugeridos por los revisores del código. Si es necesario, se realiza otra revisión.
• Cuando los revisores están satisfechos, y el desarrollador jefe da la OK, el desarrollador toma el "control" del repositorio (procesalmente - nadie más puede verificar nada hasta que se libera el control), verifica los cambios, verifica una nueva copia de la aplicación y compila y prueba que todavía se construye y se ejecuta con éxito.

Eso significa que pueden transcurrir semanas, a veces meses entre compromisos para un desarrollador, pero esto nos da mucha protección contra romper la construcción y nos permite seguir de cerca las tareas y los cambios asociados con cada uno.

Answer 11

Estoy de acuerdo con la mayoría de lo que se ha dicho aquí, pero agregaría el punto obvio de que es menos importante hacer check-ins frecuentes al repositorio central si está utilizando un vcs distribuido como bzr o git. En este caso, también puede inclinar un poco más hacia las confirmaciones no probadas, siempre y cuando solo esté actualizando su repositorio local. Es conveniente que te rindas por el día para seguir adelante y comprometerte, incluso si aún no lo has probado, porque no tienes que preocuparte por ningún problema que pueda afectar a nadie más.

Answer 12

La frecuencia con la que verifica el código fuente es en realidad una función de algunas cosas, sobre todo, la cultura y el proceso.Usted desea observar buena "higiene" marcando en frecuencia con el fin de minimizar el riesgo de pérdida de datos, pero hay otros beneficios a esta práctica que puedan aplicarse más o menos dependiendo de su metodología:

• En una entorno ágil, regular check-ins menor riesgo de la compilación rompiendo o de encontrándose fusión conflictos con otros programadores;

• más frecuentes registros de entrada implican más granulares check-ins que significa que estás recopilación de información mucho más --- esto es útil para obtener estadísticas sobre la salud del proyecto y para la caza de insectos;

• granular check-ins quiere decir que los comentarios de check-in están más enfocados, y hay menos posibilidad de cambios menores de describir que se hicieron;

• granulares check-ins asegurar que diferenciaciones entre la versión se vuelven más fáciles de navegar.

Su pregunta específica, aunque es de unos criterios de facturación --- Por supuesto, esto es una cuestión de estilo. Como regla general, intento dividir una tarea en subtareas de 1 a 3 horas, cada una de las cuales tiene un objetivo específico: registrar una vez que haya terminado una subtarea. "Finalizado" es subjetivo, pero en mi libro significa trabajando, es decir, todas las pruebas de unidad pasan, y la cobertura de su código está en un nivel aceptable (aceptable para usted, es decir).