Thread by @d4nidev

Abro paraguas ☂️

Clean Code es un libro obsoleto que en 2020, con los paradigmas de desarrollo de software que manejamos, puede hacerte más daño que beneficio.

Voy a elaborar, para que quede claro mi punto de vista y que no es simple trolling.

Para empezar, creo que es un libro excesivamente dogmático en sus principios. Sólo hay una forma correcta de escribir y evolucionar código. No habla de contextos, situaciones ni excepciones.

Me he encontrado muchas veces en momentos en los que he hecho una implementación"poco ortodoxa" y por querer hacerla más "limpia" incrementar su complejidad, líneas de código, archivos e indirección.

Capítulos donde habla de single responsibility, funciones que solo deben hacer una cosa o número de líneas de un archivo o función como Code smells, pueden llevarte a hacer código más limpio según el dogma, pero menos simple en la práctica.

Cuando habla de comentarios en el código, por ejemplo, vuelve a hacer trampas: "los comentarios siempre mienten". Y argumenta que si cambias el código pero no el comentario, éste quedará obsoleto.

Vale.

Y si no?

He estado en empresas donde talibanes del clean code me han discutido más un comentario que una implementación. Una vez más, el dogma. No tiene nada de malo un comentario, si aclara la implementación o el uso y te ahorra un nombre absurdamente largo.

Es más: hay herramientas hoy en día que se basan en los comentarios para generar documentación o intelligence (Typescript).

Pero el código debería "auto-documentarse". Ser "auto-descriptivo". Los tests deberían ayudarte a eso.

Eso me lleva a otro punto: los test.

El capítulo de unit testing, el que en mi opinión debería ser el más completo y extenso del libro, ya que los tests son los que te llevan a escribir código limpio según sus principios... Es de los más cortos.

Tan solo recoge algunas reglas básicas, pero no qué testear (y qué no) y por qué un unit test ayuda a que el código sea simple y fácil de cambiar. Que es el objetivo.

Prácticas como evitar código duplicado, recomendadas en algún punto del libro, pueden llevar a complejidad y abstracciones innecesarias. Lo mismo ocurre con técnicas como Inversión de Control o Inyección de Dependencias. Cómo encaja esto en un ecosistema de en módulos como ES6?

Este artículo de @dan_abramov, que en su día me pareció inoportuno precisamente porque en el Front End es donde peores prácticas de programación he visto; tiene muchos puntos interesantes al respecto.

overreacted.io/goodbye-clean-…

Hablando en general, los ejemplos del libro han quedado desfasados. Creo que es "demasiado" orientado a objetos y hoy en día es difícil aplicar esos ejemplos a código escrito en los lenguajes que manejamos.

En este sentido, aprecio el esfuerzo que hizo @martinfowler al reescribir su Refactoring con ejemplos en #Javascript, un libro mucho más práctico y actual, que si recomiendo, por cierto.

Otros autores como @mfeathers (Working effectively with legacy code) ya han adaptado al menos su discurso en sus últimas charlas y workshops para proponer soluciones a los paradigmas de programación que utilizamos.

Creo que Clean Code tiene muchos puntos positivos, pero necesita una revisión al nivel de la que ha tenido Refactoring. Menos dogmática y más pragmática. Explicando que la abstracción llega de forma natural y no forzada. Que las reglas no son reglas, sino recomendaciones.