Reingeniería

reingenieria


Pasos a seguir para hacer una reingeniería al código

Marzo 29 de 2017 por SoTechCo


Si tiene una aplicación con bastante tiempo y siente que lo está dejando lleno de canas, lea el siguiente post. Le ayudara a entender que debe hacer antes de continuar en hacerle mantenimiento a la aplicación en el estado que está o pensar en hacer el cambio que puede constarle mucho tiempo, trabajo y dinero

Los gerentes, arquitectos y desarrolladores saben que el software será más complejo y más difícil de mantener con el tiempo debido a los cambios adicionales que se requieren. A menudo, esto eleva los costos y el mantenimiento se vuelve desgastante para todos los involucrados

Por lo tanto, hacer una refactorización o una reingeniería del código es una muy buena opción para hacer el código más fácil de mantener (entender y hacer cambios). La reingeniería le permitirá incorporar lo que se ha aprendido acerca de cómo el código debería haber sido diseñado. Este es el tipo de aprendizaje que es la base original para el término "deuda técnica".

Entonces, ¿cómo debemos hacer reingeniería al código para que siga siendo vital y útil? En la vida real seguimos aplicando ‘parches’ a medida que hacemos cambios e incorporamos nuevas tecnologías. Esto conduce a la erosión del diseño. Y ya muchos gerentes, arquitectos y desarrolladores alrededor del mundo comprenden el carácter debilitante de esta erosión y cómo afecta la calidad, productividad y costos.

Incluso si estamos de acuerdo en que la reingeniería que se requiere, ¿cómo podemos planificarla? Aquí hay cuatro pasos clave si usted ha decidido hacerle reingeniería a su software.

1. Comprender la estructura actual del código. Siempre resístase a la tentación de hacer reingeniería sin una comprensión clara de lo que tiene. Comience siempre por comprender e identificar los componentes críticos y cuáles son sus dependencias. Por ejemplo, si es Java o .NET, comprenda los distintos archivos JAR o ensamblados y cómo están relacionados entre sí. Para C/C++, comprenda los ejecutables y bibliotecas, así como la estructura de código utilizada para generarlos. Ahora pregúntese: ¿Son estos los componentes correctos en mi arquitectura deseada? A veces sólo tiene un componente. Si ese es el caso, pregúntese si necesita dividir el componente en componentes más pequeños.

Le invitamos a leer Algunas razones para NO refactorizar

2. Examinar los componentes internos, particularmente los más grandes y los más importantes. Observe las dependencias de las clases o archivos que constituyen el componente. ¿Hay acoplamiento excesivo? ¿Este acoplamiento hace que el código sea más difícil de mantener? Como el equipo, decida cuál es su arquitectura deseada. Consulte a los desarrolladores senior. Pregunte a los miembros del equipo en las diferentes áreas de experiencia para validar sus ideas. El equipo de pruebas puede ser particularmente útil. Una buena arquitectura hará una enorme diferencia en lo fácil y efectivo que es probar. Usted debe ser capaz de tomar las clases existentes o archivos y construir nuevos componentes. Pruebe varias arquitecturas de tipo "si" para llegar a la arquitectura deseada para su código existente.

3. Con la arquitectura deseada en la mano, ahora debe saber qué cambios son necesarios y cuáles son las dependencias no deseadas. Priorice las dependencias para arreglarlas según sus necesidades. Si tiene áreas de código que cambian con frecuencia, debe pensar en modularizar. Tenga siempre en cuenta sus necesidades actuales y futuras. Si bien la reingeniería tiene sus propios beneficios, es poco probable que deje de hacer otras mejoras durante este tiempo. Cualquier esfuerzo de reingeniería es probable que esté en conjunción con otras mejoras. Una buena herramienta de reingeniería le permitirá realizar trabajos de reingeniería en conjunto para hacer mejoras continuas al producto. Otra ventaja de este enfoque es que se creara un apoyo a la gerencia para el esfuerzo de reingeniería.

4. El último paso es asegurarse de comunicar el plan de reingeniería a todo el equipo. Con un esquema de prioridades, haga a la reingeniería una parte de la integración continua. Puede crear reglas que eviten que las cosas empeoren examinando continuamente los cambios en contravía de la arquitectura deseada. Las historias de reingeniería deben ser parte de la planificación ágil como cualquier otra historia. No sólo puede hacer reingeniería, puede hacer que sea parte de su desarrollo normal. Los mejores ejercicios de reingeniería suelen minimizar la interrupción y aun así le permiten migrar a una nueva arquitectura.

No olvide

1. Haga elecciones inteligentes sobre cuándo refactorizar y cuándo reconstruir
2. Identifique los componentes clave para su reutilización
3. Haga que su código sea más modular a través de la administración de dependencias

Implemente reglas arquitectónicas para evitar la erosión del código

Para mayor información visita www.sotechco/lattix.html

Derechos reservados © by SoTechCo 2015