Reutilizacion & Mantenibilidad

Sigo preocupado y dándole vueltas al tema.

Si se hace código reutilizable, tenemos una serie de ventajas, pero también una serie de inconvenientes. Las ventajas son claras:

1. Codificaremos menos en futuros proyectos. En vez de hacer código similar otra vez, podremos instanciar una clase o módulo ya hecho. Nuestros futuros proyectos llevarán menos tiempo de codificación.
2. Con el tiempo tendremos un componente reutilizable fiable y libre de errores. Con el tiempo, esa clase que simplemente instanciamos, tendremos una cierta garantía de que no tiene errores. Nuestros futuros proyectos llevarán menos tiempo en depuración.

Sin embargo, también tiene pegas, y no son tontas.

1. Se pierde más tiempo ahora. Un componente reutilizable se tarda más en hacer. El proyecto que estamos haciendo ahora tardará más.
2. Por otro lado, el código es más críptico y menos intuitivo. Siempre es más fácil un código todo seguido que instanciar una clase configurable a la que debemos pasarle para configurarla un fichero, un patrón estrategía o heredar obligatoriamente de una interface. Depurar esas cosas mientras el componente no es totalmente fiable puede ser un pequeño infierno.
3. Requiere un tiempo de aprendizaje. Si no hemos hecho esos componentes reutilizables nosotros mismos, puede llevar tiempo. Cualquiera que haya intentado utilizar alguna de las librerías que hay por internet -javamail, jasperreport, ibatis, etc- sabe que no es tan sencillo como bajarse la librería y ponerse a codificar.
4. Los componentes reutilizables a veces nos obligan a una gestión de versiones compleja. A veces necesitamos añadir o modificar la funcionalidad de un componente reutilizable para un nuevo proyecto. Por compatibilidad con proyectos anteriores no podemos hacerlos, así que tenemos que empezar a crear versiones del componente reutilizable, o bien apañarnos para hacer las modificaciones sin perder compatibilidad. En el primer caso, si más adelante encontramos errores en el componente reutilizable, tendremos que corregirlos dos veces -o tantas como versiones distintas afectadas por el error tengamos-. En el segundo caso, tendremos que andar cargando con métodos y clases obsoletas. Todos vemos en la API de java la cantidad de métodos obsoletos que hay que no se pueden eliminar por compatibilidad.

Todo esto me lleva a pensar ¿cuál es el punto de compromiso?. ¿En qué punto compensa hacer el componente reutilizable frente a hacer un copy/paste del código anterior?.

Yo hasta hace poco tendía a hacer componentes reutilizables siempre que podía, a pesar del esfuerzo que supone. Actualmente, tras unos años de experiencia con esa política, empiezo a pensármelo dos veces antes de hacer un componente reutilizable. Sobre todo tras ver a compañeros de trabajo heredar código de otros que se han ido, no conocer los componentes reutilizables que se usan en ese código y ver cómo tarda una semana en encontrar un bug tonto, simplemente por no poder seguir el código fácilmente.

También me ha pasado a mí, a pesar de conocer los componentes reutilizables que tenemos. A veces me piden un pequeño cambio de funcionalidad en el proyecto y me basta con una sola línea de código para introducirla, pero me tiro dos días para encontrar dónde y cómo meter esa puñetera línea, precisamente porque el código no se ve a simple vista.

Un ejemplo tonto muy claro. Supongamos que vamos a leer un registro de una tabla de una base de datos. Podemos hacer un código específico que lea el registro y lo meta en un bean de java -con atributos, métodos set() y get()-. Eso sería muy claro en el código, aunque poco reutilizable. Tendríamos que hacer código similar para cada tabla distinta en base de datos.

Su equivalente muy reutilizable y que ahorra código -no hay que hacer ninguna clase- sería un Hashtable. Leemos la tabla y sus metadatos. Usando el nombre del campo como clave del Hashtable, metemos su contenido como valor. Un simple método en una clase al que pasemos en nombre de la tabla a consultar y el where de la consulta puede construirnos el Hashtable de cualquier tabla. Sin embargo, a la hora de depurar o seguir código, cualquiera prefiere tener un bean y ver los métodos get() y set() o los atributos, que andar con un Hastable intentando averiguar con el debugger qué claves tiene y qué valores.

Con el bean, para reutilización, puede usarse la introspección de java, pero a la hora de depurar o seguir el código cualquiera prefiere ver un getValor() que ver un montón de líneas de código extrañas en las que se buscan los atributos y nombres de métodos del bean para invocarlos de forma oscura y críptica.