La complejidad es el enemigo de la ingeniería de software

La clave para un software duradero y mantenible es más simple de lo que usted piensa.

Hace aproximadamente un año, estaba en la oficina de un cliente para ayudarles con un proyecto en el que estaban trabajando. Ahora, este cliente había contratado a una de las firmas de consultoría de alto nivel para este proyecto. Obviamente, no puedo nombrar nombres aquí, pero las banderas rojas empezaron antes de que yo tuviera la oportunidad de ver el proyecto, cuando el gerente de contratación me estaba explicando las cosas, me dijo que era un proyecto muy bueno y que estaban usando tecnologías X, Y y Z. Luego me dijo que este era “definitivamente uno de los proyectos más complicados” en los que había trabajado en su vida, y que era la primera bandera roja para mí. Asumen que a medida que la complejidad aumenta, también lo hace el valor. De hecho, la verdad suele ser exactamente lo contrario. A medida que aumenta la complejidad, la calidad del proyecto suele disminuir. el hecho es que la complejidad es el enemigo de los proyectos de software exitosos. Si piensas en lo que es un patrón, es algo que ponemos en práctica para ayudarnos a eliminar la complejidad. Al colocar las piezas difíciles de entender en abstracciones, los patrones se enfrentan a la complejidad para que no tengamos que hacerlo nosotros. Añade un par de características. Tienes una ráfaga inicial de energía y creatividad en torno al proyecto. Todo va rápido y sin problemas. Con el tiempo, sin embargo, se añaden más funciones a este proyecto. Con cada uno de ellos, usted comienza a pagar un impuesto de complejidad. Lo que comenzó como un simple prototipo usando algo como operaciones CRUD se vuelve demasiado complicado. Especialmente si no estás prestando suficiente atención a las acciones o eventos que ocurren. Es decir, si no tienes buenos patrones, así es como terminas con algo que se conoce como Diseño de Dominio Anémico, donde la lógica está alrededor del modelo en lugar de ser parte de él. Se modifican las cosas y se insertan los estados, y todo lo que se termina guardando al final del día es el estado actual, hay grandes problemas con un Diseño de Dominio Anémico. Martin Fowler, autor de Refactoring: Mejorar el diseño del código existente lo describe como un “anti-patrón” que sólo se parece al diseño en “primer vistazo”. ¿El problema? A medida que se profundiza, se ve que “casi no hay ningún comportamiento” unido a los objetos que hay en su interior, ¿cuál es el resultado práctico de este anti-patrón y su comportamiento mínimo? Es una pesadilla para los desarrolladores cuando necesitan cambiar algo, lo que no es el tipo de software duradero y de fácil mantenimiento al que deberíamos aspirar. ¿Por qué querríamos complicar las cosas, cuando podemos hacerlas fáciles? para la alternativa a este tipo de principios, recurrimos a Eric Evans, el autor de Domain-Driven Design: Tackling Complexity in the Heart of Software y padre de Domain-Driven Design (DDD). En términos sencillos, esto es algo que introduce mensajes y luego los emite. (Puede ver su excelente presentación sobre DDD y microservicios aquí, si está interesado en una explicación más detallada.) Hay dos tipos de mensajes que son realmente importantes para estos sistemas. El primero son los comandos y el segundo los eventos, y tenerlos en cuenta nos permite usar un patrón llamado servicebus. Piensa que es básicamente un emisor de eventos para todo tu sistema. La principal ventaja y desventaja de cada uno de ellos es que, al utilizar este patrón, se eliminan las herramientas que se están utilizando para implementar esta funcionalidad. Otra cosa que sucede sin un servicebus es que, debido a que sus microservicios tienen que comunicarse de alguna manera, muchos terminan haciendo llamadas REST. Y si se trata de REST, entonces REST no es tan fiable como una cola de mensajes persistente, y para solucionarlo, terminas trayendo otras cosas como Istio u otras mallas de servicio. Estas son sólo algunas de las herramientas que tenemos a nuestra disposición en lo que debe ser una batalla constante contra la complejidad. Muchos de los patrones pueden tener nombres complicados, pero la realidad es que no son tan complicados cuando se miran desde un alto nivel, por supuesto, todo esto es discutible si no se tienen las abstracciones correctas cuando se van a implementar. Si oyes que algo es complicado, debería ser tu señal de que algo ha desaparecido.

Etiquetas

SoftwareengineeringDiseñoCodificaciónSimpleSoftwareEngineeringLatest Tech StoriesComplejidad de la ingeniería del software

Comentarios

Continúe la discusión