¿Cómo me responsabilizo de mi código cuando un colega realiza mejoras innecesarias sin previo aviso?

71

Uno de mis compañeros de equipo es un experto en todos los oficios en nuestra tienda de TI y respeto su visión.

Sin embargo, a veces revisa mi código (es el segundo al mando del líder de nuestro equipo, por lo que se espera) sin avisar. Entonces, a veces revisa mis cambios antes de que completen el objetivo final y los hace de inmediato ... e incluso ha roto mi trabajo una vez.

Otras veces, ha realizado mejoras innecesarias en algunos de mis códigos que tienen más de 3 meses.

Esto me molesta por algunas razones:

  1. No siempre tengo la oportunidad de corregir mis errores
  2. No se ha tomado el tiempo de preguntarme qué estaba tratando de lograr cuando está confundido, lo que podría afectar sus pruebas o cambios.
  3. No siempre creo que su código sea legible
  4. Los plazos no son un problema y su carga de trabajo actual no requiere ningún trabajo en mis proyectos que no sea revisar mis cambios de código.

De todos modos, le he dicho en el pasado que me mantenga informado si ve algo en mi trabajo que quiere cambiar para que yo pueda tomar posesión de mi código (tal vez debería haber dicho "deficiencias") y él no ha respondido .

Temo que pueda parecer agresivo cuando le pido que me explique sus cambios.

Es solo una persona tranquila que se guarda para sí mismo, pero sus acciones continúan. No quiero prohibirle que haga cambios en el código (no como podría hacerlo), porque somos un equipo, pero quiero hacer mi parte para ayudar a nuestro equipo.

Aclaraciones añadidas:

  • Compartimos 1 rama de desarrollo. No espero hasta que todos mis cambios completen una sola tarea porque me arriesgo a perder un trabajo significativo, así que me aseguro de que mis cambios se desarrollen y no rompan nada.
  • Mi preocupación es que mi compañero de equipo no explica la razón o el propósito de sus cambios. No creo que deba necesitar mi bendición, pero si no estamos de acuerdo con un enfoque, pensé que sería mejor discutir los pros y los contras y tomar una decisión una vez que ambos entendemos lo que está sucediendo.
  • Todavía no he discutido esto con el líder de nuestro equipo, ya que preferiría resolver los desacuerdos personales sin involucrar a la gerencia a menos que sea necesario. Como mi preocupación parecía más una cuestión personal que una amenaza para nuestro trabajo, decidí no molestar al líder del equipo. Estoy trabajando en ideas para el proceso de revisión de código, para ayudar a promover los beneficios de revisiones de código más organizadas sin tener que ver con las molestias de mi mascota.
Jesslyn
fuente
20
¿Utiliza git, CVS o TFS para su repositorio de código? Simplemente revierta sus compromisos. Eventualmente lo recibirá :)
66
En mi organización, se supone que todos los cambios en el código pasan por una revisión de algún tipo, y se considera una forma deficiente para registrar un cambio sin tener en cuenta en la descripción de la lista de cambios quién fue el revisor. Introducir ese principio en su organización podría ser una solución a largo plazo para el problema de los compañeros de trabajo que registran los cambios en el código que escribió sin revisión.
Carolyn
13
¿Por qué tiene cambios sin finalizar en una rama compartida? Esa es una mala idea, y no solo por la razón por la que te has encontrado.
hyde
15
Por supuesto, esto depende de qué VCS use, pero eso podría ser algo a tener en cuenta, comenzando a usar más ramas. Con la rama personal, es IMO excelente cuando puede comprometerse (y presionar con DVCS) siempre que lo desee sin preocuparse, y fusionarse solo cuando se hace con una parte, o fusionarse solo parcialmente cuando sea necesario (un buen DVCS lo hace bastante fácil). También funciona muy bien con la revisión de código, pudiendo hacerlo de forma natural y solucionar problemas antes de fusionar.
hyde
44
@Jesslyn: ¿Le preocupa a su equipo que su compañero de equipo pase tiempo haciendo mejoras innecesarias al código antiguo? Por lo menos, parece ineficiente que su compañero de equipo pase tiempo haciendo cambios innecesarios en lugar de trabajar en tareas de mayor prioridad. Además, si su compañero de equipo prefiere pasar tiempo "arreglando" su código en lugar de autorizarlo a hacerlo usted mismo, eso también parece bastante ineficiente. ¿Ha discutido alguna de estas preocupaciones con el líder de su equipo?
Acantilado

