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

12

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

  

código objetivo: revisar el código por la mañana y 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   Fijación de formato, lógica, cambio de nombre de variables, refactorización larga.   métodos, etc., y luego confirmando los cambios en el VCS.

Esta práctica tiende a tener algunas ventajas y desventajas que he identificado:

  • Pro : la calidad / legibilidad / consistencia del código a menudo se mantiene
  • Pro : algunos errores se corrigen porque 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 cuida el objetivo.
  • Con : Ocasionalmente introduce errores que causan furia por parte de los desarrolladores que pensaron que escribieron un código sin errores el día anterior.
  • Con : otros desarrolladores se agravan con un exceso de nitpicking y comienzan a disgustar la contribución al código de la licitación de objetivos.

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

En mi defensa, pienso Estoy haciendo esto por una buena razón (para mantener nuestra base de código extremadamente grande en una máquina bien aceitada), pero estoy muy preocupado de que también esté creando un negativo atmósfera. También estoy definitivamente preocupado de que mi gerente deba abordar el problema.

Entonces, si fueras el gerente, ¿cómo abordarías este problema?

ACTUALIZACIÓN: no quiero que esto esté demasiado localizado, pero algunos lo han preguntado, así que quizás algún fondo sea esclarecedor. 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 aún están aprendiendo el idioma (C #). En general, tengo que responder por la estabilidad general del producto, y estoy particularmente nervioso cuando los cambios se realizan sorprendentemente en las partes arquitectónicas centrales de la base del código. Este hábito surgió porque al principio yo era optimista acerca de las contribuciones de otros desarrolladores, pero cometieron demasiados errores que causaron serios problemas que no se descubrirían hasta semanas más tarde, donde el dedo me apuntaría por escribir un código inestable. A menudo, estas "sorpresas" son cometidas por un gerente entusiasta o un compañero de trabajo que todavía está en la fase de aprendizaje. Y, probablemente, esto llevará a la respuesta: no tenemos ninguna política de revisión de código, en absoluto.

    
pregunta Kevin McCormick 16.03.2012 - 16:01

4 respuestas

52

Parece que lo que estás haciendo es básicamente equivalente a una revisión de código, excepto que en lugar de proporcionar comentarios al desarrollador, estás realizando todos los cambios que sugerirías en una revisión de código. Es casi seguro que sería mejor hacer una revisión real del código donde usted (u otra persona) proporciona comentarios al desarrollador original sobre los problemas de calidad del código y los errores obvios y le pide al desarrollador original que los solucione. Esto mantiene la calidad del código alta, pero también ayuda al desarrollador a familiarizarse con el código original y sus inconvenientes, y ayuda a mejorar los cambios de código futuros. Además, no tiene el inconveniente de causar "furia al tirar de los pelos" cuando un error se introduce silenciosamente o hace que otros desarrolladores piensen que se está hablando de ellos detrás de sus espaldas.

    
respondido por el Justin Cave 16.03.2012 - 16:08
14

Para ser franco, IMHO, esta es una idea terrible.

Espero que la moral caiga en el canal, si no lo ha hecho ya.

Para ser justo con usted, usted reconoce esto.

Las revisiones de código de pares están bien, asigna la responsabilidad a los desarrolladores en un nivel, en lugar de ser un escenario de "ellos contra nosotros". (donde están los gerentes / clientes potenciales).

Puede que haya algunos desarrolladores a los que debas vigilar más que a otros, pero el hecho de que todos los códigos pasen a través de ti es ridículo.

Y a pesar de lo bueno que pienses que eres, habrá momentos en los que te equivocas, o "no te preocupes" y esto solo empeorará las cosas.

    
respondido por el ozz 16.03.2012 - 16:17
5

Si yo fuera el administrador, para solucionar este problema:

  • Revise los estándares de código y las prácticas con el equipo, entrégueles una copia de las normas de codificación
  • Código de revisión por pares de manera regular para reforzar los estándares y prácticas que deben seguirse
  • Forzar el nitpicking / formateo con una herramienta de automatización para que los desarrolladores estén obligado a seguir las normas
  • Deshazte de todos los malos compañeros de equipo que se nieguen a seguir las normas
  • Deja de ser el portero

Sus intenciones son buenas, pero la implementación es terrible y, como otros lo han señalado, causará una mala moral y un ataque violento entre los miembros del equipo.

Para empezar, si el proyecto nunca tuvo ningún estándar, intente simplificar el nuevo estándar en etapas en lugar de simplemente oprimir un interruptor.

    
respondido por el Jon Raynor 16.03.2012 - 16:28
3

Bad juju.

No soy un gerente de desarrollo, pero si lo fuera, no querría que ninguno de mis desarrolladores toque un código que no sea parte de un defecto o una función asignada a ellos. Período. Si ve un problema con el código de otra persona, no dude en llamar la atención de los desarrolladores responsables, pero no simplemente sumérjase y corríjalo usted mismo, especialmente si no lo ha hecho. t 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 los que se han asignado esas tareas.

La iniciativa es buena en general, pero a veces te puede morder el culo. Si introduces algún error en el código de trabajo , es posible que desees rápidamente que hayas elegido una carrera diferente.

    
respondido por el John Bode 16.03.2012 - 17:13

Lea otras preguntas en las etiquetas