La revisión de código es una práctica cada vez más común en los equipos de desarrollo. Es un flujo de trabajo en el que los desarrolladores envían su código para recibir comentarios antes de fusionar sucursales o implementar código en producción. Esta retroalimentación generalmente es dada por colegas, ya sea otros desarrolladores, un gerente o un líder tecnológico. Una de las formas más familiares de revisión de código es la Solicitud de extracción de Github, en el que los desarrolladores dejan comentarios sobre líneas de código específicas y, en última instancia, aprueban o rechazan los cambios propuestos.

La revisión del código se basa en la simple suposición de que "dos cabezas son mejores que una". Todos tenemos puntos ciegos al escribir código: enfoques que no consideramos, eficiencias que no hacemos y partes del sistema que entendemos menos que otros. La revisión de código es un intento de eliminar estos puntos ciegos y mejorar la calidad del código asegurando que al menos otro desarrollador haya ingresado en cada línea de código que lo hace en producción.

(Como nota al margen, programación de pares a veces puede parecerse a una forma de revisión de código 'en vivo', donde una persona escribe el código y la otra lo revisa en el acto).

Aunque la revisión del código a menudo significa que el código tarda un poco más en llegar a producción, muchos equipos de desarrollo dicen que vale la pena debido al aumento general en la calidad del código. La revisión de código es practicada por compañías masivas de alto rendimiento, como Microsoft y Google, a startups como Historia completa. Bruce Johnson, cofundador de Fullstory, dice que su compañía hace una revisión de código porque "Una onza de prevención vale una libra de cura". En resumen, la revisión de código a menudo significa que hay menos errores en la producción.

Es posible que ya esté haciendo una revisión de código en el trabajo. Sin embargo, en mi experiencia, la mayoría de los desarrolladores realizan revisiones de código de acuerdo con su "instinto". Reaccionan a cada línea de código sin un plan claro de lo que considerarán durante la revisión del código. Debido a este enfoque ad hoc, a menudo se pasan por alto ciertos aspectos de la revisión de código.

En este artículo, buscaremos desarrollar sus habilidades de revisión de código sugiriendo los diferentes elementos que debe considerar al realizar uno. Puede usar esta lista para revisar cuando revise el código. Si esta lista parece abrumadora, Codementor también ofrece revisión de código como servicio.

1. Legibilidad, también conocida como "comprensibilidad"

La legibilidad en el software significa que el código es fácil de entender. En este caso, comprender el código significa poder ver fácilmente las entradas y salidas del código, lo que está haciendo cada línea de código y cómo encaja en el panorama general. Al leer el código, debería ser relativamente fácil para usted discernir el papel de funciones, métodos o clases específicos.

El código se vuelve menos legible a medida que se necesita más memoria de trabajo para mantener cada 'paso' en su mente. Uno de los problemas más frecuentes con el código es que no se divide en fragmentos lo suficientemente pequeños. Por lo general, esto lleva a clases, métodos o funciones que son demasiado largos con demasiadas responsabilidades enredadas. Al dividir el código en fragmentos más pequeños, es más fácil razonar y realizar cambios en partes específicas del sistema sin efectos secundarios no deseados.

Otro aspecto de la legibilidad es el nombramiento de variables, funciones, métodos y clases. Los nombres buenos y descriptivos hacen que el código sea más fácil de entender. No dude en dar su opinión sobre los nombres que se abrevian demasiado o son difíciles de entender. Por ejemplo, aunque podría estar claro para el codificador original que op es la abreviatura de options parser, puede que no esté claro para usted o la próxima persona que aparecerá en el código. Los buenos nombres ahorran tiempo a todos y reducen la carga cognitiva al leer el código.

2. Mantenibilidad

Una de las razones más comunes por las cuales el código eventualmente se vuelve difícil de trabajar es porque no está escrito para ser fácilmente extensible y modificable.

Aquí hay algunas señales de advertencia de que el código puede no ser fácil de mantener en el futuro:

• Está muy estrechamente acoplado a otro sistema.
• La configuración está codificada.
• Contribuye a la deuda tecnológica al aumentar la inversión en una tecnología que el equipo desea eliminar (por ejemplo, mediante el uso de la funcionalidad de una versión anterior de una biblioteca).
• Se basa en el código antiguo que se ha programado para su eliminación o reemplazo.

3. Seguridad

Las vulnerabilidades de seguridad a menudo ingresan en bases de código porque los desarrolladores escriben código sin pensar en la seguridad. Esto podría significar que escriben código inseguro que introduce vulnerabilidades en el sistema, o usan bibliotecas y herramientas que están desactualizadas o tienen problemas de seguridad conocidos.

Durante la revisión del código, los problemas de seguridad pueden pasarse por alto si los desarrolladores olvidan ponerse en el lugar de alguien que intenta explotar el sistema. Por ejemplo, pregúntese: si estaba tratando de obtener acceso al sistema o robar datos, ¿cómo podría explotar este código?

