Se habla mucho sobre reusar código, escribir código reusable, no reinventar la rueda, ser eficiente… Depende de a quién se escuche parece que reusar código es un objetivo a buscar siempre. Todo el código debería ser escrito para poder ser reusado en el futuro, y todo código nuevo debería buscar reusar soluciones anteriores antes que reescribir soluciones parecidas de cero. Por un lado, es cierto que reusar código es útil y hecho correctamente puede ayudar a un equipo a ahorrar tiempo y esfuerzo a largo plazo. Por otro lado, contra lo que podríamos intuir, reusar código no es gratis. Se suele pensar en el código escrito en el pasado como algo que “ya está hecho”, y se suele ignorar el trabajo necesario para adaptarlo al contexto y los problemas actuales. Tener en cuenta este coste nos puede llevar a tomar mejores decisiones respecto a cuándo se debería reusar código y cuándo tiene más sentido escribir una solución nueva.

El principal punto de fricción a la hora de intentar reusar código sucede cuando el código que se intenta reusar no soluciona exactamente el problema que se tiene, sino uno parecido. Por lo tanto, va a necesitar trabajo de adaptación para poder usarlo en el nuevo contexto. Esta situación suele tener dos consecuencias. Por un lado, ignorar este coste. Creer que el código antiguo soluciona exactamente nuestro problema y que usarlo no va a requerir esfuerzo. Esto puede llevar a estimar incorrectamente el tiempo que se va a tardar en terminar el trabajo. Por otro lado, el código antiguo después de ser adaptado va a ser más complejo que antes, porque ahora tiene que poder satisfacer dos casos de uso distintos: aquel para el que se escribió en primer lugar y el nuevo para el que se está intentando usar ahora. Por lo tanto, ahora requerirá seguramente más configuración, una lógica más compleja y por lo tanto mayor probabilidad de defectos. Además, es posible que las personas que escribieron el código original ya no estén en el equipo y esto requiera tener que aprenderse un sistema nuevo para poder modificarlo y arreglarlo. Con suficientes intentos de reutilización de este tipo, donde cada uno añade nuevos casos de uso, expande la interfaz y hace más complejo el código, el sistema puede acabar volviéndose insostenible de mantener y una fuente constante de problemas.

Otro problema potencial es que la pérdida de conocimiento y contexto sobre el propósito original del código lleve a sobreestimar sus capacidades o a asumirle funcionalidad o casos de uso que no tiene en realidad. Esto puede llevar a intentar reusar un sistema para un problema para el que no estaba preparado. Si el darse cuenta de que el sistema no sirve se da tarde, el equipo puede estar metiéndose en un callejón sin salida del que la única forma de escapar es tirando a la basura mucho trabajo o modificando severamente el sistema para que se adapte al nuevo caso de uso, terminando potencialmente en la situación de complejidad inasumible mencionado en el párrafo anterior.

Un último problema es cuando el trabajo ahorrado por la reutilización es menor que el tiempo que habría llevado reescribirlo en primer lugar. Invertir una semana de trabajo en reusar un sistema que se tardó tres meses en escribir suena a un intercambio razonable. Sin embargo, invertir una semana de trabajo en reusar un sistema que se tardó una semana en escribir ya no suena tan bien. Por el mismo esfuerzo el equipo podría haber tenido una solución adaptada exactamente a su situación. En vez de eso, tienen una solución del pasado que más o menos han conseguido adaptar a su problema, a coste de mayor complejidad y un uso más incómodo. ¡Y sin ahorrar tiempo!

Hacer código reusable por supuesto implica diseñar bien las interfaces, minimizar el número de dependencias o documentar cómo se usa, qué partes tiene y qué hace cada una. Sin embargo, otra parte todavía más importante de escribir código reusable es documentar a conciencia el contexto en el que se escribió, los problemas que resuelve, y, sobre todo, los problemas que no resuelve, las limitaciones insalvables que contiene, las asunciones bajo las que se escribió, el trabajo que queda por hacer y los defectos conocidos. Un equipo debería poder tomar la decisión informada de si les interesa reusar el código o escribir su propia solución. El código reusable debería escribirse bajo la máxima de que no reusarlo es una opción perfectamente válida y legítima. Si no, la documentación no es documentación, es marketing.