¿Cuáles son algunas buenas prácticas antes de registrar el código fuente? [cerrado]

Mi equipo usa Team Foundation Server para el control de fuente, y hoy arreglé algunos errores y la aplicación de prueba de humo antes de registrarlo, pero olvidé comentar algo de código. (Este código hizo que la interfaz de usuario fuera un poco extraña).

Quiero saber qué buenas prácticas hay antes de registrar el código; no quiero volver a cometer este tipo de error.

Una cosa que me he acostumbrado a hacer es mirar siempre las diferencias de cada archivo que estoy a punto de registrar, justo antes de registrarlos.

Nunca debe registrar el código comentado. Si tiene un código que necesita comentarse antes de registrarse, lo está haciendo mal.

En cuanto a las reglas:

1. Recibir las últimas
2. Solucionar conflictos de fusión

3. Construir

   3.1 Corregir errores de compilación

4. Ejecutar pruebas

   4.1 Arreglar pruebas rotas

5. Vaya a 1 (hasta que no haya nada nuevo que obtener)

Solo regístrese cuando todos los pasos estén completos.

Ver check-in dance .

Otras buenas prácticas:

• Revise la lista de archivos para registrarse para asegurarse de que sean los archivos esperados.
• Revise los cambios para cada archivo (eliminaciones / adiciones / diferencias)

No estoy tratando de ser demasiado comadreja aquí, pero la suposición en esta pregunta (y todas menos una de las respuestas) se aplica principalmente a VCS centralizado, como TFS, SVN, Perforce, etc. Lo
suficientemente justo, es lo que el OP está usando.

Por otro lado, sin embargo, cuando usa DVCS (como Mercurial y Git), generalmente no debe esperar para registrarse, y la mayoría de las cosas mencionadas en las respuestas, como diffs, get latest, merge, etc., no son necesarias . Incluso cosas como las revisiones de código y las pruebas son mejores que hacer después del registro (aunque tal vez antes de presionar, dependiendo ...)
La única excepción que vi aquí (hasta ahora) se asocia con un elemento de trabajo. Por supuesto, comentar sobre el registro también es bueno ...

Tres cosas que no vi en otras respuestas:

Incluir nuevos archivos

• Busque nuevos archivos que no sean parte de su lista de cambios
• Puede ser específico para SCM como Perforce: debe contarle todo lo que está en su cambio.

Revertir archivos sin cambios

• Odio cuando veo los cambios de otras personas y hay una lista de cambios con nueve archivos, pero solo tres de ellos han sido modificados.
• También revierto archivos con espacios en blanco o cambios sin sentido.

Verifique su confirmación enviada

• Asegúrese de que la compilación permanezca verde después de su confirmación.
• Solía ​​tener una segunda máquina que sincronizaría, construiría y ejecutaría después de mis confirmaciones, por lo que si algo salía mal, podría saltar y solucionarlo fácilmente.

Dos cosas cuando uso Git:

Comisiones atómicas:

• Solo realice cambios funcionales individuales para commit.
• Hacer commits lo más pequeño posible. Haga que sean fáciles de parchar, revertir y comprender.
• Solía git add --patchdividir mi cambio en varias partes si es necesario.

Ver diferencias mientras se resume

• Siempre me registro git commit --verbosepara poder ver una diferencia de mi cambio mientras escribo mi mensaje de confirmación. (O uso mi parche git-vim para mostrar la diferencia).
• Esto hace que sea mucho más fácil pasar por los cambios y describir todo el commit. Ocasionalmente, atrapo cambios no deseados en esta etapa. (Describir tu cambio te ayuda a pensarlo).

Algunos elementos de 'buenas prácticas' que impongo en los servidores de mi equipo son bastante sencillos. Primero, antes de registrarse, siempre debe obtener la última versión y ejecutar una compilación local, para asegurarse de que nadie más haya verificado nada en lo que el código choque. Además, tenga cuidado con cualquier conflicto de código en su máquina local, no en el servidor. Una vez que se haya confirmado que su código, con el último código descargado, se compila y funciona correctamente, estará listo para el siguiente paso. Ejecute cualquier prueba automatizada y luego comience el check-in para asegurarse de que todavía funcione correctamente. Luego, solo para estar seguro, obtenga las últimas novedades nuevamente.

