Una introducción a los principios de diseño de desarrollo de software

Este artículo introductorio habla sobre las cosas que un desarrollador de software debe tener en cuenta al desarrollar cualquier software. También habla sobre cuáles son algunos de los principios clave que uno debe considerar al escribir código a diario. 

Descripción general: 
Comencemos el tema con una pregunta: en el contexto del desarrollo de software, ¿qué se considera un buen diseño? 
¡La mayoría de la gente cree que no hay una respuesta específica a esta pregunta! Pero lo que resalta cuando se trata de diseño es que el costo y tiempo de desarrollo y mantenimiento de un software debe ser mínimo, más importante aún, el mantenimiento. Dado que la industria de TI pasa por muchas mejoras y actualizaciones en el software, si el costo y el tiempo de cambio de diseño son mínimos, entonces se puede decir que es un buen diseño. La razón es que es rápido y de bajo costo para realizar mejoras e impulsar actualizaciones/actualizaciones. 

Si bien podría ser un buen enfoque para un buen diseño, todavía hay un problema asociado con esto, y el problema es que cuando llega el momento de cambiar el diseño, se da cuenta de que es demasiado tarde para cambiar el diseño. Entonces, ahora nuevamente queda la pregunta de qué se considera un buen diseño. 

Para responder mejor a esta pregunta, comencemos a someter el diseño a cambios a lo largo del camino y veamos cómo se levanta el diseño. Y si no es así, sigamos evolucionando y acercándonos a algo que sea más fácil de cambiar, y esto es lo que muchos desarrolladores experimentados han hecho hasta ahora. Entonces, los principios de diseño de desarrollo de software son un conjunto de ciertas pautas dadas por desarrolladores experimentados que han aprendido de sus errores mientras estaban en la fase de desarrollo del software. 
 

Es casi imposible obtener un buen diseño por primera vez. 

Principios de diseño: 
hasta ahora, el artículo habla sobre la comprensión del concepto de buen diseño. Ahora, entremos en detalle sobre el conjunto de pautas disponibles para un buen diseño. 

1. Principio Keep It Simple, Stupid (KISS): 
Es el primer principio, el acrónimo significa Keep It Simple, Stupid . Los otros acrónimos alternativos famosos son 
 

• Mantenlo simplemente estúpido.
• Manténlo corto y simple.
• Mantenlo simple y directo.
• Mantenlo simple e inteligente.

Sugiere no involucrar complejidad en su código e intentar evitarlo tanto como pueda. Esto se debe a que se escribe un código más complejo, más difícil se vuelve modificar en cualquier momento posterior. Hay una frase muy bien dicha de Albert Einstein , que dará luz verde a lo dicho anteriormente: si no puedes explicarlo, es que no lo entiendes lo suficientemente bien . Por lo tanto, la simplicidad debe ser nuestro objetivo clave en el diseño de software. 

La imagen de arriba ilustra claramente que el objetivo principal de KISS es lograr la meta haciendo las cosas lo más simples posible y usando la solución más simple, como un camino recto en lugar de lograr las metas haciendo las cosas complicadas y luchando de un lado a otro. 

Ejemplo de violación de KISS – 
Uno podría haber pasado por una situación en la que ha escrito un código desordenado, ya sea en una etapa temprana de la carrera de programación o en algún lugar del viaje de programación. Aquí, el código desordenado significa escribir soluciones de múltiples problemas en un bloque, método o clase. Esto podría llevar a agregar algunas líneas innecesarias en el código. También puede haber una situación en la que podría haber múltiples soluciones para un problema. Por ejemplo, en algunos casos, tanto la instrucción switch como la instrucción if-else brindan una solución a un problema. Ahora, según el contexto, cuál usar y cuál sería una solución más simple, debe elegirse. Por supuesto, este fue solo un ejemplo simple con fines ilustrativos. Pero en la vida diaria de programación y desarrollo uno ha experimentado muchos de estos problemas. Requiere una pausa para pensar correctamente y seleccionar sabiamente una solución. 
 

La tarea del equipo de desarrollo de software es crear una ilusión de simplicidad. –Grady Booch

 Beneficios de KISS – 

