LA COMPLEJIDAD ESTÁ MATANDO A LOS DESARROLLADORES DE SOFTWARE

La creciente complejidad de las estructuras de software modernas pone constantemente en el lecho de muerte a los desarrolladores de software. La complejidad del software hace que el trabajo de los desarrolladores sea agotador ya que; planificar, construir y probar productos se vuelve difícil. La instigación de nuevos retos de seguridad crea frustración en administradores y usuarios. En la mayoría de los casos, complicado y complejo tienden a ser indistinguibles, pero no en este caso. La complejidad sugiere que algo es difícil de comprender, pero a medida que pasa el tiempo, con esfuerzo, puede llegar a conocerse. En cambio, lo complejo representa la interconexión entre varias entidades. Cuando el número de entidades aumenta, las interconexiones también aumentan enormemente y llegan a un punto en el que es impracticable conocerlas y comprenderlas.

En consecuencia, unos niveles excesivos de complejidad en el software aumentan el riesgo de obstruir accidentalmente las interconexiones. Algo que aumenta la posibilidad de introducir defectos al aplicar cambios puede hacer que mejorar el software sea prácticamente imposible.

Complejidad del software

La complejidad del software es la dificultad de mantener, analizar, probar, modificar y diseñar software. Cuanto mayor es la complejidad, más exigente es leer y mantener el software, y más posibilidades hay de que se produzcan fallos y defectos. La complejidad del software es una técnica que expresa un conjunto específico de características del código. Todas estas características se centran en cómo se conecta su código con otras piezas de código.

La complejidad del software se considera un factor determinante en los costes de mantenimiento del software. Una mayor complejidad del software implica que los proyectos de mantenimiento y mejora llevarán más tiempo, costarán mucho más y darán lugar a más fallos. La complejidad del software de un sistema concreto es uno de los beneficios dominantes a largo plazo de cualesquiera herramientas y enfoques que se hayan aplicado en su desarrollo inicial. Por ejemplo, la utilización de nuevos equipos CASE da lugar al desarrollo de un software mal estructurado. Las consecuencias de esa mala estructura se experimentarán cuando llegue el momento de ajustar el sistema.

Tipos de complejidad del software

La complejidad del software es cada vez más problemática a medida que evoluciona la industria de la ingeniería. Como desarrollador, con frecuencia dedica mucho tiempo a escribir, pero más tiempo dedica a mantener ese código. ¿Con qué frecuencia se encuentra con que el código se ha vuelto enmarañado y casi no puede entenderlo? Para comprender cabalmente cómo manejar la complejidad cada vez mayor, es esencial diferenciar los tres tipos fundamentales de complejidad del software.

Complejidad esencial

La complejidad esencial suele encontrarse en el ámbito empresarial en el que trabaja. Está relacionada con el problema y no puede eliminarse. Está asociada a las reglas de política empresarial que dirigen los procedimientos empresariales en términos más específicos. Cuando se esfuerza por aplicar y automatizar el procesamiento de esas reglas políticas, se encuentra con varios niveles de complejidad. El hecho de que las empresas suelan ser entornos excesivamente impenetrables hace que el problema que intenta solucionar sea inherentemente complejo. La complejidad esencial viene generada por los atributos del problema a resolver y no puede reducirse.

Por mucho que lo intente, esta complejidad no se puede paralizar porque la política empresarial que regula la tramitación de un siniestro exige 15 pasos distintos. Por lo tanto, no puede aclarar las normas saltándose algunos pasos y aplastando la tramitación a unos pocos pasos básicos. En resumidas cuentas, la complejidad esencial es inevitable y, ante todo, la verdadera razón por la que usted trabaja como ingeniero de software.

Complejidad accidental