Respuestas:

81

Creo que la mayoría de los desarrolladores se encuentran en esta posición en algún momento, y espero que cada desarrollador que se sienta víctima se dé cuenta de lo frustrante que será cuando se convierta en el senior y se sienta obligado a limpiar el código escrito por juniors.

Para mí, evitar conflictos en esta situación se reduce a dos cosas:

  1. Cortesía . Hablar con alguien sobre su código le permite a un desarrollador saber que estás interesado y puedes discutirlo como profesionales adultos.

  2. Olvídate de la "propiedad del código": el equipo posee el código . Es bueno que otras personas quieran hacer los cambios. Si un desarrollador senior realiza cambios que son "ilegibles" o peores, entonces retírelos. No necesita ser agresivo, solo deje que un editor sepa que sus cambios no funcionaron, y está más que feliz de discutir su reversión.

Recuerde, la propiedad del código por parte del equipo es excelente y corta en ambos sentidos. Si ve algo que no tiene sentido en el código de otra persona, corríjalo. Ser excesivamente posesivo e inadecuadamente comunicativo es una forma segura de crear un ambiente de desarrollo venenoso.

Miguel
fuente
44
Creo que eso se reduce al punto 1: hablen con él. Contando el hecho de que los cambios de código contra el desarrollador original es una gestión terrible (no digo que no suceda) y argumentaría que necesita solicitar mejores métricas. Cruza ese puente si y cuando sucede.
Michael
2
Creo que eso es en lo que todos debemos enfocarnos: en general, tus compañeros de equipo no están para hacerte quedar mal, no pierdas el tiempo analizando, solo sé mejor y un miembro más valioso del equipo (sé que es más fácil decirlo que hecho!)
Michael
77
@Jesslyn, si te lo está haciendo a ti, lo más probable es que se lo esté haciendo a todos. Dudo que alguien cuente eso en tu contra. (Si no se lo está haciendo a todos, es posible que tenga un problema diferente)
user606723
3
@tgkprog: (1) Por supuesto, obtener comentarios de los demás es muy importante y he aprendido algunas cosas al mirar el código de los demás, pero (2) si quieren aprender unos de otros, deberían sugerir un cambio y discutirlo juntos . Simplemente cambia cosas al azar porque crees que el código es mejor después de que el cambio no es el enfoque correcto. Hay mejores enfoques, como las revisiones de código que utilizan herramientas de revisión.
Giorgio
2
Sí, estaba pensando en momentos en que había arreglado el código de otros antes de una fecha
límite a las
86

Usted y la mayoría de los encuestados abordan esto como un problema de comunicación entre dos colegas, pero realmente no creo que lo sea. Lo que describe suena más como un proceso de revisión de código horriblemente roto que cualquier otra cosa.

Primero, mencionas que tu colega es el segundo al mando y se espera que revise tu código. Eso está mal. Por definición, las revisiones de código de pares no son jerárquicas, y ciertamente no se trata solo de encontrar defectos. También pueden proporcionar experiencias de aprendizaje (para todos los involucrados), una oportunidad para la interacción social y probar una herramienta valiosa para construir la propiedad del código colectivo. También debe revisar su código de vez en cuando, aprender de él y corregirlo cuando se equivoca (nadie lo hace bien cada vez).

