Hay muchos principios a seguir en la programación, pero parafraseando las teorías, reuniendo y resumiendo, nos podemos quedar con los siguientes sobre los que se han ido construyendo los principales patrones de diseño de software.
Hay dos básicos de sentido común que son el KISS y el DRY. Luego los archi-conocidos principios SOLID, y finalmente los STUPID de los que hay que tratar de huir. Vamos al grano..
KISS: Keep It Simple Stupid
Cuanto más simple sea un programa mejor. Si se puede hacer algo por reducir su complejidad, adelante. Se pueden dividir los problemas en otros más simples, más legibles, hacer funciones, objetos, nombres de variables simples, eliminar todo lo innecesario.
Es decir, tiene que ser simple y que funcione. Mejor no hacer malabares innecesarios en los códigos fuentes, y usar la menor cantidad posible de código siempre que quede bien legible.
DRY: Don’t Repeat Yourself
Esta es una regla de oro, que nos obliga a ir aplicando muchos de los otros principios e incluso los patrones. En el momento en que comenzamos a duplicar códigos fuentes, hay que refactorizar, y cuanto antes mejor.
La solución a esto siempre va a pasar por hacer objetos, funciones, dividir en ficheros correctamente.. para poder reutilizar los códigos fuentes sin tener repeticiones de código fuente.
Tener código repetido hace muy costoso el mantenimiento, y es síntoma de mala calidad en la programación.
Los conocidos principios SOLID
- Single responsability: una clase sólo tiene que tener una responsabilidad, sólo tiene que tener que hacer una sola cosa.
- Open/close: una clase tiene que estar abierta para extenderse, cerrada para modificarse.
- Liskov substitution: una clase derivada tiene que poder sustituirse por una de la que haya derivado.
- Interface segregation: las interfaces tienen que ser pequeñas y con pocos métodos, mejor que grandes y con muchos.
- Dependency inversion: las implementaciones o derivaciones tienen que depender de las partes de la aplicación más estables. Por ejemplo, en arquitecturas limpias las capas que más cambian dependen de las que menos cambian como el dominio, las implementaciones mejor que dependan de interfaces definidas, los usos de los métodos mejor si usan interfaces independizándose de las implementaciones concretas.
Y de los que hay que tratar de huir, si es posible, los STUPID
- Singleton: hay que evitar usar singletones en todas partes, son muy útiles, pero es un error usarlos cuando no es necesario.
- Tight coupling: hay que evitar el alto acomplamiento entre las clases.
- Untestability: el código no testeable.
- Premature optimization: no conviene invertir tiempo añadiendo complejidad en optimizaciones antes de tiempo.
- Indescriptive naming: nombrar las variables, métodos, clases.. correctamente, es una parte muy importante para hacer mantenible un programa y conseguir que funcione lo mejor posible.
- Duplication: hace referencia al principio DRY.
Bibliografía, fuentes
Internet, C. Martin, GoF, Wikipedia y otras fuentes varias..