Esta complejidad se refiere a la resolución de un problema directamente relacionado con la forma en que usted decide resolverlo y está menos asociada a la naturaleza de la complicación. Cuando adopta una estrategia para solucionar un problema que requiere más complejidad y trabajo, complejidad accidental. Podría ser la elección de sus herramientas de desarrollo de software y lo que pone sobre la mesa al descifrar el problema. Esta complejidad no es inherente a la situación que debe resolver, sino que se ha colado por accidente. La complejidad accidental se manifiesta en un mal diseño o estructura, código y procedimientos de desarrollo de software deficientes. La única forma de eliminar la complejidad accidental es eliminando su fuente.

No se puede poner en marcha la complejidad accidental intencionadamente. Incluso el nombre lo dice todo «accidental». A veces surge cuando usted:

  • ¿Desea utilizar un nuevo lenguaje o herramienta para superar un proyecto que no es el adecuado?
  • ¿Está obligado a utilizar una pila tecnológica específica?
  • Desconocimiento de las prácticas más aceptables para descifrar este problema concreto.

Causas de la complejidad en el software

El problema fundamental del software es la complejidad. El software es un sistema a gran escala que consta de cientos de microservicios que se llaman y dependen unos de otros. Muchos aspectos del software pueden no estar muy claramente definidos. A continuación se exponen algunas de las causas cruciales que conducen a la complejidad en el desarrollo de software.

  • Elegir las herramientas equivocadas. En ocasiones, tiene prisa por empezar o simplemente le encanta utilizar una herramienta concreta cuando trabaja con código. Digamos que está trabajando en un sitio web de cuatro páginas que requiere Ruby on Rails o una API web RESTful, pero usted insiste en construir el sitio utilizando Objective C. No quiere decir que Objective C sea eficaz o lo suficientemente bueno, pero simplemente se implementó para el problema equivocado. Esto puede dar lugar a complejidad en su código.
  • Construir sistemas sobre sistemas: los sistemas se formulan jerárquicamente. Por ejemplo, los sistemas bancarios se crean sobre software de Internet construido sobre software de telecomunicaciones. El software de telecomunicaciones descentraliza el poder adquisitivo y el poder de decisión interna y externamente debido a la crucial reconfiguración ágil de la nube. Esto también provoca la complejidad del software.
  • Aplicar abstracciones erróneas. De vez en cuando, descubrirá un software sobre un vocabulario concreto, tal vez registros de biblioteca, pero que se escribió utilizando otro lenguaje, digamos un tipo de datos CMSes posts. La abstracción es buena, pero no es la correcta. Todo se hizo mucho más difícil por la necesidad de manipular la incoherencia entre los dos conceptos.

HERRAMIENTAS PARA REDUCIR LA COMPLEJIDAD DE LA CODIFICACIÓN

La funcionalidad incorporada a un sistema y la integración entre sus subsistemas influyen abiertamente en la complejidad del sistema. Se necesita una estabilidad ideal entre la funcionalidad y la coordinación dentro de un sistema para lograr una complejidad reducida. En el mundo real, no siempre se puede mantener la sencillez del software. Normalmente, los atributos de las aplicaciones que ofrecen valor empresarial tienden a tener complejidad. Sin embargo, muchas formas se centran en disminuir la complejidad para los ingenieros; se pueden utilizar otros enfoques para minimizar el nivel de complejidad de su aplicación más allá de aprovechar las arquitecturas de microservicios.

Desarrollo asistido por software

Se trata de la capacidad de utilizar herramientas, normalmente asistidas por técnicas de inteligencia artificial y aprendizaje automático, para ayudarle a escribir código, diagnosticar problemas en el código y controlar la complejidad general del código. Este enfoque le permite ejecutar pruebas precisas y rápidas que minimizan la tasa de complejidad, ya que los errores se detectan fácilmente y reducen el proceso de desarrollo. Empresas como GitHub utilizan la IA para ayudar a los desarrolladores a escribir un código más fiable y con menos defectos.

Establecer una plataforma interna

La creciente complejidad ha llevado a muchas empresas a adoptar un modelo de plataforma interna. Al equipo de la plataforma interna se le confía la evaluación de las herramientas más vitales por parte de los ingenieros, la estructuración de plantillas y la facilitación de su proceso de producción. El equipo también se centra en funciones como la seguridad, las operaciones financieras y la gobernanza para reducir la carga cognitiva de los desarrolladores individuales.

