Desde hace mucho he usado Redis como una de mis utilidades favoritas para integrarla en mis proyectos. Para quien no lo conozca bien, Redis se ha considerado siempre un servicio de almacenamiento en memoria tipo clave/valor

Sin embargo, desde hace tiempo Redis es muchísmo más, soportando diversas estructuras de datos que lo enriquecen y que hace que se le pueda dar un uso mucho más amplio.

No es una aplicación que se utiliza únicamente como caché de métricas, sesiones de usuario, etc., sino que para determinadas aplicaciones cuya necesidad de almacenamiento de información no es necesariamente relacional, Redis se puede usar perfectamente como base de datos.

Existen servidores en memoria similares como Memcache. Sin embargo, en Picly.io (servidor avanzado de imágenes, proyecto en pleno desarrollo), hemos decidido usar como base de datos Redis; esto es una decisión importante de diseño y que, de algún modo, condicionará el despliegue y uso de ese servicio.

Lo que quiero recalcar es que perfectamente Redis puede sustituir en algunas ocasiones el uso de bases de datos como MySql, MongoDB, Sql Server, etc.

En este caso, estos son los argumentos que me han llevado a elegir Redis como repositorio de datos para Picly.io:

  • El core de Picly debe ser pequeño pero muy robusto y eficiente.
  • La necesidad de almacenamiento de información de Picly es relativamente sencilla: estructuras de datos planas y con relaciones muy simples.
  • El rendimiento debe ser extraordinario para servir imágenes y su procesamiento y transformaciones lo más rápido posible.
  • Redis es un producto de libre uso muy maduro, con mucha documentación y una comunidad muy amplia.
  • La instalación es sencilla, como se puede ver en este artículo para un Ubuntu 16; su mantenimiento, también.
  • Para grandes instancias de Picly (con millones de imágenes o requests de transformación de imágenes), Redis se puede escalar entre varios servidores y está soportado por diversos proveedores de servicios en cloud, como Azure Redis Cache

Y una cosa interesante: el rendimiento de Redis, el tiempo que va a tardar en devolver un objeto, es determinista, lo que no ocurre con una base de datos relacional salvo que se configure correctamente y usando muchos recursos.

Algunas de las estructuras de datos que soporta Redis son objetos clave/valor, hashes, listas, listas ordenadas con paginación, etc., lo suficiente para que una aplicación pueda apoyarse en este producto sin necesidad de usar un servidor de base de datos más pesado. Además, una incorporación desde versiones anteriores es la capacidad de utilizar scripts con Lua, permitiendo realizar consultas y procesos de cálculo más complejas.

Ahora bien, el uso directo de Redis mediante sus comandos básicos (como HADD, ZRANGE, etc.), puede enmarañar u ofuscar una aplicación de alto nivel que lo utilice.

Para ello, y puesto que Picly.io se está desarrollando con Node JS, estoy desarrollando una pequeña librería para encapsular cómodamente el uso de Redis por parte de una aplicación.

La he denominado Blue Entities y está disponible en Github; aunque se usa en Picly, todavía no me atrevería a decir que está lista para producción y tenemos pendiente incorporar bastantes mejoras en los próximos meses.

Github logo

Blue Entities

Por poner un ejemplo, con esta módulo de Node, y a partir de un esquema como:

var schema = {
   name: "users",
   properties: [
      { name: "mail", type: "string" },
      { name: "password", type: "string" },
      { name: "active", type: "boolean" },
      { name: "age", type: "integer" }
   ]
}

, se pueden añadir entidades de esta forma:

var redisConfig = { host: "localhost", port: 6379 };
var blueEntities = require("blueentities")(schema, redisConfig );

var newUser = {
   mail: "info@solidstack.es",
   password: "123454321",
   active: true,
   age: 43
}

blueEntities.addEntity( "users", newUser )
	.then( function(id) {
		// User added!!!
	});

Y su recuperación de la base de datos es trivial (y a alto nivel, que es lo interesante):

blueEntities.getEntity( "users", id )
	.then( function(user) {
		// User retrieved!!!
	});

Internamente, las entidades son convertidas a objetos de Redis pero de forma transparente y eficiente para el cliente de Blue Entities.

Existen otros proyectos muchos más completos y a modo de ORM para Redis y NodeJS, pero me parecieron demasiado pesados para las necesidades de almacenamiento de Picly.io.

En cualquier caso, sugiero encarecidamente evaluar bien cómo encaja Redis en los proyectos que desarrollamos y considerarlo como una utilidad importante a tener en cuenta.

A menudo me encuentro con la necesidad de evaluar posibles proyectos en los que se hace una apreciación muy ingenua de la dificultad y esfuerzo que cuestan desarrollar ciertas cosas.

Estamos en un momento en que cada día aparecen nuevas apps, nuevos servicios, otros cierran y los medios de comunicación muestran continuamente el éxito millonario de la startup de moda.

Sin embargo, se obvia el enorme esfuerzo y la extraordinaria complejidad que hay detrás de cualquier aplicación que medio funcione, a nivel empresarial, organizativo y financiero.

Hay tres compañías que me gustan mucho y que sigo desde hace tiempo: Doodle, Etsy y Cloudinary.

Por si no los conoces, Doodle es una startup alemana cuya aplicación facilita la creación de eventos, tanto personales como corporativos.

Por su parte, Etsy comenzó hace muchos años cuando solo unos pocos hablaban de economía colaborativa; es un portal que permite vender a artesanos de todo el mundo sus productos a cualquier cliente que se encuentre en cualquier parte. Tú haces el producto, ellos se encargan de mostrarlo y de solucionar la logística de pagos y de transporte hasta el cliente que lo compra. Conozco a gente cercana que se gana su dinerillo con Etsy. Para mí un ejemplo a seguir por ese sesgo que tiene de favorecer la economía colaborativa.

Y, por su parte, Cloudinary es un servicio que montaron unos desarrolladores hartos de tener que tratar continuamente con el problema de la gestión de imágenes en sus proyectos. Ofrecen un servicio por el que una aplicación sube las imágenes que utiliza y Cloudinary se encarga de ofrecer mediante una sintaxis basada en la url de devolverla manipulada según tus necesidades, entre otras cosas, actuando también con CDN.

Tres servicios, en mi opinión, muy útiles y hasta ahora con éxito.

Doodle logo
Etsy logo
Cloudinary logo

Pero, ¿qué tienen en común y por qué estoy hablando de ellos?

Lo que no se aprecia es que detrás de esos servicios no hay dos frikies trabajando en un garaje hasta las tantas de la noche para hacerlos funcionar, sino equipos con un montón de personas para que todo siga en marcha. Y no hablo solo de perfiles técnicos (front-end developers, Q&A engineers, etc.), sino también accounts managers, CEOs, marketing & community managers, etc.

En concreto, en los siguientes enlaces se puede ver algo de información sobre los equipos de Doodle, Etsy y Cloudinary:

  • El equipo de Doodle está compuesto de más de treinta personas, con roles que van desde product managers, hasta ingenieros iOS juniors.
  • ¿Cuántas personas crees que trabajan y permiten hacer que funcione Etsy? Échale un vistazo a la web, a sus servicios. Pues bien, más de cien personas colaboran para hacer posible que una idea como Etsy.com funcione en todo el mundo.
  • Cloudinary ha sido para mí una gran fuente de inspiración, porque ya hace años me di cuenta de lo recurrente que es en los proyectos la gestión de las imágenes. Ellos lo han resuelto de una forma extraordinaria, ofreciendo un servicio de alojamiento y de CDN genial. Unas sesenta personas dan vida a Cloudinary, nada más y nada menos.

