Ir al inicio - Autentia

Blog

Principios y patrones de diseño del desarrollo de software

Introducción

Como desarrolladores del software es nuestra responsabilidad crear un código de calidad, mantenible, y entregar valor de una forma rápida y con garantías de que va a funcionar.

¿Un dentista le pregunta al dueño del negocio si empasta una muela o es mejor quitarla? ¿Por qué en nuestra profesión se tiene asumido que son otros roles distintos a los desarrolladores de software quienes toman decisiones sobre el software?

A menudo somos nosotros mismos quienes tiramos piedras sobre nuestro tejado preguntando a Product Owners, o gente de desarrollo de negocio, si refactorizamos o si asumimos deuda técnica.

El primer error es preguntar. Nosotros debemos detectar los síntomas de degradación que presenta el código y cuáles son sus consecuencias. El segundo error es preguntarle a gente acostumbrada a tomar decisiones sobre algo que desconoce. Nosotros somos profesionales y somos nosotros quienes decidimos si se hace, cuándo y cómo, y será cuando asumamos esta responsabilidad, que se nos respetará como en otros sectores. Hasta entonces, gente menos cualificada técnicamente tomará decisiones técnicas para las que no está preparada, ocasionando frustraciones a nivel técnico y no técnico.

Ilustración donde un obrero le dice a otro sobre fondo con casa derruida: i don't undertand why it takes so long to add a new window. Patrones de diseño. Tecnical debt

Image by Vincent Déniel – @vincentdnl

En esta guía de software design vamos a ver una serie de principios y de patrones de diseño. Seguro que no se nos ocurre preguntarle al Product Owner si hacemos un Service Locator o si utilizamos inyección de dependencias. Somos los técnicos quienes al estimar tenemos en cuenta el desarrollo, el tiempo de pruebas y si hay que hacer alguna refactorización o asumir deuda técnica. Es nuestra responsabilidad desarrollar software de forma que podamos entregar valor al negocio. Si no eliminamos la deuda técnica, esta entrega de valor será cada vez más lenta y con mayor números de errores. La construcción de software de baja calidad está abocada a fracasar.

Al final, lo barato sale caro y optar por software que no cumple unas garantías mínimas de calidad nos puede dar la falsa sensación al principio, de que todo está bien. Esto es porque vemos el software como algo abstracto que no entendemos del todo. Pero no es muy distinto a un coche. Lo que al principio sale barato, entre mantenimientos y averías, al final resulta que acaba saliendo muy caro.

 

Antipatrones y patrones de diseño

Nosotros los desarrolladores tendemos a crear las soluciones desde cero. Pero ¿siempre son adecuadas las soluciones que proponemos e implementamos? ¿Para qué reinventar la rueda? Los profesionales del software pueden estar familiarizados con el término «patrones de diseño», pero muchos desconocen de dónde vienen y qué son realmente. En consecuencia, algunos no ven el valor y los beneficios que los patrones de diseño aportan al proceso de desarrollo de software, especialmente en las áreas de mantenimiento y reutilización de código. 

Los patrones de diseño se definen, normalmente, como soluciones probadas en el tiempo para problemas de diseño recurrentes. Tienen sus raíces en el trabajo de Christopher Alexander, un ingeniero civil que escribió sobre su experiencia en la resolución de problemas de diseño relacionados con edificios y ciudades. A Alexander se le ocurrió que ciertas construcciones de diseño, cuando se usaban una y otra vez, conducían al efecto deseado. Documentó y publicó sus conocimientos y la experiencia que adquirió para que otros pudieran beneficiarse. 

Hace unos 15 años, los profesionales del software comenzaron a incorporar los principios de Alexander en la creación de documentación de patrones de diseño como una guía para desarrolladores novatos. Este trabajo inicial llevó a otros a escribir también sobre patrones de diseño y culminó con la publicación de Design Patterns: Elements of Reusable Object-Oriented Software en 1995 por Eric Gamma, Richard Helm, Ralph Johnson y John Vlissides. Se considera que este libro es la «salida» de los patrones de diseño a la comunidad de software en general y ha sido influyente en la evolución de los patrones de diseño desde entonces. 

Libro Design-Patterns

Design Patterns describió 23 patrones que se basaron en la experiencia de los autores en ese momento. Estos patrones se seleccionaron porque representaban soluciones a problemas comunes en el desarrollo de software. Se han documentado y catalogado muchos más patrones desde la publicación de Design Patterns. Sin embargo, estos 23 son probablemente, los más conocidos y sin duda, los más populares. 

Por su parte, un antipatrón de diseño es un patrón de diseño que nos desvía a una mala solución de un problema. Es fundamental conocer los antipatrones de diseño, porque nos da la visión de los posibles errores. Como programador deberías conocer los antipatrones para evitarlos siempre que sea posible, lo que requiere tener una cierta idea de los mismos para poder reconocerlos, identificarlos y tan pronto como sea posible, eliminarlos dentro del ciclo de vida del desarrollo del software.

Antipatron cut and paste programming

Esta guía ayudará a comprender cómo son los patrones y los antipatrones. Además te da consejos sobre cómo usarlos. También resumirá las características más destacadas de cada patrón.

También tienes a tu disposición guías de Front, Back y DevOps a través de descarga directa en nuestra sección de libros.

Principios y patrones del desarrollo de software

Descarga la guía

DESCARGAR
Por Alberto Barranco 16 Jul 2020

¿Cómo podemos ayudarte?

HABLEMOS