La solución para una plataforma interna de desarrolladores aceptable consiste en observar el equilibrio entre el autoservicio para los desarrolladores que quieren ponerse manos a la obra y la abstracción de las tareas prácticas menores sin restringir a los desarrolladores.

MÉTRICAS DE COMPLEJIDAD DEL SOFTWARE

Cuanto mayor sea la complejidad, más agotador será mantener y leer el código, y más fallos y defectos encontrará. Medir la complejidad del software puede ayudarle a comprender y abordar el problema mientras sigue siendo menor. Las siguientes métricas pueden utilizarse para evaluar la complejidad.

Complejidad ciclomática

Esta métrica se basa en la teoría de grafos y en otras definiciones matemáticas. La complejidad ciclomática mide la complejidad estructural del código. Esta métrica estima el número de caminos linealmente independientes a través de un programa. Un camino linealmente independiente es una forma elegante de decir un camino único en el que sólo se cuentan los bucles una vez. Operaciones como IF, DO y SELECT constituyen lógica condicional, lo que hace que el programa sea más difícil de comprender. Cuantos más procedimientos de este tipo existan en el código, más ramas lógicas albergarán y mayor será la complejidad ciclomática.

Esta métrica puede determinarse utilizando la fórmula siguiente

V(G) = e – n + 2p

Donde: e = es el número de aristas del grafo

n = número de notas en el gráfico

p = número de componentes conectados

Índice de mantenimiento

Calcula el valor del índice entre 0 y 100, que constituye la facilidad relativa de mantenimiento del código. En otras palabras, esta métrica mide lo mantenible que es su código. Cuanto mayor sea el valor, mejor será la mantenibilidad de su código. El índice de mantenibilidad se calcula como una fórmula factorizada de SLOC (líneas de código fuente), complejidad ciclomática y volumen Halstead.

Métricas de Halstead

La métrica estima cuánta información objetiva existe en el código fuente, incluido el número de variables y cómo se utilizan en el código fuente, las funciones y los métodos. Se especula que cuantos más elementos independientes haya en el código y más se empleen, más complejo será el programa. Esta métrica depende de la ejecución del código y de sus medidas, que se calculan estáticamente a partir de los operadores y operandos del código fuente.

La métrica de Halstead puede calcularse con la siguiente fórmula

Difícil = L / V

Donde L = Nivel del programa

V = Volumen del programa

La fórmula para determinar el nivel L del programa es

L = (2 + n2*) *log2 (2 + n2*)

Donde: n1 = número de operadores

N2 = número de operandos

El programa para determinar el volumen del programa V es:

V = (N1 + N2)* log2 (n1 + n2)

Donde N1 = número total de ocurrencias del operador

N2 = número total de apariciones del operando

Métricas de diseño orientado a objetos

Las métricas cuantitativas para el diseño orientado a objetos suelen centrarse en las características de las clases y el diseño. Permiten a los desarrolladores evaluar el software en una fase temprana del desarrollo y comprender cómo minimizar la complejidad y mejorar la mantenibilidad.

EFECTOS DE LA COMPLEJIDAD DEL SOFTWARE

Impacto de la complejidad en las tasas de error.

El objetivo de por qué a los desarrolladores nos preocupa la complejidad está relacionado con aspectos más importantes del proceso de desarrollo de software. Cuanto más difícil de entender sea el código, más probabilidades habrá de que no se descubran los errores de programación. Cuando un programa es difícil de probar, los errores no se detectarán antes de que el software funcione.

Se esperan tasas de error elevadas en programas que manifiestan altas densidades de decisión (con su número igualmente distribuido de caminos de decisión para comprobar los errores). Es probable que se generen nuevos errores en este tipo de sistemas.

Impacto de la complejidad en los costes de mantenimiento

