N'est-ce pas frustrant quand quelque chose perturbe la compilation de votre logiciel ? Les problèmes de compilation entraînent un surcroît de travail imprévu. Ils semblent toujours survenir lorsque vous êtes pressé de résoudre un autre problème. Souvent, la compilation est perturbée par un facteur qui n'a aucun rapport avec ce que vous êtes en train de faire. Il peut donc être assez frustrant de devoir abandonner ce que vous êtes en train de faire, chercher la cause de la rupture de la compilation, résoudre ce problème et redémarrer la compilation (en espérant que vous n'ayez qu'un seul problème à résoudre).
J'ai rencontré ce problème aujourd'hui, alors que je reconstruisais certains paquets open source. Il y a quelques mois, nous avons mis à jour notre copie d'OpenSSL vers la version 1.0.0, mais nous n'avons pas reconstruit tous les paquets qui en dépendent. Il se trouve que lorsque j'ai voulu reconstruire le client subversion pour corriger un bug, j'ai constaté que la construction de subversion était défectueuse en raison du fait qu'OpenSSL 1.0.0 avait introduit certaines modifications incompatibles. Je n'ai pas mis longtemps à trouver la solution, car ce problème avait été corrigé il y a plusieurs mois, et une simple recherche sur le Web m'a permis de trouver à la fois le rapport de bogue et la correction. Mais cela restait tout de même assez irritant de rencontrer ce problème alors que je essayais simplement de reconstruire le produit.
Je n'ai pas de suggestion brillante à faire ici. Mais j'ai une observation à faire, à savoir que le temps machine est désormais abondant. Peut-être devrions-nous simplement reconstruire tous nos logiciels chaque nuit. Cela permettra de détecter les problèmes de construction alors que les questions sont encore fraîches dans l'esprit de chacun.
De plus, si votre processus de compilation comporte certaines étapes manuelles, le fait de décider de recompiler fréquemment vous incitera à les éliminer. Les étapes manuelles sont souvent source d'erreurs.
Les testeurs de logiciels ont tendance à ne pas aimer reconstruire un logiciel une fois qu'ils l'ont testé. Ils y voient une occasion d'introduire de nouveaux défauts. J'aime avoir suffisamment confiance en mes outils de construction (compilateurs, éditeurs de liens, fichiers make) pour pouvoir reconstruire à tout moment. Étant donné que nous travaillons avec des langages de haut niveau, nous devons avoir confiance en nos outils de construction. Mais il y a suffisamment de place pour les deux points de vue dans un processus de développement par étapes.
Si vous avez des suggestions sur la manière de gérer le développement logiciel afin de minimiser les risques de rupture de la compilation ou de réduire au minimum les efforts nécessaires pour corriger les problèmes de compilation, veuillez ajouter vos commentaires à cet article.