Hace un tiempo oí quejarse a alguien que usaba los cupones de Groupon por el tipo de comisión que se llevaban... Esta persona me decía que "total, eso es una web y ya está". Pues sí, ves el servicio en forma de web y también como aplicación móvil en el mejor de los casos, pero detrás existe una infraestructura software y hardware que le permite funcionar en todo el mundo, con legislaciones diferentes, distintos idiomas, una enorme cantidad de datos a tratar, etc.

De modo que cuando me tengo que encargar de evaluar una de esas propuestas felices que pretenden hacer rico a más de uno en dos días, simplemente, sonrío y me armo de paciencia.

S.O.L.I.D.

Un artículo de Rafa G. Blanes

¿Cómo conseguir que un proyecto software sea mantenible y que se pueda modificar con sencillez?

Esta pregunta tiene muchas respuestas, según la naturaleza del mismo proyecto, claro. No obstante, existen una serie de principios que, de seguirlos, la vida (y estructura) de un proyecto puede cambiar de una forma radical.

Demasiado a menudo veo proyectos, sin ir más lejos, muchos repositorios en GitHub, en los que es imposible discernir cómo se han implementado los principios de diseño más básicos en ingeniería del software, y no es que esté mal, claro, todo depende de la vida que vaya a tener ese proyecto.

No hace falta que conozcamos al detalle todos y cada uno de los patrones de diseño que más o menos son conocidos y aceptados por la industria y muy bien explicados en libros clásicos como este, pero, desde luego, si lo que queremos es que nuestro proyecto pueda ser mejorado continuamente sin demasiada dificultad, entonces sí que hay que seguir unas mínimas normas de desarrollo.

Aquí es donde entran los principios S.O.L.I.D.

Si tu proyecto tienen clases o funciones extraordinariamente largas del orden de cientos de líneas de código, si hay métodos con innumerables if o con muchos bloques anidados, o hay métodos o funciones con muchos parámetros, entonces tu aplicación camina hacia una solución espagueti difícil de mantener y evolucionar. 

Si es así, sigue leyendo...

¿Qué diferencia un principio de diseño de un patrón?

Mientras que un patrón es una solución técnica y clara a un problema particular, un principio es una guía que debe cumplir tu código a nivel de diseño. Los mejores frameworks de desarrollo son los que mejor cumplen con estos principios, y estoy pensando sin ir más lejos en Seneca, un framework que me gusta mucho para construir microservicios en NodeJS, aunque hay muchos otros ejemplos.

A grandes rasgos, los principios S.O.L.I.D. permiten diseñar una aplicación de un modo que:

  • Tenga un alto grado de desacoplamiento entre sus partes funcionales.
  • Se pueda extender en funcionalidad con sencillez, sin grandes cambios en la aplicación.
  • Es testeable.
  • Mejora la reusabilidad del código.

Aunque su implementación es más natural en programación orientada a objetos, se pueden aplicar en lenguajes funcionales. En el contexto de este artículo, hablaremos de entidades software para referirnos a clases, módulos, métodos, funciones, etc.

A continuación indico un breve resumen de estos cinco principios, junto con una técnica igualmente relevante, y que es la inversión de control.

Single-responsability principle (SRP o principio de responsabilidad única)

Una clase se debe dedicar a resolver un único problema, esto es, no se debe implementar una clase cuya funcionalidad mezcle ámbitos de la aplicación diferentes.

Si se utiliza bien este principio, entonces se podrán generar clases más o menos pequeñas y, por tanto, más reutilizables y fáciles de modificar y probar.

En el contexto de este principio, se entiende por responsabilidad como la razón para cambiar, esto es, si en una clase existe más de un motivo por el que puede cambiar, entonces es que no sigue este principo.

Quizá no sea simple de ver al comienzo, pero en este snippet de código indico un ejemplo sencillo (y algo académico), escrito en javascript para NodeJS.

Open-closed principel (OCP o principio abierto/cerrado)

Según este principio, una clase se debe diseñar de modo que sea fácilmente extendible sin modificar su funcionalidad actual. Fácil de describir, pero para implementarlo hace falta cierto grado de abstracción. Según la característica de la aplicación en la que se esté trabajando este principio se puede aplicar o no.

No niego que este principio sea algo sutil, pero si se entiende bien, en realidad lo que está indicando es que la entidad software debe abstraer al máximo el core de la funcionalidad que implementa.

Lo que persigue conseguir OCP es extender la funcionalidad de una entidad software sin modificar su código, y para ello, como digo, hace falta cierta abstracción.

En este otro snippet de código indico cómo aplicar este principio en el clásico ejemplo de validación de entradas de usuario.

Liskov substitution principle (LSP o principio de sustitución de Liskov)

Este es quizá el principio más sutil de entender, pero igualmente importante. Con LSP lo que se pretende es asegurarnos de que se implementa correctamente la herencia entre clases.

Entendemos como clase hija o extendida aquella que deriva de otra.

La definición es un tanto académica, de modo que haré una descripción más sencilla; lo que viene a decir LSP es que si un programa utiliza una clase, entonces deberá seguir siendo válido (= funcionará bien) si se la sustituye por una nueva clase que derive de ella. Si un programa utiliza la clase P, y en su lugar sustituimos P por O (donde O deriva de P), entonces, el programa deberá seguir funcionando correctamente.

Y aquí la definición de la autora (Bárbara Kiskov): si o1 es un objeto de tipo S, y o2 es un objeto de tipo T, si el comportamiento de un programa (función, método, etc.) basado en objetos T, usando o1 y o2 no cambia, entonces necesariamente S es un subtipo de T.

Puff..., en realidad está indicando cómo hay que implementar la herencia entre clases.

Sencillo de decir, no tan obvio de saber implementar, aunque con este principio nos garantizamos que la herencia se hace bien y además las clases base (padre) y sus derivadas (hijas) son más fácilmente testeables.

LSP está muy relacionado con el principio OCP, ya que establece también que una clase hija debe extender el comportamiento de la padre, no modificarlo.

Para implementar LSP hace falta un grado alto de abstracción de la solución que pretendemos resolver; si se rompe este principio en nuestro diseño, entonces es que no se está abstrayendo lo suficientemente bien.

Aquí dejo un ejemplo ilustrativo que cumple LSP.

Por último, una forma de forzar que se cumple este principio es usar diseño por contratos, en el que se especifican interfaces y las clases base las implementan.

Interface segregation principle (ISP o principio de segregación de interfaz)

Este principio pretende evitar la creación de interfaces extensas con métodos que no tienen nada que ver unos con otros, de modo que una clase que derive de ellas tenga que dejar sin implementar algunos de esos métodos porque no los necesita. 

Con ISP lo que se sugiere es dividir esta interfaz (fat interface) en interfaces más pequeñas y coherentes, de modo que las clases que deriven de ellas lo hagan porque necesitan todos y cada uno de sus métodos.

