Reutilización del código en las empresas

Todos los que trabajamos en programación conocemos la idea de la reutilización de código. Es sencillo y evidente. Si tienes tu código organizado y bien estructurado, se puede reutilizar desde otro proyecto.

Y evidentemente la mejor forma es mantener esas funciones en sitios comunes que se puedan llamar desde varios proyectos. Eso es lo mejor de lo mejor. Evitamos redundancias de código, optimizamos desarrollo, vamos la leche, ¿a quien no le gusta? 

Pero ahora llegamos a la empresa y veamos que puede pasar:

Escenario 1: proyecto con N desarrolladores y que finalmente acaba con N variantes de la misma funcionalidad por que la necesitaban todos y cada uno se lo ha guisado y se lo ha comido.

Algunas veces, antes de llegar a ese punto, si el jefe de proyecto es avispado (tampoco es muy normal que lo sea), se da cuenta de lo que puede pasar y organiza un poco el tema y llegamos al siguiente:

Escenario 2: un proyecto con varios desarrolladores y uno o varios de ellos desarrollan y mantienen un conjunto de librerías comunes para todo el proyecto.

Genial, objetivo conseguido, pero ahora viene lo más difícil todavía:

Escenario 3: Varios proyectos con diferentes desarrolladores cada uno. Aquí el resultado es el mismo en el mejor de los casos, cada proyecto acaba teniendo sus propias librerías. Si hay suerte y hay algún desarrollador con contactos, algún proyecto tendrá una librería copiada de otro proyecto, pero con modificaciones de acuerdo a sus necesidades.

Y puestos a imaginar, vamos a por el escenario ideal (es que me pierde la imaginación)

Escenario 4: Varios proyectos con diferentes desarrolladores cada uno. Como puede haber funcionalidades comunes, y es muy normal tener ciertas librerías en común, y suponiendo que haya un gestor eficaz y con conocimientos, aparecerá otro grupo de desarrollo, encargado de desarrollar y mantener esa serie de librerías de uso común.

Evidentemente el último escenario, por perfecto, es prácticamente imposible. Ya que la premisa de "gestor eficaz y con conocimientos" es una idea fantástica, algo así como cazar unicornios rosas por el monte. En los muchos años que llevo trabajando en el sector me he encontrado muy pocas veces ese escenario idea número 4, y cuando me lo he encontrado el grupo de desarrollo de la parte común estaba desaparecido y los diferentes proyectos acababan copiando y adaptando las librerías según sus necesidades (con lo que volvemos al escenario número 3).

Así que si tienes suerte puede que trabajes en el entorno número 2 o en el número 3, pero es muy habitual, realmente demasiado, que te toque trabajar en el 1.

Así que ya sabes otra de las razones por las que los proyectos de software tienden al caos de manera casi inevitable...