Además, mencionas que tu colega hace cambios de inmediato. Eso también está mal, pero por supuesto ya lo sabes; no habrías hecho esta pregunta si su enfoque entusiasta no fuera un problema. Sin embargo, creo que está buscando una solución en el lugar equivocado. Para ser sincero, su colega me recuerda un poco a mí, y lo que funcionó para mí en situaciones similares fue un proceso de revisión sólido y bien definido y un conjunto de herramientas increíbles. Realmente no desea evitar que su colega revise su código y pedirle que se detenga y hable con usted antes de que cada pequeño cambio realmente no funcione. Podría, por un tiempo, pero pronto llegará a un punto en el que se volverá demasiado molesto y volverás a donde empezaste, o peor: simplemente dejará de revisar tu código.

Una clave para una resolución aquí podría ser una herramienta de revisión de código de pares. Por lo general, evito las recomendaciones de productos, pero para las revisiones de código, el Crucible de Atlassianes realmente un salvavidas Lo que hace puede parecer muy simple, y lo es, pero eso no significa que no sea asombrosamente increíble. Se conecta a su repositorio y le brinda la oportunidad de revisar conjuntos de cambios individuales, archivos o grupos de archivos. No puedes cambiar ningún código, sino que comentas todo lo que no parece correcto. Y si absolutamente debe cambiar el código de otra persona, simplemente puede dejar un comentario con el conjunto de cambios explicando sus cambios. Vale la pena ver el video introductorio en la página de productos de Crucible si desea obtener más detalles. El precio de Crucible no es para todos, pero hay numerosas herramientas de revisión por pares disponibles gratuitamente. Una con la que he trabajado y disfruto es Review Board y estoy seguro de que encontrarás muchas otras con una simple búsqueda en Google.

Cualquiera sea la herramienta que elija, cambiará completamente su proceso. No es necesario detenerse, levantarse de la silla, interrumpir a la otra persona y discutir los cambios; todo lo que necesita hacer es tomarse un tiempo libre cada semana y revisar los comentarios (una vez por semana es solo una sugerencia. Usted conoce su horario y su rutina diaria mejor que yo). Más importante aún, las revisiones principales se almacenan en una base de datos en algún lugar y puede recuperarlas en cualquier momento. No son discusiones efímeras en torno al enfriador de agua. Mi caso de uso favorito para revisiones antiguas es cuando presento a un nuevo miembro del equipo a nuestra base de código. Siempre es agradable cuando puedo guiar a alguien nuevo a través de la base de código señalando exactamente dónde estábamos atrapados, dónde teníamos opiniones diferentes, etc.

Continuando, mencionas que no siempre encuentras el código de este colega legible. Eso me permite saber que no tienes un conjunto común de estándares de codificación, y eso es algo malo. Una vez más, puede abordar esto como un problema de las personas o puede abordarlo como un problema de proceso, y nuevamente sugeriría encarecidamente este último. Reúna a su equipo y adopte un estilo de codificación común y un conjunto de estándares lo antes posible. Realmente no importa si elige un conjunto de estándares que es común en su ecosistema de desarrollo o si crea uno propio. Lo que realmente importa es que sus estándares sean consistentes y que los cumpla. Muchas herramientas pueden ayudarlo, pero esa es una discusión completamente diferente. Solo para empezar, Una cosa muy simple es hacer que un enlace previo a la confirmación ejecute algún tipo de formateador de estilo en su código. Puede continuar escribiendo su código como desee y dejar que la herramienta lo "arregle" automáticamente antes de que alguien más lo vea.

Por último, menciona en un comentario que la gerencia no cree que las ramas de desarrollo individuales sean necesarias. Bueno, hay una razón por la que los llamamos "sucursales de desarrollo" y no "sucursales de administración". Me detendré aquí ya que no hay razón para que salga la queja que se está formando en mi cabeza.

Dicho todo esto, sepa que no dudo que su colega tenga (un poco) la culpa aquí. Ese no es mi punto, mi punto es que todo su proceso de desarrollo también tiene la culpa, y eso es algo que es más fácil de solucionar. Ármate con las herramientas adecuadas, explora los numerosos procesos formales e informales y elige aquellos que se adapten a tu equipo. Pronto llegará a un punto en el que se dará cuenta de que la mayoría de sus "problemas de personas" ya no existen. Y, por favor, no escuche a nadie (incluido usted) que presente la excusa "somos un equipo pequeño, no necesitamos todo eso". Un equipo de desarrolladores competentes puede configurar las herramientas necesarias en menos de una semana, automatizar todo lo que se puede automatizar y nunca volver a mirar atrás.

