Hoy en día es muy difícil encontrar a un programador que no conozca estos términos, pero para nosotros es vital crear un código fácil de mantener y poder ampliarlo con el tiempo. En el mundo en el que vivimos, un proyecto se trabaja en equipo (no importa dónde vivas, la cultura ni el idioma), pero además un proyecto está en continuo crecimiento y evolución. Es por ello por lo que un código debe ser limpio y claro, manteniendo una estructura ordenada, para no perder tiempo «intentando entenderlo».

 

A principios del 2000,  Robert C. Martin (más conocido como Uncle Bob) propuso seguir una serie de guías y buenas prácticas a la hora de escribir código, centrándose en la base de los niveles (formato, estilo, nomenclaturas, convenciones, etc. ). Creando el principio SOLID, este acrónimo tiene el siguiente significado:

 

  • S: ​Single Responsibility Principle (SRP)
    Principio de responsabilidad única, la noción de que un objeto solo debería tener una única responsabilidad.
  • O: ​Open/Closed Principle (OCP)
    la noción de que las “entidades de software … deben estar abiertas para su extensión, pero cerradas para su modificación.
  • L: ​Liskov Substitution Principle (LSP)
    la noción de que los “objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa”. Ver también diseño por contrato.
  • I: ​Interface Segregation Principle (ISP)
    la noción de que “muchas interfaces cliente específicas son mejores que una interfaz de propósito general”
  • D: ​Dependency Inversion Principle (DIP)
    la noción de que se debe “depender de abstracciones, no depender de implementaciones”.  La Inyección de Dependencias es uno de los métodos que siguen este principio.

Sabemos que a veces es complicado seguir al pie de la letra todos los principios (en la mayoría de los casos tendemos a acomodarnos y «olvidarnos» de seguir estas recomendaciones y estándares que nos hacen más fácil la lectura y comprensión del código, tanto desde fuera como para nosotros mismos.

 

Trabajar con un código limpio, bien estructurado y siguiendo los estándares de programación, es lo que puede marcar la diferencia entre vivir un proyecto, o en su defecto… odiarlo para siempre.

 

La calidad del código debe primar por encima de la cantidad. Programar pensando en el entorno y en el equipo que lo va a rodear, o incluso a nivel personal… Si eres programador para un segundo y piensa en ti mismo, si no has desarrollado el código con unas pautas de creación… puede que cuando hayan pasado dos semanas, lo que has escrito no lo entienda ni el mismo creador.Si estás trabajando en varios proyectos, utiliza la regla de la señora de la limpieza: Si estás tocando código, ya sea nuevo o refactorizado, contribuye a la causa y déjalo un poco más limpio de lo que la encontraste.

Un programador es aquel que es capaz de crear un código que podría pasar cualquier tipo de inspección. Lo importante es mejorar tu práctica en la programación hasta llegar a ser un artesano del software.

 

Si te interesa el tema, puedes encontrar la información al completo en el libro Clean Code, que tiene 3 partes diferenciadas.

  • Capítulos del 1 al 13: Explicación de buenas prácticas de código limpio, qué hay que hacer para obtenerlo.
  • Capítulos del 14 al 16: Ejemplos de situaciones reales en las que aplicar en la teoría
  • Capítulo 17: Recopilación de síntomas y heurísticas para detectar código no limpio, donde se repite gran parte del contenido de la teoría