Retomar una aplicación de otros
Bueno, acabas de llegar a una nueva empresa, o llegas de consultor a "solucionar problemas". El caso es que te tienes que meter con una aplicación desarrollada durante más de un año. Cuando te saludan, te dan un sitico con su ordenador, te dicen como conectar al repositorio de CVS y que si tienes alguna pregunta, -no te cortes- pregunta a tus nuevos compañeros.
- Eim, ¿por dónde puedo empezar a leer la documentación?
- Sí, chaval, mmm, no sabes que la metodología XP habla de que el código es la mejor documentación. Es que está muy desactualizada, igual te lía mas...
- ouch, vale, ¿y de qué va la aplicación?
- Bueno, fácil, es una gestión de recursos para "maximizar el valor de nuestros accionistas mediante el contexto estructural asertivo"*.
- Claaaro.
- El caso es que va lento, mira a ver que puedes hacer...
Y ahí te quedas.
Generalmente se da esta situación de dos maneras: O bien para crear nuevas funcionalidades a un proyecto que ya está funcionando, o bien para terminar un desarrollo en que te incorporas en medio del proyecto (o a solucionar bugs o problemas de eficiencia). En cualquier caso, los primeros días suelen ser intensos, y a veces divertidos!
- Intenta conocer el dominio de la aplicación a nivel general. Ten una visión general de TODO el dominio, y más en particular de lo que te vaya a tocar trabajar. O sea, que te expliquen un poco el análisis funcional
- Al principio no te centres en los detalles del código. Intenta ver la estructura desde una buena altura. Que te cuenten las "guías de diseño" que siguieron (si lo hicieron).
- Intenta que al principio tu código no afecte al resto, sobre todo si este funciona. Más tarde te darás cuenta de qué no comprendías exactamente como funcionaba.
- Realiza una aproximación "top-down" sobre los problemas para verlos en su contexto, no vayas directamente al "pedacico" de código que parece dar el error.
- Lee solo la documentación sobre el código que te aseguren que está actualizada. De otra manera solo tendrás un lío mayor.
Cuando llegué a la Editorial Aranzadi como consultor, lo primero, me contaron en una charla de más de dos horas a qué se dedicaba la compañía, cómo se organiza la información jurídica, como eran las bases de datos de legislación y jurisprudencia, etc... Una introducción perfecta para mi labor allí, aunque esa reunión fue un poco dura, no os vayais a creer ;)
*De ESTRATEgA: Hable como un Gurú. :D
Realmente muy buenos consejos, muy útiles y afinados.
ResponderEliminarEn el libro "UML gota a gota" también recomiendan hacer un esquema de alto nivel del dominio de la aplicación en UML (no de los objetos de la aplicación) para que los "expertos" locales te lo validen y poder entender mejor las cosas.
Muy buenos consejos, porque el mantenimiento es la asignatura pendiente de muchas empresas que lo suelen gestionar tal y como lo describes.
ResponderEliminarAunque del total de horas de programación, la media estadística da más parte a tareas de mantenimiento que a las de desarrollo de nuevos sistemas, lo cierto es que es el patito feo de nuestra industria.
A cualquier programador le resulta mucho más atractivo trabajar en desarrollos nuevos que en mantener en marcha viejas cafeteras.
Muchas empresas menosprecian o no se dan cuenta de la importancia del mantenimiento. Lo emplean como castigo o como tarea para los recién llegados...
¡Uffffffffff!
ResponderEliminarHay dos cosas que se descuidan: la documentación y el cierre de los proyectos.
Es como las obras en los pisos: no sabes muy bien cómo es el papeleo (¿realmente qué acredita que tu casa es tuya?) y luego la constructora no le da importancia a que falta el grifo en un baño, o que no colocaron un enchufe en cierta habitación... Porque ¿acaso no puede vivir allí (se ejecuta sin errores [graves])?
Juanjo: Realmente recordaba haber leido algo sobre eso, pero no sabía dónde, le volveré a echar un nvistazo.
ResponderEliminarJuan: Toda la razón sobre lo del patito feo. Lo malo es que es absolutamente necesario cambiar la "fachada" de vez en cuando, y luego ya nadie sabe como hacerlo.
Escéptico: Además, el cierre de los proyectos creo que queda casi siempre como una mera formalidad... y una cena, a veces.