Les logiciels de dispositifs médicaux sont très diversifiés. Des pilotes de micrologiciels de bas niveau à l’analyse des données et à l’IA, en passant par le développement Web et la cybersécurité, les technologies sont très variées, chacune avec ses propres particularités.

Dans toute cette variété, une technologie est omniprésente : Git ! Votre système de contrôle de version (VCS) est toujours là et cela vaut la peine de prendre un peu de temps pour vraiment le connaître. Si vous allez au-delà des bases, Git vous aidera à développer plus rapidement des logiciels pour dispositifs médicaux sans sacrifier la traçabilité.

Les logiciels de dispositifs médicaux nécessitent des niveaux de responsabilité supplémentaires au-delà des meilleures pratiques logicielles habituelles. Un exemple est lié à la gestion de la configuration et à la conservation d’un enregistrement de ce qui a changé entre les versions du logiciel, ce qui implique de conserver un historique clair du développement du logiciel.

Vous devez consacrer un peu de temps à créer votre propre modèle mental sur le fonctionnement de Git afin d'en tirer le meilleur parti. Plongeons dans trois réalisations révélatrices qui m’aident à mieux utiliser Git.

1. Vous n’êtes pas obligé de tout engager !

Au mieux, Git s'écarte du chemin. L'endroit où je veux être en tant que programmeur est en « mode code » – où je perds la notion du temps passé à pirater une nouvelle fonctionnalité, ou à corriger un bug, ou peut-être les deux. Il y a ici une tension entre l'écriture du code et la construction d'un historique sensé pour les futurs réviseurs. La dernière chose que je veux faire est d'interrompre ma programmation pour réfléchir à VCS et à la manière dont les changements vont être recherchés par un réviseur. Après tout, c’est une bonne pratique de faire des commits petits et autonomes.

Supposons que vous vous laissiez emporter par la programmation et que vous ayez apporté quelques modifications sans rapport sans les valider. Que fais-tu? Git sépare la « copie de travail » – où se trouvent toutes les modifications locales non validées – de la « zone de transit » – où vous ajouter les changements que vous souhaitez engager.

Voici un exemple pour illustrer comment utiliser la zone de préparation lorsque vous travaillez sur un projet avec un pilote SPI, un pilote d'affichage et une logique métier. Peut-être que les sources sont organisées comme ceci :

Vous avez construit avec plaisir votre pilote SPI, mais en chemin, vous avez une idée pour rendre les pages plus fluides sur votre écran. Vous apportez quelques modifications à votre pilote d'affichage et vous avez maintenant des modifications à la fois dans spi.c et display.c. Si vous validez tout en même temps (« git add . »), vous mélangez des changements qui ne sont pas liés, ce qui n'est pas une bonne hygiène git. Et si vous introduisiez un bug en essayant d'être intelligent avec votre pilote d'affichage ? Vous devrez annuler ce correctif, puis sélectionner les parties qui sont uniquement liées à SPI pour éviter qu'elles ne soient supprimées. Génial !

Utilisez plutôt le puissant outil de Git zone de transit pour extraire les modifications atomiques de la copie de travail. En ajoutant d'abord uniquement les modifications liées à SPI, en les validant, puis en ajoutant les modifications du pilote d'affichage, vous avez créé deux commits qui sont jolis et indépendants, mais qui proviennent de la même copie de travail !

Remarquez que vous n'avez pas à penser à ce que sera votre prochain commit before vous effectuez les modifications. Au lieu de cela, vous pouvez revenir au codage et créer des validations à partir de vos modifications plus tard ! Git ne vous punit pas si vous vous perdez dans la programmation ; cela vous aide à recoller les morceaux après une séance de correction de bugs alimentée par la caféine.

Lorsque les modifications atomiques sont localisées dans des fichiers individuels, il est facile d'intégrer des modifications indépendantes dans différentes validations. Mais que se passe-t-il s'il y a des changements dans app.c qui s'appliquent à tous les deux Modifications du SPI et de l'affichage ? Encore une fois, Git s’en occupe.

2. Ajout de modifications individuelles avec –patch

Connaître la zone de transit est une chose, mais réaliser que vous pouvez filtrer les modifications depuis dans un seul fichier ouvre un nouveau monde de capacités. La commande « git add » a une option « –patch/-p » qui vous guide morceau par morceau à travers les fichiers que vous lui avez transmis, vous permettant d'extraire uniquement ce dont vous avez besoin pour la validation. Vous pouvez être très précis avec les ajouts, diviser les morceaux fournis et même sélectionner les lignes à la main en les modifiant. Un avantage de la création de commits morceau par morceau est que vous écrirez probablement un meilleur message de commit, car les changements seront frais dans votre esprit.

Astuce : utilisez le Option de configuration « singleKey » pour rendre la navigation plus rapide (git config –global interactive.singleKey true). Vous aurez besoin du module Term::ReadKey pour que cela fonctionne.

