Sommaire

Conclusion

Le lecteur s’est certainement souvent fait la réflexion, au fur et à mesure de la lecture, que les erreurs de code relevées étaient évidentes, voire même qu’elles n’apparaîtraient pas dans une vraie application. Il est vrai que dans certains cas, l’auteur a volontairement forcé le trait. Parfois dans un but pédagogique, parfois pour réduire la taille du code à analyser, et c’est alors ce qui fait ressortir, par exemple, les redondances ou les appels multiples.

Mais toutes les erreurs détaillées ici sont des classiques. Bien sûr, elles n’apparaîtront normalement jamais dans du code solide, dédié à des applications critiques ou semi-critiques, pour lesquelles un client est prêt à payer un surcoût important lié aux tests de robustesse et de performance de l’application. Mais l’industrie n’est pas faite que de ce genre d’applications, loin de là. Elle fourmille de simples applications de gestion de données. Ce qui ne veut pas dire que ce sont des sous-applications. Par exemple, ce sont souvent des logiciels sur lesquels un gros effort de sécurité est réalisé, et qui sont de fait bien moins attaquables que certains logiciels grand public. À l’inverse, la performance n’est souvent pas prise en compte dès la conception, et les équipes de développement ne sont pas nécessairement ...