La consecuencia de este principio es que necesariamente las interfaces que se definen en el proyecto tienen un alto grado de abstracción y de granularidad.

En este otro ejemplo, se puede ver cómo aplicar este principio.

Dependency inversion principle (DIP o principio de inversion de dependencias)

Este principo es, quizá, el más popular de todos y el más fácil de implementar y en ocasiones se le confunde con la inyección de dependencias.

Lo que viene a decir es que nuestro código (en un módulo, una clase, etc.) debe depender de abstracciones, no de instancias concretas de las mismas.

Entendemos por abstracción la definición que debe implementar una clase concreta, lo que viene a ser lo mismo que clases abstractas e interfaces en OOP.

Con DIP conseguimos que el código esté más desacoplado y que las unidades de funcionalidad sean más pequeñas (y, por tanto, reutilizables y testeables).

Inversion of control (IoC o inversión de control)

La inversión de control no está dentro del conjunto S.O.L.I.D pero sin embargo está en la línea de conseguir código más desacoplado y mantenible, sin embargo; no es aplicable a cualquier tipo de proyectos.

Tradicionalmente, podemos decir muy simplificadamente que la implementación de un programa consiste en la ejecución de una llamada a un método o función tras otro. Sin embargo, a medida que este programa crece, es necesario estructurar la aplicación en módulos, entran en juego diversas arquitecturas, etc.

Es decir, el flujo habitual de una aplicación consiste en llamar a procedimientos (funciones o métodos) de una biblioteca.

Se implementa la inversión de control cuando se invierte ese flujo, esto es, cuando es la misma biblioteca la que llama al código del usuario que es el que implementa realmente la aplicación.

Parece enrevesado, pero hay multitud de ejemplos que implementan inversión de control y, además, es el enfoque natural cuando necesitamos que nuestra aplicación sea fácilmente extensible. Sin embargo, insisto en decir que no siempre es necesario implementar este mecanismo, depende de la naturaleza del proyecto.

IoC y DIP (inversión de control e inversión de dependencias) suelen ir de la mano, ya que es sencillo implementar IoC utilizando DIY:

El año comienza cargado de proyectos y de mucho, muchísimo por hacer. Tengo pendientes muchas lecturas por realizar, muchos hitos que cumplir, tanto en lo personal como en lo profesional, y, entre todo ello, una modernización de esta web en la que ya estoy trabajando y dos nuevos proyectos literarios (uno de ellos técnico).

Es estimulante comenzar el desarrollo de un nuevo producto. Siempre hago una distintación clara entre "productos" y "proyectos", ya que sus ciclos de vida no tienen nada que ver. Personalmente me gustan más los primeros, ya que tienes que pensar de otro modo para afrontarlos, considerar su mantenimiento de una forma radicamente diferente y, además, sabes que si se cierra bien, puedes pasar al siguiente, sin quedarte años trabajando en el mismo proyecto y, por suspuesto, habiendo dejado un nuevo producto para el catálogo de tu compañía. 

Otra cosa es todo lo relacionado con la rentabilidad; aunque esos son temas de desarrollo de negocio, sólo quiero apuntar algo que no me deja de sorprender. Hay demasiadas empresas de software empeñadas en captar proyectos, con el enorme esfuerzo comercial que eso supone, en lugar de apostar más por la creación de un conjunto de productos que, una vez hechos, se pueden vender una, diez o mil veces. ¿Se ve la diferencia? Al menos, integrar un modelo mixto entre productos y proyectos.

Hemos dado lo primeros pasos para el desarrollo de un nuevo producto, de nombre Smart TPL para el que además tenemos ya comprometidas la comercialización de varias licencias. Aunque lo que me interesa aquí es hablar más de cómo lo hacemos que lo que hace realmente. No obstante, aquí indico una breve descripción del mismo.

Smart TPL es una aplicación para móvil que se usará para la lectura en local de contadores digPRIME logoitales de tecnología PRIME. Esto es necesario ya que no todos los contadores que se instalan (ya sean de uso doméstico o industrial), tienen capacidad de telegestión, de modo que sigue siendo necesario que un operario se desplace al lugar de la instalación para obtener sus medidas, eventos, etc. Nota: los contadores de los que hablo con esos dispositivos que se instalan en la puerta de casa o en el cuadro centralizado de un bloque de viviendas para medir el consumo elétrico, entre otros muchos parámetros eléctricos.

¿Cómo vamos a realizar este nuevo producto?

De nuevo, no hay que inventar la rueda en el ciclo de vida, tan sólo seguir las buenas prácticas, que resumo a continuación.

Después de un tiempo en conversaciones con el primer cliente que nos has cumplido su adquisición, hemos intercambiado una serie de documentos con los que hemos consesuado las característias que debe cumplir el producto. De aquí se extraen los requisitos.

Estos requisitos software tienen que consensuarse con el cliente y, sobre todo, me tengo que asegurar que todo el mundo entiende el mismo lenguaje, es decir, todos entendemos igual ese dominio o ese universo particular relacionado con los problemas que resuelve la aplicación.

Esto parece una tontería, pero es vital para que después no termines cayendo en la clásica viñeta de la rueda y el "yo entendí"...

A continuación, se establecen fechas de entregas claras, que son tanto un compromiso personal para el equipo de desarrollo como una expectativa que el cliente espera que se cumpla.

Y, por supuesto, en esta fase, los requisitos, que ya son bien conocidos y están muy claros, se añaden a la herramienta ALM (application lifecycle managemente). En mi caso, no puede ser otra que nuestra suscripción al Visual Studio Online (antiguo Team Foundation Server) de Microsoft. En mi opinión, de las mejoras herramientas para la implementación de proyectos software que existen.

Smart TPL backlog

¿Y qué hay de las tecnologías a usar?

Puesto que conozco y el equipo conoce bien todas las tecnologías relacionadas con .NET Framework, está claro que nos debeíamos decantar por la plataforma Xamarin para el desarrollo de la aplicación móvil.  La decisión de esta elección no se hace por gusto, sino por un asunto de productividad. A expertos en C# les va a resultar muy fácil, e incluso natural, realizar aplicaciones en ese lenguaje aunque sea para otro framework o API diferentes.

XAMARIN logoAdemás, Xamarin ha sido adquirido por Microsoft, lo cual todo hace indicar que su presencia en el mercado se va a mantener durante muchos años y existe una gran comunidad alrededor de Xamarin.

¿Y cuáles son los siguientes pasos?

Puesto que implemento un acercamiento ágil al desarrollo de software, y este proyecto es un claro candidato para ese enfoque, definiremos un primer sprint de trabajo en el que montaremos el proyecto y cerraremos una funcionalidad sencilla del catálogo de requisitos (backlog items).

En este primer sprint:

  • Generaremos una versión muy elemental de la aplicación, pero aunque sencilla, se podrá usar ya desde el terminal móvil elegido.
  • Plantearemos un mock para el backend que el que debe conectar la aplicación móvil, y que estará basado en servicios REST que estarán accesibles dentro de una VPN.
  • Tendremos un conocimiento mejor de Xamarin para la implementación de los siguientes sprints.

Y, sobre todo, nos divertiremos currando en este nuevo proyecto. 

Hablaré más adelante de su progreso a medida que vayamos cerrando sprints.

