Limpieza de código
 

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, es decir, me he encontrado muchas variables que no se usan, uses agregados que no son necesarios, etc...
Mi pregunta lo mismo es una chorrada pero ¿Cómo hacéis vosotros para revisar todo esto? ¿Hay alguna manera de que me marque las variables que no se usan o este tipo de cosas? Veo que los uses se pueden limpiar los no usados, con una opción, pero y las variables, procedimientos y funciones?

Muchas gracias

Una cosa distinta es que una variable "no se use" a que "se use pero no siva para nada".
Si borras la variable en la declaración entonces dará error al compilar si se está usando.

De todas formas, lo que preguntas es sólo cuestión de paciencia, ir poco a poco, probar una sola cosa cada vez y tiempo, mucho tiempo :)

Hola!

Si, me refiero a que se declaren pero luego no se usen, porque hay muchas de esas y el código es enorme.

Le echaré paciencia jeje

. :D .

jajajaja eso mismo pensé yo, pero es que el código es muy extenso y cada vez que va acumulando mas mierda.
No crees que se debería limpiar?
Hay muchas variables que en su día se declararon, luego se borró el código pero dejaron las variables declaradas, o uses añadido que en su día necesitaron y ahora ya no... Entonces la compilación se va haciendo más y más lenta.
De hecho, en la compilación, me lanza una lista de warning que pasado a un documento mas grande que la biblia.

De las variables no usadas ya te avisa el compilador. Puedes eliminarlas directamente con lo que te diga.
Y para los uses no usados :D tienes utilidades varias que te informa de cuáles son, creo recordar que cnpack y/o gexperts te lo indican.

Hola!

Si, estoy usando la que viene en el cnPack y las variables, pues con paciencia y el compilador.

Era por verificar como hacíais vosotros y ver si más o menos iba bien encaminado.

Muchas gracias!

Bueno, a pesar de todo y si quieres enfangarte, existen herramientas como Pascal analyzer de Peganza que pueden ayudarte a la hora de ver donde están las cosas que podría interesarte cambiar. Tiene una versión Lite y también puedes probar la de evaluación. Igual te interesa.

Yo lo he estado haciendo con código que hacia cuando recién empezaba en Delphi, en mi caso lo que hago es acortar o simplificar la sintax del código.

Ejemplo: en lugar de escribir

Código Delphi [-]
Datamodule.FDQuery.SQL.Text: 'select * from clientes';
Datamodule.FDQuery.Open;

if true then
begin
 showMessage('Prueba');
end;

Lo reemplazo por:

Código Delphi [-]
Datamodule.FDQuery.Open('select * from clientes');

if true then
 showMessage('Prueba');

Y también trato de no declarar variables a lo bruto

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 [-]

//un monton de archivos terribles
class Horrible
vars terribles
procedure un_asco() // lo que tienes


//todo organizado
procedure elegante() // lo que quieres


//ruteador:

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!)

Nosotros tenemos la política de "0 warnigs / 0 Hints" en la aplicación. Estos problemas que comentas aparecen en los Hints y Warnings de la aplicación. Tal vez deberías empezar por ahí.





Eso y si quieres asegurarte más, empezar a refactorizar utilizando tests unitarios (donde se pueda). Eso asegura que las modificaciones no alteran los resultados anteriores. No es aplicable a todo el código, pero sí a funciones, procedimientos, clases,....

Si si, yo quiero ir reduciendo los hint/warnings, porque la lista que sale es inacabable.
Voy a ir empezando por los uses que puedo quitar y las variables declaradas que no se usan, poco a poco, e ir reduciendo.
Cuando consiga reducir eso, que es lo básico, ya me meteré más a fondo con el resto.