2.2 El software es como un hijo, hay que mantenerlo

Personalmente, me gusta mucho más desarrollar software (proyectos greenfield) que mantenerlo (proyectos brownfield), aunque durante mi trayectoria profesional he tenido que mantener mucho software escrito por otras personas. Mantener software hecho por otros es una tarea muy exigente porque a veces es realmente complejo llegar a entenderlo. La parte positiva es que arreglando y modificando cosas que han hecho otros aprendes mucho y adquieres una gran experiencia porque ves cómo los demás resuelven problemas y puedes aprender técnicas que desconocías. Sin embargo, también es cierto que hay cosas que es mejor no ver o no saber porque están mal hechas y pueden llevar a confusión o a adquirir malas prácticas.

El proceso de desarrollo es algo creativo, mientras que el mantenimiento es más reactivo. Cuando creas algo desde cero, lo haces tomando las decisiones de diseño con los miembros de tu equipo y, a partir de aquí, se empiezan a desarrollar los distintos componentes que van a formar el sistema. En cambio, cuando estás arreglando o modificando cosas, los inputs son más negativos, ya que te dedicas a buscar lo que está mal para hacer que funcione correctamente, o bien a añadir, quitar o cambiar partes, intentando no romper lo que ya estaba funcionando más o menos bien.

Hay mucha gente que cree que un proyecto termina cuando se pone en producción, pero esto no es así. Una vez puesto en producción es cuando van a surgir los problemas no contemplados durante las fases de desarrollo y pruebas preliminares. Es bien sabido que cuando algo es nuevo es más inestable porque siempre surgen errores, problemas, casuísticas y necesidades que no se habían previsto inicialmente. Esto les pasa hasta a las compañías más grandes, que invierten cantidades ingentes de dinero en hacer controles de calidad minuciosos (QA) y pruebas de carga y de estrés de todo tipo.

Por lo tanto, una vez desarrollado el proyecto, puesto en producción y estabilizado, empieza la etapa de mantenimiento. Durante esta nueva fase, se van corrigiendo errores que aparecen a medida que se va usando, y también surgen necesidades que implican modificaciones o nuevas funcionalidades.

La entropía del software es la medida de desorden del software que refleja la complejidad de su mantenimiento, ya que, al mismo tiempo que se hacen modificaciones o se añade código nuevo, se va perdiendo su estructura inicial y se vuelve más caótico. Por este motivo, podemos decir que los sistemas empiezan a degradar de forma más acentuada a partir del momento en el cual se requieren cambios para los que no estaban diseñados inicialmente. Pero, si además el desarrollo del sistema ha sido deficiente, tendremos en producción un sistema que ya ha empezado a degradarse incluso durante la fase de desarrollo. Los procesos de refactorización y las buenas prácticas intentan luchar contra esta entropía mortal, intentando preservar el orden y la paz.

La custodia para los padres

Muchas veces ocurre que una empresa desarrolla algo y es otra la que se encarga de mantenerlo. Desde mi punto de vista, esto puede ser un suicidio tecnológico si no está muy bien gestionado, ya que quien realmente tiene el conocimiento de cómo está hecho, cómo funciona y por qué está hecho de esa forma es precisamente el equipo que lo ha desarrollado. Por mucha documentación que haya y por muchos test que se hayan implementado, todo ese conocimiento adquirido durante el desarrollo (know-how) se va a perder. Además, si se han tenido que hacer workarounds (chapuzas) o tratar casos especiales, es muy probable que no queden documentados y luego las personas que lo tengan que mantener no sepan por qué se ha hecho algo de una determinada manera, que a priori no parece la más elegante, evidente o eficiente.

Uno de los peores casos ocurre cuando el desarrollo está mal hecho, no hay documentación del proyecto ni documentación técnica, el proyecto está obsoleto porque se trabaja con tecnologías antiguas y, además, la empresa que lo ha hecho ya no mantiene el proyecto ni hay forma de contactar con ellos. Igualmente, en el caso de que se pudiera contactar con ellos, muy probablemente tampoco serviría de nada porque los que llevaron a cabo el proyecto seguramente ya no trabajen allí o ni se acuerden de él. De hecho, hay organizaciones que desmantelan los equipos cuando finalizan los proyectos que se les habían asignado, aunque yo soy partidario de tener equipos de trabajo estables que puedan realizar múltiples proyectos a lo largo del tiempo.

Si subimos aún más la apuesta, puede que consigas algo de documentación obsoleta, sin que realmente lo sepas. También puede que logres contactar con alguien que te pueda contar algo acerca del proyecto. Pero, por desgracia, esto también puede ser contraproducente porque quizás lo que te digan no sea verdad, debido a que esté obsoleto o porque lo tengan mal entendido. Cuando me ha sucedido esto, incluso he llegado a pensar que habría sido mejor no encontrarme esa documentación ni hablar con nadie, porque eso me hacía guiar por directrices falsas que aún me complicaban más la vida, ya que no me encajaban las piezas y no entendía absolutamente nada.