Patricia - cubierta

Como una novela - portadaHace muchos años leí un libro que me impactó: Como una novela, del francés Daniel Pennac, y no sólo me gustó porque estimulara a leer como una actividad esencial en la vida, sino porque me reveló la importancia también de estar en el otro lado, el de aquel que lee pero que también escribe.

Desde hace más años de los que me acuerdo, me ha interesado mucho la escritura creativa; incluso realicé un curso presencial al borde del siglo pasado (literalmente, creo que fue en el 98 o en el 99), con una escritora sevillana relevante. En aquella época recuerdo que estaba enfrascado totalmente en interfaces de usuario con Visual C++ (qué tiempos!)

Y, desde entonces, he escrito, con mayor o menor regularidad, no sólo mi proyecto de El Libro Negro del Programador publicado hace tres años, sino retalos cortos, intentonas de novelas que no terminé, otras cosas que sí terminé pero que no me pareció de la calidad suficiente como para darlas a conocer, posts en El Blog Alternativo, etc. Hasta este año pasado en el que terminé y publiqué lo que considero mi primera novela publicable.

¿Y qué hace uno hablando sobre novelas en un blog de software más relacionado con mi actividad profesional del día a día?

Porque aunque no lo parezca, hay muchas simulitudes entre escribir software y escribir una novela, entre comenzar un proyecto software y asumir un proyecto literario con una metodología.

Si quieres saber todas las cosas que he descubierto al respecto en estos años, sigue leyendo.

Este primer proyecto literario es una novela con un argumento un poco romanticón, pero que tiene una trama de desarrollo personal importante así como su propia intriga y ritmo propios. Tiene de título "Patricia: una nueva relación que lo cambiará todo". Puedes ver más al respecto en la web literaria en la que trabajaré para todo lo relacionado con mi lado novelesco ;-) (www.gblanes.com)

Ejem... que hay autores a los que admiro mucho por su actividad profesional como Raimón Samsó y que además tienen algunas novelas de corte romántico (que, por cierto, es el género que mejor funciona comercialmente...).

Y entonces, ¿qué relación hay entre un proyecto software y un proyecto literario?

Estas son las similitudes que encontré y que sin ninguna duda me ayudaron a completar un proyecto de cerca de cuatrocientas páginas y realizado a base de micro tareas durante unos ocho meses.

  • En primer lugar, un libro no se escribe, se construye. Es un trabajo que tiene un proceso y, como siempre digo, es más importante el proceso que la tecnología a usar (o el texto a escribir). Cuando asumimos que algo se debe construir, nos damos cuenta de que ese algo tiene muchas partes independientes, que se pueden realizar a diferente ritmo.
  • Al igual que un proyecto software con una metodología basada en sprints y entregas y que necesita de una planificación (porque esto lo tienes claro, no?), un proyecto literario también se planifica. Lo siento si acabo de poner en duda tu concepción del escritor sentado en una buhardilla mientras ve por la ventana un paisaje bucólico y esperando una inspiración para plasmarla en una hoja en blanco. De ninún modo, como dice Joanna Penn (escritora independiente a la que sigo), "un libro es 5% inspiración y 95% trabajo duro y planificación". Créeme, es así.
  • Al igual que cuando escribimos código lo revisamos y aplicamos todas esas estrategias de refactoring, ocurre igual con un texto, un capítulo o sección: una vez escrito, se revisa en busca de typos, errores ortográficos, tipográficos o gramaticales, cuando no mejoras esta frase o eliminas algo para rehacerlo. Se dedica más tiempo a revisar y corregir que escribir. Esto siempre resulta sorprendente para quienes no conocen bien el trabajo de un escritor.
  • Se distingue entre avanzar y mejorar. Del mismo modo que nos centramos para cerrar una funcionalidad software (aunque después se refactorice y mejore), en una novela ocurre igual: hay una fase de escritura, que algunos autores aconsejan incluso que sea rápida para cerrar la sección o el capítulo cuanto antes, y otra fase muy distinta de revisión. Puesto que mucha gente comienza a escribir pero la mayoría no terminan el trabajo, hay quien sugiere terminar un borrador del texto lo antes posible, aunque tenga muchos fallos e incongruencias que después se pueden corregir. Aunque haga falta revisarlo, al menos tienes una primera versión y esto te anima mucho. Tiene sentido.
  • Como digo, los capítulos se revisan hasta la saciedad, y es sorprendente cómo después de varias vueltas, uno sigue encontrando detalles que mejorar (¿a que esto resuena en nuestras mentes de programadores?). Porque la igual que no hay ningún proyecto software perfecto, tampoco hay un libro perfecto, y nunca lo podrá haber, porque el ideal de perfección es demasiado subjetivo..., aunque sí hay otro tipo de elementos que se pueden medir (complejidad ciclomática / ritmo literario, tamaño de métodos / subtramas, etc.)
  • ¿Funciona el software? Quiero decir, respaldamos el código con pruebas unitarias, de integración, etc. ¿Y un libro? Pues igual, se plantean preguntas que el libro debe responder con éxito: ¿está bien descrito este personaje?, ¿no es demasiado pesada esa subtrama?, ¿es coherente a lo largo del libro la historia familiar de los protagonistas?, ¿se usan los tiempos verbales correctamente y de forma coherente? Es decir, tests, tests y tests.
  • Scrivener logoUn proyecto software se despliega, se publica, al igual que un libro, para lo que hay que compilar el texto para generarlo en formato pdf, epub o mobi junto con sus portadas, contraportadas, etc. (Nota: en la herramienta Scrivener, se incluye el concepto de "compilar" el texto, que no es más que generar el libro en el formado configurado y parametrizado. Dicho así parece sencillo, pero tiene un trabajo importante).
  • Y todo ello debe estar bajo el marco o paraguas de una metodología. En el caso del libro (al igual que hice con El Libro Negro del Programador), me creé mi propia metodología adaptada a la disponibilidad que tenía para escribir: división en tareas pequeñas, sesiones de una hora, definición de cada sección del texto (antes de empezar a escribir, me hice un guión con unas ochena secciones), etc.
  • Pruebas de validación: ¿para qué sirven si no los beta-readers? Le di el manuscrito a mi pareja y a una amiga cuando yo ya lo di por terminado (y, por supuesto, me indicaron bastantes mejoras).
  • Te documentas leyendo un montón de libros y blogs, como suelo hacer cada vez que me interesa una tecnología en particular.
  • Y mucho, muchísimo compromiso por alcanzar cada semana los hitos que yo mismo me planteaba (y que no siempre conseguía).

Cuando menos, interesante.

Por cierto, si planeas escribir un libro, no utilices Word, por favor, merece la pena gastarse unos eurillos en una herramienta como Scrivener.

Haruki Murakami - El fin del mundo y un despiadado país de las maravillasPuff..., casi siempre al comenzar el año el que más o el que menos hace una lista de buenos propósitos, de objetivos para los próximos doce meses. En cierta medida, yo lo también lo hago, pero sobre todo me gusta mirar un poco atrás y ser aún más consciente de dónde vengo (por eso de saber mejor hacia dónde voy).

