Todavía recuerdo la primera solicitud de extracción en mi tiempo de pasantía y exponiendo mi código a otros. Tomaría un lápiz, papel y escribiría todas las sugerencias que recibiera de mi mentor. La revisión única solía durar días, y en ese momento, solía pensar en lo terrible que era esta parte de mi trabajo.

Para los desarrolladores junior, la revisión puede ser un lugar de aprendizaje o un muro de vergüenza. Depende del equipo y de los seniors traer una atmósfera de confianza, honestidad y mejoras constantes. En palabras simples: si el proceso de revisión es un espacio de aprendizaje y sin ego, el equipo está feliz y las personas están creciendo.

Años de experiencia no garantizan que la calidad del código sea perfecta. Los desarrolladores junior deben tener la capacidad de hacer revisión de código de los desarrolladores senior y, si no comprenden los cambios, las relaciones públicas necesitan mejoras importantes.

Los diferentes equipos tienen diferentes políticas y normas cuando se trata de revisiones. Sin embargo, como desarrollador maduro, existen algunos estándares no escritos que debería considerar adoptar.

1. No deje que las emociones impulsen sus revisiones

Hay días malos y buenos para todo lo que hacemos. Los humanos son sensibles, los desarrolladores son humanos. Depende de nosotros ser conscientes de nosotros mismos y reconocer cuando nos sentimos deprimidos, enojados o simplemente distraídos.

Si no tiene una solución o alternativa concreta, mejor no comente nada. Si se siente enojado o estresado, es mejor posponer su revisión de código para más adelante.

2. Piense en el contexto

No se debe revisar ninguna solicitud de extracción sin considerar el panorama general.

¿Cuándo es la fecha límite? ¿Es esto una revisión? ¿Quién creó una solicitud de extracción? ¿Qué tan grande es el cambio? Hay muchas cosas a considerar al revisar el código de otra persona. Si llegamos tarde a la entrega, es mejor crear un ticket de deuda tecnológica que dedicar horas a la optimización. He visto muchas veces antes que esa revisión conduce a una optimización excesiva, y la optimización excesiva lleva a que nuestro código no sea legible o incluso a la introducción de nuevos errores.

Revisar no es un lugar para mostrar cuán inteligente o inteligente eres; es un lugar donde juntos mejoramos nuestro código, solucionamos problemas y encontramos soluciones alternativas.

Busque siempre mejores soluciones, pero no olvide entregarlas a tiempo.

3. Sea amable y brinde soluciones

Para crear un lugar de aprendizaje de solicitud de extracción y un lugar donde los desarrolladores se sientan libres de compartir sus opiniones, siempre debemos ser amables. La amabilidad también impulsa a los demás a ser amables, y eso es lo que estimula la confianza en un equipo.

Brindar soluciones en lugar de criticar es una mejor manera de liderar a los miembros del equipo con menos experiencia. Comentar sobre relaciones públicas sin un propósito o solución real es la mayor parte del tiempo quisquilloso.

4. Sea siempre sincero

No ser sincero puede causar más daño al equipo que las solicitudes de extracción rechazadas. Ocultar cosas en el desarrollo de software es una de las peores cosas que puede hacer. La mayoría de las veces, ocultar la verdad además de crear un nuevo error destruye la confianza entre los miembros del equipo.

En lugar de ocultar posibles errores o casos extremos, deberíamos informar a los demás de lo que está sucediendo y crear un ticket de deuda tecnológica o simplemente un simple comentario TODO en nuestro editor de código.

5. Encuentre su propio proceso

No existe un proceso perfecto para revisar las relaciones públicas, pero es mejor tener el suyo propio que no tener ningún proceso. El proceso de revisión individual siempre debe estar alineado con las normas del equipo.

Tenga siempre una lista de verificación: no es necesario que sea una lista de verificación escrita a mano, sino más bien un conjunto de premisas de revisión.

Aquí está mi proceso de revisión:

• Compruebe si hay un mensaje de confirmación, un título de relaciones públicas y una descripción
• Busque errores y olores de código
• Pruebe la función real
• Busque mejoras y casos extremos

Conclusión

La revisión de código / solicitudes de extracción es un lugar donde los desarrolladores son vulnerables, y siempre debemos estar al tanto de eso. No es un lugar para mostrar lo inteligente que eres, sino cómo podemos mejorar nuestro código.

Revisar no se trata de escribir 100 comentarios. Se trata de cumplir los objetivos del equipo y encontrar una mejor manera de hacer las cosas.

Busque siempre mejoras y soluciones alternativas, pero no olvide cumplir.