El Código Limpio (Clean Code) de Robert C. Martin (también conocido como Uncle Bob) es uno de los libros que todo programador debe leer en algún momento de su vida, ya seas Junior o Senior, sea la primera vez que te lo lees o la vigésima vez, siempre encuentras algún consejo que puedes aplicar.
Robert C. Martin es un ingeniero de software y autor de Estados Unidos 🇺🇸 que además de esta joya para la lectura de un programador ha creado otros libros entre los que se encuentra Arquitectura Limpia o El Limpiador de Código y hoy nos vamos a centrar en Clean Code, desde luego, el libro que le ha dado más reconocimiento a nivel mundial.
Si quieres obtener el libro de Uncle Bob te dejo aquí el enlace de afiliado para que lo puedas adquirir en Amazon.
Clean Code por Robert C. Martin
Programar para quien este empezando puede ser un mundo de caos, entre los numerosos lenguajes, y que luego los humanos somos cada uno de nuestro padre y nuestra madre, por no decir que somos lo más raros que existe y si algo lo podemos hacer de la forma más rápida y mal... ¡lo hacemos! Entonces Uncle Bob, en este libro nos propone seguir unas guías y una serie de buenas prácticas para que el mundo del código no sea un caos, más de lo que ya es.
Un claro ejemplo de lo que este libro quiere conseguir es la siguiente imágen:
Resumen de lo que consigue un Código Limpio y organizado.
En lugar de decir "Este código es una mierda" numerosas veces y de distintas formas, Uncle Bob propone ser ordenados y escribir código cuando sea necesario y que sean concisos.
Código Limpio esta compuesto por 17 enriquecedores capitulos, y te voy a comentar algunas de las perlas que nos deja Uncle Bob en esos capítulos.
La regla del Boy Scout
La regla del Boy Scout tiene mucho sentido, y se puede extrapolar a muchos ámbitos en la vida. Esta regla según el libro es que los boy scout intentan dejar los lugares por los que van un poco mejor de cómo se lo han encontrado. Es decir, hablando de desarrollo, hay que dejar el código que vemos y tocamos un poco mejor de cómo nos lo hemos encontrado.
Por ejemplo, si vas a desarrollar un mantenimiento o tocar algo que ha hecho un compañero y vemos algo que se pueda mejorar, lo ideal, sería dedicar un poco de tiempo para mejorar ese bloque de código y comentarselo al equipo para que poco a poco el código este mejor y no acumulemos lo que se llama la "Deuda Técnica".
La deuda técnica es el coste de mantener y/o arreglar un software mal construido, normalmente por hacerlo rápido o sin atención.
Las Funciones y Métodos
Las funciones y métodos son bloques de código que realizan una determinada función en el código, y Robert lo que comenta en el libro es que estos bloques tendrían que:
Ser de unas 20 líneas aproximadamente.
Tener un nombre descriptivo:
getAllBooksFromAuthorId()El nombre no importa si es corto o largo, de hecho cuanto más largo puede ser más descriptivo.
El Principio de Responsabilidad Única
Recomendable hasta 2 parámetros, 3 ya son demasiados.
Principio de Responsabilidad Única
Respecto a los métodos y funciones, la prioridad que, como desarrolladores, hay que alcanzar es el de la Responsabilidad Única, esto quiere decir que una función tiene que hacer una única cosa, lo que el nombre de esta indique.
Con el principio de Responsabilidad Única conseguimos no llevarnos sorpresas de que un método haga más cosas de las que el nombre indica. Por ejemplo:
class Jedi {
constructor(name, power, lightsiberColor) {
this.name = name;
this.power = power;
this.lightsiberColor = lightsiberColor;
}
getName() {
return this.name;
}
getPower() {
return this.power;
}
getLightsiberColor() {
return this.lightsiberColor;
}
setName(newName) {
this.name = newName;
}
setPower(newPower) {
this.power = newPower;
}
setLightsiberColor(newLightsaberColor) {
this.lightsiberColor = newLightsaberColor;
}
}
En este ejemplo, todas las variables y funciones son exclusivamente de la clase Jedi y no mezclamos otras posibles clases en ella.
Comentarios
Otra cosa importante son los comentarios, aunque se nos dice en el libro que un buen código habla por sí mismo, un mismo código puede pasar por las manos de infinidad de programadores, hay de todo. Puede que un proyecto lo toquen siempre las mismas 4 o 5 personas, o que un proyecto que sea de más larga duración pasen por él unas 10 personas al año por que tenga mucha rotación.
Esto quiere decir que si un bloque de código, una función o método están comentados le dará al programador un contexto de qué es lo que hace ese bloque y una facilidad, por eso es muy importante escribir buenos comentarios y por ejemplo en el caso de JS podemos añadir un comentario que sirva como la documentación de este, se llama JSDoc, del cual hablaremos en otro post.
const folder = './folder1/'
const filename = 'file.txt'
// Juntamos la variable folder y filename para obtener la ruta completa
const path = path.join(folder, filename);
console.log(path);
// Output: './folder1/file.txt'
Este ejemplo es my sencillo, rozando lo innecesario, pero estos comentarios son útiles cuando hay un bloque de código complejo y le tienes que explicar al próximo desarrollador que toque ese código (que puedes ser tu mismo en unos meses) qué es lo que hace.
Conclusión. ¿Por qué leer Clean Code?
Como te he comentado al principio del post, el libro de Clean Code es muy extenso, y da muchas reglas o guías como para explicarlas detalladamente en un post.
Pero estas pueden ser de las cosas que menciona Uncle Bob con las que un programador junior se puede pegar al principio de su carrera laboral. Porque cuando entramos en una empresa, siempre nos tenemos que acostumbrar al estandar que tenga esa empresa, los formateadores de código (que a veces son personalizados), algunos procesos o formas de hacer las cosas en la Arquitectura del Software, que desde la experiencia de un junior hay conceptos que pueden escaparse un poco.
Y no te sientas mal por que a lo mejor en las primeras revisiones de código (Merge Request o Pull Request) te digan que le tienes que cambiar el nombre a alguna variable para que sea más descriptiva, o que te falta algún comentario... Las revisiones de código son tanto para Juniors, Mid´s o Seniors, a todos se nos puede escapar algo o que a ojos del resto del equipo no esté claro.