Al hablar de principios de Software nos referimos a las directrices fundamentales que guían el

desarrollo, diseño y gestión de aplicaciones y sistemas de software. Aunque existen varios

conjuntos de principios según las diferentes metodologías y enfoques en ingeniería de software,
algunos de los más ampliamente conocidos incluyen:
1. Principio KISS (Keep It Simple, Stupid)
2. Principio DRY (Don’t Repeat Yourself)
3. Principio YAGNI (You Aren’t Gonna Need It)
4. Principio S.O.L.I.D
Estos principios están diseñados para ayudar a los desarrolladores a crear software que sea más
robusto, fácil de mantener y ampliar, y eficiente en su funcionamiento. Al seguir estos principios,
los equipos de desarrollo pueden evitar muchos problemas comunes en el desarrollo de software
y mejorar la calidad y sostenibilidad de sus aplicaciones. A continuación, se explica más
detallado, cada principio antes mencionado.
[Principio KISS]
KISS es el acrónimo para la frase “Keep It Simple, Stupid” o su equivalente en español “Mantenlo
Simple, Estúpido”. Es un principio de diseño y programación en el que la simplicidad del sistema
se declara como objetivo o valor principal y debe evitarse una complejidad innecesaria.

Para que las aplicaciones, los programas de software y los sitios web funcionen sin problemas,
los programadores, utilizan principios probados. KISS dice que siempre se debe usar la solución
más simple a un problema. Se trata principalmente de hacer que el código sea lo más simple
posible.

Si ya no comprendes tu propio código después de un breve período de tiempo, las campanas de

alarma deberían sonar. Porque cuanto más complicado es o se presenta, más difícil es para
todos los involucrados trabajar con él.

En programación, el principio KISS al igual que el principio DRY ayudan a reducir la

complejidad. La simplificación siempre debe ser un objetivo clave. El código simple tiene menos
errores y es más fácil de editar.
Algunas características del Principio KISS, se podrían describir de la siguiente manera:

 No tiene sentido aumentar infinitamente el nivel de abstracción, hay que poder detenerse
en el tiempo
 No tiene sentido poner en el proyecto funciones redundantes «en reserva» que algún día
alguien pueda necesitar (aquí el enfoque según el principio YAGNI es más correcto)
 Para qué incluir una biblioteca enorme si solo se necesita un par de funciones de ella
 La descomposición de algo complejo en componentes simples es un enfoque
arquitectónicamente correcto (aquí KISS se hace eco de DRY)
 No siempre se necesita precisión matemática absoluta o detalles extremos: Los datos
pueden y deben procesarse con la precisión suficiente para una solución de alta calidad
del problema, y los detalles se dan en la cantidad necesaria para el usuario, y no en el
volumen máximo posible.
 ¿Qué Beneficio tiene la implementación de la metodología KISS en nuestros proyectos?

Este principio es especialmente necesario para proyectos de software que son medianos y
grandes. Entre los beneficios se incluyen:

 Mayor calidad del código

 Código más simple de mantener
 Más flexible y fácil de ampliar, modificar, mejorar.

KISS también tiene mucho en común con el principio de separación de interfaces de los cinco
principios SOLID formulados por Robert Martin.

[Principio DRY]

El principio “Don’t Repeat Yourself” (DRY) o su equivalente al español “No Te Repitas” es de

naturaleza muy similar al principio KISS. También tiene un significado bastante simple pero
amplio.

Probablemente el principio más fundamental en la programación es evitar la repetición. Muchos

desarrolladores copian, pegan y duplican fragmentos de su propio código. En general, eso no
tiene nada de malo. Todo el mundo a veces necesita comprobar rápidamente algo
(comportamiento esperado o lo que sea). Pero poner en producción dicho código copiado es
inaceptable.

DRY nos recuerda que cada comportamiento repetible en el código debe estar aislado (por
ejemplo, separado en una función) para su reutilización. Cuando tienes exactamente las mismas
dos piezas de código en tu base de código, eso no es bueno, debido a que a menudo conduce a
la desincronización y otros errores, sin mencionar el hecho de que aumenta el tamaño del
programa.

¿Qué beneficio tendría implementar este principio?

