El costo de escribir un mal código es altísimo porque interrumpe el desarrollo y complica el mantenimiento haciendo incluso que en algunos casos se abandone el proyecto. La idea es minimizar este problema y de hecho tratar de evitarlo al máximo. Nuestro objetivo debe ser poder escribir un código principalmente testeable, preparado para ser mantenido, tolerante a cambios y más legible.

SOLID es un acrónimo que brinda la orientación ideal para escribir correctamente nuestros proyectos, nos ayuda muchísimo cuando trabajamos con programación orientada a objetos. La intención es seguir estás técnicas y principios para programar con buenos diseños y alcanzar un código eficiente y fácil de mantener.

• S: Single Responsability Principle (SRP)
• O: Open/Closed Principle (OCP)
• L: Liskov Substitution Principle (LSP)
• I: Interface Segretation Principle (ISP)
• D: Dependency Inversion Principle (DIP)

Es importante conocer cómo debemos escribir un software, pero para aprender mejor el concepto debemos contrastarlo con el cómo no debemos programar. Sabemos por ejemplo que está mal duplicar el código, no escribir pruebas, escribir nombre pocos descriptivos y otras malas prácticas que a continuación voy a describir en esta publicación.

SOLID sería la buena base al momento de proponer una arquitectura de software sólida.

Veamos aquí los diferentes conceptos que debemos tener en cuenta antes de comprender a SOLID. A continuación lo que debemos conocer y evitar.

youtube

Duplicar el código

Seguramente has leído o escuchado el principio DRY (don't repeat yourself) que significa no te repitas. La idea es tener presente como norma u obligación no duplicar el código, en otras palabras, evitar al máximo el copiar y pegar.

Cuando duplicas un código y este requiere algún cambio en el futuro debes reproducir dicho cambio de manera manual en todas las partes del proyecto donde se encuentre dicho código, es un circulo, cada vez que haces alguna actualización debes volver a copiar y pegar, incrementando así la probabilidad de que se produzca algún error.

Esto puedes hacerlo de manera eventual, accidental o con intención, solo recuerda que cuando lo haces es el usuario quien se comunicará contigo para indicar los errores que se presenten, este es quien termina descubriendo que se te ha olvidado actualizar algún bloque de código en alguna parte.

Dicho de otra manera, el consejo es escribir el código una vez y sólo una vez básicamente porque buscamos evitar la dificultad de mantenimiento y facilitar la evolución del proyecto.

Code smell

Esto significa "mal olor en el código", quiere decir que las cosas no están bien y como puedes imaginar este tema está relacionado con la deuda técnica. Significa que hay señales claras de que debemos refactorizar debido a que no hemos planeado correctamente el código.

Piensa en ello como en una serie de síntomas que indican con claridad que vamos por mal camino y puede traer grandes problemas en el futuro.

1. Deficiencias de diseño.
2. Código duplicado.
3. Grander métodos.
4. Clases con muchas dependencias.

No tiene porque ser un error claro, esto quiere decir que el código puede funcionar correctamente pero entendemos que las cosas podrían estar mejor y debemos mejorarlo.

Nombres poco descriptivos

Ya sabemos que esto es una mala práctica, todo debe ser claramente leído, con significado y descriptivo. Las clases, métodos, variables y todo en cuando al código debe nombrarse con cuidado porque lo volveremos a leer al momento de dar mantenimiento.

Recuerda que código limpio es el que se escribe con la intención de que otra persona lo entienda y pueda darle mantenimiento, evolucionarlo o alterarlo.

Acoplamiento

Aquí buscamos evitar la relación exacta entre nuestras clases porque esto dificulta el hecho de dar mantenimiento (el riesgo de que algo se dañe cuando hacemos algún cambio es alto), lo ideal entonces es alcanzar un bajo acoplamiento.

El acoplamiento hace referencia precisamente a la relación que existen entre módulos y dependencia entre ellos. Si existe mucha dependencia entonces tendremos un alto acoplamiento y debemos apuntar a la autonomía para alcanzar el bajo acoplamiento, el resultado será responsabilidades claras y definidas, módulos pequeños y con independencia.

Este término se suele relacionar con la cohesión, de hecho es común mencionar que debemos obtener el bajo acoplamiento y la alta cohesión.

Alta cohesión significa que un elemento o clase realiza únicamente la tarea para la cual fue programada, es básicamente mantener una única responsabilidad y significado, ademas de contar con una clara independencia.

Código no testeable

No creamos pruebas por no saber hacerlo o porque tenemos un alto acoplamiento, el nivel de dependencia es tan alto que nos complica el proceso de crear pruebas. Es un indicador importante y debemos detectarlo a tiempo.

Para evitar este problema debemos considerar a las pruebas al principio del desarrollo, de hecho este es la columna vertebral y si lo tenemos presente resolvemos varios problemas como la refactorización, expresividad y todo lo que hemos explicado en la sección de clean code.

Complejidad

Hacemos que nuestro código sea complejo cuando tenemos el pensamiento de resolver muchas cosas, esto le da mayor relevancia a cosas que suponen importancia pero ignoras lo único que debes resolver ahora.

Este es origen de muchos problemas porque estamos intentando anticiparnos a requisitos y problemas que aún no se han presentados y desarrollamos funciones que en este momento son innecesarias, el resultado es tener un sistema que luego será difícil de mantener. De nuevo, el testing es quien te ayudará en este sentido porque es la técnica que nos mantiene enfocado.

Con frecuencia caemos en el error de programar una complejidad mayor a la mínima conveniente o necesaria.

Lo ideal es programar lo único que se requiere en el momento, es decir, enfocarnos en lo esencial. Nuestro problema radica en querer resolver todo o mucho con un único bloque de código y terminamos creando un código que quizás ni usamos al 100% en el futuro.

Vemos claramente lo que hace que el proyecto se vuelva difícilmente mantenible y poco tolerante al cambio. Siempre debemos apuntar a lo ideal, desarrollar un código más limpio, que se pueda mantener y que pueda ser escalable a futuro.