PD. "Código de propiedad" es un término nebuloso, constantemente debatido, y significa cosas diferentes para diferentes personas. Puede encontrar una colección brillante de la mayoría de las opiniones diferentes (y a veces antitéticas) sobre C2 .

Yannis
fuente
77
+1 y más si pudiera. Gran respuesta que aborda las mejores formas de mejorar dicho proceso.
Waldfee
2
Sí, el OP necesita una herramienta de revisión de código, de esa manera pueden revisar el código juntos, no es solo alguien que cambia el código porque lo desean. Recién comenzamos a usar smartbear.com/products/software-development/code-review en el trabajo
Juan Mendes
19

¿De qué se trata el proceso que te hace querer asumir la responsabilidad de "tu código"? ¿Tiene la responsabilidad exclusiva de mantener ciertas funciones en funcionamiento? ¿El líder dijo "Michael, quiero que te hagas responsable de ..."? ¿O está implícita su responsabilidad, en que el líder y el resto del equipo lo miran cada vez que se rompen ciertas características?

De cualquier manera, si tiene la responsabilidad, entonces necesita autoridad sobre el código. La próxima vez que el otro compañero haga cambios unilaterales y el líder vuelva a usted para arreglarlos, debe sentarse con el líder y pedir que su autoridad y responsabilidad estén alineadas.

Kevin Cline
fuente
55
+1 Para señalar un hecho importante: O bien es propiedad del equipo y (1) todos son responsables (2) todos pueden cambiar el código, o hay propiedad individual y (1) el propietario del módulo es responsable (2) cada cambio debe Ser aprobado por el propietario del módulo. A menudo, la confusión surge cuando se espera que un miembro del equipo sea responsable de un módulo, pero un miembro senior se siente con derecho a realizar cambios aleatorios en el código. En otras palabras, uno debe evitar la situación de "responsabilidad sin autoridad".
Giorgio
4

No es que esto resuelva toda la situación, pero puede intentar agregar más comentarios a su código fuente.

  1. Si el código no está completo, podría marcarse como tal.
  2. Si el propósito de un bloque de código no es autodocumentarse, entonces debe documentarlo.

En general, intenta hacer limonada en lugar de perder el tiempo chupando limones. Como dijo Michael, en general, los compañeros de equipo no están para hacerte quedar mal. Intente aprender de sus errores y aplíquelos a futuras revisiones.

Si cree que sus cambios están teniendo un impacto negativo, exprese esto (diplomáticamente). Si fuera yo, simplemente preguntaría por qué se hicieron cambios específicos y veré si puedes defender tus cambios originales. Sus compañeros de trabajo superiores también son humanos. Es muy posible que se haya perdido algo y / o no esté al tanto de cualquier impacto negativo que esté proporcionando.

usuario606723
fuente
3
Chico que podría ser confuso. Imagínese: agregue un comentario que indique: "Este código no está completo" y luego olvide eliminarlo una vez que complete el código.
Riwalk
1
@ Stargazer712, ¿Más confuso que tener un código incompleto en la sucursal?
user606723
Para eso están los estantes. No verifique el código incompleto.
Riwalk
2
No. Si registras un código incompleto que necesita un comentario para etiquetarlo como tal, entonces ya estás en el infierno. Los comentarios simplemente te llevan a un rincón diferente del infierno.
riwalk
1
Se llaman TODOS, se dejan en el código de trabajo todo el tiempo
Juan Mendes
4

Todo el mundo 'posee su propio código' implícitamente, independientemente de la política, la legalización o la economía (es la 'naturaleza de las cosas'), naturalmente siente una conexión personal con su propio trabajo.

Si su compañero de trabajo está participando en el comportamiento que usted describió y no responde cuando solicita un aviso , ese compañero de trabajo es descortés, por decir lo menos, y puede estar tratando de socavarlo (por decir lo peor ... .) - NO suena como un jugador de equipo.

