¿Quién debería hacer revisiones de código?

12

En mi empresa, principalmente el arquitecto hace revisiones de código. Es un tipo de software inteligente y con mucha experiencia, por lo que es muy bueno en eso. Cuando los desarrolladores hacen las revisiones de código, no lo hacen la mitad de bien. Intentamos que los desarrolladores hicieran más revisiones de código, pero la calidad de las revisiones de código no era buena. Utilizamos Scrum para 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 de la calidad del código y de la arquitectura (lo que conduce a todo tipo de problemas).

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

    
pregunta Eugene 08.02.2014 - 17:34

5 respuestas

15

Los desarrolladores deben hacer revisiones de código. Deben hacer revisiones de código, porque deben conocer el código, los estándares de estilo y las prácticas de la empresa. Al hacer que alguien más realice 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 crees que necesitan capacitación para hacer revisiones de código, consíguelo por ellos. Dada su situación actual, puede hacer que un desarrollador realice la revisión del 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.

    
respondido por el jmoreno 08.02.2014 - 18:18
7

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ó realmente bien en mi último equipo. Pusimos a todo el equipo en una habitación con un proyector y comenzamos a revisar algunos artículos. Tal vez al principio el arquitecto es el que guía la revisión, pero en unas pocas semanas (reservamos una o dos horas cada viernes), todo el equipo comienza a hablar y comprender los conceptos clave que actualmente solo el arquitecto parece conocer.

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

respondido por el AlfredoCasado 09.02.2014 - 10:11
3

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

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

  • Grupo de cambios por requisito / problema.
  • Invite a todos los desarrolladores, al arquitecto de software y al autor del requisito / problema a revisar. (No todos ellos son necesarios para realizar una revisión).
  • Considere una revisión finalizada 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).

Por lo tanto, mi breve respuesta a tu pregunta es: Los desarrolladores deben cambiar las revisiones.

[*] Lamentablemente, no siempre es así como funcionan los proyectos en los que participo

    
respondido por el Jacob Sparre Andersen 09.02.2014 - 09:53
3

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

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

Honestamente, sin embargo, parece 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.

    
respondido por el Rob 21.02.2014 - 09:38
2

Estoy de acuerdo, si solo una persona hace comentarios, el resto de los muchachos probablemente irá con "No sé, parece funcionar, pero deja que ese chico inteligente se entere 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 imprímalos y póntelos en el baño, uhh, o en cualquier lugar que crea que atraiga algunos ojos
  • programación de pares; con otro cerebro a tu lado, lo pensarás dos veces antes de nombrar tu variable i
  • levante a su conserje y explíquele cómo funciona esa herencia (oh, sí, no funciona). Explicar su código a alguien más ayuda. Tal vez compile, tal vez haga lo correcto, pero realmente no entendiste por qué. Ahora es tu oportunidad
  • tenga un conjunto de pautas y haga que todos las sigan; cualquiera que sea la directriz, es mejor que ninguna directriz
respondido por el mihai 08.02.2014 - 18:08

Lea otras preguntas en las etiquetas