¿Cómo puedo convencer a mis compañeros de desarrollo de que QUIERA agregar comentarios a las confirmaciones del código fuente?

Sé que Subversion (lo que estamos usando en el trabajo) se puede configurar para requerir comentarios en las confirmaciones, sin embargo, no estoy en una posición de poder para simplemente activar esto. Sé que mi razón para comentar mis confirmaciones es porque es útil, aunque solo sea como un recordatorio de memoria, para comprender rápidamente la razón detrás de la confirmación. Sin embargo, esto no parece ser suficiente para combatir las dos respuestas que siempre obtengo:

1. Tarda demasiado y solo quiero que mis cambios entren en el repositorio.
2. Es bastante fácil solo mirar las diferencias.

Incluso les muestro el valor de simplemente poner un ID de problema de JIRA y cómo se vincula automáticamente con el problema, pero aún no hay dados con ellos.

Lo peor de todo es que la persona que puede hacer la llamada está en el mismo campamento: no quiere molestarse y está bien con mirar los diferenciales.

Sé que es lo correcto, pero ¿cómo puedo hacer que vean la luz? Incluso si no puedo convencer a mis colegas desarrolladores, ¿cómo puedo convencer a la gerencia de que es lo correcto para el negocio?

Centrarse en "por qué". Todo está muy bien mirando las diferencias y viendo que alguien cambió el flujo lógico de una sección de código o algo así, pero ¿por qué lo cambiaron? El por qué generalmente está en el boleto asociado (JIRA para usted).

Pueden preguntarse por qué el "Por qué" es importante, pero dentro de 2 años cuando haya detectado algún error que sea un efecto secundario de ese cambio, saber por qué se hizo es increíblemente importante no solo para solucionar su nuevo error, sino también para asegurarse no haces que el viejo error vuelva a aparecer.

También está el motivo de la auditoría. Las confirmaciones de enlace y las identificaciones de tickets hacen que sea realmente fácil decir ok, estamos lanzando la Versión 2, esto corrige los defectos 23, 25, 26 y 27, pero no hay confirmaciones contra el defecto 24, por lo que aún está pendiente.

Haz que hagan las fusiones y lidien con el apoyo. De nuevo, tal vez no esté en condiciones de hacer esto, pero si se encuentra a sí mismo siendo el que resuelve un problema de un compromiso anterior, envíelo cortésmente y dígalo. No puedo decir lo que hiciste porque no hay comentarios de confirmación, hiciste estos cambios que necesitas para resolverlo.

También para fusionar ramas. No estoy seguro de si eso recae sobre usted o no, pero esa es un área que encontré útiles los comentarios.

Una vez más, no en su barco, pero cuando gestioné un equipo de software, les dije que si hacían buenos comentarios de compromiso, los usaría en un informe de estado semanal. Obtuve excelentes compromisos después de eso y también fue más fácil para mí hacer un seguimiento de lo que estaba sucediendo como gerente.

Necesitamos comentarios de check-in por la misma razón por la que necesitamos saltos de línea y espacios en nuestro código. Para hacer que las cosas sean más fáciles de rastrear, comprende leer y comprender.

A veces necesitas comparar, pero a menudo no. Obligar a los desarrolladores a comparar cuando todo lo que necesitaban era leer 2-3 oraciones es una pérdida total de tiempo. Me pregunto por qué no ven el valor del tiempo del desarrollador.

