3 règles pour un développement logiciel sûr et fiable : suivez-les !

La mission d’écriture et les logiciels critiques pour la sécurité sont un défi permanent depuis longtemps. Les meilleures pratiques formelles sont utiles et existent depuis l’époque des mainframes. En tant qu’ingénieur système et professeur, j’ai lu les premiers travaux qui tentaient de définir les meilleures façons de concevoir des logiciels, c’est-à-dire « The Mythical Man-Month » de Frederick Brooks, et des dérivations plus récentes.

La NASA et le ministère de la Défense (DoD) développent tous deux des systèmes critiques. Si le logiciel, le matériel ou toute autre partie de leurs systèmes complexes tombent en panne, des vies pourraient bien être perdues. Ces professionnels doivent écrire un code aussi sûr et fiable que possible et au quotidien.

Un ensemble de directives récemment redécouvertes pour le développement de logiciels sûrs sont les règles The Power of Ten, publiées à l’origine par le Jet Propulsion Laboratory de la NASA. Certains peuvent argumenter que les directives empiriques de The Mythical Man-Month et les règles de The Power of Ten sont écrites pour des langages logiciels spécifiques, c’est-à-dire Fortran et C, respectivement. Cet argument a une base pour les règles du Pouvoir des Dix, mais beaucoup moins pour le Mois-Homme Mythique.

Mais ces arguments manquent un point important, à savoir que ces deux pièces abordent le développement de logiciels au-delà de la question de l’implémentation du langage. Ces balises s’adressent à la profession d’ingénieur logiciel, et pas seulement à l’acte de programmation.

Voici ma version légèrement modifiée et réduite de la liste de la NASA pour les règles les plus pertinentes pour les ingénieurs logiciels écrivant dans n’importe quelle langue :

1. Suivez le principe « restez simple, stupide » ou KISS

Règle de la NASA : restreignez tout le code à des constructions de flux de contrôle très simples – n’utilisez pas d’instructions ou de constructions goto et similaires

Justification de la NASA : un flux de contrôle plus simple se traduit par des capacités de vérification renforcées et entraîne souvent une amélioration de la clarté du code.

2. Conception pour un faible couplage et une forte cohésion

Règle de la NASA : aucune fonction ne doit être plus longue que ce qui peut être imprimé sur une seule feuille de papier dans un format de référence standard avec une ligne par déclaration et une ligne par déclaration. En règle générale, cela signifie pas plus d’environ 60 lignes de code par fonction.

Justification de la NASA : chaque fonction doit être une unité logique dans le code qui est compréhensible et vérifiable en tant qu’unité. Des fonctions excessivement longues sont souvent le signe d’un code mal structuré.

— Les fonctions doivent pouvoir se suffire à elles-mêmes (haute cohésion) avec un nombre minimum d’interfaces avec d’autres fonctions (faible couplage).

3. Tenez compte des avertissements

Règle de la NASA : tout le code doit être compilé, dès le premier jour de développement, avec tous les avertissements du compilateur activés au réglage le plus pédant du compilateur. Tout le code doit être compilé avec ces paramètres sans aucun avertissement. Tout le code doit être vérifié quotidiennement avec au moins un, mais de préférence plus d’un, analyseur de code source statique à la pointe de la technologie et doit réussir les analyses sans aucun avertissement.

Justification de la NASA : Il n’y a tout simplement aucune excuse pour qu’un effort de développement logiciel ne fasse pas usage de la technologie facilement disponible. Cela devrait être considéré comme une pratique courante, même pour le développement de code non critique. La règle du zéro avertissement s’applique même dans les cas où le compilateur ou l’analyseur statique donne un avertissement erroné : si le compilateur ou l’analyseur statique est confus, le code provoquant la confusion doit être réécrit afin qu’il devienne plus trivialement valide. De nombreux développeurs ont été pris dans l’hypothèse qu’un avertissement était sûrement invalide, pour se rendre compte bien plus tard que le message était, en fait, valable pour des raisons moins évidentes.

Comme les développeurs de logiciels de la NASA s’en sont rendu compte très tôt, ces règles allègent le fardeau du développeur et du testeur d’établir les propriétés clés du code par d’autres moyens. Le papier résume bien :

« Si les règles semblent draconiennes au premier abord, gardez à l’esprit qu’elles sont censées permettre de vérifier le code où très littéralement votre vie peut dépendre de son exactitude : le code qui est utilisé pour contrôler l’avion sur lequel vous volez, l’énergie nucléaire plante à quelques kilomètres de chez vous, ou le vaisseau spatial qui transporte les astronautes en orbite. Les règles agissent comme la ceinture de sécurité dans votre voiture : au départ, elles sont peut-être un peu inconfortables, mais au bout d’un moment, leur utilisation devient une seconde nature, et ne pas les utiliser devient inimaginable.