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 .