Est-ce que ça existe seulement, un logiciel qui n'a pas de "contrainte particulière"? Tout logiciel a un contexte d'utilisation, qui pondère l'importance des différents critères: clarté du code, performance RAM, performance CPU, évolutivité, expérience utilisateur, fiabilité, etc. Je ne vois pas ce qui ferait qu'automatiquement, le nombre de bugs ouverts serait le critère à optimiser en priorité. Même, au contraire, quel type de logiciel devrait avoir ce critère prioritaire? Les systèmes embarqués ou les systèmes d'aide à la décision, quand des vies humaines, du matériel qui coûte cher, ou des gros capitaux sont en jeu? Mais sur les logiciels courants (traitement de texte, IDE, navigateur, jeux vidéo, compilateurs...), si les bugs ne nuisent pas à l'utilisation (par exemple s'ils sont facilement contournables ou qu'ils concernent des fonctionnalités avancées dont on peut se passer), il est difficile d'imaginer une raison pour laquelle les ressources devraient être consacrées exclusivement à la correction des bugs.
J'aurais donc tendance à considérer que la priorité aux bugs relève de "contraintes particulières". D'ailleurs, beaucoup des logiciels qu'on utilise sont buggés, sans que les équipes de développement s'en émeuvent particulièrement.
[^] # Re: Échange avec Uncle Bob
Posté par arnaudus . En réponse au lien « Clean code » : performances lamentables. Évalué à 4.
Est-ce que ça existe seulement, un logiciel qui n'a pas de "contrainte particulière"? Tout logiciel a un contexte d'utilisation, qui pondère l'importance des différents critères: clarté du code, performance RAM, performance CPU, évolutivité, expérience utilisateur, fiabilité, etc. Je ne vois pas ce qui ferait qu'automatiquement, le nombre de bugs ouverts serait le critère à optimiser en priorité. Même, au contraire, quel type de logiciel devrait avoir ce critère prioritaire? Les systèmes embarqués ou les systèmes d'aide à la décision, quand des vies humaines, du matériel qui coûte cher, ou des gros capitaux sont en jeu? Mais sur les logiciels courants (traitement de texte, IDE, navigateur, jeux vidéo, compilateurs...), si les bugs ne nuisent pas à l'utilisation (par exemple s'ils sont facilement contournables ou qu'ils concernent des fonctionnalités avancées dont on peut se passer), il est difficile d'imaginer une raison pour laquelle les ressources devraient être consacrées exclusivement à la correction des bugs.
J'aurais donc tendance à considérer que la priorité aux bugs relève de "contraintes particulières". D'ailleurs, beaucoup des logiciels qu'on utilise sont buggés, sans que les équipes de développement s'en émeuvent particulièrement.