4. Velocidad y rendimiento

Considere el rendimiento en dos dimensiones: rendimiento para los usuarios y consumo de recursos. El rendimiento para los usuarios refleja un enfoque en la rapidez con que su código se desempeña para el usuario final. Las largas consultas a la base de datos, los activos no optimizados y las múltiples solicitudes de API pueden funcionar para que su código se sienta lento.

Cuando sea posible, el código debe usar carga diferida, así como procesamiento asincrónico y paralelo. Debe usar el almacenamiento en caché tanto como sea posible y no debe cargar nada que no se use.

La otra dimensión del rendimiento es el consumo de recursos. Esto significa no poner en servicio servidores en la nube que sean más potentes de lo necesario, no ejecutar informes intensivos con más frecuencia de la necesaria y, de lo contrario, no poner el sistema bajo más carga de la que necesita debido a las opciones de código o infraestructura.

Mientras se adhiere a las mejores prácticas como estas, tenga en cuenta no llevar esta "necesidad de velocidad" demasiado lejos. Hacerlo puede conducir a una optimización prematura, que son optimizaciones que no son necesarias, que no son notables para el usuario (o en sus métricas) o que no valen la pena la inversión de tiempo. Sé práctico. Concéntrese en el 20% de las optimizaciones que producen el 80% de los resultados.

5. Documentación

Compruebe si el código que está revisando requiere documentación adicional para acompañarlo. Si se trata de un proyecto nuevo, esto significa asegurarse de que tenga un archivo Léame adecuado que explique por qué existe el proyecto y cómo usarlo. Si se agrega un nuevo código a un proyecto existente, vale la pena pensar si el archivo Léame del proyecto debe actualizarse para documentar la nueva funcionalidad o las nuevas herramientas.

6. Reinventando la rueda

¿Utiliza el código las funciones de idioma adecuadas para realizar el trabajo? Cuando las personas escriben código en lenguajes de programación que aún no han dominado, a menudo toman el camino largo con el código. Por ejemplo, podrían escribir laboriosamente una función para hacer algo que ya existe en el idioma que están utilizando. Al hacer la revisión del código, asegúrese de que el código use todas las funciones de lenguaje apropiadas. El código no debe volver a implementar funciones que ya existen en el lenguaje o las bibliotecas que utiliza el proyecto.

7. Confiabilidad

El código confiable es un código que tolera fallas. Cuando las cosas salen mal en un código confiable, la experiencia del usuario está protegida del impacto tanto como sea posible. El código confiable está escrito bajo el supuesto de que las cosas fallarán, que los activos a veces no se cargarán, las solicitudes de API ocasionalmente devolverán 500 errores y faltarán los registros de la base de datos. Cuando se anticipa un cierto nivel de falla, se puede manejar con elegancia. El código que supone que nada saldrá mal generalmente termina fallando catastróficamente.

8. escalabilidad

Considere la escalabilidad imaginando qué podría pasar con el código que está revisando si se coloca bajo una carga inesperada. ¿Qué le sucede a su página de inicio si se vuelve viral y recibe docenas de solicitudes por segundo? ¿Qué sucede si un usuario con miles de actividades en su aplicación decide ver su registro de actividad completo? ¿Qué sucede si su producto aparece en las noticias y 100 personas intentan comprarlo todo a la vez? Es importante tener en cuenta lo que es probable que suceda con el código en períodos de uso muy alto al realizar revisiones de código. Después de todo, el peor momento para descubrir problemas de escalabilidad es cuando desconectan su sitio web / aplicación / servicio.

9 Reusabilidad

Verifique que el código esté escrito teniendo en cuenta los posibles casos de uso futuros. Por ejemplo, si está revisando el código de un mercado que está expandiendo rápidamente su gama de productos, asegúrese de que el código pueda actualizarse fácilmente para admitir nuevos tipos de productos en el futuro.

Del mismo modo, asegúrese de que el código no lleve esto demasiado lejos al tratar de tener en cuenta los casos de uso que es poco probable que sucedan. Todos hemos visto código en el que el autor intentaba probar su creación tanto en el futuro que terminaron agregando características adicionales que nunca se usarían en su código. El código que nunca se usa es inmediatamente un código heredado. Por lo tanto, es importante lograr un equilibrio entre el código que es reutilizable y el código que viola el Principio YAGNI: no lo vas a necesitar.

DRY es una de las primeras máximas aprendidas por los programadores. Significa que no te repitas. En otras palabras, no duplique código o funcionalidad. Una de las mejoras más rápidas que puede realizar durante la revisión del código es identificar el código repetitivo y sugerir una función o clase reutilizable para reemplazarlo.

