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:
El arquitecto se convierte en un cuello de botella.
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?
code-reviews
Eugene
fuente
fuente
Respuestas:
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.
fuente
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.
fuente
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:
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.
fuente
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.
fuente
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:
ifuente