Otra situación es cuando la "empresa" decidió en un día de lucidez extrema encargar a la "élite" de programadores de su plantilla (o externalizarlo), que crearan un framework de desarrollo para hacer aplicaciones como churros. Mira que a mi me gustan los churros (y los jeringos mas), pero seamos serios, las aplicaciones software no son churros. Este caso de marco de trabajo para todas las aplicaciones (dadme un martillo y moldearé el mundo) de la empresa es un modelo arcaico y retrógado, que a mi parecer ha hecho mucho daño, sobre todo a la evolución profesional de los desarrolladores que se enfrentan a esta situación. Dejan a los desarrolladores atados a unas tecnologías que pronto quedarán obsoletas, sin contar con que ese marco de desarrollo seguramente se dejará de mantener y actualizar. Por supuesto la empresa queda en desventaja competitiva con respecto a la evolución del entorno tecnológico contemporáneo, que cambia a un ritmo de vértigo.
Si te toca en gracia heredar un proyecto de estas características, RESIGNACIÓN. Hay que mantenerlo, cueste lo que cueste, pero ¿Qué tal si vamos intentando reducir la deuda técnica? en la medida de las posibilidades de cada proyecto puede ser interesante aplicar técnicas que ayuden a que la vida de las personas que tienen que mantener ese software sea mejor, se encuentren motivados y vean la mejora en su día a día, y en la vida útil del proyecto. Por supuesto eso repercutirá en el producto, y por ende en el usuario final.
¿Qué hago para reducir la deuda técnica incluida por el/los frameworks heredados? en la mayoría de casos no depende de mi. Y en algunos casos mi propuesta es siempre radical: "lo tiramos y hacemos uno nuevo, en menos tiempo y con menos esfuerzo de lo que cuesta mantener lo que hay". Incomprensiblemente, esta propuesta no suele cuajar. Así que lo que intento es recomendar desacoplar partes del proyecto, descubrir subsistemas y en la medida de las posibilidades reimplementar, incrementalmente, las funcionalidades. Como suele decirse cambiar de bicicleta sin dejar de pedalear, o sería mas bien, arreglar la bicicleta sin parar. Es fácil decirlo, pero en la práctica nunca resulta tan sencillo. Esto supone un gran sobreesfuerzo, sobre todo mental, ya que no solo luchas contra los frameworks heredados y con el código heredado, si no que además contra las personas involucradas en el proyecto, jefe de proyecto, directivos o incluso desarrolladores reticentes al mas mínimo cambio.
Al igual que comentaba para el legacy code, existen mecanismos para reducir la deuda técnica de los legacy frameworks. Establecer prioridades en los frameworks obsoletos usados y analizar el alcance del cambio es un buen punto de partida, para posteriormente actualizarlo a versiones recientes o reemplazarlo por otro. Todo depende del querer aplicarlas.
Otra situación, que para mi es totalmente inexplicable, es cuando se empieza un proyecto nuevo, y ya se está obligando a utilizar tecnologías y frameworks obsoletos. Las excusas que se suelen aplicar son varias, como por ejemplo: "esta tecnología es madura para el proyecto", "es lo que conocemos", "este es el marco de trabajo de la empresa y nos obliga a usarlo", "el cliente obliga a usar esto", etc, etc. Puede que sean razones suficientes (algunas), para acomenter el trabajo, pero desde el primer momento, justo antes de escribir la primera línea de requisitos (historias de usuario, o llámalo x) se debe dejar claro que el punto de partida ya acumula deuda técnica alta, y eso no puede ser bueno.
¿Cómo escapar de los legacy frameworks? dificil respuesta (al menos para mi). Lo principal que se me ocurre es desacoplamiento. No te cases con ninguno, lo que hoy es fantástico y maravilloso, mañana quizá ya no lo sea tanto, y requieras cambiarlo. Actualiza lo mas frecuentemente posible. Apóyate en estándares y no en modas y por supuesto vigila la tendencia de la industria
Comentarios