Y desde luego, puedo decir que ni he tenido un trabajo rutinario desde que terminé la carrera ni que me he mantenido en el mismo tipo de rol. ¿Podría haber sido de otro modo? Pues ni idea, seguramente sí, ya que yo mismo he sido responsable de mis acciones y decisiones. ¿Quién si no?

Echo la vista atrás y ojalá los próximos diez años sean igual de intensos y productivos.

Me gusta Haruki Murakami y me le ha acompañado desde que cayó en mis manos casi por casualidad uno de sus libros allá por el noventa y pico.

A modo de resumen...

Terminé la titulación de Ingeniería Superior en Informática por el 2001, después de presentar un proyecto fin de carrera que me llevó casi un año. Se trataba de una aplicación hecha con Visual C++ y librerías MFC/ATL, para la creación de interfaces de usuario de un producto Scada que realizábamos por aquélla época en la compañía para la que trabajaba. Entonces pertenecía a lo que se denominaba el Grupo de Desarrollo de Software (nada original, por otro lado).

Visual C++

Fruto de este proyecto (que creo que sigue en producción en algún centro de operación ferroviario), fue este artículo que ya en su día publiqué en CodeProject y de título Improving ATL-ActiveX Serialization y mucho, muchísimo profiling y escribir código optimizado. Y ahora que lo pienso, ese artículo fue lo primero que me dio por publicar! Y por cierto, veo que tengo que actualizar la información con la que me registré en CodeProject, portal que sigue siendo para mí referencia hoy día.

Lo más interesante de aquéllo fue que en esa aplicación integré VBA (Visual Basic for Applications), toda una novedad en aquel momento, y también un gran reto técnico.

Acostumbrado a C++, todo el nuevo entorno de .NET framework junto con C#, creó una gran expectativa que abrazamos casi todos en el departamento desde el primer momento. De hecho aún conservo un libro que me regalaron en un evento sobre esa nueva tecnología y que creo que sería de lo primero que se publicó entonces.

C#Siempre he estado muy ligado a tecnologías de Microsoft, y también siempre me han parecido infantiles y no profesionales las comparaciones y dilemas un poco tontos y muy de nuestro sector entre esto o aquello. Toda tecnología tiene sus luces y sus sombras. Punto.

Sin embargo, desde hace unos años trabajo muy de cerca con Azure (la plataforma de cloud computing de Microsoft y de enorme crecimiento) y sigo con detalle todos los movimientos de esa compañía hacia una visión más "open" del software. De hecho, no en vano, .NET Core y la liberación de algunos productos tradicionales de Microsoft para su funcionamiento en Linux (como Sql Server, nada más y nada menos) es una muestra más de esa mayor amplitud de miras. Y no digo Azure por capricho, es que tengo clientes que funcionan desde esa plataforma con un éxito rotundo.

En 2006 ya estaba trabajando en Suecia en un proyecto de muchos millones de euros; mejor dicho, el proyecto tenía un montante de cien millones de euros pero la parte software, aunque, residual, era crítica: sin ese pilar, todo el proyecto se caía y las penalizaciones económicas por parte del cliente podían poner en riesgo la viabilidad misma del proyecto. Había mucha presión, teníamos que trabajar con prisas, cumpliendo hitos literalmente con la lengua fuera, además de toda la presión de los cambios que supone trasladarte con tu familia a un país muy diferente a España.

Pero aprendí, y muchísimo; fue para mí, a pesar de las crisis que viví junto con mis compañeros, una de las etapas más fértiles de ese periodo. Recuerdo alguna noche entera realizando una actualización de uno de los sistemas en los que se basaba el proyecto.

No había metodología, sólo tirar hacia delante del modo que fuese. Curiosamente, todos mis compañeros que entonces participábamos en ese proyecto para una compañía eléctrica sueca (Vattenfall), ya no están en la misma empresa, incluido yo mismo. Todos fuimos saliendo poco a poco encontrando (o buscando) mejores oportunidades laborales y profesionales.

De aquel proyecto me quedó muy claro la extraordinaria importancia de mantener una mínima metodología y orden en los desarrollos (abajo no había orden porque en el nivel ejecutivo ni lo había ni se fomentaba). Y también de la enorme importancia de un diseño pulcro y eficiente de la base de datos, ya que la aplicación era muy data-centric. La base de datos crecía a razón de millones de registros a diario, de modo que continuamente nos encontrábamos con nuevos cuellos de botella (tanto a nivel de software como de hardware). Todo un reto que finalmente pudimos estabilizar (nos llevó más de un año).

Después volví a España y comencé a interesarme por todo lo ágil y clean-code. Fue una época de lecturas frenéticas de toda la literatura relacionada que encontraba interesante (los libros, cómo no, de Martin Fowler, Robert C. Martin, etc.) y poco a poco fui confirmando ciertas intuiciones acerca de los pilares con los que construir buen software. 

Y como consecuencia natural, muy pronto comencé a darme cuenta de que no todo el mundo entendía igual el concepto de buen software, y que apenas se le prestaba atención a asuntos tan importantes como la organización de un equipo de trabajo, las dinámicas de grupo, la ausencia del concepto de jefe o gestor como aquel que facilita el trabajo de los demás, etc., cuyo resultado termina generando un producto bueno o malísimo.

Continuaba escribiendo software de un modo u otro, a veces con buenas condiciones y casi siempre en muy malas condiciones (exceso de reuniones impuestas, tareas no planificadas para hoy, etc.).

Entre 2008 y 2009 hice mi primera tentativa emprendedora. Y fue un total fracaso, pero me permitió meterme de lleno en Drupal. La idea era buena, pero somo se suele decir, la ejecución lo es todo. Por aquélla época comencé a leer mucho sobre emprendimiento e intraemprendimiento. Siempre digo que dejé esa compañía en la que mantenía un contrato fijo y con buen sueldo porque ya llevaba años preparándome mentalmente para probar otro tipo de cosas. Y es que nos centramos demasiado en la acción, pero se nos olvida una verdad trascendental: no es el hacer sino el ser (lo que somos) lo que provoca cambios verdaderos. Bueno, que enrollo en temas de desarrollo personal...

Entre pequeños proyectos de I+D y el mantenimiento del sistema que montamos en Suecia, tenía tiempo de comenzar a interesarme por otras tecnologías fuera del ecosistema de Microsoft. Comencé a hacer mis primeros proyectos web y a leer todo lo que podía sobre Drupal. Y, por supuesto, abracé NodeJS desde el primer momento. Entre otras cosas.

Tanto fue mi entusiasmo por Drupal que terminé participando como ponente en dos sesiones (esta y esta otra) en la Drupalcamp de 2011 en mi ciudad. Descubrí ese ecosistema y una comunidad muy implicada y estimulante.Drupal

Comencé a hacerme cargo de la gestión de equipos de trabajo sobre el 2009. Y no tenía ni idea de qué iba aquello, así que leí muchísimo al respecto y lo intenté hacer lo mejor posible.

La empresa para la que trabajaba entonces (la ingeniería Telvent Energía, ahora propiedad de Schneider Electric), no se puede decir que fuese una de esas cárnicas, pero lógicamente, la presión de sacar proyectos era alta. Como en todo, hay momentos buenos y malos, pero todo lo que quiero recordar de aquel periodo (trabajé en esa compañía desde el 2000 hasta el 2012) es bueno y hasta excepcional, y considero que no todo el mundo tiene la suerte de caer en una empresa y tener las experiencias nacionales e internacionales como tuve en Telvent, asistiendo a eventos importantes, etc. Viajé varias veces a USA (estuve en semana asistiendo a TAP program de Microsoft en Seattle, toda una experiencia viendo, oyendo y hablando con auténticos gurús, de los de verdad), así como viajes a diferentes ciudades de Suecia, Holanda, Eslovenia, etc. y hasta una semana en Beirut.

