¿No odias cuando algo rompe la estructura de tu software? Los problemas de construcción crean trabajo extra, no planificado. Parece que siempre ocurren cuando te apresuras a resolver algún otro problema. A menudo, la construcción se rompe por algún factor que no está relacionado con nada de lo que estás haciendo en ese momento. Por lo tanto, puede ser bastante frustrante tener que dejar de hacer lo que está haciendo, investigar qué causó la ruptura de la compilación, solucionar ese problema y reiniciar la compilación (con la esperanza de que sólo tenga un problema por resolver).
Me encontré con este número hoy, mientras reconstruía algunos paquetes de código abierto. Hace unos meses, actualizamos nuestra copia de OpenSSL a la versión 1.0.0, pero no reconstruimos todos los paquetes que dependen de ella. Resulta que cuando fui a reconstruir el cliente de subversión para corregir un error, me encontré con que la construcción de subversión estaba rota debido al hecho de que OpenSSL 1.0.0 introdujo algunos cambios incompatibles. No me llevó mucho tiempo encontrar la corrección, porque este problema había sido corregido hace meses, y una simple búsqueda en la web encontró tanto el informe de errores como la corrección. Pero aún así fue bastante irritante encontrarme con este problema cuando estaba tratando de reconstruir el producto.
No tengo una sugerencia brillante para hacer aquí. Pero tengo una observación, que es que el tiempo de la máquina es ahora abundante. Tal vez deberíamos simplemente reconstruir todo nuestro software cada noche. Eso atrapará los problemas de construcción cuando los problemas estén todavía frescos en la mente de todos.
Además, por si acaso tiene algunos pasos manuales en su proceso de construcción, decidir reconstruir con frecuencia será un buen incentivo para eliminarlos. Los pasos manuales son una fuente común de errores.
A los probadores de software les disgusta reconstruir el software una vez que lo han probado. Lo ven como una oportunidad para introducir nuevos defectos. Me gusta tener suficiente confianza en mis herramientas de construcción (compiladores, enlazadores, makefiles) que puedo reconstruir en cualquier momento. Dado que estamos trabajando en lenguajes de alto nivel, debemos tener confianza en nuestras herramientas de construcción. Pero hay espacio suficiente para ambos puntos de vista en un proceso de desarrollo por fases.
Si tiene sugerencias sobre cómo gestionar el desarrollo de software para minimizar las posibilidades de romper la construcción, o de minimizar el esfuerzo necesario para corregir los problemas de construcción, por favor, añada sus comentarios a esta entrada.
Empresa