L'option « –patch » est disponible sur plus de commandes que simplement « ajouter ». Vous souhaitez supprimer un commentaire particulièrement passif et agressif d'un fichier ? « git réinitialiser –patch » ! Ou souhaitez-vous enregistrer juste une ligne ou deux dans votre réserve pour plus tard ? "git stash-patch" !

3. Historique de Git

"L'histoire me sera gentille, car j'ai l'intention de l'écrire."

• Vous, ouvrez votre prochain PR

Maintenant que vous rassemblez facilement des commits atomiques, vous pouvez avoir une vue d’ensemble de l’histoire que vous racontez avec l’historique de Git. Par exemple, vous travaillez sur une nouvelle fonctionnalité depuis quelques jours selon le modèle familier « deux pas en avant, un pas en arrière » consistant à intégrer de nouvelles fonctionnalités dans le logiciel.

Vous introduisez un nouveau module dans votre base de code, mais provoquez par inadvertance un bug ailleurs. Alors, vous corrigez ce bug et validez ceux changements. Cette tendance consistant à introduire du nouveau code puis à corriger les bugs ou les régressions que vous avez introduits précédemment se poursuit pendant un certain temps. Enfin, vous avez tout corrigé et votre nouvelle fonctionnalité brillante est prête à être fusionnée dans la branche « principale ».

Peut-être que la branche des fonctionnalités ressemble un peu à ceci :

Lorsque vous fusionnerez cette branche, elle emportera avec elle tout cet historique. C'est l'histoire qui personne ne s'en soucie. Dans 5 ans, lorsque vous examinerez l’historique du projet, personne ne se souciera des bogues introduits lors d’un commit et corrigés lors du commit suivant. Vous vous soucierez de ces commits comme de points de contrôle pendant le développement, mais dès que tout fonctionnera, vous n'aurez plus besoin de vous rappeler comment vous y êtes arrivé. Les évaluateurs veulent simplement voir l'ensemble minimal de modifications qui fait passer le projet de la pré-fonctionnalité à la post-fonctionnalité, peut-être avec quelques étapes importantes entre les deux. Alors, comment gérer cela ? Vous pouvez attendre pour valider quoi que ce soit jusqu'à ce que la fonctionnalité soit écrite et fonctionnelle à 100 %, mais c'est un moment périlleux à mi-chemin du développement.

Git vient à nouveau à la rescousse avec « git rebase –interactive », permettant aux utilisateurs de modifier de manière interactive l'historique des validations. Vous pouvez réorganiser, modifier, supprimer ou « écraser » les commits de l'historique. Notez que le rebasage interactif change votre historique Git. Cela les rend potentiellement très dangereux. Vous pouvez gravement endommager votre dépôt ici si vous ne faites pas attention.

Je recommande de configurer l'hôte distant git pour autoriser uniquement les autorisations de « rembobinage » aux développeurs sur les branches qui correspondent à un modèle tel que « dev/* ». Cela gardera la branche principale et les autres points de contrôle importants intacts, peu importe ce que font vos développeurs. Sur mes projets, le « rembobinage » n'est autorisé que sur les branches correspondant à « tmp/* » et « dev/* ». Une fois les modifications effectuées sur une branche de fonctionnalité partagée ou « principale », l’historique ne changera plus ! Dans la mesure du possible, poussez cette idée jusqu'à sa conclusion logique en interdisant tout push vers la branche « principale » à moins qu'il ne provienne d'une pull request acceptée.

En revisitant notre exemple de branche de fonctionnalités, voici à quoi ressemble l'historique après un nettoyage :

Les deux commits de correction de bogues ont été écrasés dans leurs commits parents. Cela donne un historique clair et agréable qui montre clairement qu'une nouvelle fonctionnalité est introduite dans la base de code, sans le bruit des erreurs de développement de fonctionnalités.

Conserver un historique fiable est l'une des raisons d'utiliser un VCS : la gestion de la configuration est une exigence clé de la norme CEI 62304 pour les logiciels de dispositifs médicaux. Utilisez le rebasage interactif pour rendre votre historique clair et voir facilement comment le logiciel a progressé entre deux versions.

Conclusion

Le maintien d’un historique clair est un aspect essentiel du développement de logiciels de dispositifs médicaux. Lors du développement de fonctionnalités passionnantes et étendues pour les produits de dispositifs médicaux, la puissante zone de préparation de Git et les fonctionnalités de rebasage interactives vous permettront d'avancer rapidement et de moins casser.

Image : Adobe Stock

Levi Puckett est un Software Engineer chez Starfish Médical. Diplômé en génie électrique, il comble le fossé entre l'électronique et les logiciels embarqués de haute qualité. Levi travaille à tous les niveaux des logiciels de dispositifs médicaux, aidant les entreprises à développer des logiciels efficaces, innovants et sûrs pour leurs nouveaux dispositifs médicaux.



• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://starfishmedical.com/blog/3-git-tips-to-improve-medical-device-software/