1. Ayuda a resolver problemas rápidamente.
2. Dado que la solución es simple, ayuda a mantener el código.
3. Proporciona flexibilidad para modificar o refactorizar el código.
4. Proporciona solución de problemas complejos en líneas de código de fiebre.
5. Al final entrega código de alta calidad.

2. Principio de You Ain’t Gonna Need It (YAGNI): 
YAGNI significa You Ain’t Gonna Need It. Eso significa que si no te resulta útil más adelante, no lo hagas ahora. Al ser programador, el desarrollador suele implementar tantas cosas que realmente no necesita. Implementar algo que no se requiere en absoluto ahora, siempre consumirá costos, tiempo y esfuerzo. Por lo tanto, siempre es una buena práctica posponer cosas para el futuro que no se requieren hoy. En resumen, YAGNI simplemente dice que realmente no hagas algo, hasta que realmente encuentres valor en hacerlo. 

Este principio funciona detrás de la programación extrema (XP) pero es aplicable en todo tipo de procesos y metodologías de desarrollo de software. La implementación de YAGNI ahorra tiempo y entrega el proyecto de manera eficiente. En resumen, este principio está en contra del desarrollo de cualquier característica que no se requiera en la actualidad. Para que el desarrollador pueda ahorrar tiempo y concentrarse en otras piezas o componentes de un código. 

3. Principio SECO: 
Los programadores suelen escribir enormes códigos duplicados de forma accidental o no. Este principio nos obliga a evitar este hábito. Dice que no te repitas. Significa que cada pieza de conocimiento en un sistema debe tener exactamente una representación inequívoca. Los programadores pueden deshacerse de la duplicación de código utilizando herramientas como CPD y Simian. CPD son las siglas de Copy Paste Detector. Y Simian significa mono, que naturalmente copia una cosa u otra. 

Ejemplos de violaciones: el 
programador repite los códigos una y otra vez de muchas maneras. Algunos de los ejemplos podrían ser declarar demasiadas variables locales para cada asignación e inicialización. Escribir múltiples métodos y clases para la misma tarea una y otra vez. Considere una situación en la que se escribe un método fuera del servicio o la capa de datos para obtener un conjunto de datos de usuarios de un repositorio, y es necesario aplicar algún filtrado en ese conjunto. Ahora, si hay el mismo tipo de requisito en otra capa, la lógica debe escribirse nuevamente porque esa capa no es accesible desde esta. Generalmente, este tipo de tarea reside en la capa de servicio/datos. De modo que siempre que exista el mismo tipo de requisito, se puede invocar el método en cuestión de ese servicio o capa. 

Cómo evitar la SECA: 
para evitar la SECA, siga los puntos mencionados a continuación. 

• Reutiliza tu código y nunca lo dupliques
• Siga las convenciones de nomenclatura y asigne nombres claros de un método, variable, clase y objetos, etc.
• Escribir código en capas, ubicaciones y servicios apropiados

Nota: 
Seguir las convenciones de nomenclatura y agregar código a una ubicación adecuada ayuda a identificar la duplicación en el código. 

4. Principio SÓLIDO: 
SÓLIDO es una combinación de los siguientes principios de diseño, y de donde se ha tomado su acrónimo mnemotécnico. 

1. Principio de responsabilidad única
2. Principio abierto/cerrado
3. Principio de sustitución de Liskov
4. Principio de segregación de interfaz
5. Inversión de dependencia

5. Principio de responsabilidad única (SRP): 
este principio dice que nuestro código debe ser de naturaleza cohesiva. Aquí cohesivo significa que debe estar enfocado, ser estrecho y hacer una cosa y solo una cosa bien. Lo que a su vez significa que un código cohesivo no asume muchas responsabilidades y se enfoca en hacer una sola cosa. En el contexto del diseño orientado a objetos, bien se dice que una clase debe tener una sola y única responsabilidad para que tenga que cambiar con menos frecuencia. 
 

Si un código es cohesivo, tiene una, y sólo una, razón para cambiar.

 Entonces, si hay una pieza de código que hace varias cosas, entonces ese módulo tiene que cambiar constantemente, lo cual es más costoso porque cuando un programador viene a cambiarlo, tiene que asegurarse de que los cambios no rompan otras cosas y realmente se vean afectadas. y sale muy caro. Por otro lado, cuando una pieza de código se divide en varias partes donde cada pieza hace una y solo una cosa bien, entonces el costo de cambiar esa pieza es mucho más fácil. 