La complejidad del software tiene un impacto directo en los costes de mantenimiento. Cuanto más exigente sea el mantenimiento de un sistema de aplicación complejo, más gastos se producirán durante el mantenimiento, que consume la mayor parte del proceso de desarrollo. El mantenimiento del software se percibe como un procedimiento de producción cuyos insumos son los recursos informáticos y la mano de obra, y el resultado es un código mejorado. Las horas de mano de obra son considerablemente más significativas que los recursos informáticos, y ambos tienen posibilidades de sustitución insustanciales. Se presta atención a las horas de mano de obra como el gasto considerable en el que se incurre.

UN REMEDIO PARA LA COMPLEJIDAD EN EL DESARROLLO DE SOFTWARE

Aunque las arquitecturas de microservicios crean aplicaciones más extensas y complejas, desentrañan el trabajo de los desarrolladores de base. Las arquitecturas de microservicios generan una aplicación más compleja que una aplicación correspondiente construida como un monolito. Aun así, esto no significa que el trabajo del desarrollador sea más complicado.

Complejidad de la arquitectura de microservicios.

La arquitectura de microservicios es un DevOps que proporciona una técnica más dinámica y ágil para ejecutar, desarrollar y gestionar aplicaciones trabajando con componentes modulares frente a una construcción monolítica.

Para muchos, se supone que los microservicios curarán todos sus problemas de complejidad del software. Sin embargo, sólo pueden rehabilitar el cincuenta por ciento de esos problemas por sí solos. Para resolver la otra mitad, debe fusionar los microservicios con las últimas prácticas de DevSecOps y convertir su empresa en la máquina de matar definitiva.

Los microservicios sancionan a las empresas para ejecutar un millón de despliegues diarios, escalar el sistema hasta el infinito, minimizar la complejidad de la base de código y ahorrar recursos. Los microservicios trasladan la complejidad de los servicios a la plataforma, ignorando los hechos se obtienen resultados subóptimos. Muchas empresas han diseñado aplicaciones monolíticas sólo para descubrir que se vuelven demasiado complejas. Como desarrollador que opera en una única base de código, resulta pesado añadir funciones y rectificar defectos de forma independiente. Normalmente, esto limita el número de proyectos en los que puede trabajar en una sola aplicación.

Los microservicios hacen que una aplicación sea menos compleja al eliminar determinadas partes de ella. Cuando divide la aplicación en diferentes módulos, está intentando dividir esa complejidad para minimizar el número de desarrolladores que trabajan en una única base de código. La división puede hacerse de modo que desarrolle una complejidad organizada que sea fácil de entender.

El modelo de complejidad del software

Las causas de la complejidad se han tratado en la génesis de este capítulo. La complicación confiere al proyecto una complejidad inherente, y luego surge más complejidad en el transcurso del diseño y la fase del proceso de desarrollo del software. Según este modelo, la complejidad se une a otros factores para determinar la propensión a errores y el tamaño del programa. También se ha discutido la naturaleza, las fuentes y los efectos de la complejidad del software y se ha proporcionado un marco teórico para una divulgación gráfica del concepto de complejidad del software.

CONCLUSIÓN

Muchas empresas tienen que lidiar con la complejidad del software, y los enfoques que utilice al abordarla afectarán al futuro de su empresa. Hay varias formas de gestionar la complejidad del software. Enfoques como el establecimiento de una plataforma interna y la estandarización de los servicios externos en toda la empresa pueden ser buenas estrategias.

Además, aunque las arquitecturas de microservicios aumentan la complejidad del software, ofrecen el valor de minimizar la carga cognitiva y la complejidad visual para los desarrolladores individuales.

DevologyX OÜ
Harju maakond, Tallinn, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Cape Town
7530

[email protected]

DevologyX OÜ
Harju maakond, Tallin, Lasnamäe
linnaosa,
Vaike-Paala tn 1, 11415

+372 6359999
[email protected]
DevologyX Limited
Nakawa Business Park
Kampala
Uganda

+256206300922
[email protected]

DevologyX Pty Ltd
Tijger Park 3
Willie van Schoor Drive
Bellville
Ciudad del Cabo
7530

[email protected]