Lo bueno de llevar mucho tiempo trabajando en una empresa pequeña es que todo te queda más cerca. Entre el señor que vende cosas, el que las desarrolla, el que las prueba, el que las documenta, el que las instala o el que da servicio postventa, no hay mucha distancia. A veces hay tan poca distancia que incluso son todos la misma persona.

Esta cercanía, que sin duda también tiene sus inconvenientes, hace que todos seamos más conscientes de lo que supone el funcionamiento real de la compañía y de los problemas las consecuencias de las decisiones que tomamos.

En una empresa grande resulta más sencillo pasar la pelota de un departamento a otro, pero cuando quien da la cara en el departamento de soporte es uno de los (literalmente) tres únicos invitados de tu boda, cuesta más pasarle el marrón de los problemas que han surgido porque el software que has desarrollado no se comporta como se esperaba.

Todos lo hemos padecido

Más de una vez me ha tocado trabajar con gente que funcionaba de otra manera. Para ellos su trabajo era desarrollar software, pero una vez que habían «terminado», o mejor dicho, que ellos consideraban que habían terminado, el resultado era algo que no había quien manejase.

Posiblemente el código no fuese malo, y de hecho en alguna ocasión que tuve que revisarlo no lo era. Buenas prácticas, principos SOLID, nombres adecuados, … En fin, lo que cabría esperar de un desarrollador competente. Tampoco se trataba de una cuestión de funcionalidades; todo lo necesario estaba más o menos cubierto. El problema es que el código no resistía el contacto con el mundo real y en cuanto llegaba el momento de ponerlo en producción se hacía patente.

El desarrollo se había centrado en implementar las funcionalidades más visibles de la aplicación y en hacerlo con código flexible, extensible y todo eso, pero nadie había pensando que, en el mundo real, ese código, esa aplicación que se había desarrollado, tenía que acabar en producción.

Y eso implicaba que alguien tenía que instalarla. Y configurarla. Y que el usuario tendría que introducir su información para poder empezar a trabajar con ella. Y que habría que monitorizar que estaba funcionando correctamente. Y que antes o después surgiría algún problema y habría que diagnosticarlo. Y que cuando corrigiéramos el problema, necesitaríamos un plan para actualizarla. Y… Y todas esas cosas que pasan en el mundo real pero que hacen que el código quede más feo porque hay que poner ifs y capturar excepciones y generar logs y hacer scripts de instalación, y que, además, tampoco son nuestro problema, que para eso están los de sistemas (o los DevOps, si quieres ir de moderno).

Algunos consejos

Para mi este tipo de cosas son las que distinguen a un buen profesional, incluso más que la calidad del código que escribe (y mira que eso es algo que valoro mucho). Comprender que un proyecto no termina en el desarrollo y tener eso previsto es algo vital. Al menos, hay varios puntos que deberías haber pensando durante el desarrollo para poder dormir tranquilo más adelante.

Si te has leído algunos de los libros sobre desarrollo que recomendaba en el post anterior, especialmente Release It!, es probable que todo esto ya te suene. Si no, es un buen momento para empezar a concienciarte.

Prepárate para un entorno real

Está muy bien tener test de diversos tipos, pero vas a necesitar hacer pruebas en un entorno lo más parecido a producción posible. Con datos reales, sobre hardware similar. Tu aplicación con 4 registros en tu i7 de desarrollo con un SSD ya sabemos que funciona muy bien, pero cuando son 400.000 registros en un Atom D525 con un disco de 5.400rpm… mejor haberlo tenido en cuenta.

No te olvides de dedicar un rato a pensar todo lo que puede salir mal. Las conexiones de red que se van a caer, los servidores que no van a responder en el tiempo esperado, las consultas que en lugar de devolver 30 registros devuelven 30.000… Nunca vas a conseguir preverlo todo, y habrá circunstancias de las que no te merezca la pena protegerte, pero es una cuestión de valorar riesgos.

Piensa cómo vas a desplegar

Cuando vas a pasar a producción, el primer punto a tener en cuenta es el despliegue o la instalación de tu sistema. Tanto si es un proyecto concreto que sólo vas a desplegar una vez (mentira, al menos un par de veces lo harás, aunque sea en pruebas y producción), como si es una aplicación que acabará desplegada en miles de equipos, necesitas un plan para esto.

