No existe eso llamado Clean Code
(steveonstuff.com)- La gente se esfuerza por lograr código "limpio", pero "limpio" no es una medida útil
- El código no puede ser simplemente "limpio". Eso se debe a que "limpio" no explica nada sobre el código
- Cuando la gente dice que un código es limpio, por lo general es porque el código es excelente de alguna manera
¿El código limpio realmente es buen código?
-
El código puede ser excelente por muchas razones
→ fácil de leer, fácil de entender, simple, con buen rendimiento, seguro, elegante, testeable, encapsulado, extensible, mantenible, reutilizable... -
Pero estas características, en cierto sentido, entran en conflicto entre sí
→ El código más simple probablemente no sea el más fácil de testear
→ Las interfaces y las dependencias inyectadas facilitan las pruebas, pero están lejos de la simplicidad
→ Si se usan muchos singletons, puede ser fácil de entender, pero quizá no sea una aplicación mantenible -
Algunas de estas cosas son, en esencia, opuestas, así que puede ser difícil cumplirlas todas al mismo tiempo
→ Como la ingeniería es trade-off, también podría ser posible debatir en el equipo cuáles son los compromisos adecuados aquí
Si el código es excelente, tenemos que hablar de "por qué" lo es
- Cuando alguien dice que una solución es "limpia", no está justificando racionalmente la razón; solo dice que es una mejor elección
- Para tener una discusión constructiva sobre una solución técnica, hay que poder explicar con claridad por qué una solución es mejor que otra
→ En lugar de decir solo "es limpio", decir "está desacoplado, es fácil de entender, es bueno para testear..."
Hay que usar términos precisos
- Programar suele ser un deporte de equipo. Cuando hackeas tú solo puedes hacer lo que quieras, pero cuando trabajas con un equipo tienes que discutir ideas
- Usar un lenguaje específico para debatir soluciones técnicas y que todo el equipo tenga una comprensión compartida es muy importante para entendernos
- La expresión "clean code" significa algo distinto para cada persona
→ Para alguien puede significar que la arquitectura está bien definida; para otra persona, que el código está escrito de forma simple con un estilo de formato consistente... - Palabras como "encapsulado", "testeable" y "reutilizable" tienen significados en los que todos podemos coincidir
- Cuando usamos palabras más específicas para describir las características del código, podemos estar seguros de que estamos en la misma página
- "Limpio" tiene un nivel de precisión parecido al de "bueno"
Entonces, ¿qué es "clean code"?
-
Llegué a la conclusión de que, cuando describo un código como "limpio", muchas veces en realidad quiero decir: "el código es bueno, pero no puedo estar completamente seguro de por qué"
→ O que conozco las razones por las que el código es bueno, pero no encuentro una palabra que lo exprese con claridad -
Está bien desarrollar esa intuición, pero no hay que quedarse ahí. Hay que profundizar más e intentar entender "por qué este código es bueno"
→ ¿Este código tiene alguna característica que otros no tienen? ¿Y esa característica es la que mejor se adapta a nuestro proyecto? Tal vez esa no sea la solución correcta -
Ojalá podamos estar seguros de que no necesitamos código limpio, sino código ______
6 comentarios
Muchas gracias por el buen artículo ~~
No existe tal cosa como el Clean Code
No patees el código legado a la ligera
¿A quién le has cumplido хотя бы una vez el primer requirement?
Estoy de acuerdo.
Parece que, en "ese libro", el código limpio del que hablaba el autor estaba enfocado, entre estas cosas, en que fuera "fácil de entender" y "testeable". Por supuesto, creo que ambas son métricas muy importantes. Pero a veces, por especificaciones que aún no están formalizadas o bibliotecas que no están terminadas, no queda otra que usar lo que suele llamarse un "hack", y en ese sentido parece inevitable ceder en la calidad del código para mantener la calidad del programa.
Coincido. Si entendemos “limpio” como “de alta calidad”, entonces (como dijo Weinberg) la calidad es algo valioso para alguien, así que creo que dentro del equipo es necesario tener criterios y una definición de lo que significa calidad.
Este es un texto que propone dejar de hablar de manera ambigua sobre "código limpio" y, en cambio, decir con precisión a qué nos referimos.
Sobre esto, también en Hacker News hay varios comentarios sobre cómo interpretar "código limpio". Vale la pena leer también los comentarios.
There’s No Such Thing as Clean Code https://news.ycombinator.com/item?id=30111516
Aunque el tema es un poco distinto, también pueden consultar el siguiente texto que se publicó antes.