5 reglas básicas para una mejor revisión del código

Como hacer una mejor revisión del código

5 reglas básicas para una mejor revisión del código. ¿Cuántas veces te has perdido como revisor, mientras revisabas un código muy desordenado con un desarrollador web que constantemente tiene que explicar lo que ha hecho, sólo para descubrir que el código ni siquiera se puede recopilar?

¿Y cuántas veces, como desarrollador web, has sentido que la revisión del código no tenía sentido, y que se habia utilizado un tiempo sin que se aprendiera una lección?

Si te relacionas con cualquiera de las anteriores preguntas, aquí tienes 5 reglas básicas que te recomiendo que sigas, tanto como desarrollador web como revisor, que mejorarán enormemente tu proceso de revisión del código y te ayudarán a crear un impacto mucho mayor y más duradero al hacerlo.

Evita tirar de peticiones, hazlo cara a cara.

Hoy en día, utilizar servicios como github, es prioritario por su fácilidad, no te voy a decir que no lo hagas, pero piénsalo por un minuto, el acto de transferir un conocimiento que se está introduciendo en una pequeña caja de texto (un comentario), sin conversación o interacción humana, sin dar la oportunidad de que el desarrollador web se explique adecuadamente.

una mejor revisión del código

¿Es la codificación tan simple como el blanco y el negro? ¿No preferirías aprender a escribir mejor el código, tanto al revisarlo como al escribirlo?

Las revisiones de código cara a cara crean conversación, un vivo intercambio de ideas. Permite al revisor ofrecer sugerencias y consejos que no necesariamente cambiarán tu código, pero que te abrirán la mente la próxima vez que escribas algo similar. Y también le da al desarrollador web la oportunidad de explicar por qué cree que lo que hizo es mejor, y quién sabe, tal vez el revisor también aprenda algo nuevo.

2. El revisor toma el timón, mientras el desarrollador web se sienta y observa.

Las revisiones de código cara a cara tienen un gran inconveniente. Tener al desarrollador web explicando su código a lo largo de toda la revisión, podría hacer difícil entender si el código no es limpio y legible. Otros programadores tendrán que lidiar con su código sin que se siente a su lado y explique sus ideas paso a paso – y ahí es donde entra en juego la siguiente regla.

El revisor debe manejar el código solo, y el desarrollador web sólo debe responder cuando se le pida, el desarrollador web no inicia una conversación, sólo responde cuando se le pide.

De esta manera, la conversación sobre la legibilidad del código es sincera, y el revisor no se sentirá engañado. Sé que suena bastante estricto, pero funciona, y aún así se puede seguir una conversación de forma educada.

3. El desarrollador web es «Responsable».

No le hagas perder el tiempo al revisor, asegúrate de que tu código se compila, todas tus pruebas son correctas, y echa un último vistazo a tu código (evita errores tipográficos, problemas de filtrado, etc.) antes de pasar a la etapa de revisión.

No queremos que la revisión del código sea sobre tecnicismos, recuerda, tiene que ser significativa.

4. Nunca digas «tú», di «nosotros» en su lugar.

Notarás que si usas demasiado el término «Tú», el desarrollador web puede ponerse a la defensiva mientras protege su código (y tal vez sienta que su dignidad también está en juego). Asegúrate de que esta revisión de código sea productiva y no tenga ningún sentido.

desarrollador web puede ponerse a la defensiva

Recomendar tu argumento al equipo o a ti mismo, es más agradable y abre al desarrollador web para que esté más atento a los cambios.

Por ejemplo: «Lo que hiciste está mal» => «Lo que solemos hacer es eso» => «Lo que hago normalmente es así, ¿qué opinas?

Sí, ese tipo de «tú» está bien 🙂

5. Que el desarrollador web elija a su revisor para la revisión del código.

Este consejo está dirigido a los managers que hay entre nosotros, que asignan al mismo revisor (en su mayoría ellos mismos) para hacer revisiones de código para su equipo. En mi humilde opinión, cuando se trata de revisiones de código, la experiencia debería tener poco significado, y déjame que te sorprenda: Un estudiante de último año también puede aprender algo de los estudiantes de tercer año!

Cuando hay un solo revisor – sólo se hacen réplicas de sus propias opiniones y estilo de codificación en todo el equipo, en lugar de tener un «mix & match» de las opiniones y estilos de codificación con los que todo el equipo está de acuerdo.

Resumiendo la revisión del código, me gustaría dejarte una nota:

Las revisiones de código deben ser sobre el intercambio de conocimientos y la auto-mejora. Una mejor base de código es sólo un bonus, y llegará cuando los miembros de tu equipo se respeten y aprendan unos de otros.

Si te ha gustado este artículo pero aun no has comenzado a estudiar programación, te recomiendo leer Fundamentos De JavaScript: Sintaxis Y Estructura, para que puedes empezar en este maravilloso mundo 🙂

Deja un comentario

Háblame ;)
¿Necesitas ayuda?
Hola! estás interesado en mis servicios? hablemos por WhatsApp ;)