¿Quién debe hacer revisiones de código?

En mi empresa, principalmente, el arquitecto hace revisiones de código. Es un tipo de software muy experimentado e inteligente, por lo que es muy bueno en eso. Cuando los desarrolladores hacen las revisiones de código, no lo hacen a la mitad. Intentamos darles a los desarrolladores que hicieran más revisiones de código, pero la calidad de las revisiones de código no era buena. Utilizamos Scrum como metodología de desarrollo.

Sin embargo, con el sistema actual hay dos problemas:

1. El arquitecto se convierte en un cuello de botella.

2. Los desarrolladores no se responsabilizan por la calidad del código y la arquitectura (lo que lleva a todo tipo de problemas).

¿Cómo podemos abordar estos problemas? ¿Deberíamos cambiar quién revisa el código?

Los desarrolladores deben hacer revisiones de código. Deben hacer revisiones de código, porque deben conocer el código, los estándares y prácticas de estilo de la compañía. Al hacer que alguien más haga revisiones de código, le está diciendo a sus desarrolladores que no es su responsabilidad asegurarse de que el código cumpla con los estándares de la compañía.

Si cree que necesitan capacitación para hacer revisiones de código, consígalo para ellos. Dada su situación actual, puede pedirle a un desarrollador que revise el código y luego que su arquitecto lo comente: haga que el desarrollador envíe la revisión al arquitecto para su aprobación antes de enviarla al remitente.

En esta situación, lo que necesita es el conocimiento de este desarrollador experimentado para ayudar al resto del equipo a crecer. La calidad de un equipo no está definida por las habilidades del mejor desarrollador; se define por las habilidades de lo peor. Puedes probar cosas como:

• Revisiones colaborativas. Esto funcionó muy bien en mi último equipo. Pusimos a todo el equipo en una habitación con un proyector y comenzamos a revisar algunos artículos. Quizás al principio el arquitecto es el que guía la revisión, pero en unas pocas semanas (reservamos una o dos horas todos los viernes) todo el equipo comienza a hablar y comprender los conceptos clave que actualmente solo el arquitecto parece saber.

• Programación en pareja. Para mí, esta es la mejor herramienta para difundir el conocimiento en un equipo.

Si bien puedo ver el punto de hacer que el arquitecto del sistema / software firme todos los cambios / confirmaciones, los desarrolladores de software deberían poder hacer revisiones sin involucrar al arquitecto, excepto el arbitraje.

Mis procedimientos de revisión preferidos [*] son:

• Agrupe los cambios por requisito / problema.
• Invite a todos los desarrolladores, al arquitecto de software y al autor del requisito / problema a revisar. (No todos están obligados a hacer una revisión).
• Considere una revisión terminada cuando:
  • Dos desarrolladores han revisado.
  • Todos los comentarios son respondidos. (Posiblemente haciendo que el arquitecto de software tome una decisión).
  • Ha pasado un día hábil sin más discusión (o todas las partes invitadas han revisado).

Entonces, mi respuesta corta a su pregunta es: Los desarrolladores deberían hacer revisiones de cambios.

[*] Desafortunadamente, no siempre es así como operan los proyectos en los que participo.

Me gusta la práctica de revisiones ocasionales de códigos de equipo que incluyen a todo el equipo, los arquitectos, pero luego montones y montones de revisiones de código entre dos o tres miembros del equipo.

Si es un código realmente complicado o delicado, entonces aliste al arquitecto o a los miembros principales del equipo.

Honestamente, sin embargo, suena un poco ridículo que un arquitecto haga revisiones de código. Debería estar haciendo revisiones de diseño o revisiones de código ocasionales de manera informal para compartir su experiencia. El equipo de ingeniería debe asumir la responsabilidad del código. Si hay problemas, mejorarán con el tiempo.

Estoy de acuerdo, si solo una persona hace comentarios, el resto de los chicos probablemente simplemente irán con "No sé, parece funcionar, pero deja que ese tipo inteligente lo descubra si está bien o no". Puedo pensar en lo siguiente:

• haga público su código para que todos puedan ver en qué están trabajando todos; poner nombres al comienzo de cada archivo que contiene código; tal vez imprimirlos y sellarlos en el, uhh, baño o donde sea que sienta que llamará la atención
• programación de pares; con otro cerebro a tu lado, lo pensarás dos veces antes de nombrar tu variablei
• recoja a su conserje y explíquele cómo funciona esa herencia (oh, sí, no funciona). Explicar su código a otra persona ayuda. Tal vez se compila, tal vez hace lo correcto, pero realmente no entendiste por qué. Ahora es tu oportunidad
• tener un conjunto de pautas y hacer que todos las sigan; cualquiera que sea la guía, es mejor que ninguna guía