Nota: 
cuando dice «un fragmento de código», piénselo como clases, métodos o funciones. La violación del principio de responsabilidad única aumenta el nivel de dificultad para un programador y se vuelve difícil probar, leer, recordar y reutilizar el código. 

6. Principio abierto/cerrado (OCP): 
este principio dice que una pieza de código (en general, una clase, un módulo o un componente) debe estar abierta para la extensión y cerrada para la modificación. lo que significa que las clases, los métodos o las funciones deben escribirse de manera que estén listos para adoptar/agregar nuevas funciones, pero no interesados ​​en ninguna modificación. En el contexto del diseño orientado a objetos, esto podría lograrse con el concepto de Abstracción y Polimorfismo. 

7. Principio de sustitución de Liskov (LSP): 
este principio dice que la función que usa referencias de clases principales también debe poder usar objetos de clases secundarias sin saberlo. Significa que los métodos que pueden usar el tipo de superclase deben poder trabajar con el objeto de la clase derivada sin ningún problema. 

El usuario de una clase base debería poder usar una instancia de una clase derivada sin saber la diferencia. 

8. Principio de segregación de la interfaz (ISP): 
este principio dice que no se debe obligar a un cliente a implementar una interfaz si no la necesita. Esto suele suceder cuando una interfaz contiene más de una función y el cliente solo necesita una, pero no todas. En este caso, el cliente se ve obligado a implementar todas las funciones de esa interfaz. que es una locura y debe evitarse. 
Por lo tanto, uno siempre debe mantener una interfaz cohesiva y estrecha y enfocada en una y solo una cosa. 

9. Inversión de Dependencia o Inyección de Dependencia (DI): 
Este principio habla de acoplamiento. El acoplamiento es el grado de conectividad entre las cosas, así es como su pieza de código está conectada entre sí. El punto crítico para recordar aquí es que cuando nuestro código está hablando con otras piezas de código, siempre aumenta el acoplamiento. En resumen, el acoplamiento es algo de lo que depende nuestro código. Un gran ejemplo podría ser la herencia tradicional basada en clases. 

La herencia en realidad aumenta bastante el acoplamiento. Ahora, según este principio, elimine o minimice la dependencia en la medida de lo posible. Si no puede eliminar toda la dependencia, al menos minimícela, y esto se denomina acoplamiento flexible. En el contexto del diseño orientado a objetos, dependiendo de una clase se denomina acoplamiento estrecho , mientras que dependiendo de una interfaz, se denomina acoplamiento flexible . 

Un buen diseño siempre termina con alta cohesión y bajo acoplamiento 

Este principio funciona en conjunto con el principio OCP. Para evitar la violación de OCP, use el principio de inversión de dependencia. Los marcos orientados a la inyección de dependencia como Spring son un ejemplo del mundo real y la implementación de este principio. 

Revisión: 
no es un principio de diseño, sino una buena práctica que siguen muchos desarrolladores o empresas. Una vez que se completa el desarrollo del software o componente, debe someterse a un proceso de revisión de código antes de pasar a la siguiente etapa. Esta revisión la puede hacer cualquier miembro de su equipo. 
 

Recuerda que los humanos juzgan rápidamente las faltas de los demás, pero nunca señalan las propias.

 Una vez que se ha revisado y los comentarios de revisión están disponibles, mantén nuestro ego alejado y échale un vistazo, y realiza cambios si es necesario. 

Conclusión: 
Los anteriores fueron algunos de los principios de diseño muy discutidos, que son extremadamente importantes y nos ayudan a evitar la duplicación de código, esfuerzos y nos ayudan a mantener la complejidad al mínimo posible. Por lo tanto, puede aplicar estos principios en nuestra vida cotidiana de codificación, siempre que esté desarrollando una pieza de software o un componente de ella. También es una buena práctica discutir estos principios entre colegas o compañeros de equipo con los que está trabajando durante el proceso de diseño y desarrollo, de modo que si falta alguno de los principios o los viola, se señalará en una etapa anterior en lugar de hacer una error en una etapa posterior.