FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
Asumiré que ya sabes de que va la app, y que puedes consultar los resultados esperados a alguien (asi no sepa como están hechas por dentro las cosas) El arranque:
A partir de aqui ahi 2 mayores rutas que tomar.
El paso MAS importante es que entiendas los DATOS. Si la BD/archivos que usa la app es terrible, *el codigo reflejara eso*. Ahora, estrategia general cambia en base al camino a elejir: SMALL STEPS En tal caso, aqui toca algo salvaje: Cojer la BD y por medio de vistas, funciones y stored procedures limpieza de sus estructuras y/o interfazes de las mismas. Esto es la forma de "limpiar el codigo de la BD" Si estas de malas, y la bd no SQL, migraria eso primero y cambiaria lo que hay pa que cuadre. Si estas de buenas y la version del motor es "vieja", tu paso es subir a lo ultimo, porque para hacer lo anterior hay que jalar de SQL moderno. Esto se ve asi. Digamos que la BD es un asco y tienen los usuariso como
Una vez tienes limpia la BD puedes proceder con el resto. Cuando quieras mejora algo hace un ruteo
Esto tiene una razon importante: No borras ni cambias lo horrible, solo creas una version del programa donde lo viejo queda pero lo nuevo se ejecuta, pero a la vez, peudes hacer una *copia* y comparar ambos programas y mirar si y donde hay desviacion. Esto puede ser con compilacion condicional o una variable de entorno que se ejecuta en runtime. Una vez que `elegante` esta aprobado, borras `un_asco` y sigues. Todo esta en git, asi que no hay que temer perder nada. Asi sigues hasta completar BIG STEPS Creas otra bd, con estructuras elegantes. Creas un *importador* que jale los datos viejos y lo sube a lo nuevo. Esto es fundamental y el peor error es tratar de saltarse este paso. Luego hacer cambios por modulos. Aqui es parecido a los cambios del codigo "small steps". La diferencia enorme es que no estas tratando de que hay 2 codigos que A LA VEZ corran sobre la MISMA bd. Asi que puedes hacer cambios estructurales mas pronto. La pega es que cualquier divergencia o logica no obvia que "funciona" en lo viejo te tocara descubrir mas tarde, y como tienes que hacer el RESTO de los grandes modulos para ver todos los efectos (ej: no veras que facturas determina si puede vender o no a ese cliente hasta que esta cartera,usuarios, pagos, listo). --- Cual es mejor? Es dificil saber. SMALL STEPS es la opcion de algo que es MUY riesgoso de cambiar y BIG STEPS requiere mucha abilidad para recuperar toda la logica que si tiene sentido de lo viejo. Tal vez toque combinar, o invertir algunos pasos (ej: Es poco probable que tenga sentido salvar la tabla usuarios si esta muy horrible: Mejor hazla bien y le haces una vista para que lo VIEJO crea que esta como antes!)
__________________
El malabarista. Última edición por mamcx fecha: 10-04-2023 a las 23:46:26. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Limpieza de base de datos | chipsoni | SQL | 5 | 09-02-2007 03:26:11 |
Limpieza del DBgrid | Alexita22 | OOP | 3 | 09-08-2006 08:27:15 |
Omitir limpieza de cabezal de impresora | emeceuy | Impresión | 5 | 06-08-2005 05:07:47 |
de vuelta con la limpieza de edit | botones67 | Varios | 3 | 06-06-2005 19:47:07 |
|