Diario de Programación

Llevo mucho tiempo intentando hacer código que se pueda reutilizar en varios proyectos.

Al principio es fácil. El código reutilizable que haces suelen ser pequeños componentes o librerías a las que más o menos es fácil llamar y que cumplen un trabajo muy concreto: Un algoritmo matemático, unos editores numéricos, de fecha/hora etc.

Poco a poco, la cosa se va complicando. Ves posibilidad de hacer código reutilizable de más alto nivel. Ves que en todas tus aplicaciones hay partes comunes. Por ejemplo, pedir un usuario y password y entrar en la aplicación. Muchas ventanas que van contra base de datos, etc, etc. Te lo piensas y los grupos de componentes y librerías que salen son más grandes y requieren configuraciones más complejas. También es más difícil que te salgan bien a la primera.

Sin embargo, el problema realmente gordo es otro. Si estás trabajando con un grupo de desarrolladores más o menos grande -y más de dos son multitud-, que además entran y salen de la empresa, difícilmente van a reutilizar ese código. En primer lugar no saben que existe salvo que alguien se lo cuente. Tampoco, aunque sepan que existe, saben cómo usarlo. La "curva de aprendizaje" de esos componentes reutilizables es muy pendiente.

¿Soluciones? La verdad es que no tengo ni idea. Todavía ando peleándome con esos temas.

Una que parece evidente es hacer documentación de esos componentes. Sin embargo tengo mis dudas de que funcione -de hecho ya hay documentación y nadie la mira ni por asomo-. A los nuevos hay que decirles que existen los componentes y que los usen. La documentación les puede aclarar cómo usarlos. Si no les dices qué componentes hay y les das un tocho-documento de componentes reutilizables, veo muy probable que ni siquiera lo miren. Muchas veces pensarán que tardan menos en hacer algo nuevo que en buscar si existe en la librería.

Otra que me planteo es la programación por parejas propia de la programación extrema. La programación por parejas, entre otras cosas, permite que la gente vaya conociendo sin demasiado esfuerzo los componentes comunes. Los nuevos van aprendiendo su existencia y cómo utilizarlos cuando programan en pareja con alguien más antiguo que ya los usa. Sin embargo, este tipo de cosas, programación en parejas, está en general muy mal visto por los jefes ¿para qué hacen falta dos para el trabajo de uno?. Encima, siguiendo las modernidades de ahora de que la gente debe trabajar en mesas corridas y salas diáfanas, sin despachos, podría ser un pequeño guirigay tantas parejas trabajando y hablando.

¿Quizás un diseño detallado de verdad en el que se diga qué componentes deben utilizarse en cada caso?. Seamos realistas, ¿quién hace diseño detallado antes del código y lo hace de verdad, pensando en lo que se va a codificar?. No sé, puede que alguna empresa lo haga, pero no la conozco.

Lo único que parece que medio funciona y, desde luego, no es la mejor solución, es que los que saben de esos componentes vayan llevando de la mano a los nuevos, diciéndoles qué usar y cómo. No es la programación por parejas, pero se le parece mucho, al menos en este aspecto de aprendizaje. El problema es que los antiguos van ascendiendo, cogiendo responsabilidades y cada vez pueden dedicarse menos a los nuevos.

Entradas relacionadas:

• No hay entradas relacionadas.