Un buen compañero de trabajo podría tocar la base con usted y señalar el problema con su código a usted - y le permiten fijar / cambie, o responder de manera apropiada. Estoy muy agradecido de que, incluso cuando era un novato, mis mentores siempre me señalaron lo que estaba haciendo mal, me explicaron por qué y me dejaron (o me hicieron ) arreglarlo. Eso me hizo un mejor programador y todos se beneficiaron. Y eso es lo que siempre he hecho al revisar el trabajo realizado por otros. Luego, usted (o quien sea) realmente aprende algo de su 'jota de todos los oficios', y el código y el equipo mejoran, incluido su maestro: la enseñanza ayuda a comprender.

Si es posible, discutiría el asunto en privado con el líder del equipo. Según su descripción de la situación, un buen líder de equipo se pondrá de su lado, uno malo no lo hará ... Obviamente, esto requiere precaución, tendrá que juzgarlo usted mismo.

Vector
fuente
1
Además de la declaración inicial (hay equipos que adoptan la propiedad del equipo y otros equipos que adoptan la propiedad individual), encuentro las observaciones en esta respuesta OK (+1 para esto): también he observado que la propiedad del código compartido se usa para socavar un equipo posición del miembro dentro del equipo modificando arbitrariamente su código. Entonces no entiendo los votos negativos. Sería bueno si los votantes negativos quisieran explicarlo.
Giorgio
1
Creo que la respuesta de Mikey es una buena explicación de cómo sigo siendo un jugador de equipo. Tal vez esto es demasiado centrado en las personas? Como Yannis sugirió, el proceso de desarrollo de mi equipo parece ser el verdadero problema. Independientemente, tengo curiosidad de por qué esto fue rechazado.
Jesslyn
1
@Jesslyn - Supongo que fui rechazado debido a mi declaración "Todos implícitamente 'poseen su propio código'". Esta es una pregunta filosófica, no una pregunta de política. :-)
Vector
1
@Mikey: "Todos, implícitamente, 'poseen su propio código'" Esto puede ser un tema de debate, por supuesto. Los programadores que no trabajan por cuenta propia normalmente firman un contrato que dice que no poseen el código fuente. Aparte de esto, creo que el autor del código es el que entiende mejor el código, y si alguien más cambia el código, entonces ni el autor ni el segundo desarrollador realmente entienden el código al 100%.
Giorgio
1
@Mikey: la propiedad del código compartido intenta garantizar que suficientes miembros del equipo entiendan el código lo suficientemente bien (mientras que nadie realmente lo entiende realmente bien). Esto es preferible a la propiedad de código individual, donde cada módulo (al menos en principio) es entendido completamente por un programador, pero existe el riesgo de que este conocimiento se pierda si ese programador se cierra.
Giorgio
1

Si escribes código, entonces debería revisarlo.

Si cambio su código durante la revisión, entonces el código ya no es el código que revisé, sino el código que cambié. Por lo tanto, debe ser revisado. Probablemente por ti.

Si confirmo su nuevo código con mis cambios sin que alguien los revise, entonces he cometido (1) un cambio no revisado y (2) el peor pecado posible si las revisiones de código se toman en serio.

gnasher729
fuente
0

Creo que lo estás manejando de la manera correcta por ahora, pero pronto habrá un punto de inflexión en el que te distraerá en la medida en que no estés contento de codificar de esta manera.

Si yo fuera usted, solicitaría un rápido uno a uno con esta persona y explicaría mi punto de vista con calma pero con firmeza. La propiedad del código del equipo, etc., está bien, pero a menos que le dé a cada desarrollador suficiente espacio para poner su trabajo, cometer errores y mejorar, nunca construirá un buen código. Esto puede ser un área de fricción más temprano que tarde.

(Hay una respuesta totalmente diferente si esto fuera en el lugar de trabajo. Intercambio de pila. Encontrar la forma correcta de hacer revisiones de código es la parte fácil. Convencer a su compañero de trabajo para que cumpla con esto es mucho más difícil).

Sandeep
fuente