author
José Mª # Senior Developer 5 min.

Clean Code

¿Qué es el Clean Code?

Vamos allá, compañeros/as... La realidad es esta:

Un código mal organizado, o mal escrito, no tarda en dar más problemas que soluciones.

Cuando un desarrollador o desarrolladora comienza su formación suele recibir indicaciones estrictas sobre estructura, nomenclatura, abstracción. Pero como en cualquier profesión, las prisas y la falta de control derivan en hábitos y prácticas que empeoran la calidad del código resultando en el temido código espagueti. Hacerlo tal cual las normas aprendidas conlleva esfuerzo y cuesta menos tiempo escribir código sucio. Tiempo que se puede rentabilizar invirtiendo en otras tareas para otros clientes. Aparecen altos niveles de productividad, efectivamente, pero solo durante un tiempo.

Los proyectos de software, ya comiencen como pequeños microservicios o como grandes plataformas, están en contínuo crecimiento y adaptación. Constantemente surgen nuevas necesidades que obligan a un mantenimiento, reestructuración o cambio del código.

Clean Code

Trabajar sobre un código limpio, siguiendo las normas establecidas por la comunidad y el propio equipo de desarrollo, facilita el trabajo a los desarrolladores, el análisis de nuevas casuísticas a los analistas, el testeo y la puesta en producción a los técnicos de sistemas, la evaluación de tiempos y riesgos a la dirección y sobre todo, lo más importante, resulta en un mejor servicio y satisfacción del cliente.

A medio plazo no existe otra opción. Reescribir el código a mejor es una ayuda para nuestro futuro. Siendo el tiempo limitado ¿Queremos invertirlo en programar o en investigar qué es lo que hace exactamente un script de hace dos meses escrito por alguien que ya no pertenece a la compañía?

Clean code parece una opción pero ¿por dónde empezar?

La concienciación por hacer un trabajo más profesional es más importante que cualquier conjunto de normas. El código limpio sólo es real cuando el equipo es consciente de que un pequeño esfuerzo a tiempo evita un esfuerzo mayor en el futuro.

Un buen comienzo es seguir los PSR en el caso de PHP, y adaptar guías de estilo ( para API´s, para Sass/Less) al estilo de programación en base a la comunidad y el equipo. La parte del equipo es importante. En programación siempre hay tareas y formatos que pueden afrontarse de diferentes maneras, y la manera en la que el equipo se sienta más a gusto debe tenerse en cuenta.

Más que centrarse en normas centrémonos en nosotros.

Por supuesto, y más tratándose de este sector, se trata de automatizar todo lo posible la revisión de la calidad del código. Disponemos de numerosas herramientas que nos ayudan. Hoy en día basta una búsqueda de “Lint” en Github para encontrar librerías que ayudan a dar formato a nuestro código sea cual sea el lenguaje en que desarrollamos. Incluso es posible configurar nuestro IDE con plugins detectores de smells (Swiftlint, SonarLint, PhpClean) que no sólo nos ayudan con el formato sino que detectan partes de código que son, como poco mejorables, y que deberíamos refactorizar.

Con Gitlab CI/CD se puede evitar que se suban al repositorio archivos que no cumplan los estándares, incluso que el código sucio no se publique en el servidor. Todo automáticamente. Estas metodologías permiten localizar errores en el código durante el ciclo de desarrollo y publicación, asegurando que todo el código cumple los requisitos y estándares que se hayan especificado.

¿Un código limpio es suficiente?

Aunque no hablamos necesariamente de una metodología TDD (Test driven development), los test son parte fundamental del código limpio. Testear un alto porcentaje de nuestro código lo hace más adaptable a cambios. Un código limpio puede testearse fácilmente y una buena batería de test obligan a mantener limpio cualquier desarrollo.

Aunque en PHP, PhpUnit sigue siendo base de muchos desarrollos hoy en día existen varias alternativas recomendables, por ejemplo Codeception 4 dispone de test unitarios, funcionales, de aceptación e incluso test para APIs.

Con Gitlab CI/CD se permite la ejecución de estos test antes del despliegue. Postman permite la creación de runners para probar los endpoints de nuestras APIs y la monitorización de nuestros proyectos ejecutando los test cada poco e informando del resultado en vivo.

Sin tests, cada cambio es un posible error. No importa cuán flexible sea tu arquitectura, no importa cuán bien particionado su diseño, sin test, seremos reacios a hacer cambios debido al temor de introducir errores no detectados. - Robert C. Martin

Code Testing


eu