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?

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...

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.

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?

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...

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.

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.

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.

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?

Question woman

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

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

Archivo

Trabajo en...