En este primer post del año, quiero reflexionar acerca de una característica que llevo observando en los proyectos que implemento o dirijo desde hace más tiempo del que recuerdo, pero que quizá no se tenga demasiado en cuenta cuando estamos desarrollando software.

Si has tenido alguna vez la sensación de que se han implementado funcionalidades o características similares de un proyecto a otro, entonces puede que tengas la oportunidad de extraerlas de un modo útil para su reutilización. No en vano, no tiene sentido implementar un nuevo proyecto totalmente desde cero (sin usar ningún tipo de framework y librerías de terceros), reinventando la rueda una y otra vez, a no ser que se esté experimentando o aprendiendo.

Aunque pueda sonar algo extraño, el denostado y fatídico 2020 ha sido para mí un año muy productivo y creativo; al margen de todo lo relacionado con estos tiempos agitados que estamos viviendo con pandemia, confinamientos, derrumbe económico, etc., puedo decir que, afortunadamente, lancé varios proyectos que espero que vayan mejorando en los próximos meses; algunos de ellos se venían gestando desde el año anterior, otros, como mis libros y que también considero proyectos, fueron surgiendo a medida que acumulaba temas sobre los que hablar y que pudiese sintetizar en ese formato, sobre todo después de lanzar Hub de Libros.

Siempre he animado a todo el mundo a estar trabajando en proyectos personales y no solo dedicarse exclusivamente a aquellos por los que les pagan como empleados en sus compañías o los que te contratan como freelance: la riqueza que se obtiene de dedicar tiempo a ellos siempre me ha parecido que es incluso superior a la de realizar cursos, seminarios y leer libros.

Tanto es así, que, con el tiempo, comienza a diluirse la frontera de lo que es un proyecto personal y lo que no, ya que yo, a estas alturas, lo considero parte de mi trabajo profesional y me tomo tan en serio tanto lo uno como lo otro, independientemente de mi condición de freelance y consultor independiente. Es más, proyectos que inicialmente eran personales y realizados casi por juguetear un poco, terminaron convirtiéndose en productos comerciales y corporativos, como Picly.io.

En mi propio cocktail de autoformación continua, siempre tengo uno o dos libros que estoy leyendo (tanto técnicos como de muchos otros temas), podcasts que escucho regularmente y algún que otro curso, cuando no aplico ese principio que dice que aprendes lo que enseñas, de ahí que regularmente trabaje en un nuevo proyecto literario, y este nuevo año tengo ya varios proyectos en mente. Y, sin embargo, y como decía antes, lo que percibo como más enriquecedor es realizar un proyecto de verdad, porque, lógicamente, se aprende leyendo, escuchando podcasts y haciendo cursos, claro está, pero lo que has aprendido solo se consolida en conocimiento cuando lo has puesto en práctica. Obvio.

Leer esta bien y es necesario, qué duda cabe, pero aplicar lo aprendido es todavía mejor.

Sin embargo, hay una característica de realizar proyectos (tanto dentro de una empresa como personales) que me viene a animar todavía más para realizarlos y que requiere de trabajar con cierta actitud porque afecta incluso al modo en que los enfocas y diseñas.

En software, la reutilización es un concepto fundamental: nada peor que encontrar redundancias dentro de la misma solución. Eliminarlas es importante para mantenerla un poco más limpia y mejor estructurada; tanto es así, que en la metodología (una de tantas) que propongo para modernizar proyectos heredados en mi último libro (Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido), le dedico un capítulo completo.

Hay diferentes niveles en esta reutilización de la que hablamos: puede afectar a simples funciones, clases de ayuda o componentes, pero también a grupos funcionales de mayor importancia dentro del proyecto.

Un paso más allá consiste en tener cierto nivel de abstracción y ver, concretar y diseñar dentro del mismo proyecto, otros de menor tamaño en los que se apoya.

En Hub de Libros, sin ir más lejos, se utiliza un potente gestor masivo de archivos que, poco a poco, fui extrayendo como un proyecto propio y que lo tengo publicado con el nombre de files-repo en GitHub; del mismo modo, el framework en el que se basa (Mantra), fue generando poco a poco una librería a modo de ORM que, también, extraje como proyecto independiente (se trata de RedEntities), y algunos más que aún no he publicado.

De este modo, un mismo proyecto ha generado diversos subproyectos independientes que, sin duda, reutilizaré a menudo y que quién sabe a dónde me conducirán.

La dificultad de extraer un subproyecto no radica en copiar y pegar sencillamente un conjunto de clases o componentes, sino en implementarlo de modo que no esté vinculado al proyecto padre de donde surgieron para así aportar una solución que se pueda integrar con naturalidad y no forzadamente en otros proyectos.

Con el tiempo, mantener esta actitud de detectar lo que puede ser un nuevo subproyecto, tiene ventajas inesperadas, ya que de ese modo, cuando te enfrentas a un nuevo desarrollo y que, como yo, tienes la responsabilidad de estimar el esfuerzo y hasta de determinar las bases de su diseño y arquitectura, piensas y lo enfocas ya no solo como un conjunto de componentes que se orquestarán de algún modo, sino que los abordas también con un conjunto de subproyectos que se desarrollarán independientemente y que serán integrados a su debido tiempo.

De este modo, animo a trabajar con esto en mente y a detectar qué partes homogéneas de una solución se pueden extraer como proyectos independientes.

Esto, además, puede ser hasta una estrategia comercial para obtener más productos de lo desarrollado en uno de ellos, algo que también he hecho en los últimos años tratando de rentabilizar librerías y desarrollos que se hicieron específicamente para ciertos clientes.

Conclusión: si pensamos en un nuevo desarrollo tratando de distinguir algunos subproyectos que se integran en él, lo podremos rentabilizar mejor y la reutilización de éstos nos permitirá avanzar más rápido en los siguientes proyectos y hasta plantear nuevos productos independientes.

Comparte esta entrada...

De qué hablo cuando hablo de programar (volumen 1)

PD: artículo revisado, corregido y mejorado en mi libro "De qué hablo cuando hablo de programar (volumen1)".

Todos mis libros

Todos los libros de Rafael Gómez Blanes

Mi último libro (el primero para un público general): Bitcoin, Una guía esencial y práctica para comprender y usar la mayor innovación de la historia después de Internet.

De qué hablo cuando hablo de programar (volumen 1 y 2): Cómo avanzar mejor y más rápido en tu carrera como desarrollador.

Si quieres conseguir una carrera de éxito desarrollando software y saber cómo evitar los errores habituales, lee El Libro Negro del Programador best seller en su categoría en Amazon), o adquiérelo ya aquí.

Si quieres conocer las principales técnicas de desarrollo ágil, código limpio y refactoring, lee El Libro Práctico del Programador Ágil, o descárgalo ya aquí.

Si estás de acuerdo conmigo en que somos seres de hábitos, conviértete en mejor profesional leyendo The Coder Habits, o consíguelo ya aquí.

Los tres libros técnicos los tienes ahora a tu disposición en el pack La Trilogía del Programador Profesional, léelo ya.

Si tienes un proyecto que gestionar y no sabes cómo, aprende metodología lean y lee El Método Lean MP, o adquiérelo aquí.

Si quieres emprender y desarrollar un proyecto digital, lee El Arte del Emprendedor Digital

Las Doce Claves, las claves de desarrollo personal extraidas de El Arte del Emprendedor Digital

Para tratar con código heredado: Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...