Clean Code — Aprendiendo a construir código limpio

Como desarrolladores, cada día estamos inmersos en proyectos que nacen, o están en ejecución y necesitan mejoras. Esto desde el punto de vista ideal, serán implementaciones libres de errores, pero la realidad es otra, la realidad es que muchos desarrolladores están inmersos a diario en procesos de detección de errores y sus correcciones.

Ahora bien, como mejorar ello?

Cuando desarrollamos es de suma importancia que sigamos algunas pautas, más allá del conocimiento de las herramientas, la metodología con que desarrollemos, que sigamos ciertas reglas.

En ese sentido buscando ofrecer una posible solución al problema planteado anteriormente, Robert C. Martin o también conocido popularmente como “Uncle Bob”, escribió un libro llamado Clean Code.

Dentro del desarrollo de software ágil, muchos desarrolladores consideran Clean Code como un libro de cabecera, donde puede encontrar formas de escribir un buen código, cómo mejorar cualquier código hasta lograr que sea bueno, y muchas otras cosas esenciales, como pruebas unitarias, manejo de errores y muchos otros puntos importantes para el día a día de cualquier desarrollador de software.

Clean Code se ha convertido en una filosofía de desarrollo cuyo principal objetivo es aplicar técnicas sencillas que pretenden facilitar la escritura y lectura de código. Su perspectiva principal es que los detalles importan.

Cualquiera puede escribir código que una computadora entienda. Los buenos programadores escriben código que los humanos entienden. — Martín Fowler

¿Y qué es clean code?

Como podrás pensar, el concepto de “clean code” es amplio y que muchos expertos tienen sus propias definiciones e incluso discrepan entre sí.

Uncle Bob en su libro cita a Grady Booch, un científico jefe de ingeniería de software de IBM Research, por considerar que:

“El código limpio es simple y sencillo. Un código limpio se lee como una prosa bien escrita. El código limpio nunca oscurece la intención del diseñador, sino que se completa con abstracciones nítidas y líneas de control sencillas”.

Por su parte, Michael Feathers, autor de Working Effectively with Legacy Code, considera a la palabra “cuidado” como elemento central del código limpio.

¿Por qué es importante escribir un clean code?

Hay que entender que cuando se produce un software, quien hará uso de él es un ente cambiante, por lo tanto el software también sufrirá cambios. Los requisitos del negocio cambian, las necesidades de los usuarios también y eventualmente el código que escribiste tendrá que evolucionar. Esto incluso sucede durante el desarrollo inicial del proyecto.

Esto se debe a que un software o sistema nunca está completamente terminado, sino que siempre sufrirá actualizaciones y recibirá nuevas características, lo que hace que sea importante que esté lo más limpio posible.

Así que, muy probablemente otras personas en algún momento deberán leer tu código, entenderlo, cambiarlo o incluso arreglarlo. Un código limpio presupone la escritura de un código de legible y entendible, lo que lleva a una buena capacidad de mantenimiento. Siguiendo el libro de Uncle Bob (en traducción libre):

“Si has sido programador durante más de dos o tres años, probablemente te hayas visto frenado por un código desordenado. El grado de ralentización puede ser importante. […] Con el tiempo, el desorden se vuelve tan grande, profundo y ruidoso, que no se puede limpiar”.

La frase anterior nos lleva a incluso al punto en que a veces se llega a hacer nuevamente todo el software de cero, siendo más económico esto que intentar hacer uso y mantenimiento del que código que se tiene.

¿Cuales características debe tener un código para ser considerado “Código Limpio”?

• Simple y sencillo: siguiendo el principio de KISS (Keep It Simple Stupid), un código bien escrito debe tener la menor complejidad posible para que pueda ser fácilmente depurado y comprendido.
• Evita duplicidad: Este principio puede ser traducido como “no te repitas a ti mismo”. Una expresión, que fue descrita por primera vez en un libro llamado The Pragmatic Programmer y se aplica a áreas de desarrollo, como: Banco de datos, pruebas, documentación, código. DRY defiende que cada parte del conocimiento de un sistema debe tener representación única y ser totalmente libre de ambigüedades. En otras palabras, define que no pueden existir dos partes del programa que realicen la misma función.
• Atención a los nombres: el nombre es esencial para el código. Debe ser directo y representar bien lo que significa, aunque sea un nombre largo.
• Funciones pequeñas: Una regla primordial es que las funciones siempre deben ser lo más pequeñas posibles y tener una única responsabilidad, con el fin de facilitar su comprensión y evitar que sean más propensas a los cambios.

“La primera regla de las funciones es que tienen que ser pequeñas. La segunda regla de las funciones es que tienen que ser aún más pequeñas”. Roberto C. Martín

• Comentar solamente lo necesario: Este principio afirma que los comentarios pueden hacerse; sin embargo, estos deben ser necesarios. Según Uncle Bob, los comentarios mienten; y esto tiene una explicación lógica. Lo que ocurre es que, mientras los códigos son modificados, los comentarios no. Estos son olvidados, y por lo tanto, no retratan la funcionalidad real de los códigos. Entonces, ya sabes; si vas a comentar el código, que sea solamente lo necesario y que sea revisado en conjunto con la versión del código que lo acompaña.
• Tratamiento de errores: los programadores son los responsables por garantizar que el código continúe realizando lo que necesita, aún cuando existan comportamientos no esperados. Es decir, tratar las excepciones de forma correcta es un gran paso para el programador en desarrollo.
• Se debe probar todo lo que pueda fallar: Un código limpio debe ser susceptible a pruebas, debe lograr pasar cada una de ellas, estas pruebas deben ser sencillas pero deben abarcar una gran cantidad de escenarios.

Clean code: pruebas de programación

Frente a estas reglas, siempre es importante recordar que el código que se escribe probablemente pasará por mantenimiento y refactorización. El código sólo se considerará limpio si pasa las pruebas.

Por lo tanto, al producir un software, hay que asegurarse de que cada línea del código esté validada para que siga funcionando.

Es interesante utilizar la metodología de Desarrollo Dirigido por Pruebas (TDD) y realizar pruebas de Integridad, Instalación, Configuración, Usabilidad, Seguridad, Integración y otras.

Si te ha gustado este contenido, te comparto el link de mi canal en YouTube, donde podrás acceder a material sobre Javascript, React y Bases de datos SQL, tal como: