Systerel vous propose 17 recommandations qui vous permettront d’améliorer la qualité et l’efficacité de vos développements Ada. Ces recommandations ne sont pas toutes liées au langage Ada et peuvent pour la plupart s’appliquer à d’autres langages.

 

  1. Penser systématiquement à la maintenabilité de votre code 
    Il est facile d’écrire du code illisible, mais il n’est pas si difficile d’écrire du code lisible !
  2. Bannir les commentaires et les identificateurs inappropriés ou fantaisistes
  3. Mettre en place des règles de codages simples, vérifiables et justifiées
    et ne pas garder des règles liées à un historique Ada83 par exemple.
  4. Ne jamais ignorer les warnings compilateurs.
    Une livraison logicielle doit être faite avec zéro warning !
  5. Interdire en phase de développement les warnings inacceptables
    («… will be raised at run time …»).
  6. Activer les optimisations compilateur en dernier recours et se méfier de -O3 !
  7. Soignez l’environnement de développement (en évitant les couplages avec un VCS).
    Un environnement soigné permet toujours de gagner à terme beaucoup de temps ! Pour tout projet digne de ce nom, il faut mettre en place une intégration continue.
  8. Faire dans la mesure du possible le maximum de tests sur hôte (plus aisés, moins coûteux, plus d’outils disponibles, etc.)
    Si nécessaire, regarder les possibilités d’émulations (QEMU).
  9. Soigner le système de log.
    Comme pour l’environnement de développement, cela permet toujours de gagner à terme beaucoup de temps, que ce soit dans les phases de développement ou lors de l’exploitation opérationnelle du CSCI (Computer Software Configuration Item).
  10. Maintenir si possible les vérifications de la RTS Ada + pragma Detect Blocking.
  11. Avoir toujours une approche défensive
    (utilisation du prama Assert, programmation par contrat Ada 2012).
  12. Utiliser le pragma Restrictions (…)
    afin de détecter au plus vite des structures/unités Ada interdites ou jugées permissives dans le contexte du développement.
  13. Bien réfléchir à ce que vous allez produire en termes d’images en fonction du contexte (RELEASE, DEBUG, etc.)
    Maintien des tests de la Runtime Ada ?
    – Suppression des symboles dans le binaire (strip) ?
    – Maintien des informations de debug ?
    – Mise en œuvre du pragma Discard_Names?
    – Mise en œuvre d’un mécanisme de « built-in versioning » permettant de connaitre facilement le « versioning » et le contexte de construction d’une image binaire sans avoir à l’exécuter ?
    – Obfuscation ?
    – …
  14. Ne pas pousser le compilateur Ada dans ses derniers retranchements.
    Un compilateur Ada (validé ou pas) n’est pas dépourvu de bugs, il faut donc faire des choses simples (voir la règle 17) !
  15. Ne pas hésiter à « refactorer » votre code.
    Tenez compte du fait qu’en Ada le compilateur et le binder peuvent mettre en exergue des problèmes de structuration/design du code.
    En Ada, le refactoring est aisé et très peu risqué !
  16. Ne pas développer des composants CSCs (Computer Software Component) trop compliqués dont on n’utilisera au final que quelques fonctionnalités.
    Mieux vaut quelque chose d’adapté au besoin et facile à faire évoluer : concevez votre CSC en conséquence.
  17. Faire des choses simples !
    Mieux vaut un code simple voire naïf, qui marche qu’un code de « guru » qui ne marche pas ! (ou du moins est beaucoup plus difficile à comprendre et donc à maintenir). Si vous n’utilisez pas tous les traits du langage ce n’est pas bien grave !
    “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” Professor C. A. R. Hoare.