Principios KISS, DRY y YAGNI
El código limpio tiene como uno de sus pilares el “menos es más” de toda la vida y se aplica a diferentes aspectos, y los desarrolladores tenemos algunos acrónimos para algunos de los principios del código limpio.
Principio KISS - Keep It Simple, Stupid
Evitar la complejidad innecesaria en el código, optar por una documentación simple y concisa, así como optar por interfaces de usuario limpias y claras.
Este principio también abarca el usar nombres claros para nuestras entidades (variables, métodos, interfaces, funciones, clases, etc), y esos nombres deberían significar una sola cosa siempre.
Además al separar nuestro software en capas, cada una debe tener responsabilidades bien definidas.
Principio DRY - Don’t Repeat Yourself
No debes tener código duplicado, duplicar hace que el código sea más complejo y extenso, y cuando sea necesario cambiar alguna parte de este, será necesario cambiar el mismo código en múltiples lugares, dando lugar a trabajo extra y posibles errores.
Este principio incluye copiar y pegar código ya existente para reutilizarlo, pero también incluye en pensar y construir código nuevo teniendo en cuenta su posible reutilización.
Y por último también hay que tener cuidado del código que puede estar en múltiples lugares y que puede lucir diferente, pero que al final de cuentas hace exactamente el mismo funcionamiento.
Principio YAGNI - You Ain’t Gonna Need It
De la mano de todo lo anterior, este principio habla sobre no crear características innecesarias.
Evitar implementar funcionalidades solo porque piensas que posiblemente algún día podrías necesitarlas, en su lugar podríamos optar por implementarlas cuando realmente sean requeridas.
El principio KISS habla sobre evitar la complejidad innecesaria, YAGNI habla sobre enfocarnos en evitar lógica y funcionalidad innecesaria y remover características que no se usen o que sean redundantes.
Siempre será bueno dejar el código mejor de lo que lo encontramos. Cuando nos encontremos con código que no sea muy claro y no cumpla con los principios anteriormente descritos siempre podemos dedicar al menos unos minutos para corregirlo.
Principios SOLID
Este acrónimo por Robert C. Martin, engloba otros 5 principios de diseño de software enfocados al código limpio en la programación orientada a objetos, pero incluso va más allá y apuntan al código flexible, fácil de entender, extender y mantener.
Aunque antes de explicar los principios solid primero hay que tener en cuenta tres cosas:
- Cada clase que creemos debe servir para un único objetivo claro y bien definido
- Asegurarnos que las clases interactúan entre sí mediante interfaces
- Diseñar interfaces pequeñas y las clases solo deben implementar las interfaces que requieran
S - Single responsibility principle
Cada clase debe tener una única responsabilidad. Entre más responsabilidades tenga una clase, más seguido será necesario cambiarla, además de que generará más dependencia en otras clases. Teniendo clases dependientes genera el problema de que muchas salgan afectadas al hacer un solo cambio.
O - Open-Closed principle
Este principio habla sobre que las entidades en nuestro código deben estar abiertas a ser extendidas, pero cerradas a ser modificadas. Debemos crear código modular que pueda ser extendido sin requerir modificaciones.
Esto se consigue mediante abstracción, herencia e interfaces por ejemplo.
L - Liskov substitution principle
Este principio establece que una subclase debe poder sustituir a la clase base de la que hereda sin que el código se rompa.
Por ejemplo, teniendo una función que acepta como argumento objetos de una clase A, esta función debería ser capaz de aceptar también objetos de una clase B que extienden a la clase A y todo debería seguir funcionando correctamente.
I - interface Segregation principle
El principio de segregación de interfaces establece que múltiples interfaces específicas son mejores que una única interfaz de propósito general.
En este principio se tiene en cuenta también que una interfaz debe depender más del código cliente que la llama que del código que la implementa y no debemos obligar al cliente a depender de interfaces innecesarias.
Por lo tanto, una clase debe implementar diferentes interfaces creadas en función de los diferentes clientes.
D - Dependency inversion principle
Finalmente tenemos la inversión de dependencias, que es el principio que establece que las clases deben comunicarse por medio de Interfaces.
El código debe depender de abstracciones y no de implementaciones concretas.