Hay algunas preguntas que me hago recurrentemente cuando llevo un tiempo desarrollando o dirigiendo un nuevo proyecto. Lo he hecho recientemente ahora que estamos a punto de lanzar Picly (web en pruebas aquí: http://stage.picly.io)

Uno de los elementos que caracterizan un buen equipo de otro que no lo es tanto, es la disciplina, a la hora de mantener en el día a día las buenas prácticas, los procedimientos establecidos. Esta disciplina, por lo general, suele venir impuesta por el responsable del equipo, y no por los mismos miembros de este que... bueno, no siempre todos están lo suficientemente motivados o interesados en generar un producto o proyecto mantenible y evolucionable.

En uno de los capítulos de El Libro Negro del Programador resumí en forma de setenta y ocho preguntas los indicadores más relevantes que tenemos que tener en cuenta para generar software de calidad. Son preguntas sencillas, directas, que nos indican en qué punto flaqueamos o qué podemos mejorar tanto para nuestro día a día como desarrolladores así como para mejorar en nuestro sector como profesionales.

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.

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