Dernièrement discutant de conception et de programmation avec un programmeur externe, il m’expliqua son approche de programmation défensive.

Mais avant d’aller dans le détail de ses explications, Wikipédia aide-nous à définir la programmation défensive :

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. The idea can be viewed as reducing or eliminating the prospect of Finagle’s law having effect. Defensive programming techniques are used especially when a piece of software could be misused.

On comprend que c’est un « mind set » qui est excellent en soit, puisqu’il nous permet de livrer du code moins fragile. De plus, cette façon de voir le code est en lien direct avec la création de test automatisé unitaire (le TDD ou TLD (Test Last Development) mais je ne rentrerai pas dans ce débat ici).

Voici une illustration de sa vision (du développeur)

Le développeur m’expliquait qu’il est essentiel de mettre de la gestion d’exception dans le Service123 mais aussi dans toutes les fonctions de toutes les classes de l’assembly utilitaire. Aussi qu’il était impératif de mettre de la validation de paramètre partout, mais aussi dans les classes marquées comme internal, donc pas visible et utilisable à l’externe de l’assembly qui les contient.

C’est là que je me suis dit : « Est-ce que la programmation défensive à ses limites et peut rapidement devenir de la programmation paranoïaque ? » Je m’explique, les try catch et les validations ont des impacts à plusieurs niveaux dont sur la performance et la lisibilité du code pour ne nommer que ceux-ci.

Moi, avant tout j’essaie d’identifier les points d’entrée de mes composantes qui peuvent amener des irrégularités dans le fonctionnement de mon système. Aussi j’essaie d’identifier les endroits où j’ai une dépendance vers des contextes hors de mon application (web service, base de données, fichier physique) puisque ces dépendances peuvent fragiliser ma composante ou classe. Le reste je me fie à mes tests unitaires pour valider ma non-régression et le bon fonctionnement des cas limites des fonctionnalités de mes classes.

Donc si on revient à notre exemple, les points d’entrée de ce micro-système sont ProduireDoc du Service123 et CreerPatente de la classe Composante A. Ces deux endroits devraient valider leurs paramètres d’entrées. Ensuite, Service123 dépend de ComposanteA donc devrait avoir une gestion d’exception pour différentes raisons (masquage d’exception internet, gestion de l’expérience cliente plus élégante, journalisation, etc).

Et vous, comment gérez-vous votre programmation, êtes-vous plus du type défensif ou paranoïaque ?