Es posible, como administrador de TFS, hacer cumplir los comentarios en todos los registros. Recomendaría siempre incluir comentarios de check-in para su trabajo, independientemente de si se aplica o no. Si tiene la opción de hacerlo, aplíquelo. Asegúrese de que los comentarios son, al menos, un resumen general de lo que ha cambiado desde la última vez que revisó su código. De esa manera, si algo sale mal, puede revisar los registros y ver, aproximadamente, qué fue cambiado en ese check-in. Hace que la depuración de una compilación rota sea mucho más fácil.

Además, si tiene privilegios de administrador de TFS, haga cumplir las compilaciones sucesivas en los registros (para asegurarse de que todos los demás sepan de inmediato si su registro rompe algo), y puede configurar el servidor para que realice un registro controlado ( si el código registrado rompe la compilación, el servidor lo rechaza), o simplemente puede hacer que cree un error y lo asigne a quien rompió la compilación.

Hay algunas otras opciones que puede activar o desactivar para mantener todo en orden, o sugerirle a su administrador de TFS que lo active para mantener las cosas agradables y limpias ... pero son en gran medida preferidas

Buscar y reemplazar palabras de maldición ;-)

Si está ingresando desde Windows, verifique si su código no tiene esos caracteres ^ M invisibles: los editores en UNIX a menudo dan errores / advertencias debido a eso.

También intente y reemplace las pestañas: diferentes usuarios terminarán viendo las pestañas de manera diferente, algunas con 4 espacios, otras 8 y no son buenas para la legibilidad del código.

El mejor enfoque en mi humilde opinión es que un script predefinido verifique su código con las pautas de codificación de su organización. Un montón de sistemas de control de fuente tienen esta funcionalidad.

En mi empresa utilizamos revisiones de registro. Estos no tienen que ser detallados, pero solo mostrarle a alguien las diferencias en su lista de cambios y hablar a través de ellos a veces resaltará el error tipográfico extraño que se perdió en las pruebas.

Nuestro servidor de control de fuente no le permitirá registrarse a menos que indique el nombre del revisor en los comentarios (en el formulario! Iniciales, por ejemplo! BW si Bruce Wayne hizo su revisión). El revisor recibe un correo electrónico indicando que ayudó a revisar. Esto está abierto a una explotación obvia, pero parece funcionar bastante bien.

Siempre que sea posible, me gusta asociar un check-in con un elemento de trabajo. Esto le brinda información contextual sobre POR QUÉ se cambió esto, no solo QUÉ se cambió. TFS tiene un sistema de seguimiento de elementos de trabajo bastante decente, por lo que es bastante trivial en el momento del check-in.

(esto es además de revisar las diferencias de mis cambios)

Una pequeña cosa que hago es no registrar los archivos que realmente no han cambiado. Estos archivos pueden haber sido modificados inadvertidamente, o pueden haber estado involucrados en refactorizaciones que se han revertido o se han convertido en discutibles.

De esta manera, su conjunto de cambios (asociado con un elemento de trabajo) contiene exactamente los archivos necesarios para satisfacer el elemento de trabajo.

Para combinar todas las respuestas aquí y dar una lista de verificación completa

1. [entrada / salida] no debe registrarse directamente en la transmisión en la que otros están trabajando. Debe tener una estrategia de transmisión: por ejemplo, por desarrollador, una transmisión en la que pueda ingresar y salir independientemente sin molestar a los demás: su trabajo esté seguro pero en su propia secuencia de desarrollo, así que [solo en su propia secuencia de desarrollo]. Con cada verificación, lo asocia con un registro de cambios para que sus cambios sean atómicos contra ese cambio llamado conjunto de cambios (para que pueda distribuir los rfc / errores individuales, etc., sin tener que entregar 'todo').

