Constantemente me comprometo a proyectos de código abierto (Red Hat, etc.). Y notó que las revisiones negativas de códigos, subjetivas en esencia, toman más tiempo. La mayoría de las veces esto sucede con commits, donde al responsable por alguna razón no le gusta su cambio. En el mejor de los casos, dicha estrategia de revisión de código resulta en tiempo perdido en debates sin sentido; en el peor de los casos, desalienta activamente el compromiso, creando un ambiente hostil y elitista.

La revisión del código debe ser objetiva, concisa y, si es posible, contener solo ciertos hechos. Este no es un debate político o emocional, sino técnico. Su objetivo es avanzar, desarrollar el proyecto y todos los participantes. Cualquier compromiso debe evaluarse solo en función de los méritos, y no en una opinión subjetiva.

Estrategias de revisión de código

Aquí hay algunas estrategias a tener en cuenta al considerar el código que a usted (como mantenedor) no le gusta por alguna razón:

1. Reformule la objeción como una pregunta

• Malo: "Este cambio hará que XXX sea imposible" (Esto es una exageración; ¿es realmente imposible?)
  
• Bien: "¿Cómo haremos XXX después de tu cambio?"

2. Evita la exageración

Simplemente exprese sus preocupaciones y haga preguntas para ayudarlo a lograr el resultado deseado.

• Malo: "Este cambio destruirá la productividad".
  
• Bien: “Parece que X puede ser más lento que el Y existente; "¿tomó medidas / recopiló datos para mostrar que esto no es así?"
  
• Mejor (si tiene tiempo): “Por ahora, estoy recopilando datos. Intentaré verificar que X no sea más lento que Y ".
  
• También bueno: “Este cambio cambia un solo ciclo O (n) a un ciclo O (n²) doblemente anidado; ¿afectará el rendimiento?

3. Deja comentarios maliciosos para ti

Algunos pensamientos son mejor guardados contigo. Si no puedes decir cortésmente, mejor calla.

• Malo: "Creo que este es un mal cambio que arruinará todo".
  
• Malo: "¿Está seguro de que el desarrollo de software es la elección de carrera adecuada para usted?"

4. Actuar positivamente

¿Quizás tenías una idea diferente sobre cómo resolver el problema? Si actúas positivamente, finalmente encontrarás una solución que es mejor que cualquiera de las opciones originales.

• Malo: "Este cambio apesta, mi versión es mejor".
  
• Bien: "También tengo un cambio para este lugar: quizás podamos comparar y / o combinar ideas".
  
• También es bueno. "Tengo un cambio similar en mi trabajo, pero decidí hacer X, porque ZZZ; ¿Por qué elegiste Y?

5. Recuerde que todos tienen una experiencia diferente.

En todos los demás aspectos, un ingeniero absolutamente competente puede no conocer durante algunos años algunos hechos que usted toma como sentido común. No hay nada malo en decir lo obvio, a menos que sea condescendiente o malicioso.

• Malo: "¿No puedes ver que esto está claramente mal?"
  
• Bien: "Esto no es cierto porque arroja una excepción de puntero nulo cuando X es Y".

6. No minimices la complejidad de lo que no es obvio

Recuerde que las cosas que son obvias para usted pueden no ser obvias para todos. Al sugerir enfoques alternativos y señalar ejemplos útiles, puede ayudar a todos a sincronizarse.

• Malo: "¿Por qué no simplemente aplastar la gnosis?"
  
• Bien: "Si aplastas la gnosis, entonces esta parte puede ser más fácil (ver XXX para ver un ejemplo)".

7. respeto

A veces, un compromiso simplemente no cumple con el estándar mínimo de calidad. Es normal decir esto, pero mostrar respeto no requiere un esfuerzo adicional.

• Malo: "Este es un código estúpido escrito por una persona estúpida".
  
• Bien: “Gracias por tu aporte. Sin embargo, no puede adoptarse tal como está; hay muchos problemas (como se indicó anteriormente) ".
  
• También es bueno: “Como se indicó anteriormente, hay varios problemas con esta confirmación. ¿Quizás retroceder y hablar sobre escenarios de uso? Esto ayudará a encontrar el camino ".

8. Administre sus expectativas (y su tiempo)

Si la confirmación es demasiado grande y no se puede considerar rápidamente, es normal decirlo de inmediato. Luego busca una solución.

• Malo: "No lo acepto, es demasiado grande".
  
• También malo: ignora el commit hasta que desaparezca.
  
• Bien: "¿Podrías dividirlo en commits más pequeños? No tengo demasiado tiempo para una revisión de código, pero es una confirmación demasiado grande / complicada para una revisión ".

9. Di "por favor" (muestra cortesía)

Simplemente diciendo "por favor", demuestra que respeta el tiempo del remitente, especialmente cuando desea cambiar el formato o el estilo, lo que puede parecer un ligero cambio. Ejemplos:

• "¿Podría documentar los cambios en las brechas en otra solicitud de grupo?"
  
• "¿Podría alinear estas definiciones de variables para que sean más fáciles de leer?"

10. Comience una conversación

Si después de todo esto aún no le gusta algo, pero no está seguro de por qué, es posible que solo tenga que soportarlo. O diga: "No me gusta, pero no estoy seguro de por qué, ¿podemos hablar de eso?" Esta es una pregunta razonable, y aunque puede llevar un poco de tiempo, a menudo vale la pena porque ahora tiene dos personas y ambas están aprendiendo (explicando y escuchando), y no dos personas que se oponen entre sí.

Incluso los ingenieros calificados y experimentados deberían poder decir: "No entiendo por qué no me gusta". Esto no es una invitación a atacar la posición del revisor, sino más bien una búsqueda honesta de conocimiento.

Resumen

Evite declaraciones hiperbólicas o pomposas, evite disputas, expresiones y construcciones elitistas o degradantes como "obvio" y "por qué no simplemente ...". Utilice declaraciones claras y objetivas y lenguaje de apoyo, haga preguntas y siga adelante. Recuerde que los colegas y colaboradores también son personas. Su tiempo merece el mismo respeto que el tuyo.