Escribir código limpio, comprensible y fácil de mantener, no depende sólo de conocer el lenguaje de programación. Existen reglas basadas en la investigación y recomendaciones empíricas útiles para el desarrollo de software.
En forma de Principios, perviven a pesar de la aparición de nuevos lenguajes de desarrollo y plataformas. Son enfoques, estilos, filosofías y mejores prácticas introducidas por ingenieros de software y autores destacados de la industria.
Eso sí, quizás sin descartar un hipotético Principio UDASP, en inglés Use, Don’t Abuse, Software Principles; es decir, «Usa, No Abuses, de los Principios del Desarrollo de Software» : )
Principios básicos
Principio DRY
Del inglés Don’t Repeat Yourself, «No te repitas» (también se conoce como Una vez y sólo una).
Según este principio debe evitarse la duplicidad de cualquier «pieza de información» porque incrementa la dificultad de los cambios y el posterior mantenimiento, perjudica la claridad y crea un espacio para posibles inconsistencias.
Debe entenderse «pieza de información» en un sentido amplio, abarcando datos almacenados en una base de datos, código fuente, o documentación.
Principio KISS
Del inglés Keep It Simple, Stupid!, «¡Mantenlo sencillo, estúpido!».
Establece que los sistemas funcionan mejor si se mantienen simples. La simplicidad debe ser un objetivo clave del diseño, evitando cualquier complejidad innecesaria.
Principio YAGNI
Del inglés You Aren’t Gonna Need It, «No vas a necesitarlo».
Consiste en no agregar nunca una funcionalidad innecesaria o no solicitada.
La tentación de escribir código que no es necesario, pero puede serlo en un futuro, sacrifica tiempo que podría destinarse a funcionalidades básicas, sin olvidar que cualquier característica nueva, necesaria o no, debe ser depurada, documentada y soportada.
Principios SOLID
Asociados al diseño orientado a objetos. Cada letra en «SOLID» representa un principio:
|
S |
Single-responsibility Principle (Principio de responsabilidad única) Cada módulo o clase debe ser responsable de una única cosa, y esa responsabilidad debe estar completamente encapsulada por la clase. |
|
O |
Open-closed Principle (Principio de abierto/cerrado) Las clases, módulos o funciones deben estar abiertas para su extensión, pero cerradas para su modificación. O de otra forma, se debería poder extender el comportamiento de una clase, sin modificarla. |
|
L |
Liskov Substitution Principle (Principio de sustitución de Liskov) Una clase debería ser sustituible por su clase padre. La clase heredada debe complementar, no reemplazar, el comportamiento de la clase base. |
|
I |
Interface Segregation Principle (Principio de segregación de la interfaz) Ningún cliente debe verse obligado a depender de métodos que no utiliza. Es preferible contar con muchas interfaces con pocos métodos que tener una interface que requiera implementar métodos que no serán usados. |
|
D |
Dependency Inversion Principle (Principio de inversión de la dependencia) Las dependencias deben recaer sobre abstracciones (interfaces), no sobre clases concretas (implementaciones). |
Otros principios
Principio SoC
Del inglés Separation of Concerns, «Separación de Asuntos».
Se organiza el código según el asunto o su responsabilidad en la aplicación. Un buen ejemplo es el patrón de diseño de software MVC que separa el modelo de datos, la interfaz del usuario y el código destinado a la lógica de control.
Principio SLAP
Del inglés Single Level of Abstraction Principle, «Principio de Nivel Único de Abstracción».
Escribir código tiene que ver con abstracciones, ocultando detalles de bajo nivel de los conceptos de más alto nivel.
Este principio propone dividir el programa en funciones o métodos con una única responsabilidad, pocas líneas de código y un único nivel de abstracción. Sólo deben hacer una cosa, y hacerla bien.
Si es necesario se pueden usar funciones o métodos compuestos, con llamadas a otras funciones o métodos privados, cada uno con un nombre claro que identifique su responsabilidad.
Principio 4C’s
Del inglés Clean Code, Clever Code, «Código limpio, código inteligente».
La base de este principio es empatizar con el programador que leerá nuestro código, para asegurarnos de que le damos la legibilidad necesaria para que pueda entender cómo hemos resuelto un problema o una necesidad dada, a pesar de pensar y programar de manera diferente.
Referencias
- Principles Wiki, donde se recopilan, examinan y discuten decenas de estos principios
- What Are The Best Software Engineering Principles?
- 3 Key Software Principles You Must Understand
- Levels of abstraction
- Los 5 principios SOLID
- Doce principios de diseño que todo desarrollador debería conocer
- En la Wikipedia: DRY, KISS, SoC, SOLID, YAGNI
Última revisión: 16/06/2020
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!