Estoy en un proyecto del que estoy hasta los cojones, se entrega en enero y llevo un mes con el, y la verdad no sabria calcular la estimación total, ni yo, ni ningún analista de este planeta. Vamos a ponernos en situación, y a filosofar un poquito sobre la programación que se practica por aquí. Hay una serie de aplicaciones web hechas con JSPs y muchisimo javascript a pelo, es decir sin frameworks ni nada, y funcionan, de hecho hasta su mantenimiento no es tan incomodo como podia parecer, pero se está migrando todo a un framework propietario super chulo de la muerte basado en struts,
La perspectiva no parece muy mala, al fin y al cabo el framework propietario tiene sus ventajas a la hora de programar, la principal que no hace falta saber programar, el problema es que precisamente quieren que pongan a monos programando con el, debe ser por eso pasa por 300 clases para poner un hola mundo, y 300 mas para ponerlo centrado y en negrita, esto es facil de ver cuando salta una excepción no controlada y el track ocupa 5 pantallas (scroll). Lo mas insoportable del framework es que para moverte de una pantalla a otra, en linea recta perfecto, como quieras hacer un salto a otro lado, prepara tu imaginación y mogollon de rato para mapearlo todo, no basta con meterlo en sesion (StrutsContext). Dado que está pensado para ir en linea recta y palante, un simple menú que permita saltar entre las pantallas es lo mas tedioso de implementar, depende de como lo plantearas, una nueva pantalla representar modificar todas las vistas, y todos los webeans (flujos).
El otro gran quebranto es la migración, los modelos aquí son comunes en muchos proyectos, pero creeis que he podido reutilizar ni una sola clase de modelo? juas, ya me gustaria a mi, vereis, struts 1, o al menos la forma en que aquí lo utilizan, es muy bonito cuando tus modelos o beans tiene todas las propiedades como Strings, o alguna clase que implemente toString y te de su valor, como fechas etc, pues bien, aquí el colega programador super purista ya divido los datos en mogollon de clases, vease por ejemplo que un Cliente, tiene propiedades de la clase Domicilio, siendo domicilio una clase con las propiedades calle, numero, pisoPuerta, ciudad, cp, las cuales si son Strings, o si no hay suerte pueden ser de otros tipos propios. Esto va fatal para trabajar aquí, la cosa es que estos modelos no son del proyecto en JSPs, son de proyectos YA MIGRADOS!!, acojonante.
Total todos los modelos y beans nuevecitos de mi puño y letra, lo mas fácil ha sido hacerlo por pantallas, al ser una serie de formularios (como todo vamos) pues un bean con todos los datos de la pantalla, que es lo que le mola para luego pintar o recojer los datos (sobretodo recojerlos), en serio no soy yo, es que al fwork le va mejor. Total, aun por la mitad estoy añadiendo nuevas propiedades a estas clases.. pq? bueno, vayamos a la información de la que dispongo.
Acceso parcial a la aplicación original: pues como no podia ser de otra manera tiene fallos, sobretodo de javascript y como solo funciona en IE y es bastante especial se complica mucho pasar de pantalla, asi que no puedo ver ni todos los pasos ni hacer pruebas.
Screenshots de las pantallas actuales: posiblemente lo mas util del proyecto, ya que yo no consigo acceder a todo que mejor que poder ver como serian esas pantallas, estas screenshots han servido para reproducir las pantallas y crear los modelos.
El analisis de requisitos: vaya, ahora es cuando muchos pensaran que seré un inutil por no saber aprovechar este documento, amigos, el que consiga aprovechar este documento que me lo diga, es el analisis de requisitos original, solo le falta estar escrito en castellano antiguo, 27 paginas en las sobra redundancia, y creo que muy mal separado, si implemento un método que valida algo, quiero cerrarlo y punto, no quiero pasar 3 paginas y tener que editarlo, y pasar 3 mas, borrar lo anterior y volverlo a editar y si me lo leyera entero primero, no serviria, demasiados detalles que no recordaria, asi que hay que seguirlo paso a paso.
Con este material estoy lidiando, siguiendo el documento que me proporcionaron y que cada vez me cansa mas, sobretodo esos requisitos concretos de cada cliente, vale son requisitos y hay que ponerlos, pero joder, seguro que habia una forma mejor de indicarlo.
Para rematarlo la base de datos es comun para TODOS los proyectos en desarrollo, una fantastica db2 que debió inventarse antes que el fuego y que no para de ser tocada por todo cristo, lo cual conlleva a que en medio del desarrollo deje de funcionar la consulta de datos… genial vamos. Desde luego tengo algunas ideas de como mejorarlo, pero a estas alturas ya es chungo, no voy a volver a empezar.
Voy a citar un texto que me explico un compañero, es de un libro de “teoria de programación”, y creo que es muy acertado:
Si en un barrio, se rompe una ventana y nadie la repara, a la larga la gente que pase por ese barrio y vea la ventana pensaran que en este barrio no se cuida nada, así que el siguiente que pase no se molestará en tirar su lata de cocacola a la papelera, la dejará por ahí, y si se rompe otra ventana tampoco la repararán, y el siguiente que pase aun le parecera que lo cuidan menos ese barrio. Con esto quiero decir que los proyectos de software son como ese barrio, si hay un pegote de mierda enorme en los requisitos, no va a er el programador el que lo limpie, y dejará también pegotes en su código, y el siguiente programador que venga detras de el, cuando vea tal spaguetti hará lo mismo, haciendo la bola de mierda mas grande, hasta que llega un dia que hay que migrar la aplicación, y si se reaprovecha la basura que habia antes, pues acabará pasando lo mismo…, mas spaguetti, ni por muchos frameworks propietarios ultraproductivos que se utilicen, la cosa no va a mejorar por que sí a no ser que se replantee bien desde sus raices.
Fin del /cry.
. Pero bueno al menos tubimos una cena muy bonita los dos en un restaurante 
jeje, muy romantico todo.
.
.
