Barrapunto

Gracias por esta entrada.
Mientras iba leyendo he ido identificando mentalmente cada parte con el caso real donde trabajo.
En la metodología para reducir la deuda tecnológica que describes, indicas que hay que diferenciar en el punto B, lo que no funciona bien porque hace "crash" (B1), y lo que es horrible a nivel de código aunque funciona bien como caja negra (B2)


La dudas que tengo son:
duda 1) ¿que se hace luego con las partes detectadas de B2?
duda 2) ¿y si se da el caso llamémosle "B3": "que funciona bien pero no es una caja negra"?


Un ejemplo: tenemos un "monstruo" de aplicación web que data del año 2000 y que no ha evolucionado en cuanto a tecnología. Es horrible a nivel de código: - sin diseño Modelo Vista-Controlador. Toda la lógica de la aplicación esta metida en las páginas jsp, que son gigantescas. Los jsps son un caos en los que va todo: desde la lógica con scriptlets, llamadas a la base de datos con sql, hasta código java que en ultima instancia sirve para pintar los elementos en pantalla
- utiliza librerías no estandar de las que no existe documentación, por ejemplo: en lugar de usar jdbc, toda la aplicación utiliza para el acceso a datos una librería que se coloca por encima del api jdbc. Tambien utiliza una especie de seudolibrería para la presentación que hace la función de pintar elementos html. El no usar tecnología estandar hace que los desarrolladores necesiten formación extra de la que no disponemos.
- No hay código de pruebas


La aplicación funciona "bien", pero adolece de una interfaz de usuario amigable. Además es practicamente imposible meterle mano, por lo que cuando hay que corregir algo o cambian los requisitos, el monstruo crece otro poco.
Mediante la refactorización se podría ir corrigiendo poco a poco, pero cuesta mucho menos hacer la aplicación entera de nuevo.
(Reflexión personal)... posiblemente el llamado "B3" en este caso es intratable. Habría que tratar la aplicación entera como un "B2" y no tocarla. En nuestro caso lo único que podría aprovecharse de la aplicación es el modelo de datos. He pensado que una posiblidad sería plantear una arquitectura-infraestructura MVC con tecnología estandar nueva (JPA, JSF, spring) partiendo de ingeniería inversa, integrarlo en paralelo con el código existente y a partir de ese momento toda modificación-corrección o nueva funcionalidad realizarla en el código bueno.

Usarlo mientras se necesite, pero no hacer ninguna expansión sobre ello. En el punto 3 de prevención de problemas comentaba algo al respecto: <<Intenta evitar nueva funcionalidad a una base de código malo: Añade lo nuevo en un contexto "sano", i.e. si tienes componentes defectuosos pero que "funcionan" y no puedes permitirte reprogramarlos, en lugar de añadirles funcionalidades nueva dentro, hazlo en otros componentes nuevos.>>.

Intentaría encapsularlo, sin tocar "las tripas", y añadir una interfaz que lo haga operar como una caja negra a través de una API ad hoc.

Pinta bien. Te ahorras el hacer doble mantenimiento, añades lo nuevo en un contexto sano/mantenible, y evitas reescribir "el monstruo espantoso, pero que funciona bien".