Cita:
Empezado por juggern
Buenos días,
Verán, tengo una aplicación en Delphi 7 muy muy antigua, ha pasado por muchas manos y tiene mucho código generado.
Me gustaría ir haciendo una limpieza de código...
|
Hay un libro que habla de todo esos temas:
https://www.amazon.com/Working-Effec.../dp/B005OYHF0A, pero en caso de que te interese unos tips cortos:
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:
- TIENES que usar un herramienta como Git. Creas un"branch" donde vas aplicando los cambios y mejoras. Es mejor que cada mayor tarea tenga su propio branch. Pasara que tengas que hacer "arreglos" en lo viejo, y en ese caso te alegrara haber hecho caso.
- Creas una lista de tareas (o usas una herramienta como pivotal tracker) y ademas vas documentando lo que vas encontrando importante, y vas con disciplina haciendo tracking del progreso.
- Haces todos los arreglos "mecanicos": Arregla todos los warnings y formatea el codigo con un auto-formater. Esto hazlo POR PASOS! No todo el proyecto! asi puedes ver si algo se rompe
A partir de aqui ahi 2 mayores rutas que tomar.
- Hacer cambios pequeños y progresivos. Tiene sentido si es mas modernizar el codigo y la app es "estable" desde punto de vista del usuario (en adelante SMALL STEPS), y es importante que cada cambio este MUY bien testeado
- Hacer grandes cambios, casi que reescribir todo. Tiene sentido si el codigo es insalvable y ves que "arreglarlo" es tan o mas lento que volver a hacer (en adelante BIG STEPS) y el cliente aguante que tenga que probar algo "incompleto" y tener downtime (ej: Montaste lo nuevo, algo no funciona, toca devolver a lo viejo y quizar re-aplicar los datos cambiados de la bd nueva a la vieja)
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
Código SQL
[-]
CREATE TABLE usr01 {
id PRIMARY KEY
n CHAR(5)
pwd MEMO
}
-- Creas una vista ACTUALIZABLE:
CREATE UPDATABLE VIEW users
SELECT
id as user_id,
n AS user_name,
pwd
Una vez tienes limpia la BD puedes proceder con el resto.
Cuando quieras mejora algo hace un ruteo
Código Delphi
[-]
class Horrible
vars terribles
procedure un_asco()
procedure elegante()
procedure rutear()
begin
if VIEJO then un_asco() ELSE elegante() end
end
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!)