• Pon un buen ejemplo. Haga que sus propios mensajes de confirmación sean un brillante ejemplo de utilidad. Incluya referencias a cualquier otro sistema que su equipo use para administrar historias y defectos. Ponga una breve declaración que resuma el cambio y una buena explicación de por qué el cambio es necesario y no otra cosa en cada presentación.
• Siempre que la falta de un mensaje de confirmación decente le cause trabajo extra, envíe una pregunta al remitente. Sea persistente con esto (pero no un idiota).
• Si no es sobrepasar su rol, escriba un script que envíe un registro de cambios diario utilizando los mensajes de confirmación. Esto le dará credibilidad a su argumento de que los mensajes útiles tienen un beneficio más allá de navegar por las revisiones. Esto también podría ayudar a que la administración esté de su lado, ya que verán día a día lo que sucede.
• Identifica a tus aliados. Esperemos que haya al menos otra persona que esté de acuerdo con usted (quizás al no estar en desacuerdo). Encuentra a esa persona o esas personas y convéncelas más para que no estés solo.
• Cuando se presente la oportunidad de mencionar cómo los mensajes de confirmación decentes le han ahorrado tiempo (o los mensajes deficientes le han costado tiempo), aproveche.

No tengas miedo de ser la rueda chirriante. Combatir los malos hábitos de otras personas es a menudo una guerra de desgaste.

Esta tiene que ser una de las preguntas más extrañas que he escuchado. ¿La gente pasa horas o incluso días arreglando algo y 2 segundos adicionales para escribir un mensaje de confirmación es demasiado largo? Tengo que decir que me preocuparía trabajar con personas tan miopes. Obviamente, no están utilizando sus herramientas para acercarse a su máximo potencial.

Aquí hay un ejemplo de una revisión de código en la que participé la semana pasada. Nuestro software de control de versiones no conserva el historial de las fusiones, por lo que para los cambios más antiguos debe encontrar la rama exacta en la que se realizó, de lo contrario, el mensaje de confirmación solo muestra algo como "fusionado de la rama Y". La rama Y podría mostrar "fusionada de la rama Z", y una rama de unos niveles de anidamiento más profundos en realidad tiene el mensaje de confirmación real.

Un nuevo empleado no sabía cómo rastrear el historial correctamente, lo que significa que estaba trabajando esencialmente solo con los diferenciales. Vio un código comentado relacionado con el error que estaba rastreando. Cuando descomentó el código, su error desapareció. Asumió que alguien había comentado el código durante la depuración y lo registró por error.

Eso no nos pareció bien a algunos de nosotros durante la revisión del código, así que rastreé el mensaje de confirmación real y descubrí que había una razón válida para eliminar ese código hace un año. El nuevo empleado pudo corregir su código para corregir el error recién descubierto sin reintroducir el antiguo.

Hay mejores maneras de evitar la introducción de ese tipo de regresiones, como pruebas unitarias exhaustivas, pero de alguna manera no veo personas que no puedan molestarse con un mensaje de confirmación de 2 segundos que "pierde" el tiempo en las pruebas unitarias.

Tuve exactamente el mismo problema aquí, así que agregué un enlace de preconfirmación a Subversion para que no aceptara ninguna confirmación que no comenzara con el número de Historia del usuario (alguna coincidencia de patrón básico para un formato esperado).

No hay nada que los detenga entrando 000-0000, pero una vez solo un idiota disruptivo inventará un número cuando tenga un número perfectamente aceptable allí.

Hice esto después de pasar días tratando de encontrar en qué compilaciones entró un conjunto de historias de usuarios. Sí, era para lidiar con una falla del proceso en otro lugar, pero aún así es una información increíblemente valiosa para rastrear.

Los buenos comentarios de confirmación son como cualquier buena documentación, una memoria caché para su cerebro lento y desaparecido o una memoria caché del resultado de una larga depuración / análisis de problemas / investigación.

Por ejemplo, cada vez que pasa tiempo descubriendo algo, como depurar, analizar registros o lo que sea, sus hallazgos y resultados son preciosos. Por supuesto, la mayoría de las tareas pueden repetirse, pero puede llevar tiempo. Por lo tanto, siempre debe documentar sus resultados.

Aún así, la documentación lleva tiempo y, a veces, se considera innecesaria, como "solo tuvimos que hacer esto una vez, entonces, ¿por qué escribirla?". Está bien, pero tan pronto como haga lo mismo una segunda vez porque no documentó los resultados la primera vez, entonces, por supuesto, es inteligente documentar los resultados.

