Contra el ovillo de lana: desenredo de estructuras de software desarrolladas

Contra el ovillo de lana: desenredo de estructuras de software desarrolladas

Con un nuevo proyecto greenfield, puede y debe decidir sobre una arquitectura adecuada desde el principio y verterla en módulos (Maven) apropiados, cada uno con sus propias dependencias. Con tantas reliquias crecidas o cubiertas de maleza, esto ya no es posible después. La estructura de estos tesoros debe ser reconocida y constantemente mejorada. En este artículo, aprenderá cómo hacer esto sistemáticamente. Para esto se utiliza una pequeña biblioteca de Java, que se puede utilizar para comprobar las dependencias entre clases.

Wider das Wollknäuel – Entflechtung gewachsener Software-Strukturen

prehistoria

A principios de la década de 2000, como desarrollador junior en un proyecto EJB 2.0 clásico, tuve la tarea de escribir pruebas (unitarias) para mejorar de alguna manera la calidad del código después. Esta tarea resultó ser extremadamente difícil porque todo estaba entrelazado y no se podía probar la funcionalidad parcial sin iniciar la aplicación completa. La aplicación funcionaba más bien mal que bien, siempre había problemas, los errores eran difíciles de entender y las supuestas correcciones de errores generaban nuevos problemas. Por lo tanto, se consultó a un consultor externo. Junto con el arquitecto, elaboró ​​la estructura del proyecto e identificó una solución. Esto resultó en un extenso proyecto de refactorización en el que se resolvieron las dependencias cíclicas en particular.

Se utilizó una herramienta de código abierto llamada Dependometer para monitorear el progreso [1]. Utilicé la herramienta en proyectos de seguimiento, pero pronto me di cuenta de que nadie tenía tiempo para analizar informes HTML complicados en el estresante trabajo diario de un proyecto. Un semáforo en rojo en el entorno de CI sería ideal, indicando violaciones de la arquitectura, similar a una prueba unitaria fallida. Entonces, nada es más obvio que implementar dichas comprobaciones de arquitectura como una prueba unitaria. Sin embargo, las bibliotecas adecuadas para ello eran escasas y traían consigo conflictos de dependencia. Por lo tanto, decidí escribir mi propia biblioteca para este propósito, que no tiene dependencias y se las arregla con una versión de Java muy antigua (Java 6) para que realmente pueda usarse con cualquier reliquia. Por supuesto, la biblioteca también se ejecuta con versiones de Java más nuevas hasta Java 16.