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

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.

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.

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 .

¿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.

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.

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.

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.

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).