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.