Entonces, si sus colegas sienten que es demasiado trabajo agregar comentarios de compromiso, por ejemplo, al menos señalar el caso / Ticket Jira que estaban resolviendo, entonces, podrían estar motivados por la presión de responder constantemente a las preguntas sobre el motivo de cada uno conjunto de cambios

En mi opinión, la documentación debe ser producida en función de la información solicitada. Por ejemplo, la correspondencia por correo es un sistema de documentación bastante bueno. Las preguntas reciben respuestas que luego se pueden recuperar, así es como las listas de correo y los foros funcionan en la práctica como bases de conocimiento.

Desafortunadamente, donde trabajo, el correo se elimina automáticamente después de 3 meses, por lo que no siempre funciona en la práctica.

Busque el perdón, no el permiso.

Aunque fue duro, hice exactamente esto. Tenía una división de 50/50 entre las personas que apoyaban y las que se oponían, la mayoría de las cuales tenían el mismo nivel que yo en el grupo. Los argumentos fueron "No puedo ser molestado" y "¿Cuál es el punto?". (Ambos indican apatía y pereza, no preocupaciones genuinas).

Agregué un gancho previo al compromiso que simplemente midió la longitud de la cadena y le di un mensaje ligeramente humorístico antes de rechazarlo. Puse mi nombre en el mensaje para que la responsabilidad de "este ultraje" fuera clara. Por supuesto, "la oposición" podría eliminarlo fácilmente, ¡pero profundizar en los guiones requeriría más esfuerzo que agregar un comentario más!

Durante una semana recibí mensajes agregados como * * (improperio eliminado) o kjhfkwhkfjhw. Después de eso, comenzaron a aparecer mensajes básicos.

Un año después, los escépticos usan comentarios significativos y realmente admiten cuán miopes eran. Nunca podría haber llegado a un consenso, pero ciertamente obtuve perdones y tal vez credibilidad. Funciona, la gente lo usa.

Si quisieras ser más amable (o sentir que te meterías en problemas), pide permiso para agregar un enlace de compromiso durante un período de prueba. Digamos que si a la gente no le gusta en 2 o 4 semanas, lo sacará. Lo más probable es que pierdan interés ... o que les guste.

Por lo general, convenzo a las personas a través de:

• dialéctica con buenas razones de apoyo
• predicar con el ejemplo
• desgaste

Si quisiera que nuestro equipo hiciera algo lo suficientemente malo, seguiría molestando hasta que me salga con la mía. Intento molestar durante esos momentos en los que puedo señalar que podríamos haber ahorrado tiempo / dinero si ya hubiéramos estado haciendo X.

Otras buenas razones para cometer comentarios:

• Generando ChangeLog automáticamente a partir de los comentarios.
• Seguimiento de auditoría para la corrección de errores, adiciones de funciones. Esto es útil tanto dentro como fuera del equipo.
• Haga que el correo de confirmación sea más útil.
• Evite que pregunte al desarrollador qué hace commit X (después de casi cada commit).

• Revise sus registros SVN para algo oscuro hecho hace 6 meses.
• Haga algunas preguntas sobre esto sin decir cuándo se ha hecho.
• ???
• Lucro

¿Cómo haces que quieran agregar buenos comentarios?

De una experiencia con un colega que acabo de tener. Al final de un proyecto, tuvimos que escribir un documento resumen de todos los cambios realizados a lo largo del proyecto. Al no haber tomado buenas notas de confirmación, mi colega encontró esta tarea bastante lenta, y ahora ha cambiado a hacer comentarios bastante largos con cada confirmación.

Entonces, la conclusión: una solución podría ser que los desarrolladores escriban documentos de resumen al final del proyecto que detallen qué cambios se hicieron a qué archivos, qué archivos se agregaron / eliminaron y por qué.

Proponga esto a la gerencia a puerta cerrada:

El peor de los casos sucede: todos los desarrolladores de nivel superior salen por la puerta.

