¿Cómo debe ser manejado por un Gerente de Desarrollo el código "Tending Goal"?

Primero permítame acuñar un término:

Código objetivo: revisar el código en la mañana, luego revisar en silencio todos los cambios realizados por los otros desarrolladores el día anterior archivo por archivo (especialmente los archivos de código que desarrolló originalmente), y corregir el formato, la lógica, cambiar el nombre de las variables, refactorizar métodos largos, etc., y luego confirmar los cambios en el VCS.

Esta práctica tiende a tener algunos pros y contras que he identificado:

• Pro : la calidad / legibilidad / coherencia del código a menudo se mantiene
• Pro : algunos errores se corrigen debido a que el otro desarrollador no está demasiado familiarizado con el código original.
• Con : A menudo es una pérdida de tiempo para el desarrollador que tiende a la meta.
• Con : Ocasionalmente introduce errores que causan furia por parte de los desarrolladores que pensaron que escribieron código libre de errores el día anterior.
• Contras : Otros desarrolladores se ven agravados con una excesiva selección y comienzan a no gustarles contribuir al código de la licitación de objetivos.

Descargo de responsabilidad: para ser justos, en realidad no soy un gerente de desarrollo, soy el desarrollador que realmente está haciendo el "cuidado de objetivos".

En mi defensa, creo que estoy haciendo esto por una buena razón (para mantener nuestra base de código extremadamente grande como una máquina bien engrasada), pero me preocupa mucho que también esté creando una atmósfera negativa. También estoy definitivamente preocupado de que mi gerente deba abordar el problema.

So, if you were the manager, how would you address this problem?

ACTUALIZACIÓN: No me refiero a que esto esté demasiado localizado, pero algunos lo han preguntado, por lo que tal vez algunos antecedentes sean esclarecedores. Me asignaron un proyecto gigante (200K LoC) hace tres años, y solo recientemente (hace 1 año) se agregaron desarrolladores adicionales al proyecto, algunos de los cuales no están familiarizados con la arquitectura, otros que todavía están aprendiendo el idioma (C #). Generalmente tengo que responder por la estabilidad general del producto, y estoy particularmente nervioso cuando sorprendentemente se realizan cambios en las partes arquitectónicas centrales de la base del código. Este hábito surgió porque al principio era optimista sobre las contribuciones de otros desarrolladores, pero cometieron demasiados errores que causaron serios problemas que no se descubrirían hasta semanas después, donde me señalarían con el dedo por escribir código inestable. A menudo estos "

Parece que lo que está haciendo es básicamente equivalente a una revisión de código, excepto que en lugar de proporcionar comentarios al desarrollador, está haciendo todos los cambios que sugeriría en una revisión de código. Seguramente sería mejor hacer una revisión de código real en la que usted (u otra persona) proporcione comentarios al desarrollador original sobre problemas de calidad del código y errores obvios y solicite al desarrollador original que los solucione. Eso mantiene la calidad del código, pero también ayuda al desarrollador a familiarizarse con el código original y sus dificultades, y ayuda a mejorar los cambios futuros del código. Además, no tiene el inconveniente de causar una "rabia desgarradora" cuando un error se introduce silenciosamente o hace que otros desarrolladores piensen que se les está hablando a sus espaldas.

Para ser sincero, en mi humilde opinión, esta es una idea terrible.

Esperaría que la moral caiga en la cuneta, si aún no lo ha hecho.

Para ser justo con usted, usted reconoce esto.

Las revisiones de código de pares están bien, pone la responsabilidad de los desarrolladores en un solo nivel, en lugar de ser un escenario de "ellos contra nosotros". (donde están la gestión / leads).

Puede haber algunos desarrolladores a los que necesite vigilar más que otros, pero es obligatorio forzar todo el código a pasar por usted primero.

Y a pesar de lo bueno que crees que eres, habrá momentos en los que te equivocarás o "picarás" y esto empeorará aún más las cosas.

Si yo fuera el gerente, para abordar este problema:

• Revise los estándares y las prácticas del código con el equipo, entrégueles una copia de los estándares de codificación
• Código de revisión por pares de manera regular para reforzar los estándares y prácticas que se deben seguir
• Aplique nitpicking / formateo con una herramienta de automatización para que los desarrolladores se vean obligados a seguir los estándares
• Deshágase de los malos compañeros de equipo que se niegan a seguir los estándares.
• Deja de ser el portero

Sus intenciones son buenas, pero la implementación es terrible y, como lo han señalado otros, provocará una moral baja y disparos entre los miembros del equipo.

Si el proyecto nunca tuvo un estándar para comenzar, intente facilitar el nuevo estándar por etapas en lugar de simplemente presionar un interruptor.

Bad juju.

No soy un gerente de desarrollo, pero si lo fuera, no quisiera que ninguno de mis desarrolladores toque código que no sea parte de un defecto o característica que se les haya asignado. Período. Si ve un problema con el código de otra persona, comuníquelo a los desarrolladores responsables, pero no se limite a solucionarlo usted mismo, especialmente si no se ha coordinado con el otro desarrollador ( s) primero.

Las tareas de limpieza solo deben ejecutarse después de una revisión formal del código por parte del equipo, y solo por los desarrolladores a quienes se han asignado esas tareas.

La iniciativa es buena en general, pero a veces puede morderte el culo. Si se introduce algún error en lo que fue el código de trabajo, que rápidamente puede ser que deseen que había elegido un camino diferente.