En mi opinión, hoy en día se desarrolla mucho y mal. Las especificaciones de los proyectos cambian cuando el desarrollo está a punto de terminar, se prueba poco o nada, y no se diseñan las aplicaciones de forma sencilla.
Una de los puntos que más se confunde es la reutilización de código. Reutilizar código no quiere decir hacer todo lo suficientemente abierto como para que sea usable por cualquier otro proyecto.
La reutilización, por tanto, no debe ser a priori, sino a posteriori. No podemos definir toda la arquitectura considerando que cualquier parte podría ser utilizada en cualquier otro proyecto.
La clave está en detectar que código necesitaremos reutilizar, pero a posteriori, es decir, una vez nos encontremos ante una necesidad que permitiría aprovechar algo de un proyecto anterior. En este caso, es más efectivo invertir tiempo reescribiendo esa parte del antiguo proyecto de forma que sea lo más simple y genérica posible, y después integrarla en el nuevo desarrollo.
Este procedimiento nos evita complicaciones innecesarias en el código de aplicaciones de las que jamás de aprovechará una linea. En cambio ayuda a tener pequeños "retales" que son sencillos, probados y eficientes que son usables en montones de sitios.
Intentar reaprovechar cualquier cosa, nos lleva a ir arrastrando en todos los futuros proyectos, clases inestables, difíciles de usar y a menudo incompletas.
Los candidatos a ser estos pequeños retales son típicamente funciones de validaciones de campos, capa de acceso a datos, unidades de depuración, y algunas utilidades sencillas que se utilizan con frecuencia.
Es importante que estos fragmentos reutilizables tengan las mínimas dependencias posibles. Por ejemplo, si implementamos un componente de impresión utilizando Crystal Reports, es probable que no se pueda utilizar en algún proyecto que lo requiera debido a que no se desea depender de Crystal. Exagerando un poco, podríamos acabar teniendo una función que suma dos números, pero que requiere montones de componentes de terceras partes para funcionar. Con lo cual acabaríamos reescribiendo esa función de suma de otra forma. Por tanto si ya sabemos que al final lo tendremos que hacer, ¿por qué no comenzamos con buen pié, y lo hacemos así desde el principio?
A veces algunos componentes de terceros, pasan a formar parte de las herramientas estándar de desarrollo de ese equipo de trabajo, y son usados en todos los proyectos que se desarrollan. Si ese fuera el caso, podríamos decir que no es una dependencia externa, y por tanto puede ser aprovechado en cualquier código que desarrollemos, incluído el que vaya a ser reutilizado.
Al final tendremos unas pocas clases básicas que serán reutilizadas de forma fácil. Con frecuencia esto es mejor a tener muchas de uso complicado.
La reutilización no es ninguna revolución, no consigue un ahorro sustancial en el tiempo en el desarrollo, como desde muchas fuentes de proclama. En cambio si que reduce los errores de las aplicaciones, ya que se dispone de un conjunto de rutinas que realizan tareas sencillas al mismo tiempo que están muy probadas.
Por definición, las propias clases reutilizables evolucionan, y van creciendo incorporando nuevas tareas que se repiten de proyecto en proyecto. Esto no debe confundirnos, y hacer que las nuevas clases sean incompatibles con las versiones anteriores. Es importante que tengamos solamente una versión de esas clases, que es la que se va actualizando, modifcando y corrigiendo. Esa única versión es la que usarán todos los desarrollos, de manera que se beneficien automáticamente de mejoras de rendimiento y correcciones de errores.
Si se diera el caso de tener que desarrollar una nueva versión de una aplicación, tendríamos de forma transparente disponibles las nuevas funcionalidades que se han incorporado en las clases reutilizables.
En general, esas clases reutilizables se incluirán de forma sistemática en cualquier proyecto, aunque no sean necesarias en el momento incial.
Interesante reflexión, Guti…
Yo no soy de los que suele comerse mucho la cabeza a la hora de programar para hacerlo todo reutilizable. Lo que si hago es intentar estructurar modularmente el código para hacerlo más legible y facil de entender.
Creo que tienes mucha razón en que la mayoría de veces el código que programamos no se llega a reutilizar nunca, por eso hay que saber seleccionar qué partes deben hacerse reutilizables y cuales no (en general serán siempre unas pocas rutinas…)
Lo de hacerlo a posteriori no me lo habia planteado nunca, pero no parece una mala idea… tendré que pensarlo la próxima vez.
Salu2.
Me alegra que este comentario en particular te haya parecido interesante.
De hecho es una idea que va bastante en contra de lo que suele hacerse hoy en día.
Si lo llegas a poner en práctica, ya me dirás cual de los dos sistemas te ha ido mejor!
Con algunos años de retraso (digamos que una década) pero me parece un buen punto, por ejemplo yo tengo una clase en VB.Net donde implemento un montón de funciones para manejar un archivo de excel y extraer información de él.
En el trabajo no hay problema, todas las computadoras tienen office, la dependencia de excel no es problema, pero, yo no tengo office en mi casa, de hecho uso libre office, así que cuando quiero compilar esa librería en otro proyecto ajeno al trabajo resulta que office no se encuentra y genera error…he ahí el problema.
Entonces hasta donde sea posible hay que evitar dependencias pero no siempre será posible, muy bueno tu blog, saludos.
Tienes toda la razón Manuel las dependiencias externas, condicionan la reusabilidad de tu código, ya que dependes de ellas.
Imaginemos un programa en VB 6, que sería perfectamente capaz de seguir funcionando en Windows 8.1, sin embargo, los runtimes, puede que no lo sean, y se causará el problema. Es algo parecido a lo que cuentas de Excel. Imaginemos que un día desaparece…
Mmmm, VB6 fue un auténtico dolor de cabeza para mi, primero porque no estaban los runtimes en la máquina destino, segundo porque aunque encontré la manera de llevarlos (había que copiar todas las dlls y ocx que usaba en la carpeta del ejecutable) esto no siempre funcionaba, ¿con adivina que?, así es: Excel.
No bastaba con llevarse las librerías de excel (las que enlazaba el programa), sinó que estas también tenían dependencias, no había de otra que usar el instalador que proveía VB6, cosa que no me gustaba porque yo quería una aplicación 100% portatil y pues no siempre fué posible.
Recuerdo esa época yo también Manuel, desregistrando y registrando DLL a mano para hacer que funcionase. Por eso cuando vi lo que hacía Delphi en aquellos tiempos, me quedé alucinado.
¿Cómo era en delphi?
Pues eran los años en que VB aún no generaba código nativo, acababa de aparecer la versión 4, que generaba ejecutables para Win16 y Win32. En ese mismo tiempo, Delphi tenía un compilador que generaba ejecutables nativos para Win16 y Win32, además de permitir el enlazado estático como ahora hace, es decir, tenías un ejecutable con todas sus dependencias, ni runtimes ni nada.
Pero lo mejor de todo, eran los componentes, que al ser librerías igualmente nativas, tampoco requerían OCX extenos, todo iba enlazado en el ejecutable de tu aplicación. Pero es que además, si querías usar los ActiveX de VB, ¡podías!
ahhh, pero me imagino que el ejecutable estático tenía un tamaño muy grande verdad?
Un ejecutable más o menos sencillo en VB 4, eran unos 50 KB, y los runtimes de VB sumaban del orden de 1 MB.
En Delphi el ejecutable eran unos 300 KB, es decir, 6 veces más, pero al evitar los runtimes, al final resultaba ser 3 veces más pequeño.
Por no hablar del rendimiento, que al ser compilado, era unas 20 veces más veloz.
Si te apetece, échale un vistazo a Delphi XE8, o a Lazarus, la versión Open Source del mismo: https://www.javiergutierrezchamorro.com/lazarus/1633
Sería interesante con lazarus, luego le doy un vistazo, gracias, por ahora estoy centrado en mi librería de VB.Net pero no estaría mal aprender algo nuevo.
Verás que como es habitual, la curva de aprendizaje cuesta al principio, pero luego en seguida lo tendrás por la mano.