Proyecto Higiene

Resumen

• «¡Come verdura!»
• «¡Haz ejercicio regularmente!»
• «¡Cepíllate los dientes todos los días!»

Estas son las exhortaciones que todo niño ha escuchado (¡muchas veces!) y que ha llegado a aborrecer. Sin embargo, no se trata de prácticas diseñadas únicamente para hacer sufrir: son estímulos para ayudar a desarrollar y mantener una buena higiene. Dictionary.com define la higiene como «Condición o práctica que favorece la conservación de la salud, como la limpieza». Es decir, «Si haces estas cosas con constancia, reducirás la posibilidad de que te ocurran cosas malas en el futuro«. Por mucho que tener que seguir cepillando los dientes a diario sea un dolor, tener que ir al dentista para que te los extraiga por haber descuidado estos cuidados va a ser mucho más doloroso.

Se trata de un concepto que también puede aplicarse fácilmente a la ingeniería del software. Los proyectos de software tienen sus propios aspectos de mantenimiento al margen de las tareas principales de desarrollo de código: documentación, gestión de dependencias, despliegue, etc. El apoyo a estos aspectos puede no ser el trabajo más emocionante o intelectualmente estimulante, pero al igual que la higiene humana, tal es la naturaleza de apoyar la higiene de un proyecto: la falta de hacerlo podría causar un gran dolor para el desarrollador en el futuro. Por lo tanto, cuando se desarrollen las prácticas y actividades de un equipo de desarrollo de software, hay que intentar desarrollar un plan para mantener la higiene del proyecto mediante actividades programadas regularmente que puedan incorporarse al plan de desarrollo del proyecto.

Conceptos

Dependencias

Prácticamente todos los proyectos de software de hoy en día se construyen utilizando bibliotecas de software externas: desde los frameworks de terceros como Spring o Django hasta el lenguaje de programación en el que se escribe el código del proyecto (Java, C++, Python, etc.). Estas bibliotecas externas, naturalmente, son proyectos de software en sí mismos; en la mayoría de los casos, los desarrolladores detrás de estos proyectos los mantienen activamente y publican nuevas versiones del código en diferentes momentos.

Puntos a considerar

• ¿Cómo sabrá el equipo del proyecto cuándo se ha publicado una nueva versión para cualquiera de las dependencias de software del proyecto? La comprobación manual de nuevas versiones puede ser un proceso arduo; las herramientas de detección automatizada como Dependabot pueden reducir o eliminar este tipo de trabajo.
• Una vez que se publica una nueva versión de una dependencia de software, ¿cuál será el protocolo para evaluar cuándo incorporarla al proyecto? Salvo en el caso de cambios de ruptura irresolubles, una nueva versión de una dependencia de software debería incorporarse lo antes posible a un proyecto. Aunque no aporte un valor inmediato al proyecto, refuerza el hábito de mantener el código del proyecto actualizado de acuerdo con las dependencias que utiliza. Mantener una versión antigua de una dependencia porque «simplemente funciona» está bien, hasta que no lo está. Un día, puede llegar el anuncio de Internet de que es <a href=»https://www.zdnet.com/article/spring4shell-flaw-heres-why-it-matters-and-what-you-should-do-about-it/»>absolutamente necesario actualizar</a>; de repente, podría ser necesario saltar varios años de versiones de dependencias. Lo que podría haber sido una serie de pequeños cambios en el código del proyecto cada cierto tiempo es ahora un gran conjunto de trabajo no planificado que debería haberse hecho ayer.

Depreciaciones

Como se ha mencionado anteriormente, el software se encuentra con frecuencia en un estado constante de mejora y refinamiento; a veces, esto no significa únicamente añadir nuevo código y funcionalidad, sino también eliminar código y funcionalidad. Lo ideal es que los desarrolladores de software indiquen el código y la funcionalidad que eventualmente pretenden eliminar marcándolos como obsoletos.

Puntos a considerar