A medida que la empresa se esfuerza por llenar los puestos de desarrolladores vacíos, el equipo de gestión tiene la tarea de comunicar el estado del sistema al cliente.

Pregúnteles qué creen que facilitaría su trabajo al reconstruir el historial de la aplicación:

¿Lees confirmaciones simples en inglés que describen claramente el estado cambiante del sistema?

¿O preferirían mirar las diferencias de código y resolverlo ellos mismos?

Supongo que una forma de convencerlos sería experimentar realmente el dolor que estás sintiendo.

Por ejemplo, supongamos que están trabajando en el siguiente problema: tienen un error que, de alguna manera, apareció cuando se implementó otra corrección de error para el mismo código (oh, la ironía). Sería genial poder buscar esto simplemente buscando a través de los mensajes de confirmación (y así descubrir quién lo escribió).

Otra forma sería explicarles que el mensaje de confirmación podría ser útil para dar una pista de por qué algo se implementó de cierta manera. Incluso si el mensaje de confirmación solo dice "característica X", aún puede obtener una pista de quién lo implementó, para saber con quién hablar.

Sin embargo, esto no parece ser suficiente para combatir las dos respuestas que siempre obtengo:

1. Tarda demasiado y solo quiero que mis cambios entren en el repositorio.
2. Es bastante fácil solo mirar las diferencias.

¿Has intentado lanzar un desafío a tus compañeros desarrolladores para que obtengan algún otro beneficio al hacer comentarios? Uno podría ver esto desde cualquiera de un par de ángulos diferentes:

1. Mejorar su juego: esta puede ser la perspectiva más complicada de tomar, pero la idea aquí sería que lo hagan durante un período de tiempo y se acostumbren a la idea, de modo que el hábito es que tomaría más tiempo ir en la otra dirección. Otro punto aquí es ¿cuánto escrutinio recibirían los comentarios? Si quieres una historia corta en el comentario, podría entender su punto.
2. Subsidiar un cambio: aquí es donde tendrías algún tipo de concurso como una forma de tener la aceptación inicial para probar esto u ofrecer algún otro tipo de incentivo para que el cambio se realice por un tiempo.

Algo más a tener en cuenta es ¿qué tan bien sabe qué gestionan sus compañeros desarrolladores donde trabaja? Si intentan hacer 10 cosas ayer, podría entender que tal vez no quieran cambiar lo que ven como algo que ya funciona. ¿Estás tratando de decirles, "No, esto no funciona?" Si es así, entonces puedo ver cómo pueden ser un poco defensivos o combativos en esto. Si está tratando de decirles: "Si bien esto puede funcionar, hay una alternativa que puede ser mejor ...", entonces puede tener una oportunidad. Tener una actitud de "Más santo que tú" aquí no te va a ayudar, OMI.

Otra forma de ver esto es como una forma para que los desarrolladores involucrados hagan crecer sus carreras: deben poseer la documentación de su trabajo.

Además de otros puntos planteados en el artículo mencionado anteriormente, existe la posibilidad de poder revisar los cambios en el código para averiguar dónde / cuándo / por qué se realizó un cambio. Eso podría ser vital al rastrear un error esquivo.

Después de haberlos convencido de que es importante comentar sus confirmaciones, puede crear un script que fuerce los comentarios sobre las confirmaciones, de lo contrario fallará. Incluso puede especificar un mínimo de caracteres para asegurarse de que sea un comentario significativo. Esto les ayudará a "recordar".

Sin embargo, es importante que entiendan el Por qué, como dijo @Kevin, o de lo contrario simplemente agregarán cualquier comentario al azar.

¿Tienes revisiones de código? Una cosa que puede ayudar es instituir una regla que indique que cualquier compromiso o fusión debe ser examinado y aprobado por otro desarrollador. Luego, si usted es el revisor, tendría que pedirle al desarrollador que se compromete que le explique lo que hizo. Una vez que lo haga, debe pedirle que escriba en el comentario lo que acaba de decirle. A menudo, cuando no se puede explicar coherentemente los cambios que se hicieron, significa que esos cambios no deberían haberse realizado en primer lugar.