Pero el ciclo se fue acabando y comencé a interesarme por otras cosas y otras posibilidades laborales. Digamos que dejé de verme en un futuro lejano trabajando para la misma compañía.

Best Practices

Artículo disponible en epub y pdf:

Cómo usar repositorios de datosCómo usar repositorios de datos epub

 

 

Me llama mucho la atención cómo a lo largo de los años puedo haber trabajado en aplicaciones con .NET en C#, con javascript utilizando Angular y NodeJS, y también con PHP cuando estaba más centrado a hacer módulos en Drupal, y cómo con todos esos lenguajes con sus respectivos entornos de desarrollo se pueden aplicar las mismas buenas prácticas.

Hay veces que éstas se refieren a procedimientos de trabajo o al modo de estructurar un proyecto, otras hacen referencia a aplicar patrones de diseño e incluso antipatrones para detectar precisamente lo que no se hace bien. En otras ocasiones, son sencillamente prácticas habituales que hace la mayoría de la gente que usa una tecnología en particular (de ahí, por ejemplo, los proyectos de scaffolding).

Un buen proyecto software debe oler a buenas prácticas, de principio a fin, desde la arquitectura del mismo hasta la evolución de las funcionalidades que se le van añadiendo poco a poco.

Nada peor que una aplicación, proyecto o sistema en el que no se pueda ver claramente cómo están implementadas esas buenas prácticas.

Y es que además tienen algo en común: la mayoría de ellas son fáciles de implementar.

Y como me gusta escribir... pues voy a ir hablando de ellas, de aquellas con las que yo directamente he visto que tienen más impacto en la mejora de la calidad de un proyecto software.

Un aviso a navegantes: en muchas ocasiones los beneficios de estas recomendaciones no se ven claramente, ni siquiera en el corto plazo, y su impacto positivo a medio y largo plazo es más una cuestión sutil que sólo se aprende cuando has cometido todos los errores posibles y entonces se hace la luz y dices algo como, "ahora sí que lo entiendo".

Para mí la implementación de repositorios de datos es una de las prácticas más útiles en cualquier proyecto software.

El principio general de implementar un repositorio de datos vendría a ser el siguiente:

Todos los accesos a los datos que utiliza una aplicación (vengan de bases de datos, entidades de datos del mundo cloud, datos en caché, etc.) deben realizarse desde un único punto.

Dependiendo de la tecnología y del tipo de aplicación que se esté desarrollando, ese único punto se entiende por un módulo con sus clases, una librería, una API, un servicio REST, etc. Lo importante es que todos esos accesos estén centralizados y bien localizados en el proyecto.

¿Qué beneficios se obtiene de esto? Son muchos, muchísimos, algunos de ellos no fáciles de ver en un principio.

Por resumir, centralizando el acceso a los datos conseguimos:

  • Cumplimos con el principio SoC, (separation of concerns separación se intereses), básico en el desarrollo ágil. De este modo tenemos una parte muy concreta y localizada del proyecto especializada en acceder a los datos que utiliza.
  • Se evitan duplicar código repitiendo los mismos accesos a los mismos datos a lo largo de la solución. En lugar de ejecutar algo como un "select * from dbo.users where userId = 20" cada vez que se necesita la información de un usuario, tenemos algo mucho más general como "data.getUserById(20)" (esto es un sencillo ejemplo en pseudocódigo, eh!).
  • Se simplifica la solución y se reduce el número de líneas de código. Al estar encapsulado el acceso a los datos en métodos muy concretos, no necesitamos ensuciar u ofuscar la lógica de negocio de la aplicación con detalles de acceso a los datos (tales como abrir una conexión a la base de datos, cerrarla, etc.), y ni hablar cuando esos accesos con más complejos y necesitamos transacciones o joins anidados.
  • Es más fácil ejecutar un análisis sencillo de profiling: tan sólo repasando en el objeto repositorio a qué datos se accede y cómo, podemos determinar qué índices hacen falta, en el caso de bases de datos relacionales e implementar tests de rendimiento que se puedan ejecutar continuamente.
  • Conseguimos desacoplar la solución de cómo ésta accede a los datos. ¿Y si mañana cambiamos de motor de base de datos? ¿Y si por escalabilidad se decide distribuir los datos en diversas bases de datos incluso con diversas tecnologías? Nada peor que empañar todas las partes de la solución con los detalles de acceso a los datos. Puesto que todo está encapsulado en el repositorio, tan sólo hay que tocar éste. El resto de la aplicación, ni se entera del cambio.
  • Con la implementación del repositorio, al estar éste desacoplado, se pueden crear tests específicos, unitarios y de rendimiento.
  • Es trivial también crear mocks. ¿Qué pasará cuando la tabla "usuarios" tenga cien mil registros? ¿Aguantará el front-end? Con un repositorio de datos es fácil simular diversas situaciones en previsión de problemas de escalabilidad pero sobre todo, que esas situaciones pueden estar respaldadas por pruebas.
  • Al estar todos los accesos centralizados, es más fácil para la persona encargada del desarrollo de la base de datos y su acceso trabajar en esa área especializada.
  • Al no estar dispersos por la solución todos los accesos al repositorio de datos, las migraciones del mismo no terminan en pesadilla...

Hace un tiempo se hablaba en ciertas tecnologías de la capa DAL (data access layer), que vendría a ser el mismo concepto pero más ligado a bases de datos relacionales.

Si se utiliza algún tipo de ORM que crea objetos alrededor de las entidades de datos, ¿deberían esos objetos viajar a lo largo de la lógica de negocio? Esta pregunta me la encuentro recurrentemente, y mi opinión es que no, puesto que de ese modo la aplicacíon tiene una dependencia clara de la tecnología ORM utilizada. Los objetos que se deberían distribuir a lo largo de la lógica de negocio serán similares pero no ligados a la tecnología ORM usada (son los que se llaman los data transfers objects o DTOs).

A ver, al final hay que aplicar el sentido común (con un poco de experiencia y hasta de suerte...): si trabajamos en un proyecto cuyo ciclo de vida es muy claro y sabemos que se terminará y que no va a evolucionar, pues nos podemos tomar cierto tipo de licencias, pero si tenemos entre manos un producto o proyecto que crecerá y evolucionará en funcionalidad a lo largo de muchos años, entonces sí hay que cuidar mucho este tipo de decisiones y dependencias, así como aplicar con mayor rigor aún todas las buenas prácticas posibles.

Sí, ya sé, es que a veces no hay tiempo, el proyecto viene muy cerrado en horas, etc. De acuerdo, razón de más para aplicar este tipo de buenas prácticas desde el principio, porque sólo así se podrá avanzar en el proyecto con productividad y mayor rapidez.

Todo esto es más fácil de implementar que de describir; sin embargo, un buen proyecto software que necesita de cualquier mecanismo para persistir datos, tiene que acceder a ellos a través de un objeto / módulo / librería que implemente esta buena práctica.