• Cuando el código de una dependencia externa ha sido desaprobado, ¿cuál será el protocolo para reemplazarlo? Piensa en las banderas de depreciación como un gesto de buena voluntad: los desarrolladores de la dependencia externa han anunciado que harán un cambio de código que requerirá cambios en el código que utiliza la dependencia, pero darán a los usuarios externos la ventaja de tener tiempo para preparar su propio código para el cambio. Aprovecha esa cortesía y planifica igualmente cómo y cuándo hacer los ajustes adecuados, ya que eventualmente se publicará una nueva versión de la dependencia externa en la que ese código obsoleto ya no existirá.
• Una vez que una dependencia de software ha quedado obsoleta, ¿cuál será el protocolo para sustituirla? A veces, la depreciación se produce no solo en partes específicas del código de un proyecto de software, sino en todo el proyecto en sí. Un ejemplo de ello fue la librería Hystrix de Netflix, de la que la compañía anunció en 2018 que dejaría de desarrollarse activamente. Cuando se dan casos como este, es recomendable dedicar tiempo a investigar cómo sustituir su uso en el código de un proyecto, sobre todo por las mismas razones que con las dependencias de código: eventualmente, algún evento como una vulnerabilidad de seguridad anunciada podría obligar a la actualización, momento en el que el trabajo se haría necesario pero tampoco se habría planificado.

Flujo de trabajo

El ciclo de vida del desarrollo de software contiene muchos pasos, además del propio desarrollo del software: pruebas, limpieza del código, despliegue, etc. Con frecuencia, lo que antes eran pasos que requerían una acción manual para ser completados han caído bajo el ámbito de los programas de software para ser configurados y luego ejecutados como parte de un proceso automatizado. De hecho, el concepto de automatización de las distintas partes del ciclo de vida del desarrollo de software -ahora conocido como DevOps- ha crecido rápidamente en la última década hasta convertirse en su propia carrera profesional.

Puntos a considerar

• ¿Cómo determinará el equipo si algún proceso del flujo de trabajo de desarrollo puede ser automatizado? Los sistemas de Integración/Despliegue Continuo como CircleCI y Jenkins ya proporcionan una multitud de capacidades para automatizar varias partes del ciclo de vida del desarrollo; sin embargo, a veces existen oportunidades para crear una mayor automatización en un proyecto fuera de los entornos CI/CD. Por ejemplo, si un proyecto incluye el desarrollo de múltiples microservicios, podría valer la pena dedicar tiempo a investigar si la creación de un equivalente casero a un servicio de inicialización programática como Spring Initializer podría valer la pena.
• ¿Cómo evaluará el equipo si algún paso del flujo de trabajo puede ser reordenado? Aunque un paso de verificación, como la comprobación del código, pueda ser ya una parte definida del proceso automatizado de CI/CD, trasladar ese paso a una parte anterior del proceso de desarrollo podría reducir el tiempo que transcurre entre la creación de cambios por parte del desarrollador y la comprobación de si esos cambios pueden mejorarse. Git proporciona hooks en los que se ejecutará un script antes o después de un paso del proceso Git; en este escenario, el paso de la depuración del código podría ejecutarse en el gancho de precommit para que el desarrollador sea notificado sobre un posible olor del código inmediatamente en lugar de recibir un mensaje del CI/CD en un momento posterior.
• Si se ha desactivado alguna parte del flujo de trabajo de desarrollo, ¿cuándo volverá a examinar el equipo si se puede volver a activar? A veces, el código o los pasos del ciclo de vida de desarrollo deben deshabilitarse por diversas razones, por ejemplo, una dependencia de prueba externa que se ha vuelto repentinamente poco fiable. Sin embargo, esto debería ser una medida expresamente temporal. Si se deja sin resolver, la razón por la que se pretendía que la medida fuera temporal podría olvidarse con el tiempo, y la medida se osificará y se convertirá en otro «así son las cosas» que podría impedir que se detectaran otros problemas. Merece la pena programar una revisión periódica de la base de código del proyecto y del proceso de desarrollo para detectar si una medida «temporal» se ha convertido de hecho en permanente y qué habría que hacer para resolver el problema subyacente.