2. [luego vuelve a redactar con la secuencia de tu equipo] significa que obtienes los cambios de otros en tu propia secuencia. Durante esa operación, puede ver en el diálogo de fusión todos los "diffs" y revisarlos o ... si hay miles y / o está usando no código, sino también, por ejemplo, modelos de datos / proyectos siebel, etc., confíe en fusiones no triviales, fusiones triviales automáticas y triviales, la última categoría contiene las difíciles. Recuerde que todavía está trabajando en su propia secuencia.

3. [rebase completo] Si todo está bien, compruebe todos los cambios que acaba de recibir de la transmisión del equipo: su propia transmisión ahora está actualizada

4. [entregar] ahora entrega tu trabajo a la transmisión del equipo. SI no desea entregar todo, también puede seleccionar, por ejemplo, 1 RFC específico con esas versiones específicas de archivos o un conjunto de RFC / defectos resueltos.

5. [entrega de prueba] debería funcionar bien, pero dado que existe la posibilidad de que alguien entregue cambios también: puede probar si su trabajo funciona con los últimos cambios en la transmisión del equipo. Con los mismos diálogos de fusión que muestran diferencias.

6. [completar entrega] completa tu entrega y tu trabajo ahora está en la secuencia del equipo.

Para hacerlo más complejo: dado que todavía existe la posibilidad de que el trabajo que entregó = ok, PERO ya está trabajando en una versión adicional, debe usar la línea de base siempre después de la entrega e indicar qué línea de base es la preferida para otros usuarios. . Eso asegura que otros desarrolladores obtengan una recomendada y no la última versión en la transmisión (si está trabajando en ese escenario). Esa es también una verificación triple, de modo que incluso si las últimas versiones en la secuencia del equipo son "malas", todavía no son las que otros desarman o miran y su administrador de configuración puede fusionar la versión anterior a la siguiente versión para deshacer su entrega