Algunos enlaces de interés:

The Repository Pattern

Repository Pattern Done Right

No me gusta repetir trabajo ni tareas pesadas que se hacen una y otra vez y que de algún modo se pueden automatizar o al menos indicar lo pasos a realizar para que la siguiente vez no pierdas tanto el tiempo en recordar cómo se hacía ésto o aquéllo. Si te encuentras en esta situación a menudo, que sepas que puedes evitarlo.

Si es verdad que debemos poner el foco en aquello que aporta valor, en las tareas verdaderamente creativas y productivas, entonces tenemos que encontrar la forma de no tener que reinventar la rueda continuamente. No estoy hablando de tareas que hay que hacer sí o sí (como un parte de trabajo) y hablo en sentido general, no sólo desde el punto de vista del desarrollo de software, sino de hacer todo lo posible para que estas tareas ocupen el menor tiempo posible y, sobre todo, no tengamos que pensar reiteradamente cómo se hacían.

Voy a poner varios ejemplos:

  • El proceso de publicar una nueva noticia en la web, ya sabes, crear el contenido, fijar bien la url, revisar el contenido, comprobar la estructura del mismo, revisar faltas de ortografía o de expresión, pedir la aprobación del mismo si es necesario, etc. Son varios pasos, sí, pero si este trabajo lo haces una vez cada varios meses, terminar olvidándolo y preguntándote ¿cómo había que poner el formato de las url?
  • Si mantienes varias webs, como es mi caso, y además todas con Drupal, y dado que no las actualizo continuamente (actualizaciones de módulos, mejoras de diseño, etc.), puedes encontrarte con que cada vez que vas a actualizar una, tienes que volver a investigar cómo se hacía esto o aquello, como por ejemplo, cómo y dónde guardar una copia de seguridad, cómo etiquetar la nueva versión de la web en GIT o similar, cómo comprobar que la nueva actualización no ha roto nada, cómo desplegar para que no te quede ningún cabo suelto, comprobar la seguridad, etc.
  • Llevo dos años usando la herramienta Scrivener para la creación de libros. Su proceso de compilación genera un fichero en format eBook, pdf, docx, etc. Sin embargo, después de generar el fichero tienes que comprobar varias cosas según tu flujo de trabajo y el propósito que tengas. Por ejemplo, si generas un eBook para Kindle, tienes (o deberías), revisar que el epub pasa las pruebas de validación con una herramienta como epubcheck, después tienes (o deberías) abrirlo con la herramienta Kindle Previewer y revisar página a página, y no digamos le proceso de publicación en Amazon.

En fin, son trabajos que realizas que requieren de varios pasos para su realización. Salvo que tengas una memoria prodigiosa, cada vez que los vayas a enfrentar algo se te quedará en el tintero.

¿Resultado? No se terminará del todo bien y se tardará más en realizarlo, aparte de lo tedioso que resulta tener que investigar algo porque lo has olvidado... Y si te fijas bien, parte de tu trabajo lo pasas realizando tareas que bien podrían estar bajo el paraguas de un procedimiento.

Llevo años procedimentando este tipo de tareas e intentando establecer una cultura y hábito en procedimentar en los ámbitos laborales en lo que me muevo.

Crear un procedimiento no es más, en esencia, que establecer en una simple guía los pasos para realizar una tarea. No estoy hablando de esas compañías que para hacerlo todo tienen un repositorio de procedimientos o normas más largos que El Señor de los Anillos, sino de sencillas guías que te puedes hacer tú mismo para evitar tener que recordar continuamente las mismas cosas y así hacerlas con mayor rapidez y seguridad.

Y esto se aplica a cualquier ámbito personal o profesional. ¿Qué sería si no la gestión de la configuración un proyecto software sin un procedimiento entendido por todos los desarrolladores?

Si lo tuyo es el marketing, es posible que tengas establecido cómo documentar tus próximas acciones comerciales así como sus resultados (= procedimientos).

Es sorprendente la cantidad de tiempo que se gana cuando tienes guías sencillas y prácticas para realizar tareas más o menos complejas.

Pero por otra parte, ¿cómo si no muchas personas de una organización, por pequeña o grande que sea, podrían trabajar sin seguir ciertas normas o esquemas de trabajo (= procedimientos)?

Lamentablemente en muchas organizaciones, se terminan aprendiendo las cosas no porque las leas en un documento de bienvenida o algo así, sino porque a algún compañero o compañera le endosan la tarea de explicarte cómo se hacen las cosas (por lo cual también es una pérdida de productividad para él).

Estos son algunos de mis procedimientos que más uso:

  • Generación y revisión en la generación de epubs y pdf de cara a su publicación.
  • Procedimiento de crear contenidos (como este) en las distintas webs así como su difusión.
  • Uso de los repositorios de código para los proyectos en los que trabajo.
  • Actualización y mantenimiento de mis webs con Drupal.
  • Desarrollo de nuevas ideas y propuestas.
  • etc.

Si en tu organización no hay procedimientos de trabajo de algún tipo, chungo. Y si en tu día a día, en la forma de organizarte o de afrontar los distintos proyectos en los que trabajas, pero aún.

Estoy convencido de que las personas más exitosas y las organizaciones que funcionan mejor tienen una fuerte cultura de establecer y usar procedimientos de trabajo ágiles, claro, porque su abuso puede suponer al final todo lo contrario de lo que se desea obtener.

No es la primera vez que me encuentro ante un nuevo proyecto en el que el cliente te exige utilizar ciertas tecnologías para sus desarrollos internos. Se trata de una compañía que tiene su propio departamento para satisfacer las necesidades software de la empresa (web corporativa, intranets, canal de pedidos, gestión de tickets e incidencias, etc.); ahora necesitan externalizar algunos trabajos.

No es que usen esas tecnologías porque sí, sino que es la misma política de empresa la que en su día decidió apostar por ellas y no salir de ahí salvo por un motivo bien justificado. De ese modo, todas las aplicaciones internas tienen cierta coherencia.

Esa decisión puede ser muy arriesgada: ¿y si basamos todos los desarrollos en este motor de base de datos que termina cayendo en desuso o cuya licencia sube de precio escandalosamente? ¿Y si usamos este framework para las interfaces de usuario web y con el tiempo surgen otros mucho mejores y productivos?

¿Acaso alguien tiene una bola de cristal y puede predecir las necesidades de la empresa a años vista? Puff...

Trabajar realizando proyectos software que deben tener una vida muy larga es en ocasiones gestionar muchísima incertidumbre en cuanto a la elección de las mejores tecnologías para ese proyecto.

Yo lo digo a menudo, y no me cansaré de repetirlo: es casi más importante usar bien una librería o framework que usar todo lo último porque sí

Por poner un sencillo ejemplo, me encanta Angular, es increíblemente productivo y te permite desacoplar muchos elementos de las interfaces de usuario para poder crear tests sobre ellos. Sin embargo, la nueva release Angular 2 es un mundo aparte en relación a la anterior versión y por tanto, si has hecho algo en los últimos años con Angular 1.x, pues ya sabes que o tendrás que continuar con ello mucho tiempo o tienes que plantear una migración, si te interesa, a la nueva versión. Y cómo no, desde el punto de vista empresarial, esa migración cuesta dinero...