Una advertencia: es posible llevar la reutilización demasiado lejos y dar como resultado un código que es tan abstracto e intenta acomodar tantos casos de uso potenciales que no sirve a ninguno de ellos. Es el equivalente a tratar de inventar un utensilio de cocina que es un tenedor, cuchillo, cuchara y plato, todo en uno. Todavía no se ha hecho, lo cual es una señal de que probablemente no sea una buena idea.

10. Patrones

Otra consideración al agregar un nuevo código a una base de código es si coincide con los patrones que su equipo ya ha establecido. Es probable que su base de código ya tenga su propio estilo y que tenga una guía de estilo dedicada. El nuevo código no debe desviarse de los patrones establecidos sin una buena razón.

11. Prueba de cobertura y calidad de prueba

La revisión del código es tan importante para las pruebas como lo es para el código que se prueba. Esto se debe a que una prueba defectuosa es más peligrosa que no tenerla. Pasar las pruebas le permite al desarrollador sentirse seguro y dispuesto a impulsar un nuevo código a producción. Pero, ¿qué sucede si una de las pruebas se aprueba por la razón incorrecta o no se prueba lo que se supone que se debe probar? Este tipo de prueba puede ser una bomba de tiempo, permitiendo que los errores se cuelen en su base de código.

Los mismos requisitos para el código de producción también deberían aplicarse a las pruebas. Las pruebas deben ser legibles, mantenibles, eficaces y cumplir con los patrones establecidos. Cuando llegue el momento de actualizar o mantener el código existente, es probable que sus pruebas sean lo primero que necesite cambiar. Por lo tanto, es fundamental que sean fáciles de trabajar para su equipo.

Por último, no te detengas a revisar las pruebas que están allí. Piense detenidamente si faltan pruebas. ¿Hay casos límite que no han sido probados?

12. Apto para el propósito

El código puede funcionar, pero ¿funciona de la manera que espera su gerente de producto, CEO o usuario? Antes de que el código pase a producción, vale la pena verificar que el código realmente proporcione la funcionalidad que estaba destinada a proporcionar. Si no tiene un proceso de garantía de calidad definido para una nueva funcionalidad, la revisión del código puede ser la única oportunidad que tiene para confirmar esto.

13. Note lo que falta

La revisión del código puede alentar un sesgo hacia considerar solo lo que está frente a usted. Revisas el código que te han dado. Pero, ¿qué pasa con el código que no está allí? Por ejemplo, es importante pensar en casos extremos, entradas inesperadas y escenarios de manejo de errores que el autor del código puede no haber considerado. ¿Qué sucede cuando la API en la que se basa el código se cae? ¿Qué sucede cuando el usuario presiona el botón de enviar dos veces en rápida sucesión? ¿Qué sucede cuando el navegador del usuario no es compatible?

14. Alejar

Uno de los riesgos con la revisión de código es que fomenta un enfoque en los detalles del código, en lugar de en el panorama general. ¿Qué sucede cuando se envía una solicitud de extracción que contiene cientos de líneas de código y, sin embargo, el enfoque para resolver el problema es inferior? ¿Quizás es ineficiente, quebradizo o mal diseñado? Esto puede ser una retroalimentación realmente difícil de dar, especialmente cuando el desarrollador ha pasado varios días trabajando en una solución antes de solicitar la revisión del código.

Sin embargo, este tipo de comentarios es importante porque las solicitudes de extracción que no deberían haberse aprobado en primer lugar a menudo se convierten en puntos débiles en su base de código. Debe sentirse cómodo sugiriendo un enfoque totalmente nuevo si la solicitud de extracción es fundamentalmente defectuosa.

Una de las mejores maneras de hacer que esto sea más realista es garantizar que las solicitudes de extracción no sean demasiado grandes. Si los desarrolladores trabajan de forma aislada durante días y finalmente envían una solicitud de extracción grande, este es un antipatrón. Las solicitudes de extracción deben ser pequeñas y frecuentemente integradas. La función alterna, a veces también llamados banderas de características, pueden ayudar con esto. Son herramientas inteligentes que permiten dividir grandes porciones de trabajo en una colección de solicitudes de extracción incrementales. Permiten un progreso constante en la funcionalidad de su base de código sin exponerla a los usuarios hasta que esté listo.

Cuéntanos: ¿Qué más consideras al revisar el código?

Esperamos que esto haya servido como una lista de verificación útil para que la tenga en cuenta durante la revisión del código. Incluso si no hace referencia a todos los elementos de la lista cada vez que revisa el código, puede ser útil tomar nota de los aspectos de la revisión del código que tiende a pasar por alto. Estos serán diferentes para todos y dependerán de sus antecedentes o experiencia. Sin embargo, todos estos aspectos del código son críticos para la calidad y no se deben omitir.

¿Qué más crees que es importante tener en cuenta al realizar una revisión de código? Nos encantaría saber de usted en los comentarios.

Fuente: https://www.codementor.io/blog/code-review-checklist-76q7ovkaqj