• la respuesta de histumness ocurre 2 veces: en los pasos 2 y 6
• la respuesta de Oded en el check-in dance: idem pero una capa adicional de entrega y rebase en el check-in / check-out para asegurarse de que trabaje aislado y los errores siempre se puedan eliminar fácilmente incluso en etapas posteriores
• la respuesta de guildsbounty respondida: obtener la última es el paso 2. Para la compilación: realmente depende si TIENES una compilación ... en mi mundo tienes entradas de modelos de datos, documentos de texto, hojas de requisitos, datos de configuración de informatica, siebel, etc., y sí, también código java, código .net, etc., que todos deberían mezclarse. Así que no hay realmente "una compilación" aquí, sino más bien una integración más arriba dependiendo de si esa sola compilación, por ejemplo, de su "código" se integra con todo el resto de las cosas, ya que no puede saber con certeza si se trata de cosas de integración y dependiendo de sus entornos de prueba podrían ser compilados, se necesita material o, en entregas superiores, otra compilación porque necesita algo de otro equipo.
• la respuesta de guildsbounty sobre comentarios y requisitos: creo que todos los entornos en los que no tienes integración de VERSIONES y Cambios en los conjuntos de cambios (y tipo: defectos, RFC, hotfi) no están maduros. Creo que es un caos si no puede, por ejemplo, automatizar las notas de la versión con la cantidad de errores y rfcs enviados a los que se puede hacer clic para acceder a las versiones exactas que se tocan (ya que, por ejemplo, la versión 1 y la versión 3 de hello.c podrían muy bien entregarse, pero la versión 2 no debería haberse entregado porque esas cosas allí serían parte de un lanzamiento posterior, pero algunos novatos ya lo pusieron) (por lo que significa una decisión manual SI también desea sacar la versión 3 de hola. c PERO sacar la versión 3 significa que también debe eliminar todas las demás versiones tocadas por ese RFC / defecto, por lo que debe ser fácil y rápido con una herramienta para eliminar todo (incluso si varios desarrolladores trabajaron en partes de ese mismo RFC), pero al menos necesita cosas a su alrededor para decidir, etc. La documentación adicional siempre es útil, pero al asociar conjuntos de cambios se obtiene el círculo completo: una versión <- un conjunto de cambios <- elementos de trabajo <- un ticket / rfc / defect <- un requisito. Significado: usted sabe qué requisitos se entregan total o completamente: un requisito tiene múltiples RFC o errores o lo que sea. El RFC tiene múltiples elementos de trabajo para múltiples personas. ese elemento de trabajo corresponde a un conjunto de cambios que existe de un conjunto de versiones (por ejemplo, las versiones 1 y 3 de hello.c en la secuencia de integración que, por supuesto, NO son las versiones 1,
• el comentario de luis.espinal: no rompa la compilación se verifica dos veces en rebase y entregue aún ... hay entregas más altas para 'gestores de lanzamiento y meisters de construcción' que deberían ver los conjuntos de cambios y las líneas de base como su información. "Nunca trabaje directamente en la rama principal" sí, la estructura de transmisión puede ser grande o simple, pero en esencia: los desarrolladores tienen su propia transmisión, entregan a una transmisión de equipo que entregan a una transmisión de lanzamiento. -> para que las entregas de todos los equipos (por ejemplo, equipo de documentación, equipo de requisitos, equipos de desarrollo,

En su ejemplo, indica que olvidó comentar el código. Los errores suceden. El sistema de gestión de la configuración a su alrededor debería ocuparse de ello. Realmente puede ser que, por ejemplo, entren miles de cambios y las "compilaciones" e "integraciones" se realicen en una jerarquía de flujos en diferentes servidores encadenados y procesados ​​a tiempo. Entonces, incluso después de 5 meses, su código comentado se prueba en un servidor de integración porque su código necesita integración con otro código y sistemas, aún así debería ser posible sacar atómicamente su conjunto de cambios y continuar. Entonces, la mejor práctica es más o menos en un nivel superior. El diseño general de las secuencias de gestión de configuración debe ocuparse de ello. Para desarrolladores individuales, la mejor práctica es, por supuesto, validar / prueba unitaria. Pero desde el panorama general hasta "

Algunos de los siguientes se aplican más que otros (o en diferentes formas) dependiendo de su SCM, así que aquí van:

1. No rompa la compilación: compruebe solo el código que compila.
2. Comente sus entradas (y posiblemente sus salidas si su SCM le ofrece esa opción).
3. No mantenga las cosas sin marcar durante largos períodos de tiempo.
4. Regístrese a menudo (varias veces al día si es posible).
5. Etiqueta de manera significativa.
6. Etiquetar regularmente.
7. Nunca trabaje directamente en la rama principal.
8. Cada lanzamiento a producción debe tener su propia etiqueta (y una rama de solo lectura fuera de la rama principal si es posible). Cuando sea posible, haga lo mismo para las versiones de prueba UAT / Integración / Preproducción.
9. Debería poder construir exactamente lo que está en producción a partir de lo que está en su SCM y de una etiqueta.

NOTA : algunos de los elementos anteriores parecen bastante obvios, pero no creería cuántas personas trabajan realmente en la rama principal o realizan cambios en la producción primero y luego crean manualmente deltas para pasar al control de versiones ... directamente en la rama principal. .. y con etiquetas. Dulce como la bilis fermentada mezclada con jugo de axila sin lavar ... sí, así.

Tener una lista de verificación personal. Comience vacío cuando comete un error, en una entrada. Cuando se convierta en una segunda naturaleza, elimínelo de la lista.

Ejecute las pruebas. Si pasan, regístralo. Si te equivocas y algo pasa de las pruebas, escribe una prueba.

Hacemos lo siguiente ...

1. Prueba: queremos asegurarnos de que funcione. Por lo menos, queremos saber que no rompe nada.

2. Revisión de código, o al menos una verificación de amigos: esta es una excelente manera de garantizar que el conocimiento se difunda y que las personas se mantengan actualizadas. También ayuda a detectar errores antes de registrar cosas.

3. Enviar una notificación anticipada: se envía una notificación anticipada al grupo antes de registrarse. El propósito no es solo hacer que otros sepan qué archivos o áreas están cambiando, sino que les da aviso (en caso de que decidan tomar nota) en caso de que se espere que esos cambios los afecten.

4. Algunas horas después de enviar el aviso anticipado, se realiza el registro y se informa al grupo por correo electrónico. Todos en el grupo pueden saber cuándo se realiza el trabajo particular en un error o característica.

5. Se pega una copia del aviso de registro en el registro de corrección asociado con el error o la función. Al buscar a través de los registros, encontramos que es muy útil tener una idea de lo que implica la corrección / función.

Ejecute sus pruebas unitarias en las que ha estado trabajando tan diligentemente. El verde es bueno

Asegúrese de que su código esté formateado correctamente (por ejemplo, para Java: seleccione su código y presione Ctrl-Shift-F en Eclipse). Pero tenga cuidado de hacer lo mismo para un documento completo.

Siempre, siempre, siempre , verifica que cualquier cambio que hayas realizado no rompa la compilación. Especialmente cambios menores que pueden parecer triviales.

Una vez que hice un cambio muy pequeño que no pensé que causaría ningún problema justo antes de dejar el trabajo para el fin de semana. Efectivamente, ese pequeño cambio rompió la construcción y no se ejecutaron pruebas nocturnas para nuestro proyecto. El jefe de preguntas y respuestas no estaba muy contento con eso, y con razón.

Busque porciones de sus cambios que pueden entrar como unidades independientes.

A menudo, para cuando tengo una solución o una mejora del código, hay bastantes cambios. Algunos de ellos son específicos del cambio de comportamiento que busco; otros son refactorizaciones que hice para hacer ese cambio más limpio.

Prefiero registrar cada refactorización por separado, con su propia descripción del cambio, como esta:

REFACTORADO: Cambiar el nombre de X a Y

X tenía sentido antes porque ... pero ahora debería ser Y. Esto está relacionado con el trabajo para el número 9.

Luego, una vez que se registra cada refactorización, el cambio de comportamiento final es a menudo trivial.

Además, algunos cambios afectan muchas líneas de código pero no son muy interesantes, mientras que otros cambios están muy localizados pero tienen un impacto importante. Si estos cambios se registran juntos, puede ser difícil leer los diferenciales. Entonces, los mantengo separados.

Más tarde, cuando alguien lee el historial de cambios, es obvio cómo las cosas llegaron al estado actual de las cosas y por qué son así. También es trivial deshacer mi cambio de comportamiento porque no está enredado con toneladas de otras ediciones.

Haga lo que haría al devolver algo que le pidió prestado a alguien. Asegúrese de que esté limpio y en buen estado. Si hizo un desastre, asegúrese de limpiar antes de devolver el código a su propietario (en la mayoría de los casos, su empleador).

Mantengo un repositorio local de hg para mi trabajo.

• Cada vez que reviso algo, miro el diff y me aseguro de que todos los cambios sean aceptables.
• Intento notar la característica clave del registro.
• Intento mantener cada tamaño de confirmación en una característica clave.

No digo que estos sean los mejores, pero funcionan para mí.

Cuando escribo código que sé que no debe ser registrado, agrego una línea antes de que contenga "// TEMP:" y luego con "// END TEMP". Esto, junto con hacer diff antes de registrarse, promete que no registraré ese código por error.

Pruebe a fondo todo lo que agregó o cambió. Pruebe todos los casos posibles que se le ocurran. No deje la prueba al control de calidad. Si tuviera un sándwich por cada vez que hiciera algún cambio menor, y luego probara algunos casos de prueba solo para estar seguro, e inmediatamente viera problemas, tendría muchos sándwiches. Por lo general, me digo en voz alta: "Estoy muy contento de haber intentado eso ..."

Dices que la IU se volvió extraña después de tu cambio. Si solo hubiera ejecutado el programa y hubiera mirado la interfaz de usuario antes de registrarse, ¿habría notado el problema?