Tan pronto como comienzas a repetirte (por ejemplo, una expresión larga, una serie de
expresiones similares, entidades similares) creas nuevas abstracciones. Seguir el principio de
programación DRY permite lograr una alta capacidad de mantenimiento del proyecto, facilidad
para realizar cambios y pruebas de alta calidad.

Si el código no está duplicado, para cambiar la lógica, basta con hacer correcciones en un solo
lugar y es más fácil probar una función (aunque más compleja), en lugar de un conjunto de
docenas del mismo tipo.

Seguir este principio siempre conduce a la descomposición de algoritmos complejos en

funciones simples. Y la descomposición de operaciones complejas en operaciones más simples
(y reutilizables) simplifica enormemente la comprensión del código del programa.
La reutilización de funciones derivadas de algoritmos complejos reduce el tiempo de desarrollo y
prueba de nuevas funciones.

El acceso a una funcionalidad específica debe estar disponible en un solo lugar, unificado y
agrupado de acuerdo con algún principio, y no «disperso» alrededor del sistema en variaciones
arbitrarias. Este enfoque se cruza con el principio de responsabilidad única de los cinco
principios SOLID formulados por Robert Martin.
 [Principio YAGNI]

El principio YAGNI o You Aren’t Gonna Need It, es un principio de optimización de trabajo en el
desarrollo de software que establece que los componentes deben añadirse cuando sean
estrictamente necesarios. Este principio forma parte de la filosofía de la llamada programación
extrema (XP), que contribuye a evitar el exceso y la ineficacia y concretar un producto
informático en menor tiempo.

Esta filosofía logra que los desarrolladores desperdicien esfuerzos en características que solo
forman parte de una suposición de su uso en “algún momento”. El principio YAGNI influye para
que el trabajo se realice bajo términos pragmáticos y utilitarios, de manera que los
desarrolladores se enfoquen en las características y componentes realmente necesarios.

En el desarrollo de un software existen factores que son de vital importancia,

principalmente para la empresa que hace la inversión. Estos factores son:
tiempo y economía. Es por eso, que en la medida en que se logra optimizar el
tiempo, también se logran concretos y mejor consolidados y si por cada
software se invierte menos tiempo, significa que hay oportunidad de aumentar
la producción.

¿Qué ventaja tiene implementar esta metodología?

El principio YAGNI contribuye a mantener los costes de inversión, los costes de oportunidad y
optimiza el tiempo de implantación. Además, si solo se llevan a cabo los requisitos que deben
implementarse de manera concreta, estas son algunas ventajas:
 Se evita la dispersión de funciones.
 No se crea «bloatware», es decir, software con funciones que apenas se utilizan o que
no se utilizan en absoluto.
 Las funciones que no se implementan no tienen que ser probadas, documentadas y
soportadas. Por tanto, no hay esfuerzo (innecesario).
 El beneficio aumenta, porque se elimina el esfuerzo para la implementación de
funciones supuestamente necesarias.
 La base de código sigue siendo más «magra» y, por lo tanto, es más fácil de mantener.

“El principio YAGNI es el complemento del principio KISS”

El Principio KISS busca la solución más sencilla posible a una complejidad. El principio YAGNI
complementa al KISS planteando la pregunta «¿realmente necesitamos esto?», propiciando una
respuesta más acorde a la orientación de evitar trabajos innecesarios.

La complementariedad de ambos principios, propicia que no se implementen patrones, no se

utilicen bibliotecas y no se automaticen los procesos de despliegue. Ocurre con regularidad que
los desarrolladores suelen cargarse de tareas, por lo que, estás técnicas plantean mayor
eficiencia en el proceso de trabajo para que todos los procesos funcionen de forma rápida y más
fácil.

[Principio SOLID]
Principios SOLID no es más que un acrónimo que hace mención a los cinco principios de diseño
que se encuentran orientados a objetos (OOD). Cuando estos principios se combinan se facilita
el trabajo de programación para el desarrollo de software de calidad.

Si se necesita refactorizar fácilmente el código y el desarrollo de software ágil o adaptativos, los

principios SOLID se encargan de facilitar a los programadores o desarrolladores el trabajo, así
como evitar y corregir errores de código. Los acrónimos cuando se expanden pueden parecer
complicados, sin embargo, son bastante fáciles de entender. Veamos.

