Cuando nos encontramos con un equipo que no está familiarizado con patrones de arquitectura, principios de diseño y arquitecturas empresariales es bastante complicado instruir a cada miembro en las costumbres y principios de diseño para cualquier desarrollo de software de un tamaño considerable. Pues bien, aunque en este artículo no me dé tiempo ni de lejos a explicar los principales principios de diseño, os dejo una lista muy práctica para imprimirla en una hoja y colocarla en un sitio visible para no perder de vista ningún principio a la hora de hacer un desarrollo.
Os dejo un enlace de un documento PDF que tiene el contenido de este artículo resumido en una sola página. Yo suelo entregar a cada desarrollador que viene nuevo al equipo una copia para que la tenga presente.
La unificación de procesos no conlleva tener una clase que haga todo. Las clases deberán tener una agrupación por funcionalidad (SOLID).
SRP (The Single Responsibility Principle o Principio de Responsabilidad Única): una clase debe tener una, y solamente una, razón para cambiar. OCP (The Open/Closed Principle o Principio Abierto / Cerrado): Una clase debe estar abierta para la extensión y cerrada para la modificación.
LSP (The Liskov Substitution Principle o Principio de Sustitución de Liskov): las clases derivadas deben poder ser sustituibles por sus clases base.
ISP (Interface Segregation Principle o Principio de Segregación de Interfaces): hacer interfaces de grano fino que son específicos para un uso.
DIP (The Dependency Inversion Principle o Principio de Inversión de Dependencias): las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.
No repetirse (Don’t Repeat Yourself): se debe especificar „la intención‟ en un único sitio en el sistema. Una funcionalidad específica se debe implementar en un único componente. Separación de Responsabilidades (Separation of Concerns): Cada módulo debe tener una responsabilidad única, minimizando los puntos de interacción entre módulos para conseguir una alta cohesión y un bajo acoplamiento.
keep It Simple S*****, Make It Simple S*****: Mantener los diseños y módulos simples de forma que se puedan entender, analizar y corregir fallos fácilmente. Si una extensión de un módulo lo complicaría sería mejor crear un módulo dependiente.
Minimizar el diseño de arriba abajo (Upfront design): diseñar solamente lo que es necesario, no realizar “sobre-ingenierías” ni “sobreArquitecturizar” evitando el efecto YAGNI (You Ain‟t Gonna Need It).
diseño cohesivo de componentes (CCD): no sobrecargar los componentes añadiendo funcionalidad mezclada. Ejemplo: evitar mezclar lógica de acceso a datos con lógica de negocio.
Aspectos transversales aislados de la lógica específica: seguridad, log, parametrización, instrumentalización, etc. Debe estar separada para no dar lugar a diseños acoplados difíciles de extender, mantener o migrar. AOP (Aspect Oriented Programming).
Command-Query separation principle) Separación de Comandos y Consultas: Separar los métodos en dos tipos: métodos que realizan consultas al sistema y métodos que realizan comandos en el sistema. Los métodos de consulta no alteran el estado del sistema, mientras que los métodos de comando no devuelven información sobre el sistema.
El principio de Hollywood: “No me llames, yo te llamo” (IoC) 
Convencion sobre configuración (Convention over configuration) Si se reduce el número de decisions a tomar en el desarrollo se gana en simplicidad, pero no se pierde en flexibilidad. Un desarrollador sólo necesita especificar los aspectos no convencionales de una aplicación. Mejor composición que herencia (Composition over inheritance): Es mejor realizar composición sobre una clase que encadenar herencias para diferentes responsabilidades.
Navaja de Ockham: La explicación más sencilla suele ser la correcta. Cuando dos o más explicaciones se ofrecen para un fenómeno, la explicación completa más simple es preferible; es decir, no deben multiplicarse las entidades sin necesidad.
Principio de Pareto: Desarrollo: "el 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan sólo un 20% del esfuerzo".
Pruebas de software, "el 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80% genera tan solo un 20% de los fallos".
No hay comentarios:
Publicar un comentario