L'article en question met sans le vouloir le doigt sur ce qui constitue une des principales origines des bugs : Les changements de cahier des charges. Les deux exemples mentionnés ne sont pas de bugs, ce sont des demandes de fonctionnalités supplémentaires non prévues au départ. C'est l'implémentation à la va vite de ces fonctionnalités qui a généré des bugs.
Le logiciel en question n'était sensé au départ ne fonctionner qu'avec SqlServer. Ca faisait partie des acquis. Il doit donc y avoir dans le code de nombreux endroits où on suppose que telle opération doit se comporter de telle manière parce que c'est la façon dont ça marche sur SqlServer. Il est très difficile d'adapter le logiciel dans ces conditions.
Le deuxième problème n'est pas non plus un bug. Le logiciel n'était pas prévu pour tourner sous Linux. Ce n'était pas demandé au départ. Les développeurs ont donc du supposer que le caractère de fin de ligne etait toujours CRLF que ce soit pour écrire ou parser du texte. Ils ont du modifier en urgence le truc en collant des "if (Windows) CRLF else LF" mais forcément ils en ont oublié. Si la portabilité avait fait partie du cahier des charge dès le départ, ils auraient défini une constante "EndOfLine" dans un coin et terminé.
Ce genre de changement est quasiment toujours problématique. Le code a été conçu en fonction de la demande initiale et il y a donc probablement dedans pas mal de suppositions. Et si en plus un commercial trouve le moyen de vendre ça en "pas de problème on vous le fait pour demain" toutes les conditions sont réunies pour l'explosion en vol.
# De l'origine des bugs
Posté par Croconux . En réponse au journal Pourquoi nous vendons un code contenant des bogues.... Évalué à 10.
Le logiciel en question n'était sensé au départ ne fonctionner qu'avec SqlServer. Ca faisait partie des acquis. Il doit donc y avoir dans le code de nombreux endroits où on suppose que telle opération doit se comporter de telle manière parce que c'est la façon dont ça marche sur SqlServer. Il est très difficile d'adapter le logiciel dans ces conditions.
Le deuxième problème n'est pas non plus un bug. Le logiciel n'était pas prévu pour tourner sous Linux. Ce n'était pas demandé au départ. Les développeurs ont donc du supposer que le caractère de fin de ligne etait toujours CRLF que ce soit pour écrire ou parser du texte. Ils ont du modifier en urgence le truc en collant des "if (Windows) CRLF else LF" mais forcément ils en ont oublié. Si la portabilité avait fait partie du cahier des charge dès le départ, ils auraient défini une constante "EndOfLine" dans un coin et terminé.
Ce genre de changement est quasiment toujours problématique. Le code a été conçu en fonction de la demande initiale et il y a donc probablement dedans pas mal de suppositions. Et si en plus un commercial trouve le moyen de vendre ça en "pas de problème on vous le fait pour demain" toutes les conditions sont réunies pour l'explosion en vol.