Los 5 principios SOLID de diseño de aplicaciones de software son:

 S – Single Responsibility Principle (SRP)
 O – Open/Closed Principle (OCP)
 L – Liskov Substitution Principle (LSP)
 I – Interface Segregation Principle (ISP)
 D – Dependency Inversion Principle (DIP)

1. Principio de Responsabilidad Única
“A class should have one, and only one, reason to change.”

La S del acrónimo del que hablamos hoy se refiere a Single Responsibility Principle
(SRP). Según este principio “una clase debería tener una, y solo una, razón para
cambiar”. Es esto, precisamente, “razón para cambiar”, lo que Robert C. Martin identifica
como “responsabilidad”.
El principio de Responsabilidad Única es el más importante y fundamental de SOLID,
muy sencillo de explicar, pero el más difícil de seguir en la práctica.
El propio Bob resume cómo hacerlo: “Gather together the things that change for the
same reasons. Separate those things that change for different reasons” , es decir: “Reúne
las cosas que cambian por las mismas razones. Separa aquellas que cambian por
razones diferentes”.

2. Principio de Abierto/Cerrado
“You should be able to extend a classes behavior, without modifying it.”

El segundo principio de SOLID lo formuló Bertrand Meyer en 1988 en su libro “Object

Oriented Software Construction ” y dice: “Deberías ser capaz de extender el
comportamiento de una clase, sin modificarla”. En otras palabras: las clases que usas
deberían estar abiertas para poder extenderse y cerradas para modificarse.
En su blog Robert C. Martin defendió este principio que a priori puede parecer una
paradoja . Es importante tener en cuenta el Open/Closed Principle (OCP) a la hora de
desarrollar clases, librerías o frameworks.

3. Principio de Sustitución de Liskov

“Derived classes must be substitutable for their base classes.”

La L de SOLID alude al apellido de quien lo creó, Barbara Liskov , y dice que “las clases
derivadas deben poder sustituirse por sus clases base”.
Esto significa que los objetos deben poder ser reemplazados por instancias de sus
subtipos sin alterar el correcto funcionamiento del sistema o lo que es lo mismo: si en un
programa utilizamos cierta clase, deberíamos poder usar cualquiera de sus subclases sin
interferir en la funcionalidad del programa.
Según Robert C. Martin incumplir el Liskov Substitution Principle (LSP) implica violar
también el principio de Abierto/Cerrado.

4. Principio de Segregación de la Interfaz

“Make fine grained interfaces that are client specific.”

En el cuarto principio de SOLID, el tío Bob sugiere: “Haz interfaces que sean específicas
para un tipo de cliente”, es decir, para una finalidad concreta.
En este sentido, según el Interface Segregation Principle (ISP), es preferible contar con
muchas interfaces que definan pocos métodos que tener una interface forzada a
implementar muchos métodos a los que no dará uso.

5. Principio de Inversión de Dependencias

“Depend on abstractions, not on concretions.”

Llegamos al último principio: “Depende de abstracciones, no de clases concretas”.

Así, Robert C. Martin recomienda:
1. Los módulos de alto nivel no deberían depender de módulos de bajo
nivel. Ambos deberían depender de abstracciones.
2. Las abstracciones no deberían depender de los detalles. Los detalles
deberían depender de las abstracciones.

El objetivo del Dependency Inversion Principle (DIP) consiste en reducir las

dependencias entre los módulos del código, es decir, alcanzar un bajo acoplamiento de
las clases.

[Conclusión]
Cómo pudimos contemplar en el documento, tenemos distintos principios o pautas a
seguir para conseguir que el código en el que estemos trabajando sea construido de una
manera más limpia, esto con el propósito de facilitarnos la comprensión del software que
estemos realizando. Cada metodología tiene relación entre sí y sobre todo tienen como
base los 5 Principios de la metodología SOLID. Es por esta razón que el uso disciplinario
de estas metodologías es muy importante al momento de trabajar ya que son conductas
que nos ayudan a ahorrar tiempo y dolores de cabeza al tratar con algoritmos o código
que requieran tareas o procesos demasiados complejos.