lunes, 3 de mayo de 2010

Mantenibilidad vs Reusabilidad

Ya hace bastante tiempo que vengo haciendo entrevistas para contratar Programadores. Aparte del hecho de que es una actividad que depara no pocas sorpresas (ver sino: the-nonprogramming-programmer), y a la que debemos evidentemente darle alguna vuelta de tuerca, como hacer pair programming con el candidato, llenar de brea a los mentirosos o algo asi, no es el objetivo de este post charlar sobre técnicas de entrevistas sino sobre una pregunta que suelo hacer durante las mismas.

Recientemente un compañero, con el que estaba haciendo una búsqueda en particular entrevistando junto a mi, se reia cuando al promediar cada una de las entrevistas disparo la misma pregunta "Qué es lo más importante a tener en cuenta al programar un sistema? La Reusabilidad o la Mantenibilidad? Si te tuvieras que quedar con una de las dos, cual elegirias?". Luego de un par de segundos de desconcierto, la respuesta llega, siempre, invariablemente, la misma: " La Reusabilidad, claro".

Porqué? porqué?, cuando?, quien?, En que momento metimos en las cabezas de los programadores que el objetivo fundamental a perseguir cuando uno programa es la reusabilidad, es hacer componentes que puedan ser reusados una y otra vez?

Con una mano en la biblia del programador ("The art of computer programming", de Knuth?) cuantas veces recuerdan haber reutilizado un componente escrito para un sistema anterior? o Para el sistema presente? Vamos, recuerden que esta bajo juramento!

Ahora, cuantas veces recuerdan haber buscado en el código (o internet) un codigo parecido al que tenes que trabajar, copiarlo , pegarlo y modificarlo (POC/P: Programacion Orientada a Copy/Paste) ? Muchas?

Lo cierto es que a lo largo de la carrera profesional de un desarrollador siempre, invariablemente hemos visto como el marketing de un determinado framework proclama a viva voz : "Es para permitir armar componentes reutilizables", "Este framework generico te permite escribir ABM genericos, de manera de poder reutilizar las pantallas (los formularios, la ui)", "Este lenguaje permite extenderlo para facilitar la reusabilidad", incluso la POO fue vendida inicialmente como la panacea para lograr componentes reusables y extensibles.

A ver, que no se malinterprete, el código que uno desarrolla DEBE ser lo más reusable posible pero siempre, subrayo siempre, se debe dar prioridad en el diseño y el desarrollo a la MANTENIBILIDAD.

Porque?

Simple y sencillamente porque el hecho de que algo vaya a ser reusable depende de decisiones y acciones futuras con una determinada probabilidad mientras que la Mantenibilidad se necesita en el 100% de los casos y desde el primer dia de vida del sistema a lo largo de tooodo su ciclo de mantenimiento (notaron? Mantenimiento y Mantenibilidad? que casualidad), siempre claro, que el sistema entre en produccion.

Como uno no puede preveer el futuro, y no sabe si realmente va a reutilizar el componente que esta diseñando hoy, hacerlo más genérico de lo necesario implica hacerlo mas complejo de lo necesario para el caso en cuestion y esto a su vez lo hace mucho, mucho más dificil de mantenerrrrrrr!!!

Increible como parezca el mantenimiento de un sistema representa del 60% al 80% del costo total de un sistema, siendo el otro 20%-40% el costo del proyecto inicial de desarrollo (y estoy siendo conservador, conozco algunos que .... pero mejor no entro en detalles...por ahora). Reducir este costo es crucial y solo se puede lograr con un sistema lo mas simple posible, refactorizado y con amplia cobertura de tests de unidad. Esto último es esencial porque además si un sistema es mantenible los tests de unidad facilitan luego su extensibilidad porque es fácil modificarlo sin pisar alguna mina antipersonal y que todo el sistema explote!

Y La reusabilidad, que?

La reusabilidad de un componente, si viene, no viene dada por la clarividencia de un arquitecto iluminado sino por la repetida necesidad de una solucion similar a un mismo problema, que se refactoriza y extrae, utilizando justamente técnicas de refactoring y patrones de diseño (Ver GOF "Design Patterns", "Refactoring" de Martin Fowler o más recientemente Refactoring to Patterns, de Joshua Kierevisky). Es Posterior a la primera implementación, solo cuando uno se encuentra con el segundo ejemplo del problema o, mejor aún, el tercero, comienza a pensar en que está faltando un método o un componente (Clase) reutilizable (o cualquier otro síntoma de problemas con el codigo, ver Code Smells en el libro de Refactoring).

Entonces?

Entonces, chimpances entrenados, en todos los sistemas que hemos realizado lo más productivo ha sido tener, siempre y en todo momento, a la mantenibilidad como valor más alto.

El truco es que justamente al enfocarse en que nuestro código sea mantenible aumenta la reusabilidad!!! El código mantenible es más simple, tiene métodos y clases cortas, con menos acoplamiento, mayor cohesión, su intención y proposito es más claro, todo lo cual hace más fácil extraer comportamientos comunes y al refactorizar descubrir componentes faltantes que puedan ser reutilizados. Haciendolo al revés, se los digo por experiencia, no da el mismo resultado (el orden de los factores SI altera el producto, y no saben en que medida).

Ahora, hablar de "cómo?" hacerlo más mantenible es tema de otro Post, diría de una serie...., pronto en sus salas de blog más cercano!

2 comentarios:

  1. Excelente . Lo peor es que la mayoria cree que la POO es reusabilidad de codigo y el Single responsability principle Open closed principle y demas quedan olvidados en un tarro . La poo se invento para lidiar con nuestro amigo llamado CAMBIO ( y es gracias a quien el mantenimiento existe) Y no reutilizar algo en tiempo de development ( que es una fraccion de la de mantenimiento). Es como usar TDD para hacer las pruebas de que funquen las cosas HOY y no como un resguardo para hacer cambios MAÑANA.
    HERALDO

    ResponderEliminar
  2. Muy buen análisis, y algo que quizás hay que recalcar es que en la facultad te enseñan la reusabilidad y la no duplicación de código. Y el mantenimiento solo lo aprendes cuando presencias el gran hito, no siempre exitoso, de que el sistema entre en producción. Aquí es donde no preocupamos porque no se caiga.
    Y arquitectos con sus ABM's genéricos hay unos cuantos...

    ResponderEliminar