Documentación

Ah, escribir documentación: ¡la tarea favorita de los desarrolladores de software! /s. Sin embargo, aunque el trabajo de documentación no sea la más agradable de las actividades, los esfuerzos acabarán dando sus frutos. El conocimiento Tribal (es decir, no tener acceso a él) y acabar en el lado equivocado del bus factor son dos impedimentos potenciales para la productividad del grupo en un proyecto, y cuanta más documentación se produzca para el proyecto, más se pueden mitigar los riesgos de verse impedido, especialmente en los casos en los que no es posible aumentar el factor bus por medios «orgánicos» (es decir, asignando más personas al proyecto).

Puntos a considerar

• ¿Cómo y cuándo evaluará el equipo si un desarrollador con cero conocimientos del proyecto puede configurar su entorno únicamente leyendo la documentación del proyecto? En los proyectos que están en desarrollo activo, la respuesta podría ser siempre «no» en el sentido más estricto del término, ya que los proyectos de software no triviales tendrán suficientes aspectos que eventualmente *alguna* parte de la documentación quedará desactualizada. Sin embargo, merece la pena esforzarse por conseguir un «sí» en la medida de lo posible, no vaya a ser que se instale la mentalidad de «no es posible mantenerla totalmente actualizada, así que para qué molestarse» y la documentación envejezca hasta quedar inservible. Un buen ejercicio en este sentido es proporcionar a un desarrollador experimentado en el proyecto un entorno limpio y hacer que intente configurar su entorno mediante el método descrito anteriormente; tendrá la experiencia necesaria para saber qué lagunas en la documentación hay que rellenar y dónde.
• ¿Cómo y cuándo evaluará el equipo si un desarrollador con cero conocimientos del proyecto puede aprender a contribuir al mismo únicamente leyendo la documentación del proyecto? En relación con el punto anterior, el proceso de desarrollo de un proyecto puede variar con respecto a otros de múltiples maneras:
  • ¿Cuál es la estrategia de ramificación del proyecto?
  • ¿Cuál es el ciclo de vida del desarrollo de softwarepara el proyecto?
  • ¿Cómo se crea una tarea? ¿Qué tipos de tareas existen?
  • ¿Cómo se realizan las revisiones del código? ¿Quién participa en las revisiones del código?

Y así sucesivamente. Mientras que estos conocimientos podrían considerarse innatos para alguien inmerso en el proyecto, no lo serán para alguien completamente nuevo en el proyecto. Un recorrido con alguien que conozca el proyecto para «mostrar las cuerdas» ayudará a inculcar este conocimiento en el recién llegado, pero eso a) quita tiempo al desarrollador experimentado que podría ser utilizado de otra manera para el desarrollo, y b) no hay garantía de que el desarrollador experimentado sepa exactamente qué temas necesita cubrir. De nuevo, el mismo ejercicio para el punto anterior ayudaría: hacer que un desarrollador experimentado revise periódicamente la documentación del proyecto para asegurarse de que la información del proceso de desarrollo está actualizada.

Conclusión

Todos los puntos enumerados anteriormente son meramente orientativos. Las circunstancias de cada proyecto de software serán diferentes y, por tanto, requerirán políticas diferentes para mantener la higiene del proyecto. Asimismo, es posible que otros aspectos de la higiene del proyecto que no se han mencionado aquí sean relevantes para un proyecto de software concreto; naturalmente, también deben tenerse en cuenta. Lo más importante es el concepto de incorporar tareas periódicas que reexaminen el estado general del proyecto de software y evalúen qué medidas pueden tomarse para que el proyecto funcione bien o para mantenerlo. Una vez más, no serán las tareas más atractivas, pero este «aburrimiento» ayudará a evitar catástrofes «emocionantes» en el futuro, así que pon las verduras en el plato, ¡y empieza a revisar esa documentación!