Todos hemos pasado por ahí: un proyecto que se vuelve un caos. Archivos enormes, funciones interminables, errores que aparecen de la nada. Eso no solo le pasa a los programadores: en cualquier equipo, cuando no hay orden, las cosas se vuelven lentas y frustrantes. Por ello hablaremos en esta publicación de los Principios SOLID y Clean Code.
En el mundo del software existe un concepto llamado “clean code” (código limpio). Y aunque suene muy técnico, la ideas es sencilla: mantener las cosas claras, simples y fáciles de entender. Un poco como tener un escritorio ordenado: sabes donde esta cada cosa y cualquiera puede encontrar lo que busca.
¿Qué es el clean code?
Imagen generada con Gemini
Clean code es aquel que cualquiera puede leer y entender sin tener que ser un genio. Se parece mucho a redactar un documento claro, con párrafos cortos, títulos bien puestos y sin repeticiones innecesarias.
Un famoso ingeniero de software, Robert C. Martin (conocido como Uncle Bob), lo resumió así:
“El código debe leerse como si estuviera escrito por alguien que se preocupa”.
Los principios SOLID
Para mantener un código limpio (clean code) hay una guía de cinco ideas simples que ayudan a lograrlo. Esta guía es la llamada Principios SOLID.
- S – Una sola responsabilidad (Single Responsibility)
Cada parte del código debe hacer un solo trabajo claro.
Imagina que tienes una función que guarda usuarios y envía correos, cuando algo falla, no sabes si el error está al guardar o al enviar. Mejor separa en dos funciones: una guarda, la otra envía, así si una falla, la otra sigue funcionando, así se aplica el principio Single Responsability
- O – Abierto a crecer, cerrado a romper (Open/Closed)
Deberías poder agregar nuevas funciones sin modificar las que ya existen.
Imagina que tu programa calcula precios, cada vez que agregas un nuevo producto, tienes que editar el mismo archivo una y otra vez. Eso aumenta el riesgo de romper algo y consume más memoria. Mejor creas otra función que permita agregar nuevos tipos de productos sin tocar el código viejo.
- L – Sustitución coherente (Liskov Substitution)
Si algo se comporta como otra cosa, debe funcionar igual sin causar errores.
Si cuentas con una función llamada: Vehículo que hace avanzar un objeto, y creas otra función llamada: Bicicleta que hereda la de vehículo, también debe poder avanzar sin errores, si no lo hace, entonces no debería heredar.
- I – Interfaces pequeñas (Interface Segregation)
Siempre piensa en pequeño; mejor varias herramientas simples que una gigante que confunda.
Piensa en una aplicación que obliga a todos los usuarios a usar funciones de “imprimir”, “escanear” y “fax”. Pero no todos necesitan eso.
Mejor divide las funciones en partes pequeñas y que cada una cumpla tareas específicas, así cada quien usa solo la que necesita.
- D – Flexibilidad ante todo (Dependency Inversion)
Tu código no debería depender de cosas “fijas”, sino de conceptos generales.
Si tienes una aplicación que envía mensajes, hoy lo hace solo por WhatsApp, pero mañana el cliente quiere usar otra aplicación de mensajería. Si tu código depende solo de WhatsApp, tendrás que cambiar todo, pero si haces que tu aplicación funcione desde un principio sin importar el tipo herramienta de mensajería, estarías aplicando este principio, y así puedes realizar cualquier cambio sin tocar el resto del sistema.
Otras buenas prácticas
Además de SOLID, hay algunas reglas simples que ayudan a mantener un clean code:
- No repitas código, crea funciones reutilizables.
- Mientras más simple mejor.
- No programes “por si acaso”: Planifica.
Quizá te pueda interesar
¿Por qué importa todo esto?
Imagen generada con Gemini
Escribir buen código no se trata solo de que funcione hoy, sino de que siga funcionando mañana. Aplicar estos principios SOLID y Clean Code significa menos errores, menos trabajo y más tiempo para crear cosas nuevas.
Sobre todo, significa que otros podrán entender lo que hiciste. Es una forma de trabajar con cuidado, respeto y orden, que hace que los proyectos crezcan sin caos.
La próxima vez que escribas un código, pregúntate: ¿Podría alguien más entender esto sin preguntarme nada?
Porque como dijo Martín Fowler…
“Cualquier tonto puede escribir código que una máquina entienda. Los buenos programadores escriben código que los humanos pueden entender”.
Si te gustó esta publicación compártela para que llegue a más personas a quienes les interesa temas relacionados con la programación. No olvides seguirnos en Facebook, Instagram y Linkedin, ahí encontrarás más contenido relevante.
Referencias: Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall. Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley Professional. Smith, S. (2020, May 10). The SOLID Principles Explained in Plain English. Ardalis. https://ardalis.com/solid-principles-explained Refactoring Guru. (s.f.). Principios SOLID: diseño orientado a objetos. Recuperado de https://refactoring.guru/es/design-patterns/solid McConnell, S. (2004). Code Complete: A Practical Handbook of Software Construction (2nd ed.). Microsoft Press.
