🏩 👨‍🚒 👩‍👦‍👦 Revisión de código Terminator. Revisión por la cual se te agradecerá ♋️ 🙋🏿 😌

^{Ginger me ayuda a revisar el código. Y cuando no le gusta algo, también un Terminator real,}

"Terminator de revisión de código", un colega me llamó una vez después de una revisión particularmente productiva. Por un lado, entretuvo a la República Checa y fue agradable. Por otro lado, un colega realmente aprendió algo nuevo, y esto le permitió escribir un mejor código. Entonces ganar-ganar.

Después del cambio de trabajo, los colegas también cambiaron. Pero también en un lugar nuevo, comenzaron a agradecer la revisión. Decidí averiguar por qué y ponerlo en los estantes. Resultó 11 recomendaciones.

1. Trate la revisión como una de las actividades principales.

Dejar un par de comentarios como "Y luego no hay suficiente verificación nula" no es suficiente. Es necesario:

Averigua lo que hay que hacer
Comprende cómo se hizo
. ( , , )?
, , . — , .

2.

Una cosa es sentarse al lado de un colega y discutir algo, mirando una pantalla. Otra cosa es revisar el código en el github o bitbucket. Es fácil malinterpretar las intenciones de un colega cuando la comunicación ocurre en el texto. Tome la frase "Hay un error en esta línea". Sí, está claro que la frase dice que el artículo tiene un error. Pero se le podía decir con diferentes emociones: ira, sorpresa, alegría de que el error fue atrapado y no entró en producción. O tal vez con indiferencia.

Su colega puede malinterpretar sus intenciones, y esto genera resentimiento, tensión en el equipo y, en general, apesta.

Haz tu vida más fácil: suaviza la frase, transfórmala en una pregunta o quizás agrega una cara sonriente.

3. Asignar tiempo

Para asegurarse de que el código funciona correctamente y correctamente, debe comprenderlo completamente. Y lleva tiempo; asegúrese de resaltarlo lo suficiente. Recuerda que revisar partes de la aplicación que no conoces llevará aún más tiempo.

En general, este es el otro lado de las buenas críticas: lleva mucho tiempo. Si no tiene tiempo para hacerlo bien, intente posponer o nombrar a otra persona (parece el consejo de un procrastinador, pero las situaciones son diferentes). Si esto no es una opción, pero necesita hacer una revisión, recuerde que sacrifica la calidad. Aunque necesario, pero un compromiso. Si lo convierte en un hábito, obtendrá más deuda técnica en el futuro.

4. No haga suposiciones; pedir

Cuando encuentre un código extraño o una solución demasiado compleja para una tarea aparentemente simple, no asuma por defecto que un colega cometió un error o una mala elección. Quizás él esté al tanto de algunas circunstancias que usted no conoce. Simplemente puede aclarar y evitar el riesgo de situaciones incómodas y estresantes si culpa injustamente a alguien. Por ejemplo: “¿Tal vez puedas usar una clase así aquí? Según tengo entendido, encajaría bien aquí y eso sería más fácil que la implementación propuesta ”.

5. Captura situaciones en las que necesitas contactar directamente

Por lo general, las revisiones se realizan de forma asincrónica. Para que pueda sumergirse en el código y distraer menos a su colega. Pero en algunas situaciones, es mejor contactar directamente (subiendo o llamando):

Cuando se acaban los plazos. La retroalimentación rápida acelera las decisiones. Pero claramente: con fechas límite y demás, todo está armado y las distracciones molestarán y reducirán la concentración.
Errores graves Discutirlos públicamente puede ser muy vergonzoso y frustrante para alguien. Es mejor hablar en persona y explicar el problema. Tal vez sea solo un descuido, o tal vez una brecha de conocimiento, que ahora está llena.
Enfoque completamente equivocado seleccionado. Para decirle a una persona que necesita tirar su trabajo, debe tener cuidado. Es mejor utilizar el lenguaje corporal y la entonación para transmitir aclaraciones sin ofender.

Bueno, es una buena idea agregar un resumen de conversación al sistema de revisión.

6. Lea el boleto primero

Algunos de los requisitos pueden no estar cubiertos en una solicitud de extracción aparentemente correcta. Para evitar esto, solo lea la declaración del problema primero. Al mismo tiempo, esto ayudará a comprender lo que generalmente sucede en los cambios.

7. Justifica tus sugerencias

Algunos errores (errores tipográficos, por ejemplo) no necesitan explicación. Pero si ofrece una solución arquitectónica alternativa u otro nombre, explique las ventajas y desventajas de ambas opciones. Lo que parece obvio para usted puede no ser completamente obvio para otras personas.

Además, hay un proverbio: “Dale un pescado a un hombre y lo alimentarás un día. Enséñale a pescar y lo alimentarás de por vida. Cuando le enseñaste a un colega un nuevo enfoque, podrá usarlo en el futuro y escribir mejor el código. Al mismo tiempo, la calidad del proyecto también mejorará como bonificación.

8. Elogie las buenas decisiones

Una revisión no tiene que ser una lista de errores. Si viste un buen lugar, una solución interesante, un método útil, cuéntamelo. Un breve comentario "Decisión genial" puede mejorar el estado de ánimo de una persona durante todo el día. Sí, y no elogie las malas solicitudes de extracción: es tenso y destruye el significado de la idea.

9. Sé cortés

Sugerencia: una frase como " ¿Podemos deshacernos del estilo de sintaxis de comentarios estúpido de redes dañadas por el cerebro? " cierto tipo de comentarios, por cortesía, agregando "por favor").

10. Ayuda

Si durante el proceso de revisión analizó varios archivos y, como resultado, encontró una solución alternativa, descarte los enlaces del colega a estos archivos. Puede incluso con números de línea, es aún más conveniente. No tomará mucho esfuerzo, pero un colega puede ahorrarle mucho tiempo.

11. Sugerir, no indicar

Cuando proponga un enfoque diferente para la revisión, no le diga a su colega, por orden, que use su opción. Discuta y deje que su colega decida. Lo más probable es que siga tu consejo. Y si no, ¿cuál podría ser la razón?

Ambos enfoques son casi iguales. Si no hay razones objetivas para elegir un nuevo enfoque, entonces no hay razón para perder el tiempo y aplicarlo. Descargo de responsabilidad: la uniformidad del código es una razón objetiva.
Hay una razón objetiva por la cual su enfoque es mejor. Pero por alguna razón, el autor del código no lo entiende. Revise su argumento, explique nuevamente y, al mismo tiempo, verifique si usted mismo está equivocado.
Conflictos personales. Esto es hielo resbaladizo y debes actuar aquí con cuidado. Y esto ya está más allá del alcance del tema de revisión.

Eso es todo. Resumiendo: Mejora

un poco el mundo que te rodea. Haz buenas críticas.

UPD Este artículo es una traducción gratuita de mi original en inglés . Convertido de "traducción" a "artículo" para no confundir a los lectores.

Revisión de código Terminator. Revisión por la cual se te agradecerá