En un reciente debate en la lista de Extreme Programming  en Yahoo Groups se exploró el conflicto aparente entre desarrollar software reutilizable y la práctica de XP de no escribir el código hasta que se necesite.

Ron Jeffries y otras personas compartieron sus ideas acerca de los costos y beneficios de la reutilización de código, y cómo y cuándo ponerlo en práctica en un entorno ágil.

Brandon Olivares inició la discusión. El había acabado de pasar 30 horas en un código cuando se dió cuenta que había una oportunidad de ser reutilizado. Él se sintió confuso sobe el hecho de poder o no generalizar ese código, para que otros proyectos también puedan utilizarlo.

Por lo que yo entiendo, XP desalienta que asumamos que algo sería necesario, hasta que realmente te das cuenta de que es necesario. Asimismo, de acuerdo a mi entender, eso incluye la abstracción de código con el fin de hacerlo más genérico para su reutilización, hasta que haya una duplicación, así puede ser refactorizado.

La reutilización del software ha sido identificada como un factor de gran economía de tiempo. Por lo tanto, los desarrolladores de otro proyecto pueden beneficiarse reutilizando su código, en lugar de reinventarlo. Brandon preguntó a los miembros del grupo cómo deciden cuándo abstraer o generalizar el código para que otros proyectos puedan reutilizarlo.

Ron Jeffries fue el primero en responder, explicando algunas de las razones por las que la reutilización de los equipos pueden ser más difíciles y costosas que lo que parecen a primera vista.

Necesito el trabajo de empaquetarlo, lo que no precisaría si fuese utilizado sólo por mí, preciso documentarlo, debo hacerlo más robusto, eliminando problemas que podría eludir fácilmente; debo dar soporte y responder a preguntas acerca de él, preciso capacitar a las personas para utilizarlo.

Si hacemos todo esto, es caro. Si no lo hacemos, la utilizaión de mi código por otras personas es difícil y no las ayuda mucho.

Todo esto lleva a Ron a abordar el asunto de esta manera:

Yo construí las abstracciones que preciso. Si necesito de ellas nuevamente, en un contexto diferente, mejoro la abstracción. Pero, a menos que el objetivo de mi proyecto sea construir infraestructura para otros proyectos, yo intento no gastar ni dinero ni tiempo mío, desarrollando para los otros.

Otra persona señaló que la reutilización se puede facilitar por todos los proyectos que comparten el mismo sistema de build y un conjunto unificado de pruebas. Por lo tanto, un equipo que quiere reutilizar algo de código, puede generalizarlo para sus necesidades. El sistema de build ayudaría a garantizar que ninguna prueba de los otros proyectos que utilizan el mismo código, se rompió.

George Dinwiddie, Ralph E. Johnson y otros recomiendan generalizar en la segunda utilización (o hasta mas tarde). Adam Sroka llamó a este enfoque como la "reutilización de emergencia" y señaló que ella parece ser más eficiente que el "proyecto para la reutilización». Un participante llamado Tim explicó esto a la gente de su empresa de la siguiente manera: "La primera vez usted paga por el código que será escrito. En la segunda, usted paga para que sea reusado y reusable. En la tercera, el código le sale gratis."

George advirtió que el problema más difícil podría ser como hacer que los otros equipos sean conscientes de un código potencialmente reutilizable. El costo de comunicación necesario para un descubrimiento útil puede ser significante. Jeff Langr sugirió que si los desarrolladores tuviesen pares en otros proyectos, podría ser una manera eficaz de resolver el problema de ese descubrimiento.

Scott Ambler entró a la discusión diciendo que el open source es una forma de reutilización que ha tenido mucho éxito. También mencionó las bibliotecas de código, los kits de desarrollo, e incluso mash-ups, son ejemplos de reutilización de software que funciona.

Adam continuó con esta observación:

Es importante distinguir cuando mi equipo usa lo que él mismo utilizó con anterioridad y cuando él usa lo que otra persona usó en otra época. La segunda alternativa requiere más reflexión ... incluso para alguien fuera de mi equipo ser consciente de ello. Existe un costo en eso y ese costo precisa reproducir algún valor mejor para el negocio.

Algunos dicen que el Jefe de Proyecto puede ser el responsable  de identificar las potenciales reutilizaciones. También podría ser la organización de un "Grupo de Arquitectura" responsable por el alinieamiento y la padronización de las soluciones creadas, y que ellos identifiquen las reutilizaciones, aunque algunos con experiencia en este sentido (en un grupo de una empresa llamado "Diseño de Soluciones") dicen que no sirve ya que traba gran parte del desarrollo y que en general son personas muy generalistas que no siempre tienen la condición de saber en detalle todas las implementaciones. Con buena intención, acaban sugiriendo cosas imposibles, y muy buenos reaprovechamientos pasaban desapercibidos a sus ojos.

 ¿Cómo decides cuando reutilizar tu código? Deja un comentario y compartí tu experiencia.

Basado en Uma Abordagem Ágil para Reutilização de Código