![]() |
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
Lo reemplazo por:
Y también trato de no declarar variables a lo bruto |
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!) |
Cita:
![]() ![]() 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. |
La franja horaria es GMT +2. Ahora son las 22:34:37. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi