Programación Clean Code
El Clean Code incrementa la productividad de la empresa hasta un 90 por ciento.
Según datos del portal de empleo InfoJobs en 2021 se publicaron 83.898 ofertas de empleo para programadores, un 25% más que el año anterior y colocándose en el perfil IT más demandado por las empresas. Entre los perfiles de programadores más valorados por las empresas se encuentran aquellos que además de conocer los principales lenguajes de programación programan código limpio, el motivo es que puede incrementar la productividad hasta en un 90% al reducir el tiempo y coste de los desarrollos.
En muchas ocasiones un programador se encuentra con un código que le cuesta entender, mantener, que genera errores, fricciones en los equipos, retrasos en las entregas... ¿Cómo puede evitar esa situación?, programando código limpio, aquel que es fácil de entender y mantener, que hace una única cosa y la hace bien.
Coincidiendo con el Día Mundial del Programador que celebra hoy 13 de septiembre, el equipo de desarrolladores de la tecnológica Paradigma Digital ha querido reunir y compartir en el ebook Clean Code la opinión de distintos expertos en desarrollo de software sobre la necesidad de programar código limpio y dar algunas recomendaciones sobre las mejores prácticas para obtener y mantener un código limpio entre las que destacan las siguientes:
• Código limpio y directo. "La lógica debe ser directa para evitar errores ocultos, las dependencias deben ser mínimas para facilitar el mantenimiento, el tratamiento de errores, completo y sujeto a una estrategia articulada, y el rendimiento debe ser óptimo para que no se tienda a estropear el código con optimizaciones sin sentido. El código limpio hace bien una cosa", según Bjarne Stroustup, inventor de C++
• Ley del Boy Scout. El 80% de las modificaciones de código se realizan durante el mantenimiento y por personas que no desarrollaron esa pieza, por lo que cobra gran importancia la mantenibilidad. Por eso, dejar el "campamento" más limpio que cómo lo hemos encontrado es esencial. De esta forma, cada vez que tengamos que hacer un nuevo desarrollo, intentaremos mejorar el código existente. Así, en cada iteración, el código va quedando mejor.
• Teoría de las ventanas rotas. Si en un edificio existe una ventana rota, lo más probable es que los vándalos vayan rompiendo más y más. Ocurre lo mismo con la basura en la calle: si no se va recogiendo, lo más seguro es que vaya apareciendo más. Si lo llevamos al mundo del código, nos encontramos módulos mal diseñados y difíciles de mantener que sabemos que existen y debemos eliminar lo antes posible. Quizás en el momento actual no podamos acometer la tarea, pero habría que añadirla al backlog y acometerla lo antes posible.
• Dedicar tiempo a pensar en el orden del código y su coherencia. Es importante dedicar tiempo a pensar el orden de nuestro código, y no solo a que funcione.
• Evitar desarrollos con mezcla de idiomas en el código. El idioma en el que desarrollamos el código y los comentarios que añadimos debe ser un acuerdo del equipo y además es conveniente utilizar un único idioma.
• No utilizar nomenclatura divertida o friki. Puede que queramos usar un nombre divertido incluso algo friki en el código, pero no suele ser muy eficiente para el mantenimiento o desarrollos posteriores, haciendo difícil de entender el código.
• Comentarios con sentido. Los comentarios sólo deben realizarse para aportar conocimiento en aquellos casos donde no hemos de expresarnos con el código. Los comentarios son notas técnicas y de diseño que merece la pena leer, y se deben mantener en el futuro.
• Funcionalidades concretas, claras y con una única responsabilidad. La clave para saber si una funcionalidad está bien escrita es responder a esta pregunta: ¿se puede entender la funcionalidad de un simple vistazo? Las funciones que no se utilizan (muertas) deben ser eliminadas, al igual que todo el código que se encuentre comentado, porque para eso tenemos los repositorios de código.
• La ley de Demeter. Siguiendo con las funcionalidades, hay que incidir en que dentro del código hay que minimizar el acoplamiento (lo que sabe una clase de otra). Para ello existe la ley de Demeter, que básicamente la podríamos resumir en que una clase habla con sus amigos y no con desconocidos.
• No repetir código. Cuando tengamos la sensación de estar haciendo lo mismo, merece la pena pararse y mirar si podemos hacer una librería, una funcionalidad genérica o cualquier técnica con la podamos reutilizar el código. Debemos estar comprometidos con el desarrollo y refactorizar cuando sea necesario, buscando una mayor mantenibilidad y claridad. Si no, estamos generando una ventana rota y habrá que hacer un doble esfuerzo en el futuro para mantener ese código.
En definitiva, se buscan desarrolladores de software sí, pero según los expertos parece que el mejor programador es aquel que desarrolla código limpio, un código sencillo, fácil de entender, de mantener, que hace una única cosa y la hace bien.
