Sé que hay cosas como hacer una comprobación manual para asegurarse de que los códigos confirmados sean fundamentalmente correctos. Pero al lado de eso? La razón por la que pregunto es porque un gran proyecto hay tantos compromisos todos los días.¿Hay alguna razón por la que todos quieran ser notificados cada vez que alguien cometa algunos códigos?
Lo encuentro principalmente útil para el seguimiento. En general, esas notificaciones automáticas se filtran en un cubo en mi correo, junto con el correo electrónico tipo "smoketest passed, smoketest failed" ... luego, cuando hay un error, puede rastrearlo al conjunto de registros de forma bastante sencilla.
Tenga en cuenta que también se puede intuir la madurez de un proyecto por la forma de la curva de comprobaciones: número de líneas de código cambiadas por día en función del tamaño total de la base de código. De hecho, da una idea razonable de cuándo va a ser "hecho" ...
Espero que esto ayude!
Claro, usted quiere ver el código que se pone para tener una idea de lo que otras personas en su equipo están haciendo, y no está atrapado en una cueva solo escribiendo su código.
Incluso si no está supervisando el código de la calidad, puede tener una idea de lo que otras personas están trabajando.
Ayuda a construir el equipo.
Normalmente tenemos las actualizaciones para que todos sepan que algo se ha actualizado y debe ser revisado por un colega. Si no tiene que asignar un usuario, puede obtenerlo y tratarlo cuando tenga tiempo.
Vi a alguien que publicó un sistema que envía mensajes de estilo de Twitter a Yammer cuando se comprometen a realizar un "cambio rápido" en el registro de comentarios de estilo de código. Ordenado. Ahora no puedo encontrar el enlace.
En general, las notificaciones de compromiso son útiles para que tenga una idea de lo que sucede en el código diariamente. Por ejemplo, sé cuándo se ha implementado una nueva función o si se ha corregido una corrección de errores. Si hay tantos compromisos que se pierde en el ruido, entonces podría valer la pena filtrar o reducir el número de mensajes de confirmación que vea (quizás puede limitarlo solo a módulos específicos en los que trabaja, por ejemplo).
Dicho esto, aparte de darle otros desarrolladores la oportunidad de revisar al menos superficialmente código, también puede notificar a las personas que:
Ya entendió la idea. Básicamente, está destinado a ayudar a fomentar la transparencia en todo el grupo, no solo para poner más atención en un compromiso sino para mejorar el ciclo de desarrollo del equipo en general.
Puede ser útil si alguien realiza un cambio en uno o más programas en los que usted mismo puede estar trabajando. Es un aviso, si lo desea, que puede necesitar resolver algunos conflictos que pueden requerir una mayor comunicación.
He visto la situación en la que el programador A cometió algunos cambios y luego se fue de vacaciones un par de días después.El Programador B también estaba trabajando en los mismos programas y hubo algunos conflictos en el momento en que el Programador B fue a comprometer sus cambios. Normalmente esto no es gran cosa, y la comunicación siempre debe mantenerse abierta entre los miembros del equipo. En este caso, el Programador B tenía algunas preguntas sobre los cambios realizados por el Programador A, pero tuvo que esperar una semana hasta que el programador regresara. Un correo electrónico directo, incluso uno generado automáticamente, habría sido útil en esta situación.
Sólo mis dos centavos.
Muchas de las cosas mencionadas anteriormente son útiles al recibir notificaciones de registros. Me suelen utilizar durante un par de cosas:
Incluso si hay muchas notificaciones, no creo que tengan que leerse en su totalidad. Los muestro un montón, pero eso es suficiente para volver a los compromisos apropiados cuando necesito más información.
En muchas compañías, las revisiones de código son obligatorias, pero se realizan en el sistema de honor. Las notificaciones de compromiso enviadas por correo electrónico implementan un mecanismo de "confianza, pero verificación" para estos entornos.
Lo uso principalmente para medir el latido del corazón del proyecto. Cada mensaje de compromiso es un pulso. Con el tiempo, obtendrá una idea de cómo suena un pulso "normal".
En un día normal, recibimos de 4 a 6 mensajes de confirmación. Eso se ralentiza a 1 o 2 a medida que llega la fecha de iteración y se detiene aproximadamente un par de días antes de la publicación de la iteración. Un día o dos después de la iteración, comienza a recuperarse nuevamente y, si se encuentran errores, podemos obtener 1 mensaje de confirmación por hora a medida que se resuelven los errores. Un día normal con pocas confirmaciones puede significar que un desarrollador tenga problemas con algunas funcionalidades o que pase demasiado tiempo en Stackoverflow.
También encuentro mensajes de confirmación informativos muy útiles. Algunas veces, un gerente o examinador ni siquiera tiene que preguntarle a los desarrolladores el estado de una característica o un error, solo mire los mensajes de confirmación para ver si se realiza algún trabajo al respecto.
Según tengo entendido, la razón principal de CCing para informar a los desarrolladores es evitar conflictos: ve un compromiso en un archivo con el que está trabajando para saber que tiene problemas incluso antes de comprometerse. Sin embargo, esto es bastante molesto, por lo que existen herramientas (por ejemplo, Palantir, el antiguo IBM Jazz) que realmente le mostrarán qué archivos se están editando al mismo tiempo.
Los filtro en una carpeta de Outlook, luego hago una búsqueda para el nombre de clase cuando noto que algo roto ha sido registrado así sé a quién enviar correos electrónicos. –