Pero esto no es todo, hay proyectos en los que, por desgracia, una empresa hace el análisis funcional, otra desarrolla el proyecto y una tercera lo mantiene o, mejor dicho, hace lo que puede. Es decir, ya no estamos hablando de que sean dos empresas, sino tres (o incluso más si alguna de ellas hace subcontrataciones). En consecuencia, estos pobres proyectos tienden a degradarse varias veces, antes incluso de ser puestos en producción, una por cada cambio de empresa. La cosa es aún peor cuando se trata de transiciones duras, es decir, cuando no hay ningún tipo de acompañamiento ni asesoramiento por parte de los que salen del proyecto a los que toman el relevo.

Sí, sé que esto parece el apocalipsis, pero todo esto me ha ocurrido y es realmente un infierno. Como digo a veces: «Esto no está pagado». En casos así, no queda más remedio que hacer «ingeniería inversa», donde, a partir del código, tienes que intentar entender qué es lo que se supone que se hace y documentarlo mínimamente para que al menos se sepa algo acerca de cómo funciona todo ese lío.

Así que, si viviéramos en un mundo ideal, los desarrolladores serían los que mantendrían los proyectos que ellos mismos han creado, existiría documentación del proyecto, documentación técnica, pruebas unitarias, pruebas de integración, etc., y, además, se harían las actualizaciones pertinentes. Desgraciadamente, la realidad es que en muchas ocasiones tenemos que mantener proyectos a los que no tenían cariño ni las personas que los desarrollaron inicialmente, y eso se nota mucho.

Evidentemente, también hay que ser conscientes de que en muchos casos no es factible que las mismas personas que desarrollaron los proyectos los mantengan para siempre. Con el paso del tiempo, la dedicación requerida para la implementación de correctivos y evolutivos en todos los proyectos creados a lo largo de los años no les dejaría tiempo para desarrollar otros nuevos. Por lo tanto, hay que asumir que los proyectos podrán ser traspasados en algún momento. No obstante, hay que hacerlo en las mejores condiciones posibles y no en situaciones críticas como, por ejemplo, justo después de ponerlos en producción, cuando ni siquiera están estabilizados. Ten en cuenta que, típicamente, cuanto más maduro y estable es un sistema, menos cambios drásticos se hacen en él y menos horas se requieren para su mantenimiento. Por lo tanto, no es lo mismo traspasar un proyecto maduro, considerado estable y bien documentado, que otro que se encuentra en fase de cambios constantes porque todavía sigue en desarrollo o aún no está estabilizado.

Dicen que hay que desarrollar pensando que el que va a mantenerlo luego puede ser un psicópata que sepa dónde vives. Por lo tanto, es mejor hacer las cosas bien y no dejar sorpresas desagradables para el siguiente, no vaya a ser que el cuento sea verdad y luego tengamos problemas.

También dicen que un buen código es autodocumentado. Estoy de acuerdo parcialmente con esta afirmación, ya que si las cosas se hacen bien no hace falta documentarlo absolutamente todo. Piensa que es contraproducente ver código donde cada línea está documentada, así que, por favor, no lo hagas. Por otro lado, hay cosas que no son evidentes y un pequeño comentario puede ahorrar mucho tiempo y dolor en el futuro, tanto a ti como a los que vengan detrás. Muchas veces he agradecido a mi «yo del pasado» un simple comentario explicando por qué tomé esa decisión.

Una buena estrategia para impulsar las buenas prácticas y facilitar la mantenibilidad del software consiste en plantear que el proyecto pueda ser liberado como software libre en cualquier momento. De esta manera, se fomenta que los desarrolladores trabajen de forma más limpia y ordenada porque la excusa de que nadie más va a ver el código aparte de sus propios compañeros ya no sirve. Si se trabaja con control de versiones (espero que así sea), van a constar sus datos en las modificaciones y todo el mundo va a poder ver las chapuzas y quién y cuándo las ha hecho. Me he llegado a encontrar hasta contraseñas dentro de repositorios de código y esto no puede ser porque van a quedar guardadas permanentemente en el histórico de cambios y esto supone un riesgo de seguridad.

Hay una frase que resume muy bien el mantenimiento de software: «Cuando escribí esto, solo Dios y yo entendíamos lo que estaba haciendo, pero ahora ya solo lo sabe Dios». Esto significa que, a medida que pasa el tiempo, tendemos a olvidarnos de las cosas. Lo malo es que, a veces, cuando lees tu propio código tiempo después te planteas: «¿En qué estaría pensando para hacer esto?». Imagínate, si tú mismo opinas esto de tu propio código, ¿qué pensarán los demás de ti cuando lo lean?