Sin embargo, debo decir, ¿cómo pueden las personas objetar algo tan obviamente útil como enviar comentarios? No toma mucho tiempo, y es un tiempo bien empleado. Escribir un comentario te obliga a pensar en lo que acabas de hacer. Incluso puede hacer que mire las diferencias para asegurarse de que realmente ha hecho lo que cree que ha hecho, y que no ha hecho nada estúpido.

Cuando no escribe los comentarios, está siendo descuidado e indisciplinado. Y si insiste en que no se le debe pedir que escriba los comentarios, entonces está siendo negligente deliberadamente.

Dígales que es la única forma de tener la oportunidad de mantener su desorden procesal de 50,000 métodos de línea, luego considere escribir un código mejor y más explícito en el futuro para que no tenga que lidiar con un montón de comentarios sin sentido que hinchan su base de código.

Este es un elemento de cambio de proceso: haga que un gerente asigne el código desarrollado por "x" a "Y" para las comprobaciones de garantía de calidad solo en el código, incluido el control de calidad de los comentarios.

En mi propia organización, los desarrolladores no tienen permitido realizar el control de calidad final de su propio código y registrarlo, esto debe hacerlo otro desarrollador. Parte de la verificación de control de calidad son comentarios, por lo que no hay comentarios ni registros. Realizamos una gran cantidad de trabajo por contrato donde nuestro "arte" es en realidad la propiedad intelectual contractual de otra persona, por lo que otros deben ser capaces de comprender y aprovechar nuestro código. Además, hay ocasiones en que los proyectos regresan a nosotros después de un largo paréntesis y necesitamos poder recoger el código entre 18 y 24 meses después y entender el por qué, dónde y cómo llegamos al artefacto del código que tenemos frente a nosotros. Esto proporciona una motivación egoísta para escribir comentarios de compromiso.

Solicite y haga que sus colegas desarrolladores realicen algunas fusiones y busquen el historial y comparen algunos archivos del historial.

Lo más probable es que le pidan que haga comentarios al día siguiente.

Aquí hay algunos consejos:

1. No trates de cambiar el mundo. Tú fracasarás.
2. En cambio, debe reconocer que todos trabajan de manera ligeramente diferente. No hay una talla única para todos.
3. requerir algunos pasos específicos para los procesos de trabajo de las personas es muy malo. Cambiar estos procesos lleva 10 años. Les estás pidiendo que hagan esto antes de la próxima fecha límite.
4. Incluso los cambios de proceso simples pueden llevar mucho tiempo.
5. Algunos pequeños comentarios sobre commits son demasiado insignificantes para cambiar estos procesos.
6. Puede suponer que hacen un trabajo de calidad, pero debería darles suficiente libertad para elegir los pasos ellos mismos. Es posible que algunos pasos pesados ​​no sean necesarios para desarrolladores experimentados.
7. Si está cuidando a los novatos, entonces podrían ser necesarios procesos más fuertes, pero los desarrolladores experimentados no deberían lidiar con las tonterías.
8. La imposición de restricciones draconianas sobre cómo se debe hacer el trabajo nunca va a funcionar, solo puede retrasar a las personas (podría ser bueno si son demasiado rápidas)
9. Hay muchas personas que piensan que su camino es la única forma correcta de hacer las cosas. Espero que no seas uno de ellos.

Si el control de su fuente lo proporciona, active los comentarios obligatorios para evitar cualquier comunicación no comentada. Suficientemente simple y todos pronto se darán cuenta de que 5 segundos de escribir un comentario es indoloro.

Pero los commits no comentados son uno de los aspectos negativos más pequeños que existen. He sido parte de muchos proyectos exitosos en los que no se ha comentado ni una sola confirmación. No te pongas las bragas por encima.