Los proyectos legacy... esos proyectos que por lo general fueron iniciados por alguien más. Aunque a veces fueron iniciados por nosotros mismos. Por lo general son viejos y ya no programamos así o en ese lenguaje. Alguien tiene que darles mantenimiento, corregirlos...
Cuando nos toca empezar a trabajar en un proyecto de esos a veces puede ser frustrante el tratar de moverle, agregarle funcionalidad usando herramientas "anticuadas" o usando convenciones de nombrado diferentes a lo que quisiéramos. Siempre está ese pensamiento, indecisión de: "Y si lo reescribimos" o "seguiremos usando lo mismo". Es pesado trabajar en proyectos así, sobre todo si fue hecho de una manera poco organizada o si cuenta con mucha deuda técnica. Es fácil caer en quejas y empezar a verlo todo mal.
La experiencia de haber visto otros proyectos similares, de conocer diferentes arquitecturas, haber leído artículos sobre cosas que la gente intenta te ayuda a darte una idea de que estaban pensando los programadores anteriores y conocer por qué agregaron esa interfaz que a lo mejor no tiene sentido si solo tiene una implementación. La experiencia también puede hacernos arrogantes y ver con mayor desprecio ese proyecto que usa otras practicas a las que recomendarías o ya usamos y aprendimos que no son lo mejor para ese tipo de proyecto.
Si no tienes experiencias puede ser también frustrante porque no es algo que tú conoces y por lo tanto no es algo que recomendarías. A veces cuando uno empieza quiere usar lo que conoce, la tecnología con la que jugó en proyectos de prueba, que generalmente es algo nuevo. El querer usar lo último y que nos toque trabajar en un proyecto con tecnología vieja puede frustrarnos y sentir que estamos estancados. Sin aprender cosas que nos van a ayudar en el futuro.
Cuando tienes que trabajar en proyectos legacy que inició alguien más, la buena actitud con la que revisas el problema es parte de las habilidades necesarias para mejorarlo. Debemos pensar que el equipo anterior tomó decisiones con la mejor intención, con la información que tenían en ese momento.
Es fácil juzgar una vez que ves que el resultado no fue el esperado y tienes que corregirlo. Pero entrar al problema con quejas en lugar de entender el porqué de la situación, es más desgastante y puede ser más costoso porque puede haber cosas rescatables en el proyecto que no veras, además corres el riesgo de cometer los mismos errores por no entenderlos.
Evita esa frustración, piensa que se hizo lo que se creyó mejor y éntrale al proyecto con una buena actitud, buscando dar soluciones en lugar de quejas. El primer paso es darte cuenta que está en ti cambiar las cosas.
Cuando nos toca empezar a trabajar en un proyecto de esos a veces puede ser frustrante el tratar de moverle, agregarle funcionalidad usando herramientas "anticuadas" o usando convenciones de nombrado diferentes a lo que quisiéramos. Siempre está ese pensamiento, indecisión de: "Y si lo reescribimos" o "seguiremos usando lo mismo". Es pesado trabajar en proyectos así, sobre todo si fue hecho de una manera poco organizada o si cuenta con mucha deuda técnica. Es fácil caer en quejas y empezar a verlo todo mal.
La experiencia de haber visto otros proyectos similares, de conocer diferentes arquitecturas, haber leído artículos sobre cosas que la gente intenta te ayuda a darte una idea de que estaban pensando los programadores anteriores y conocer por qué agregaron esa interfaz que a lo mejor no tiene sentido si solo tiene una implementación. La experiencia también puede hacernos arrogantes y ver con mayor desprecio ese proyecto que usa otras practicas a las que recomendarías o ya usamos y aprendimos que no son lo mejor para ese tipo de proyecto.
Si no tienes experiencias puede ser también frustrante porque no es algo que tú conoces y por lo tanto no es algo que recomendarías. A veces cuando uno empieza quiere usar lo que conoce, la tecnología con la que jugó en proyectos de prueba, que generalmente es algo nuevo. El querer usar lo último y que nos toque trabajar en un proyecto con tecnología vieja puede frustrarnos y sentir que estamos estancados. Sin aprender cosas que nos van a ayudar en el futuro.
Cuando tienes que trabajar en proyectos legacy que inició alguien más, la buena actitud con la que revisas el problema es parte de las habilidades necesarias para mejorarlo. Debemos pensar que el equipo anterior tomó decisiones con la mejor intención, con la información que tenían en ese momento.
Es fácil juzgar una vez que ves que el resultado no fue el esperado y tienes que corregirlo. Pero entrar al problema con quejas en lugar de entender el porqué de la situación, es más desgastante y puede ser más costoso porque puede haber cosas rescatables en el proyecto que no veras, además corres el riesgo de cometer los mismos errores por no entenderlos.
Evita esa frustración, piensa que se hizo lo que se creyó mejor y éntrale al proyecto con una buena actitud, buscando dar soluciones en lugar de quejas. El primer paso es darte cuenta que está en ti cambiar las cosas.
Comentarios
Publicar un comentario