 |
| Proyecto multicapa y fractal: una pequeña variación en las condiciones iniciales produce resultados muy diferentes |
Desde hace una década hemos oido constantemente por parte de los fabricantes de herramientas para el desarrollo de software incontables loas hacia la programación multicapa en entornos empresariales.
Aquí voy a comentar mi experiencia en un campo muy concreto: el desarrollo de sistemas. En él, he descubierto la completa inutilidad del planteamiento multicapa. No dudo que no sea rentable en otro tipo de entornos, pero desde luego no en el que voy a describir.
Mi campo de acción en los últimos años fue el desarrollo de sistemas informáticos para grandes corporaciones nacionales. Estos proyectos suelen tener como características comunes el estar apoyados en una base de datos
Oracle o SQL Server y un lenguaje de páginas web como ASP o JSP. Debido a que estos proyectos son subcontratados a consultoras, y las peculiares características de estas, en estos desarrollos suelen trabajar en el desarrollo programadores junior con poca experiencia (el índice de rotación de las consultoras es altísmo). Eso si tiene usted la suerte de estar en Madrid o Barcelona. Si usted está leyendo esto desde Aragón no tenga la menor duda: independientemente de con quien hable usted su proyecto lo está realizando un becario.
En estas condiciones, normalmente comienza una fase que dura unas dos semanas en la que los jefes de proyecto se ponen a teorizar junto con el cliente sobre los grandes beneficios de la programación orientada a objetos y la facilidad de mantenimiento que conllevará. Ya nos estamos frotando las manos con todo el dinero que vamos a ahorrar. Como no nos dimos cuenta antes que nuestro proyecto web necesitaba objetos? Para que queremos rentabilidad si podemos tener objetos?
Luego llegan los junior que de entrada no tienen ni la mas remota idea de programación orientada a objetos. Este duro camino se ve además completado por el marco de trabajo que las aplicaciones multicapa imponen (interfaces de los objetos, versiones de los mismos, repositorio de objetos...).
Hasta ahora todo es ganar, pero esperen que viene lo mejor. Cuando el sistema comienza a ser puesto en producción aparecen problemas alucinantes e inexplicables. Como hemos inventado la rueda de nuevo, problemas que a nivel de base de datos estaban complemente solucionados (como concurrencia a recursos, reutilización de los mismos,integridad de los datos ...) producen expedientes x que dejan a nuestro equipo anonadado, y le tiene entretenido otro par de semanas. Por supuesto ya ha habido que solicitar al cliente un retraso en la puesta en producción.
Sigan leyendo, lo mejor está por llegar. El sistema se ha puesto en producción y efectivamente, con la arquitectura multicapa va un 0,1% mas rápido. Esperemos que no les pase como a una consultora que despues de implementar el marco de aplicación empresarial propuesto por Sun tuvo que migrar todos los objetos porque habiéndolos diseñado correctamente la eficiencia de J2EE no daba para más.
Pero ahora es cuando vamos a comprobar la mantenibilidad del código. Resulta que sobre la tabla más tonta de nuestro sistema, clientes, se ha añadido el campo ‘Preferencias’. Los programadores disfrutarán añadiendo el campo en la tabla, los procedimientos almacenados, los objetos de acceso a datos, la lógica de negocio, y la capa de presentación. Innegable: la programación multicapa hace el código mucho más mantenible.
Tres días mas tarde se descubre que una pantalla falla, y el programador comienza trazando el problema en la pantalla, allí identifica una llamada al objeto objAltas, que llama al objeto objNegociarAltas, que llama al objetos objDatosAltas, que accede mediante el procedimiento almacenado spGetAltas a la tabla de altas. Como no identifica el problema comienza a poner trazas en todos los objetos para reproducir el error. Cuando lo encuentra solo tiene que recompilar 3 objetos, que luego tendrá que subir a cada uno de los entornos en los que esté instalado el sistema.
Es innegable, la programación multicapa son todo ventajas.
El primer gran proyecto en el que participé consistía en un aplicativo de facturación construido sobre Netdynamics como servidor de aplicaciones y Oracle. Cuando había algún tipo de transacción compleja se encapsulaba en un procedimiento almacenado.
Posteriormente, la aplicación se migró a J2EE. Se cambiaron las pantallas pero toda la estructura de datos y la lógica de negocio permaneció inalterada allí donde debe de estar: en una buena base de datos.