Comment organiser un projet de micrologiciel

Il y a de nombreux avantages à avoir un projet logiciel organisé lors du développement d’un micrologiciel. Premièrement, de tels projets facilitent la recherche de modules et de fichiers lorsque vous en avez besoin plutôt que de perdre du temps à chercher. Deuxièmement, un projet organisé peut aider à l’évolutivité du projet en ne nécessitant pas d’ajustements constants à un fichier de création de projet ou à des propriétés de projet. Troisièmement, s’ils sont méticuleusement organisés, les développeurs devraient être capables d’intégrer facilement des outils, de reconstruire leur environnement de développement et même de porter le code plus facilement. Il existe de nombreuses façons d’organiser une base de code, mais dans le post d’aujourd’hui, je vais vous montrer comment j’organise généralement mes projets.

Lorsque vous démarrez un nouveau projet, il est bon d’avoir une sorte d’organisation de haut niveau pour faciliter la recherche. Au fil des années, j’ai adopté une structure simple mais efficace que j’utilise au début de chaque projet, qui évolue ensuite généralement légèrement en fonction des besoins du projet. La structure commence généralement par les éléments suivants :

• Application
• Documentation
• Middleware
• Projet
• Essais
• Utilitaires

Bien qu’à première vue, cette structure puisse sembler explicite, il serait peut-être préférable que j’explique ce que chacun de ces éléments fait et comment je les manipule généralement.

Le répertoire Application est utilisé pour stocker tout le code spécifique à l’application. Il s’agit d’un code personnalisé écrit spécifiquement pour le produit. Un développeur peut considérer cela comme la sauce secrète ou le code qui différencie le système embarqué de tous les autres. Ce dossier contient des modules d’application ainsi que tous les modules de configuration qui les accompagnent et qui aident à rendre le code portable et évolutif. On peut vouloir créer des sous-répertoires pour inclure le code source et de configuration, mais j’ai souvent trouvé que cela n’est pas utile et nécessite simplement d’ajouter plus de chemins d’inclusion à la configuration du projet. Si je veux les organiser davantage, faites-le dans le logiciel Integrated Development Environment (IDE).

Le répertoire de documentation est utilisé pour plusieurs types de documentation. Tout d’abord, les manuels et les fichiers générés par Doxygen sont tous stockés dans ce répertoire. Deuxièmement, toute documentation supplémentaire utile, telle que des articles sur les guides de l’utilisateur, les CRC, les formats de fichiers d’entrée, les données spécifiques au développement, etc.

Le répertoire middleware stocke tous les middlewares et bibliothèques tierces pertinents utilisés dans le projet. Je crée souvent des liens vers les sous-modules Git dans ce répertoire. Il y avait autrefois une bonne pratique selon laquelle les équipes extrayaient une copie de tout ce qu’elles utilisaient, et la gardaient statique afin que cela ne change jamais et qu’elles aient toujours une sauvegarde. C’est une excellente pratique, mais j’ai trouvé qu’aujourd’hui, il est plus pratique d’inclure le sous-module Git, puis d’extraire les révisions balisées. Avec chaque version officielle du projet, les versions de chaque bibliothèque utilisée sont documentées. De cette façon, pour rester à jour, je peux simplement extraire du sous-module la dernière révision au lieu de l’exporter, de l’importer dans mon référentiel, de l’ajouter, de la valider, etc.

Le répertoire Project stocke les informations de projet spécifiques à la chaîne d’outils. Il est possible que plusieurs choses se trouvent dans ce répertoire, par exemple, avoir plusieurs versions du même projet dans différentes chaînes d’outils. On peut vouloir avoir ou tester son projet dans GCC, Keil, IAR, Visual Studio Code ou bien d’autres environnements. Deuxièmement, il peut y avoir différentes références de produits qui utilisent une base de code commune et il existe différents projets définis pour les paramètres spécifiques de chaque produit. Dans tous les cas, garder ces éléments ensemble au même endroit empêche la structure du ou des projets de devenir trop désordonnée.

Le dossier Tests en est un qui n’aurait pas existé dans mon flux organisationnel il y a quelques années à peine. Je me suis rapidement poussé à adopter un processus de développement plus axé sur les tests (TDD) pour le micrologiciel. Tout mon code de cas de test est stocké dans ce répertoire. La structure exacte varie un peu, mais un bon point de départ est le projet cpputest-start-project de James Grenning sur Github. Les tests automatisés sont devenus si importants que chaque projet devrait inclure cela (et gérer et maintenir activement les tests).

Enfin, il y a le dossier Utilitaires. Tout comme avec le dossier middleware, il s’agit souvent d’un dossier de sous-modules Git qui donnent accès à divers outils open source. Par exemple, je lie souvent cpputest dans ce dossier. De cette façon, un nouveau développeur peut extraire le projet et initialiser les sous-modules et être en grande partie opérationnel. (J’ai également utilisé Docker pour cette tâche mais c’est une histoire pour une autre fois). Parfois, j’inclus le programme d’installation de divers outils s’ils ne sont pas open source. Parfois, je place même du code d’interface personnalisé écrit en Python dans ce dossier.

Conclusion

Avoir un projet bien organisé peut aider les développeurs à trouver facilement leur chemin dans le code et les aider à maintenir facilement ce code au fil du temps. L’inclusion de dossiers comme test implique également que les développeurs doivent écrire des cas de test. Il y a certainement d’autres répertoires qui pourraient être ajoutés à ma liste, par exemple un dossier de pilotes. Ces types de dossiers relèvent souvent de la catégorie des bibliothèques middleware dans la plupart des chaînes d’outils actuelles. Dans tous les cas, j’espère que cela vous aidera à vous faire une idée de la façon d’organiser facilement vos projets de firmware ainsi que certains processus de meilleures pratiques.