Si eres un desarrollador habrás escuchado esta frase varias veces, debemos hacer código limpio. Pero no les parece que un adjetivo como limpio, es subjetivo?
Es obvio (y si no es obvio para ti probablemente no te ha tocado leer código malo, feo, espaguethi o como le quieran llamar) que se necesita crear, editar actualizar código que sea legible y que sea fácil de entender.
Todos estamos en contra de las variables llamadas a, b, cdpTraxddo peor. De métodos o funciones que tienen a cientos de lineas, entrelazadas, mal nombradas, con código duplicado.
Un proyecto grande llegara al punto de: mejor gastar recursos y tiempo en iniciar desde cero que arreglar lo malo. Es un problema tan real como que los cerdos no vuelan. Y las repercusiones de estos problemas son enormes, imagina decirle al cliente todo tu dinero y tiempo invertido en este proyecto inservible fue desperdiciado, no podemos salvar tu inversión o tu negocio. Imagina ese momento en el que le das la noticia a alguien a quien le has cobrado miles de dólares, al que le prometiste ese software que resolvería todos sus problemas, que sería escalable, que le daría retorno de inversión, que resolvería la paz mundial, y pues, … ya no sirve, mejor deséchelo.
La importancia de esto no es cuestionable, es algo necesario y que todos los desarrolladores deberíamos saberlo como base. Si bien es cierto que no hay una regla absoluta de que es el código limpio, todos sabemos lo que es mal código. Los siguientes consejos los doy de mi lectura del libro Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin).
- Ley de LeBlacn: Despues es igual a nunca. Cualquier cosa que pienses «luego lo hago» se traduce a que nunca lo haras. Surgiran nuevos bugs, te asignaran nuevas cosas, y tu deuda tecnica ira aumentando. Haz algo al respecto.
- La lógica debe ser directa.
- El código debe ser especifico y no especulativo.
- Preocuparse por la legibilidad, prestar atención a los detalles.
- No tener duplicados, cuando algo se repite es una señal que tenemos una idea que no terminamos de representar correctamente.
- Que el método o objecto no haga mas de una cosa. Similar la S de los principios SOLID. Cada elemento tiene una y solo responsibilidad.
- El código debe ser evidente, sencillo y atractivo, que cuente una historia, de principio a fin.
- Ley del boy scout: dejar el campamento mas limpio de lo que se ha encontrado.
- Cuando se ve código malo, no es necesario refactorar todo, empieza por cambios pequeños, cambiar de nombre a una variable, separar un método en otros métodos mas especificos.
Con esto terminaría la parte 1 de una serie de post hablando sobre este tema.
¿Cuál crees que es la importancia del código limpio? Déjame tu opinión abajo.
Geek de la tecnología, en busca de la mejora y aprendizaje continuo.
Ingeniero en ciencias de la computación, Postgrado en Análisis y predicción de datos