Tener pensado cómo instalarás las prerrequisitos (¿te hace falta instalar .NET, o Java, o Ruby? ¿SQL Server?), cómo instalarás los ficheros de tu aplicación, ajustes de permisos, claves de registro, configuración de componentes externos, creación de bases de datos… No vale de nada tener una aplicación magnífica con muchas funcionalidades increíbles y un código precioso si luego no puedes ejecutarla más que en tu PC.

Facilita el arranque inicial

Una vez que has desplegado la aplicación, necesitarás tener previsto como vas a hacer la configuración o carga de datos inicial. Es muy frecuente, y más en las típicas aplicaciones de línea de negocio aburridas en las que trabajamos casi todos, que el usuario necesite personalizar algunos aspectos de la aplicación y, posiblemente, incluir información que ya tiene en otras aplicaciones.

Importar un catálogo de productos, añadir sus contactos de facebook… seguramente haya formas de facilitarle ese primer arranque de la aplicación. Sin eso, habrá usuarios que se nieguen a usar tu aplicación por no querer tener que volver a introducir la información en tu sistema. Normalmente esto pasa por tener alguna herramienta para importar datos desde sistemas arcanos o tragarse un par de hojas Excel.

Mantén el sistema funcionando

Si has llegado hasta aquí, enhorabuena, tienes la aplicación en producción. Ahora hay que mantenerla así, es decir, funcionando. Incluir algún sistema de monitorización es fundamental, por muy básico que sea. Aunque sea un triste fichero que nos indique que el proceso está arrancado y haciendo algo. Y, por supuesto, lo que es crítico es tener un sistema que te permita diagnosticar errores.

No hay nada peor que pasar varias horas mirando una aplicación completamente opaca que no funciona, no tienes ni idea de por qué y no hay un fichero de log, evento en windows, o señal de humo que te dé una pista de lo que está pasando. Todo, claro, para descubrir que es un problema de configuración, que como se reparte entre 3 ficheros y 2 bases de datos es imposible hacer correctamente a la primera. Lo he vivido y, en serio, no es nada agradable y dan ganas de matar al que ha desarrollado eso.

Asume que tendrás que actualizar

Desgraciadamente, aunque tengas sistemas para detectar y diagnosticar errores, eso no te libra de ellos, así que vete preparando porque tendrás que actualizar la aplicación.

Esto supone varias cosas, la primera es que tengas una numeración de versiones coherente. Porque tienes una numeración de versiones, ¿verdad? Y no, buena.zip, buena_2.zip y buena_old_3.zip no es una numeración coherente. Hace falta que puedas trazar qué codigo hay en cada versión y que sean generadas de una manera consistente. Tener un servidor de integración continua es una buena forma de garantizarlo.

Además, necesitarás un plan para actualizar la aplicación, los ficheros de configuración y las bases de datos implicadas. No es una tarea imposible, pero hay que dedicarle un poco de tiempo, porque a nadie le gusta estar parado varias horas durante una actualización, y mucho menos perder sus datos porque una actualización ha fallado. Si tienes suerte, todo fallará durante el momento de la actualización y podrás dar marcha atrás. Si no, la actualización corromperá silenciosamente los datos hasta que sea imposible volver a una versión anterior sin perder información.

No cargues todo el peso en el equipo de desarrollo

Con todo esto tienes un sistema bastante resistente. Para que todo siga su curso sólo te falta una cosa: todos estos mecanismos de despliegue, configuración, mantenimiento, actualización, etc., deben estar diseñados para que los pueda ejecutar cualquiera. Bueno, vale, no cualquiera, pero no debería ser necesario ser un ingeniero senior experto en el código de la aplicación para poder trabajar con ella.

Se supone que el equipo de desarrollo debería dedicarse a otras cosas, como desarrollar nuevas aplicaciones o ampliar funcionalidades, no a estar instalando y configurando la aplicación que han desarrollado, por lo que hace falta cuidar la usabilidad de estos procedimiento para que no acaben por absorber todo el tiempo del equipo de desarrollo. Si cada instalación falla y hay que ajustar a mano el script de creación de la base de datos, vas mal, automatízalo. Si cada vez que alguien de soporte lee un log no sabe qué hacer con el problema, vas mal, intenta añadir información sobre como solucionarlo en el propio log.

En definitiva, intenta ayudar tanto a los demás a hacer su trabajo que no tengan que pedirte ayuda a ti… y así podrás dedicarte a lo que (se supone que) más te gusta: desarrollar software.