Como ingeniero de software junior, siempre examinaba los comentarios de revisión de código que recibía para aprender cómo ser un mejor codificador. Pero cuando llegó el momento de intentar mi primera revisión de código, me di cuenta de que mi experiencia no me había preparado para estar del otro lado.
Desarrollé un caso grave de síndrome de impostor, en espiral hacia abajo con preguntas: ¿Debería comentar sobre esta línea de código o no vale la pena? ¿Debo encontrar artículos para apoyar cada comentario? ¿Bloquearé el sitio al aprobar esto? ¿Me odiarán? De acuerdo, admito que doy vueltas bastante rápido. Pero después de hablar con algunos compañeros de trabajo, supe que no estaba solo en mis preocupaciones.
Los ingenieros de software junior pueden verse obligados a revisar el código con una suposición análoga a "sabes cómo leer un libro para saber cómo escribir un libro, lo cual no es cierto", dice Jessica Rudder, una ingeniera de experiencia en GitHub.
Hay expectativas que vienen con la revisión del código, y el proceso puede ser estresante. Así que entrevisté a otros siete ingenieros de software para recopilar consejos sobre cómo construir una mentalidad de revisión.
1. Piensa en el impacto general
En general, una buena solicitud de extracción (PR) solo debería afectar a una parte confinada de la base de código. Sin embargo, el alcance limitado no debería evitar que piense en el cambio de código dentro del contexto de la base de código más grande.
Nigel Muñoz, un ex ingeniero de pila completa en The Muse y actual ingeniero de software independiente, alienta al revisor a pensar "cómo este cambio afecta la imagen más grande y más pequeña". Considerar la imagen más grande incluye encontrar cualquier deuda técnica: busque el código esto se repite, no es modular o no se adhiere a las convenciones estándar más recientes, además de analizar modificaciones a la arquitectura de la base de código.
Sam Donow, desarrollador principal de Hudson River Trading, cree que "no hay nada demasiado grande o demasiado pequeño para comentar". Las sugerencias para pequeñas mejoras podrían conducir a mejoras más grandes en múltiples partes de la base de código ".
Puede utilizar un comentario de relaciones públicas en GitHub para proporcionar comentarios positivos, así como señalar dónde el código puede diferir de las convenciones estándar del marco React.
Por ejemplo, durante una de mis propias revisiones de código, recibí un comentario de que ciertas propiedades en un componente React eran confusas, lo que generó preguntas más amplias sobre cómo se estaba usando el componente. Finalmente, eliminé las propiedades del componente original y creé un componente separado para aclarar el comportamiento de cada uno y garantizar que ambos pudieran usarse en más lugares.
2. Considere la seguridad
No olvide que algunos cambios podrían afectar más que solo la base de código. Rudder recomienda evaluar si un usuario "podría usar esta funcionalidad para hostigar a alguien o podría abusar del sistema". Por ejemplo, si la nueva característica en la solicitud de extracción incluye la entrada del usuario, busque inyección SQL, acceso a datos, secuencias de comandos en sitios cruzados y Otras vulnerabilidades de seguridad.
3. Centrarse en errores
Sus compañeros contribuyentes de código, no importa cuán robóticos puedan parecer, son humanos, y los humanos pueden romper u olvidar funcionalidades. Así que asegúrese de "revisar las pruebas con la misma importancia que el resto del código", aconseja Abhishek Pillai, líder tecnológico de Teachers Pay Teachers. "Evitarán nuevos errores y servirán como una forma de documentación para cualquier otra persona que trabaje en esto en el futuro".
Leer las pruebas puede ayudarlo a comprender la funcionalidad de una nueva característica y ver los diferentes casos que presentará, mientras que el análisis de las pruebas puede ayudarlo a señalar casos faltantes y encontrar características que no figuran en este PR. Si no hay pruebas incluidas en el cambio de código y parecen relevantes, es apropiado solicitarlas dentro de la revisión.
Pero las pruebas no lo son todo. "No confíes demasiado en el sistema", advierte Donow. "El hecho de que las pruebas se ejecuten no significa que no haya errores".
También es posible que desee "ejecutar la aplicación localmente para probarla funcionalmente y asegurarse de que funciona. Si no funciona, entonces no tiene sentido realizar más revisiones ”, dice Ryan Verner, desarrollador de software en 8th Light. Aunque algunos revisores no piensan que las pruebas manuales deberían ser parte del proceso de revisión del código, en parte debido al tiempo que lleva, Verner cree que es una forma rápida de determinar si debe invertir más tiempo en la revisión, así como una estrategia para ayudar a reducir El crecimiento de una acumulación de errores.
4. Sé un jugador de equipo
El cliché adquiere un nuevo significado cuando se trata de revisar el código. "Tómese el tiempo para revisar porque es la base de código de todos", dice Verner, quien aboga por un sentido de "propiedad colectiva". Usted, como revisor, debe trabajar para proteger la acumulación de errores a fin de aumentar su tamaño con el objetivo de brindarle equipo menos trabajo en la línea.
Pillai usa gifs para celebrar las relaciones públicas aprobadas y listas para fusionar de sus compañeros de equipo.
Al mismo tiempo, Charles Luxton, líder tecnológico de The Muse, alienta al crítico a comprender y recordar las prioridades del equipo. Con fechas límite y desacuerdos que se acercan rápidamente, a veces se crea un elemento de tarea pendiente para el trabajo atrasado que garantiza que se realizarán mejoras en el futuro y, mientras tanto, poner un comentario sobre el código en cuestión es la curita que necesita para mantén feliz a tu equipo.
Finalmente, preguntarse si el código tendría sentido para alguien que acababa de unirse al equipo y lo estaba leyendo en sus primeras semanas ayudará a mantener su código legible y comprensible.
5. Use el proceso para el aprendizaje y el intercambio de conocimientos
El proceso de revisión brinda a todos los involucrados un lugar para obtener más información sobre la base de código, los idiomas, los marcos y las mejores prácticas.
Matt Jeffery, líder tecnológico de The Muse, aconseja al revisor que "comprenda los cambios arquitectónicamente. Una forma es leer los nombres de los archivos, ya que ayudan a dar contexto. Por ejemplo, si está buscando un cambio en la capa de acceso a datos sabes que no estás lidiando con la lógica de negocios o la interfaz de usuario ".
Puede usar un comentario de relaciones públicas en GitHub para compartir documentación.
Cuando aprende de los cambios en el código, también tiene la oportunidad de compartir conocimientos. "Es mejor explicar su opinión y respaldarla con documentación", dice Luxton. Los enlaces que proporciona a la evidencia de apoyo y artículos confiables no solo ayudan al revisor y al redactor de códigos a explorar diferentes enfoques a medida que toman una decisión final, sino que también refuerzan su conocimiento de la programación.
Si bien tiene en cuenta estos consejos, recuerde también que revisar es un momento para ejercitar las habilidades de su gente. "Ofrezca a las personas el beneficio de la duda de que pensaron en su enfoque y señalen diferentes posibilidades al tratar de disipar la actitud defensiva", dice Rudder. "Dejo comentarios y un comentario final: esto es lo que es genial, esto es lo que se puede mejorar, esto es lo que hay que cambiar antes de fusionar".
Con este tipo de enfoque, no solo estará protegiendo su base de código de deudas tecnológicas, amenazas de seguridad y errores, sino que también estará formando su equipo.
