Pouvons-nous écrire un code 100 % sans bug ?
lewis-kang-ethe-ngugi-f5pTwLHCsAg-unsplash-Bug-Free Code
Pouvons-nous écrire un code 100 % sans bug ?
À l’été 2015, une équipe de pirates informatiques a tenté de prendre le contrôle d’un hélicoptère militaire sans pilote hautement classifié connu sous le nom de « Little Bird ».
Les pirates avaient une longueur d’avance et, en peu de temps, ils avaient déjà piraté une partie du système informatique du drone. À partir de là, ils devaient pirater l’ordinateur de bord des commandes de vol de Little Bird, et le drone était à eux. Mais ils ont échoué, et la raison en était un nouveau type de mécanisme de sécurité mis en place par la DARPA (Defence Advanced Research Projects Agency) appelé la « vérification formelle ou mathématique ».
Dans ce mécanisme, des parties critiques du système informatique de Little Bird ont été rendues impossibles à pirater avec la technologie existante, et son code a été rendu 100% infaillible, tout comme la preuve mathématique.
Et contrairement à la plupart des codes informatiques qui sont testés après avoir été écrits, les logiciels formellement vérifiés se lisent comme une preuve mathématique. Chaque énoncé découle logiquement du précédent. Un programme entier peut être testé avec la même certitude que les mathématiciens prouvent des théorèmes.
Comme Kathleen Fisher, responsable du programme fondateur du projet HACMS (High-Assurance Cyber Military Systems), l’a dit à juste titre plus tard.
« Ils n’ont pas pu sortir et perturber l’opération de quelque manière que ce soit. Ce résultat a poussé toute la DARPA à se lever et à dire, oh mon Dieu, nous pouvons réellement utiliser cette technologie dans les systèmes qui nous tiennent à cœur. »
La seule façon d’avoir un code 100% sans bogue est de prouver le code mathématiquement. Très peu de programmes dans le monde sont mathématiquement prouvés simplement parce qu’ils sont beaucoup trop chers à utiliser. La plupart d’entre nous travaillons sur des projets qui ne peuvent pas justifier le coût de la preuve mathématique, et c’est pourquoi nous devons compter sur notre sac local d’astuces pour maintenir le taux de bogues aussi bas que possible.
Cela dit, nous pouvons toujours écrire du code sans bogue, et ce que j’entends par code sans bogue, c’est écrire un logiciel avec une qualité acceptable, développé dans les délais et le coût donnés. Notre objectif est de minimiser les bogues en faisant des erreurs moins coûteuses pour éviter les plus coûteuses. De cette façon, nous pouvons atteindre un niveau de perfection raisonnable qui justifie l’investissement du projet.
Voici cinq façons de le faire.
- N’ignorez pas les avertissements.
- Testez l’automatisation.
- Gérer les entrées du programme.
- Réduire la logique conditionnelle.
- Écoutez l’utilisateur.
N’ignorez pas les avertissements
siora-photographie-CkaAkgK5mc4-avertissements-unsplash
1. N’ignorez pas les avertissements
Quand j’étais nouveau dans la programmation, j’avais l’habitude de créer des applications et, dans la plupart des cas, les avertissements vomissaient en masse. Et quand j’avais l’habitude de poser des questions à d’autres programmeurs à ce sujet, ils m’ont dit de les ignorer car les avertissements sont inoffensifs.
Vraiment? Sont-ils vraiment inoffensifs ? Je l’ai appris à la dure et j’ai réalisé que l’élimination des avertissements entraînait toujours moins de bogues et moins de code fragile. Les avertissements sont simplement des erreurs qui attendent de se produire, il est donc dangereux de les ignorer pour les raisons suivantes.
- Les avertissements sont le comportement par défaut de votre outil de compilation, qui peut ne pas convenir à votre scénario de codage.
- Au fur et à mesure que les avertissements s’accumulent, les bogues deviennent plus difficiles à corriger et à prévenir, car le code peut bientôt devenir incontrôlable.
- De nombreux avertissements signifient un manque de discipline d’équipe. Cela montre que les normes de codage sont bâclées.
- L’équipe peut prendre l’habitude de supprimer tous les avertissements, ce qui peut également entraîner la suppression des avertissements nuisibles.
Bien qu’il faille plus de temps pour corriger un avertissement que pour le supprimer, c’est du temps bien dépensé et cela se traduira par un code plus propre et meilleur à l’avenir. Pour exposer les bogues potentiels, définissez le niveau d’avertissement de l’outil de compilation sur la rigueur maximale. Ne tolérez pas les avertissements. Éliminez-les.
Faire l’automatisation des tests
andrea-de-santis-zwd435-ewb4-unsplash-automatisation
2. Faites l’automatisation des tests
L’automatisation des tests augmente l’efficacité globale du logiciel et garantit une qualité logicielle robuste. Il existe des outils spécifiques qui peuvent exécuter efficacement des cas de test automatisés et aider à comparer les résultats réels et attendus.
Certains des avantages de l’automatisation des tests peuvent être.
Rétroaction plus rapide : Il améliore la communication entre les codeurs, les concepteurs et les propriétaires de produits et permet de corriger immédiatement les problèmes potentiels.
Résultats accélérés : Les tests peuvent être effectués à plusieurs reprises, fournissant des résultats plus rapides à chaque fois avec moins d’effort et de temps.
Amélioration de l’efficacité des tests: Les tests automatisés prennent finalement beaucoup moins de temps. Ils peuvent être exécutés pratiquement sans surveillance, laissant les résultats à surveiller vers la fin du processus.
Couverture de test globale supérieure : Les tests automatisés entraînent l’exécution d’un plus grand nombre de tests sur une application. Cela conduit à une couverture plus élevée que dans une approche de test manuel.
Détection précoce des défauts : Les défauts détectés plus tôt permettent d’augmenter la vitesse de développement globale tout en garantissant une fonctionnalité correcte dans tous les domaines. Plus un défaut est identifié tôt, plus il est rentable de résoudre le problème.
N’oubliez pas qu’avoir une solide batterie de tests automatisés est un excellent moyen de réduire le taux de bogues et d’éviter de nouveaux bogues lors de la refactorisation du code. L’investissement initial peut être élevé, mais le coût justifie l’effort économisé plus tard dans le projet.
Gérer les entrées du programme
entrées tetsuya-tomomatsu-Nl79ckrM_1Q-unsplash
3. Gérer les entrées du programme
Nous connaissons tous l’adage séculaire « ordures à l’intérieur, ordures à la sortie ». Ainsi, si vos entrées sont des ordures, vous êtes obligé d’avoir des bogues.
Et tous les programmes doivent obtenir des données de sources externes, qui peuvent être peu fiables ou douteuses. La source peut être une interface utilisateur, un fichier, un système externe ou une base de données. Par exemple, vous attendez un numéro de carte de crédit comme entrée et quelqu’un entre le numéro SSN. Vous vous attendez à ce que le code postal américain soit entré et quelqu’un entre le code postal au format indien. Les possibilités d’erreur sont infinies.
Pour rendre votre programme robuste, vous devez valider chaque entrée de votre programme. Je sais que la validation augmente la taille du programme et réduit les performances. Par conséquent, il est crucial d’échanger soigneusement le « minimum » qui peut être accepté et ce qui est absolument « non négociable ».
Et lors de la validation, vous devez vous assurer que vous validez toutes les données à un seul endroit où votre programme obtient les entrées. En mettant toutes les validations en un seul endroit, vous pouvez vérifier les données non valides de manière organisée, et il n’y aura pas besoin de valider les données à d’autres endroits.
N’oubliez pas que la gestion des entrées du programme est une technique évidente mais souvent négligée pour gérer les bogues. Mais il est crucial et ne peut être sous-estimé.
Réduire la logique conditionnelle
florian-schmetz-LPckxbrqE5w-unsplash-conditionnel
4. Réduire la logique conditionnelle
J’ai récemment vu un ted talk de Miško Hevery dans lequel il proposait un défi intéressant à son public. Il voulait qu’ils écrivent du code sans aucun if-else ni aucun bloc de commutation.
Est-ce même possible ? La construction de la logique conditionnelle est le cœur de toute logique de programmation, et qu’est-ce qui peut éventuellement être gagné par un tel exercice ?
Hevery explique plus tard que tester chaque combinaison devient impossible à mesure que le nombre d’instructions conditionnelles augmente et que des bogues commencent à s’infiltrer à partir de scénarios inconcevables. De plus, trop de logique conditionnelle rend le programme plus difficile à comprendre et à rectifier.
Le point de Hevery est que le code sans les instructions if (ou switch) est
- Plus facile à lire et à comprendre
- Plus facile à tester
- Plus facile à entretenir, à étendre, etc.
Bien qu’il reconnaisse que l’élimination complète de la logique conditionnelle est inévitable, nous pouvons réduire le montant en utilisant les moyens suivants,
- Une bonne conception OO peut éliminer le besoin de coder explicitement le branchement.
- Utilisation d’assertions pour les contrôles de validité.
- Utilisation du contexte et du polymorphisme.
- Élimination du code d’épave de train – Une épave de train est constituée de plusieurs niveaux d’appels de méthode (appelés une chaîne), dans lesquels chaque code appelle une méthode sur la valeur de retour d’un autre appel de méthode. Ce modèle profondément imbriqué va à l’encontre de la loi de Demeter, une directive de conception visant à promouvoir le couplage lâche de structures de données qui ne sont pas étroitement liées et ne doivent donc pas être couplées.
Rappelez-vous, moins c’est plus. Plus vous écrivez de code en production, plus vous aurez besoin de le maintenir, et plus vous devriez être sceptique quant à sa lisibilité et son absence de bogues.
Écouter l’utilisateur
brett-jordan-mS20cgMWaPw-unsplash-écouter
5. Écoutez l’utilisateur
Oui. Par utilisateurs, j’entends de vrais utilisateurs qui utiliseront l’application et non des testeurs qui ont certifié votre code.
Vous pourriez discuter ici. Le testeur a certifié mon code. Pourquoi devrais-je m’embêter ? Faux. Vous êtes responsable de fournir un code correct qui satisfera les utilisateurs, et vous devez déduire des statistiques de leurs commentaires pour évaluer la stabilité ou l’instabilité de votre code.
Cela dit, la plupart des bogues résultent d’un code modifié ou nouveau. Trouver un bogue dans un code déjà stable qui fonctionne bien en production est peu fréquent. Mais cela arrive parfois.
Et comment savez-vous qu’un certain code fonctionne bien pendant longtemps en production ? Simplement en écoutant les utilisateurs. S’ils n’ont pas signalé de problèmes sur certaines fonctionnalités pendant une longue période, vous pouvez être sûr que le code sous-jacent est stable.
N’oubliez pas que les vrais utilisateurs se plaindront lorsqu’ils trouveront un bogue et resteront silencieux lorsqu’ils considéreront que le produit fonctionne correctement. Cela peut être votre test décisif en tant que développeur pour vous améliorer après chaque retour. Certains des commentaires les plus précieux peuvent également être utilisés pour résoudre ce problème.
- Problèmes fonctionnels dans le code.
- Validation manquante et cas d’angle
- Utilisation de l’API et modèles de conception
Etc.
Votre meilleur pari est de rechercher l’excellence, pas la perfection, et de réaliser que vous n’obtiendrez un développement sans bug que si vous construisez une navette spatiale.
diana-polekhina-F68HtpYHu_w-unsplash-excellence
Pensées finales
Rien dans ce monde n’est parfait, y compris les logiciels. Il nécessite des tests rigoureux avant le lancement et des mises à jour constantes après le lancement pour rester pertinent et garantir une bonne expérience utilisateur.
Même après la sortie du logiciel, vous ne pouvez pas contrôler son environnement d’exécution car il existe de nombreux appareils sur lesquels il peut s’exécuter et des conditions de panne peuvent survenir n’importe où, n’importe quand. Ne vous en faites pas.
Votre meilleur pari est de rechercher l’excellence, pas la perfection, et de réaliser que vous n’obtiendrez un développement sans bug que si vous construisez une navette spatiale. L’excellence concentre votre attention sur ce qui est juste et qui fonctionne plutôt que sur ce qui ne fonctionne pas. L’excellence est illimitée, progressive et toujours gratifiante.
Comme l’a dit à juste titre Rick Pitino.
« L’excellence est la capacité illimitée d’améliorer la qualité de ce que vous avez à offrir. »
Sources
- Rédaction de code solide : philosophies de développement pour l’écriture de programmes sans bogues – Steve Maguire
- Développement piloté par les tests avec C++ : un guide simple pour écrire du code Agile sans bogue – Abdul Wahid Tanner
- Clean Code : Un manuel d’artisanat logiciel agile – Robert C. Martin
- Lois intemporelles du développement logiciel-Jerry Fitzpatrick
- Guide complet de l’automatisation des tests : techniques, pratiques et modèles pour la création et la maintenance de projets logiciels efficaces – Arnon Axelrod
Ce contenu est exact et fidèle au meilleur de la connaissance de l’auteur et ne vise pas à remplacer les conseils formels et individualisés d’un professionnel qualifié.
© 2022 Ravi Rajan
