- 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.