Un pequeño vistazo a “Código limpio” de Robert C. Martin
Lectura recomendada para el desarrollo ágil de software
En el libro “Código limpio: Manual de estilo para el desarrollo ágil de software”, Robert C. Martin, junto con sus compañeros de Object Mentor, escribió una guía detallada sobre cómo y por qué construir código limpio y las consecuencias que trae no priorizar esta tarea. Así que si al igual que a mi, este tema te interesa, a continuación te comparto mis aprendizajes.
Para fines de este artículo seleccioné 2 capítulos: “Emergencia” (capítulo 12) porque retoma varias ideas importantes de otros capítulos que no me gustaría omitir y “Pruebas unitarias” (capítulo 9), debido a que fue uno de mis favoritos de toda la lectura. Y para abordarlos seguiré este orden, ya que el primero tiene una visión más general que el segundo.
¡Comencemos!😃
Capítulo 12: Emergencia
Jeff Langr, autor de este capítulo, recordó en orden de importancia las 4 reglas del diseño sencillo de Kent Beck:
- Ejecuta todas las pruebas.
- No contiene duplicados.
- Expresa la intención del equipo de programación.
- Minimiza el número de clases y métodos.
Todas ellas son fundamentales para diseñar un software correctamente. Y para que comprendas mejor a qué se refiere cada una, enseguida te explico:
Regla 1: Ejecuta todas las pruebas
“En primer lugar, un diseño debe generar un sistema que actúe de la forma prevista” escribe Langr. Por lo que para comprobar que funciona correctamente, es indispensable que contenga pruebas. Por esto mismo también argumenta que “los sistemas que no se pueden probar, no se pueden verificar, y un sistema que no se puede verificar no debe implementarse”.
Sin embargo, esta no es la única importancia que tiene crear sistemas testeables; las pruebas también orillan a construir clases pequeñas y con un único propósito, por lo que entre más se implementen en un sistema, más probabilidades hay de crear clases que cumplan con el principio de responsabilidad única (Single Responsibility Principle, SRP).
Una vez que se tienen todas las pruebas, se puede ser mucho más consciente de lo importante que es mantener el código limpio y justo aquí es donde comienza la etapa de refactorización. Durante este momento también es de suma importancia tener pruebas creadas, pues es lo que permitirá modificar el código sin miedo a romper alguna funcionalidad.
En esta fase es donde intervienen las siguientes 3 reglas de diseño sencillo.
Regla 2: No contiene duplicados
En el libro también se menciona que “los duplicados suponen un esfuerzo adicional, riesgos añadidos y una complejidad a mayores innecesaria”. Para evitar esto, hay que poner especial atención en las líneas de código parecidas, que pueden volverse lo suficientemente similares como para ser reutilizables.
Aunque sea al mínimo, reutilizar reduce significativamente la complejidad del código.
Regla 3: Expresa la intención del equipo de programación
Conforme los sistemas se vuelven más complejos, la tarea de entenderlos también se vuelve más difícil. Por esto es que el equipo de desarrollo requiere más tiempo para comprender el código, sin embargo existe el riesgo de no lograrlo y de caer en malos entendidos.
¿Cómo facilitar este entendimiento? Simple, haciendo un código más expresivo. Y algunas formas de conseguirlo son:
- Usar nombres apropiados y descriptivos.
- Mantener las funciones y clases pequeñas.
- Utilizar nomenclatura estándar.
- Crear pruebas correctamente descritas.
De hecho el autor dice: “la forma más importante de ser expresivo es la práctica. A menudo, conseguimos que el código funcione y pasamos al siguiente problema sin detenernos en facilitar la lectura del código para otros”.
En este sentido, el dedicarle unos minutos para modificarlo y volverlo más descriptivo le ahorrará tiempo a las personas que en un futuro trabajen con él.
Regla 4: Minimiza el número de clases y métodos
En un intento de hacer clases y métodos de tamaño reducido, se puede terminar creando demasiados. Por eso esta regla recuerda lo esencial que es intentar mantener la cantidad de clases y funciones al mínimo.
En resumen, este capítulo trató sobre cómo implementar el diseño sencillo para obtener código limpio: debe ser expresivo, reutilizable y reducido.
Capítulo 9: Pruebas unitarias
Desde que conocí las pruebas unitarias, construí una relación amor-odio con ellas. La verdad es que el proceso para hacerlas me parecía increíblemente fastidioso y estresante, sin embargo, siempre sentía una gran satisfacción al ver los números y letras en verde cada que pasaban todos los tests.
Por eso es que este capítulo se convirtió en uno de mis favoritos. En lo personal, desconocía mucho de lo que compartió Robert en estas páginas y al leerlo no solamente pude ver con otros ojos el proceso de creación de buenas pruebas unitarias, sino también darme cuenta de su importancia.
Algo de lo que se abordó en este capítulo fue👇
Las 3 leyes del desarrollo guiado por pruebas
El desarrollo guiado por pruebas (Test-Driven Development, TDD) propone que primero se creen pruebas unitarias antes que el código de producción. Pero esto es solo la superficie, para adentrarse al significado de esta norma es necesario considerar estas 3 leyes:
1.No se creará código de producción hasta tener una prueba unitaria que falle.
2.No se creará más de una prueba unitaria para fallar. No compilar es fallar.
3.No se creará más código de producción que el necesario para pasar la prueba de fallo actual.
Y algo a tener presente es que el código de producción y las pruebas unitarias se escriben en conjunto; las pruebas un poco antes que el código.
Pruebas limpias
Conforme el código cambia, las pruebas unitarias también. Por eso se dice que tener pruebas desordenadas dificulta esta tarea y el no contar con las adecuadas, impide hacer cambios en el código de producción con seguridad.
Para crear pruebas unitarias limpias es necesario asegurarse de que sean legibles. Como en todo el código, esto se logra con claridad, sencillez y densidad de expresión para que, quien lea la prueba, descifre lo que hace de manera rápida y sin muchas complicaciones.
Las pruebas y sus posibilidades
Como se mencionó en el capítulo 12 , las pruebas permiten modificar el código sin miedo a romperlo, algo que abre las puertas, entre muchas otras cosas, a mejorar su diseño y arquitectura cada vez que sea necesario.
El libro lo describe así: “las pruebas proporcionan las posibilidades, ya que permiten el cambio.”
El doble estándar
Aunque Robert sostiene que las pruebas unitarias son igual de importantes que el código de producción, también hace hincapié en que las pruebas no necesitan ser tan eficientes como este, pues se ejecutan en diferentes entornos (de prueba o de producción), cada uno con necesidades propias.
Lo que permite “el doble estándar” es hacer cosas que no se harían normalmente en un entorno de producción, pero que sí está bien realizar en uno de prueba. Y algo a tener presente es que esto nunca se referirá a la limpieza del código.
Un acierto por prueba o un concepto por prueba
Robert también argumenta que la regla de “un acierto por prueba” es una buena guía, sin embargo, no es obligatorio limitarse a ella. Lo recomendable es que el número de aciertos siempre sea el mínimo.
El autor explica que “puede que una regla más indicada sea probar un único concepto en cada función de prueba”. Esto quiere decir que testear diferentes conceptos en una misma prueba puede causar confusión al lector para determinar qué evalúa cada sección, por eso es necesario minimizar el número de aciertos por concepto y probar un concepto por función de prueba.
F. I. R. S. T.
Otro tema que se abordó en este capítulo fueron las 5 reglas para hacer pruebas que, por sus siglas en inglés, forman el acrónimo F.I.R.S.T. Estas deben ser:
1.Rápidas (Fast): deben ejecutarse rápido y con frecuencia.
2.Independientes (Independent): no deben depender entre ellas; una prueba no debería establecer las condiciones para la siguiente.
3. Repetibles (Repeatable): se pueden repetir en cualquier entorno; si esta regla no se cumple, siempre habrá una excusa para su fallo.
4.Validación automática (Self-Validating): deben resultar en un booleano, osea, o aciertan o fallan.
5.Oportunas (Timely): necesitan crearse en el momento oportuno, justo antes del código de producción que evalúan.
Siempre es bueno recordar la importancia del código limpio
Aunque este artículo representa solo un pequeño acercamiento al libro de “Código limpio”, espero que despierte tu curiosidad en este tema (si es que aún no lo has leído) o que te sirva para recordar información valiosa (si es que ya lo has consultado anteriormente).
Aunque ya reconozcas lo importante que es crear y mantener código limpio, no está de más que lo vuelvas a tener presente. Lo que hoy puede parecerte trabajo “extra”, más adelante podría ahorrarte muchísimo tiempo y esfuerzo.
Espero que este tema te ayude en tu trabajo diario. ¡Te deseo mucho éxito!
¿Quieres leer más temas relacionados? 👉Visita el blog de Nowports Tech👈
