Mantra

O lees o escribes, o consumes o produces, o usas tecnología de otros o la creas. Ya sabes que lo más complicado está en lo segundo (escribir, producir y crear) y no comprendo por qué pasamos los desarrolladores de software más tiempo en lo primero que en esto último.

Es especialmente emocionante cuando sacas a la luz algo en lo que has estado trabajando muchísimo tiempo (años).

Me pasa con todos y cada uno de mis libros, cuando por fin ves el último trabajo en todas las tiendas de Amazon y el resto de plataformas (como esta pequeña aportación que he lanzado recientemente sobre Bitcoin), cuando publico un nuevo proyecto o cuando por fin paso a producción el realizado para algún cliente.

Desde hace unos meses, ya puedo decir que existe una release de Mantra suficientemente madura como para poder ser usada en proyectos en producción.

Para lo bueno y para lo malo, como desarrador profesional de software así como responsable de equipos y de proyectos desde hace más años de los que recuerdo, me ha tocado a menudo trabajar en proyectos más bien grandes y complejos y que, a lo largo de su ciclo de vida, han tenido que evolucionar mucho con bastante dificultad.

Del mismo modo, también me han contratado en ocasiones para evaluar la calidad de un proyecto software y recetar qué hay que mejorar para que la bola de barro (deuda técnica) no siga creciendo hasta hacer el proyecto inviable, inmanejable o inmantenible, cuando no se ha tenido que tirar todo a la basura y comenzar de nuevo, para espanto de los directivos y frustración de los desarrolladores. Esto no solo suele ocurrir por falta de profesionalidad en el código, también por déficits organizativos, entre otras cuestiones.

Te aseguro que detectar todo lo anterior no es ni fácil ni sencillo.

Esto es, conozco de primera mano por qué el software tiende a corromperse, cómo y por qué se acumula deuda técnica y cuáles son los malos hábitos de nosotros los desarrolladores que hace que un proyecto sea costoso de mantener, y también, tal y como digo, los malos hábitos organizativos que contribuyen a todo lo anterior.

Si has leído alguno de mis libros, sabrás ya que hablo de estos temas continuamente y en profundidad en ellos.

Y lo sé porque yo soy el primero que he cometido (y sufrido) todos los errores que se puedan cometer, pero siempre con el propósito de no comenter el mismo error más de una vez...

No en vano, uno de mis libros ("Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido"), sugiere cómo mejorar en un conjunto de pasos la calidad de un proyecto software heredado y que hay que modernizar.

Mantra es un framework basado en Node.js que obliga a estructurar correctamente un proyecto, en base a una componetización radical y un desacoplamiento extremo entre ellos, permitiendo, a la vez, una alta testeabilidad y reusabilidad de todos y cada uno de los componentes que forman parte de un proyecto, entre muchas otras características.

Mantra no nace para competir con otros propuestas que existen desde hace mucho más tiempo (como Next.js, y que me encanta, por cierto), sino para dar respuesta a lo que yo considero que es una forma viable de enfocar el desarrollo de software para minimizar esa deuda técnica que tanto daño hace a la competivividad de las empresas, especialmente en proyectos de gran tamaño, que evolucionarán mucho, de alto rendimiento y escalables y que tienen que ser lo más competitivos posible.

Por decirlo de algún modo y sin que suene especialmente pretencioso: Mantra implementa un paradigma de desarrollo de software.

El desarrollo de un proyecto con Mantra sigue una serie de principios que he estructurado de la mejor manera posible en un whitepaper que puedes leer en inglés y en español.

Quizá, el whitepaper en el que se basa Mantra te sorprenda, porque, en realidad, más que identificar unos principios a seguir, se trata en verdad de un cambio de paradigma para enfocar el desarrollo de proyectos profesionales, grandes, evolucionables y escalables. 

Es mi pequeña contribución a la ingeniería del software aunque, créeme, muchos de esos principios son, sencillamente, buenas prácticas bien conocidas en nuestro sector pero que he agrupado en un conjunto coherente y que se implementa en Mantra para que los proyectos puedan crecer y evolucionar (con requisitos aún desconocidos) sin acumular deuda técnica.

Algunos de estos principios, incluyen:

• Componetización radical: un componente es la pieza fundamental de código de un proyecto y, por definición, es pequeño y reutilizable, apenas unos cientos de líneas de código.
• Un componente implementa una funcionalidad muy específica y la expone al resto del proyecto.
• Por definición, un componente está totalmente desacoplado de otro (las dependencias son blandas y no duras).
• La funcionalidad de alto nivel se implementa mediante orquestación de funcionalidad de bajo nivel.
• La persistencia de datos de un componente es transparente al mismo y no supone un vínculo fuerte.
• Un componente define modelos de datos minimalistas (apenas una, dos o tres entidades). Sí, leelo bien, nada de bases de datos grandes y acopladas, imposibles de mantener, migrar y evolucionar. Es más, Mantra permite aplicaciones multirepositorios (que usan varias fuentes de datos de forma transparente).
• Un proyecto está basado en un conjunto de aplicaciones que se comunican entre ellas.
• Las migraciones de un proyecto son frecuentes e incrementales.
• etc.

Las consecuencias prácticas de aplicar los principios anteriores son increíbles: proyectos evolucionables, sencillos y menos costosos de mantener, mayor reusabilidad, mejor testing y escalabilidad.

Con Mantra he construido ya varios proyectos para diversos clientes, incluidos Hub de Libros así como el mismo site del proyecto, claro está.

Y funciona: el esfuerzo para la evolución de cada proyecto (implementación de nuevos requisitos) es pequeño si se han seguido los conceptos anteriores, la mantenibilidad es extraordinaria y la satisfacción de desarrollador alta porque pasamos la mayor parte del tiempo... implementando funcionalidad o modificando la existente.

Aunque ya se puede usar libremente, Mantra es un proyecto más ambicioso en el que iremos publicando componentes descargables, seguros y probados, con funcionalidad habitual así como proyectos completos que puedan ser puntos de partida para proyectos finales específicos.

Sinceramente, estoy entusiasmado con Mantra, creo que es el proyecto más complejo que he realizado nunca y confío en poder dedicar gran parte de mi tiempo profesional a él.

¿Cómo aprender a realizar aplicaciones con Mantra?

La curva de aprendizaje es extraordinariamente corta.

Se ha hecho un gran esfuerzo en crear una documentación exhaustiva y clara (de momento solo en inglés), y, además, continuamente se están publicando proyectos de demostración mostrando cómo realizar tareas concretas, además de la constante publicación de how-tos indicando en breves artículos cómo hacer tareas concretas.

Mantra, como cualquier proyecto software, es un proyecto en evolución continua, en el que constantemente se están introduciendo mejoras de rendimiento y en la funcionalidad existente, pero con el compromiso de que el usuario y la empresa que usa Mantra, no tenga que pagar un coste por migraciones a las nuevas releases que vayamos lanzando, porque, insisto, uno de los objetivos que tiene Mantra es reducir el coste del desarrollo de aplicaciones profesionales para que sean más competitivas, y esto se consigue desde diversos ángulos.

Como framework, fue surgiendo poco a poco de forma natural al trabajar todos estos años atrás en proyectos basados en Node.js y sin convencerme del todo otros frameworks que ya existen, sencillamente por no poder implementar fácilmente y de forma natural los principios anteriores.

Como CTO de Mantra, confío en que esta aportación sea de una gran utilidad para nuestro sector, siempre en evolución y siempre con ese espíritu de kaizen de mejora continua.