Typefully

Clean Code

Avatar

Share

 • 

4 years ago

 • 

View on X

Mi opinión de 💩 sobre la discusión de Clean Code en forma de 🧻 👇
La primera cosa es que tengo la sensación de que se confunde clean code (código limpio o código inteligible) con el libro Clean Code (y toda su serie de Clean *) y como su autor resulta tan polémico, pues el lío está servido.
Porque entonces más que intentar analizar las ideas las miramos con el filtro de las sensaciones que nos produce el autor. Unamos eso a la tendencia bastante generalizada en el sector de intentar buscar recetas simples para todo.
Que sí, que tenemos que reconocer que buscamos recetas que se puedan aplicar sin pensar mucho. De eso se ve mucho con el paradigma del DDD, que tanta urticaria da leerse el libro azul.
En fin, a lo que íbamos, la idea de que el código debería ser inteligible por sí mismo no es monopolio del tío Bob. Otros muchos referentes del sector han defendido y defienden esto desde hace mucho tiempo.
Que Bob es uno de los más vocales, polémicos y todo lo demás, también es cierto. Miraos las charlas y los libros de Sandi Metz y veréis la misma idea. O la biblia de Feathers sobre Legacy que al final es la búsqueda de significado en el código.
Y Pragmatic Programmer, ídem de lienzo. Y es que el código es un lenguaje, un idioma, con el que expresar ideas y conocimientos. Y nos olvidamos de eso.
En cualquier caso, no se trata de una guerra santa de comentaristas vs no comentaristas. Yo soy más de los segundos y explicaré por qué.
Que nadie ha pedido nunca que desaparezcan o se prohiban los comentarios, sino que se usen con cabeza, como cualquier otra herramienta.
Del mismo modo que en código buscamos evitar la duplicación cuando podemos detectar un concepto general emergente, deberíamos evitar la duplicación entre código y comentarios.
Los comentarios son una segunda narrativa aplicada al código y siempre tenemos el riesgo de que esa doble narrativa diverja en algún momento (similar a que dos pedazos de código similares pueden divergir y meternos en un lio)
Así que deberíamos considerar los comentarios como algo que añadir cuando la ocasión lo merece y cuando la posibilidad de divergencia futura con el código sea la mínima posible.
Así, por lo general, los mejores comentarios son los que explican el por qué (no el qué o el cómo, que debería ser explicado por el código mismo)
Para lograr esto utilizamos recursos de todo tipo, como nombres largos y expresivos, o extracción de métodos para igualar los niveles de abstracción en cada bloque de código, ocultando los detalles.
¿Que os parece excesivo extraer métodos de una línea? Bueno, pues puede que sí o puede que no. Cada base de código es un mundo y también diría que no es buena idea juzgar ejemplos en blogs o libros como si fuesen las tablas de la ley.
Los ejemplos en blogs y libros suelen hacerse extremos para que se vea bien la idea que se pretende transmitir. Pero si vas a copiapegar el ejemplo para aplicarlo a tu problema sin entender la razón, pues mira, apechuga con las consecuencias, que no serán bonitas.
Eso sí, hacer el ejercicio de "extraer hasta que no puedas más", "No más de de cinco líneas por función", "sólo un nivel de indentación", por ejemplo, es sanísimo. Calistenia.
Es el equivalente para programadores de hacer sentadillas, planchas o isométricos, para la forma física. Es un modo de entrenar al cerebro para encontrar patrones y descubrir la simplicidad en un mar de líneas de código confusas.
Con ese entrenamiento de los básicos es con lo que vamos luego a enfrentarnos a los problemas de nuestros respectivos dominios. Pero no hay recetas, no hay atajos, hay que entrenar el cerebro y usarlo. Y decidir cosas y hacerse responsable de esas decisiones.
Y un código claro, en el que se pueda entender lo que pasa es clave para eso. Y si hay que complementarlo con comentarios útiles, pues también.
Por otro lado, hay muchísima vida más allá de Clean Code (el libro) y de los principios SOLID, que parece que el diseño de software se haya reducido a si SOLID sí y SOLID no. O que si lo que dice tío Bob va a misa o mejor hagamos lo contrario.
Avatar

Fran Iglesias

@talkingbit1

Testing, refactoring, patterns, software design. (he/him) Personal opinions. Rollos: typefully.com/talkingbit1. Mastodon: mastodon.online/@talkingbit