Si el éxito de una compañía consiste, en parte, en mitigar y reducir riesgos, entonces definir el conjunto de tecnologías que usa para sus desarrollos internos puede tener sentido. Este enfoque no es único para grandes corporaciones, de ningún modo, cualquier organización de cualquier tamaño puede implementar esta política.

¿Qué ventajas puede aportar tener lo que podríamos llamar un framework corporativo?

Se me ocurren las siguientes:

  • No hay curva de aprendizaje para los nuevos desarrollos: el equipo de trabajo ya domina las tecnologías que se usan.
  • Al estar basado todo en las mismas librerías, lenguajes, etc., es más posible poder reutilizar componentes ya desarrollados para el resto de proyectos o aplicaciones.
  • El mantenimiento de las distintas aplicaciones es (o debería ser) menor, si se ha definido una forma común a la hora de realizar los desarrollos.
  • Es más sencillo plantear los flujos de trabajo, ya que éstos en ocasiones dependen de las tecnologías que se usan.

En el caso de este nuevo cliente, utiliza ExtJS, PL/SQL (bases de datos Oracle) y C# para todos o casi todos los desarrollos, además de procedimientos claramente definidos para la especifación, validación y puesta en producción de los nuevos desarrollos.

A la hora de definir un framework corporativo no hay que juzgar los gustos particulares de cada uno, sino evaluar si todo lo que se quiere usar encaja o no con las necesidades presentes y futuras de la compañía.

En el otro lado de la balanza están otras empresas que utilizan tal dispersión de tecnologías para sus desarrollos que finalmente el mantenimiento de todo termina siendo un gran obstáculo. Basta con ponerse en el lugar de alguien nuevo que llega al equipo de trabajo y que tenga que asumir diez tecnologías diferentes en lugar de un grupo reducido y coherente de ellas...

No, no voy a hablar de nada relacionado con los principios de desarrollo S.O.L.I.D., que, en cualquier caso, recomiendo a cualquier programador conocer en profundidad y, sobre todo, ponerlos en práctica.

En los últimos meses he tenido que leer bastante documentación sobre licitaciones y también he estado inmerso en propuestas de nuevos proyectos en colaboración con otras compañías.

En esas licitaciones, algunas para gobiernos autonómicos de mi país, llama la atención la falta de rigor en las especificaciones. Es más, concretamente en alguna se indicaba que "las tareas a realizar se plantearán con exactitud cuando el proyecto sea adjudicado al licitante". En otra, decía que el licitante debía adaptarse a las metodologías de trabajo más comunes, y mencionaba CMMi, Métrica 3, etc. En fin...

Al mismo tiempo, la mayoría de esos proyectos consisten en evolucionar aplicaciones que ya están funcionando en consejerías o departamentos de esas regiones.

¿Cómo poder estimar el esfuerzo para evolucionar algo sin ver su estado actual? ¿Estará la solución hecha unos zorros? ¿Será el típico proyecto espagueti o en cambio todo se habrá hecho con conciencia, mejoras continuas, limpieza de código, etc.?

Miedo me da encontrarme con algo así. 

En esos proyectos se hablaban de tecnologías que ya existían hacer quince años y que siguen muy presentes aunque bajo revisiones más recientes.

En otro, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protoloco DLMS.

Y para variedad, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, y de nombre Altafonte. Utilizan un sistema basado en PHP, base de datos MemSQL, etc. A sus desarrolladores los considero unos héroes, por haber sabido avanzar en la solución, la base y el core de su negocio, mientras éste crece con multitud de nuevos requerimientos continuamente.

Pensando en todos esos proyectos, ¿qué es lo que pueden tener en común?

En realidad, tecnológicamente hablando, puede parecer que nada, son completamente diferentes, y sin embargo, desde un punto de vista más integral (holístico dirían en otros contextos), el éxito en todos esos proyectos tan dispares, sólo depende de principios que son comunes y antiguos, y que además no son exclusivos de nuestro sector de desarrollo de software.

¿Qué sería de todos esos proyectos sin una correcta organización y planificación?

Para cualquier cosa que haya que hacer, escribir un libro, ahorrar a largo plazo, realizar un proyecto software cuya solución va a durar años, todo medianamente complejo y que se expande en el tiempo, requiere de organizar y planificar.

Y eso es un trabajo en sí mismo. Lo he visto muchas veces, me temo, se organiza al principio, pero ya después las cosas van cayendo en el olvido. 

Cualquier esfuerzo de organización debe ser continuo y hay que dedicarle un tiempo recurrente, es una tarea más que hay que meter entre nuestras actividades.

El proyecto, aún sin la mejor organización, se puede terminar, claro, pero con toda seguridad se habrá tenido que dedicar un esfuerzo mucho mayor y la gente habrá soportado mayores niveles de estrés.

Todos esos proyectos, ¿se podrían enfocar igual sin una mejora continua?

En cualquier proyecto largo, sobre todo si lo actual depende de lo anterior, hay que tener una actitud de mejora continua sobre todo lo que ya se ha realizado. De no ser así, el tema va creciendo y creciendo sobre bases que no están bien, y llegará el momento en que todo se desmorone.

Hay que realizar restrospectivas cada cierto tiempo; las lecciones que nos dan tienen muchísimo valor para seguir avanzando con pasos seguros.

En software, ¿se mejoran todos tipos de assets?

Se tiende a pensar que las técnicas de refactorización sólo afectan al código de producción.

Pues no, de ningún modo; aunque refactorizar es un término que se aplica al código, el resto de assets pueden y deben ser mejorados al mismo ritmo, sin olvidar que la calidad de las pruebas debe ser la misma que la calidad del código de producción.

A medida que un proyecto crece, hay que mejorar su estructura, su diseño, la documentación, etc.

Estoy hablando de proyectos software que deben ser evolucionados en un periodo de tiempo muy largo, años.

Todo, absolutamente todo, influye para el resultado final sea mejor.

¿Y qué hay de los flujos de trabajo?

Me encuentro que las organizaciones se hacen las cosas de un modo determinado, que puede funcionar mejor o peor, sí, pero no existe la conciencia de establecer claramente un flujo de trabajo para cada proceso que necesita emplear la compañía. Basta con poner por escrito de algún cómo se debe hacer esto o aquello y consensuarlo con la gente implicada.

De ese modo, con el tiempo podemos comprobar las deficiencas, trazarlas y mejorar esos mismos flujos de trabajo.

Podemos estar usando tecnologías de hace diez años u otras más recientes, podemos diseñar una nueva solución orientada desde un principio a alguna infraestructura cloud, una nueva aplicación móvil con la úlima API de Android, o entornos como Xamarin o PhoneGap, o bien actualizar una solución de NodeJS basada en la versión 0.12.x al nuevo salto de nivel con la versión 5.x.x., etc.

Sin embargo, cada vez estoy más convencido de que todas esas tecnologías que evolucionan, van y vienen, son la parte de un puzle mayor. Aplicando correctamente estos principios sólidos a la hora de afrontar tu trabajo, podrás usar una tecnología casi obsoleta o el stack más de moda en la actualidad, pero tendrás así muchas más posibilidades de éxito y adaptación a nuevos escenarios.

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...