Zephyrnet-Logo

3 Git-Tipps zur Verbesserung der Software für medizinische Geräte

Datum:

Git-Tipps für medizinische GeräteSoftware für medizinische Geräte ist sehr vielfältig. Von Low-Level-Firmware-Treibern über Datenanalyse und KI bis hin zu Webentwicklung und Cybersicherheit sind die Technologien vielfältig und jede hat ihre eigenen Besonderheiten.
Bei all dieser Vielfalt ist eine Technologie allgegenwärtig: Git! Ihr Versionskontrollsystem (VCS) ist immer vorhanden und es lohnt sich, sich etwas Zeit zu nehmen, um es wirklich kennenzulernen. Wenn Sie über die Grundlagen hinausgehen, hilft Ihnen Git dabei, Software für medizinische Geräte schneller zu entwickeln, ohne die Rückverfolgbarkeit zu beeinträchtigen.

Software für medizinische Geräte erfordert zusätzliche Verantwortungsebenen, die über die üblichen Best Practices für Software hinausgehen. Ein Beispiel betrifft das Konfigurationsmanagement und die Aufzeichnung der Änderungen zwischen Softwareversionen, was bedeutet, dass eine klare Historie der Softwareentwicklung geführt werden muss.

Sie müssen etwas Zeit investieren, um Ihr eigenes mentales Modell für die Funktionsweise von Git zu erstellen, um das Beste daraus zu machen. Lassen Sie uns auf drei augenöffnende Erkenntnisse eingehen, die mir helfen, Git besser zu nutzen.

  1. Sie müssen nicht alles tun!

Im besten Fall geht Git aus dem Weg. Der Ort, an dem ich als Programmierer sein möchte, ist der „Code-Modus“ – wo ich den Überblick über die Zeit verliere, in der ich an einer neuen Funktion, einer Fehlerbehebung oder vielleicht auch an beidem arbeite. Hier besteht ein Spannungsverhältnis zwischen dem Schreiben des Codes und dem Erstellen einer sinnvollen Historie für zukünftige Prüfer. Das Letzte, was ich tun möchte, ist, meine Programmierung zu unterbrechen, um über VCS nachzudenken und darüber, wie Änderungen für einen Prüfer aussehen werden. Schließlich ist es eine gute Praxis, Commits klein und in sich geschlossen zu gestalten.

Angenommen, Sie haben sich beim Programmieren hinreißen lassen und ein paar unabhängige Änderungen vorgenommen, ohne sie zu übernehmen. Was machst du? Git trennt die „Arbeitskopie“, in der sich alle lokalen, nicht festgeschriebenen Änderungen befinden, vom „Staging-Bereich“, in dem Sie sich befinden hinzufügen Änderungen, die Sie übernehmen möchten.

Hier ist ein Beispiel, um zu veranschaulichen, wie Sie den Staging-Bereich verwenden, wenn Sie an einem Projekt mit einem SPI-Treiber, einem Anzeigetreiber und etwas Geschäftslogik arbeiten. Vielleicht sind die Quellen so organisiert:

|– Fahrer/
| |– spi.c
| |– spi.h
| |– Anzeige.c
| |– display.h
|– App/
| |– ca.c
|– …

Sie haben mit Freude an der Entwicklung Ihres SPI-Treibers gearbeitet, aber unterwegs haben Sie eine Idee, wie Sie Seiten auf Ihrem Display flüssiger darstellen können. Sie fügen ein paar Änderungen an Ihrem Anzeigetreiber ein, und jetzt haben Sie Änderungen sowohl in spi.c als auch in display.c. Wenn Sie alles auf einmal festschreiben („git add .“), verwirren Sie Änderungen, die nichts miteinander zu tun haben, was keine gute Git-Hygiene darstellt. Was wäre, wenn Sie einen Fehler einschleusen würden, während Sie versuchen, mit Ihrem Bildschirmtreiber clever umzugehen? Sie müssten diesen Patch zurücksetzen und dann die Teile auswählen, die nur mit SPI zu tun haben, um zu verhindern, dass sie gelöscht werden. Knorrig!

Verwenden Sie stattdessen die leistungsstarken Tools von Git Bühnenbereich um atomare Änderungen aus der Arbeitskopie herauszuarbeiten. Indem Sie zunächst nur Änderungen im Zusammenhang mit SPI hinzufügen und diese festschreiben, dann Durch das Hinzufügen von Änderungen am Anzeigetreiber haben Sie zwei Commits erstellt, die nett und unabhängig sind, aber aus derselben Arbeitskopie stammen!

git add Drivers/spi.c
git commit …
git add Drivers/display.c
git commit …

Beachten Sie, dass Sie nicht darüber nachdenken müssen, wie Ihr nächster Commit aussehen wird Bevor Sie nehmen die Änderungen vor. Stattdessen können Sie später mit dem Codieren fortfahren und Commits aus Ihren Änderungen erstellen! Git bestraft Sie nicht dafür, dass Sie sich in der Programmierung verlieren; Es hilft Ihnen, die Scherben nach einer koffeinhaltigen Fehlerbehebungssitzung wieder in Ordnung zu bringen.

Wenn die atomaren Änderungen auf einzelne Dateien beschränkt sind, ist es einfach, unabhängige Änderungen in verschiedene Commits einzubinden. Was aber, wenn es Änderungen in app.c gibt, die für gelten? beide SPI und Anzeigeänderungen? Wieder einmal hat Git alles im Griff.

  1. Einzelne Änderungen mit –patch hinzufügen

Sich über den Staging-Bereich zu informieren, ist eine Sache, aber zu erkennen, dass man durch Änderungen filtern kann innerhalb einer einzigen Datei eröffnet eine neue Welt der Möglichkeiten. Der Befehl „git add“ verfügt über die Option „–patch/-p“, die Sie Stück für Stück durch die Dateien führt, die Sie ihm übergeben haben, sodass Sie nur das abrufen können, was Sie für den Commit benötigen. Sie können mit Ergänzungen, der Aufteilung bereitgestellter Abschnitte und sogar der manuellen Auswahl von Zeilen, indem Sie diese bearbeiten, sehr spezifisch vorgehen. Wenn Sie Commits Stück für Stück erstellen, haben Sie den Vorteil, dass Sie wahrscheinlich eine bessere Commit-Nachricht schreiben, weil die Änderungen noch frisch im Kopf sind.

Tipp: Verwenden Sie die Konfigurationsoption „singleKey“. um die Navigation durch Hunks zu beschleunigen (git config –global Interactive.singleKey true). Damit dies funktioniert, benötigen Sie das Modul Term::ReadKey.

Die Option „–patch“ ist für mehr Befehle als nur „Hinzufügen“ verfügbar. Möchten Sie einen besonders passiv-aggressiven Kommentar aus einer Datei entfernen? „git reset –patch“! Oder möchten Sie nur ein oder zwei Zeilen für später in Ihrem Vorrat speichern? „git stash –patch“!

  1. Git-Verlauf

"Die Geschichte wird nett zu mir sein, denn ich habe vor, sie zu schreiben."

  • Sie eröffnen Ihre nächste PR

Da Sie nun ganz einfach atomare Commits zusammenstellen können, können Sie mit Git History das Gesamtbild der Geschichte betrachten, die Sie erzählen. Sie arbeiten zum Beispiel seit ein paar Tagen an einer neuen Funktion nach dem bekannten „Zwei Schritte vorwärts, ein Schritt zurück“-Muster, bei dem neue Funktionen in die Software integriert werden.

Sie führen ein neues Modul in Ihre Codebasis ein, verursachen aber versehentlich an anderer Stelle einen Fehler. Sie beheben also diesen Fehler und begehen einen Commit diejenigen Änderungen. Dieses Muster, neuen Code einzuführen und dann zuvor eingeführte Fehler oder Regressionen zu beheben, bleibt noch eine Weile bestehen. Schließlich haben Sie alles gepatcht und Ihre glänzende neue Funktion kann wieder in den „Hauptzweig“ integriert werden.

Vielleicht sieht der Feature-Zweig in etwa so aus:

$ git log –oneline –graph feature_branch
* (feature_branch) Problem mit Grenzfällen behoben.
* Anzeigetreiber umgestalten.
* Seitenweise Rendering-Verbesserungen.
* Die Anzeige wird Seite für Seite gerendert.
* (hauptsächlich) …

Wenn Sie diesen Zweig einbinden, trägt er den gesamten Verlauf mit sich. Das ist Geschichte niemand kümmert sich darum. Wenn Sie in fünf Jahren den Projektverlauf überprüfen, wird sich niemand mehr um Fehler kümmern, die in einem Commit eingeführt und im nächsten Commit behoben wurden. Sie werden sich während der Entwicklung um diese Commits als Kontrollpunkte kümmern, aber sobald alles funktioniert, müssen Sie sich nicht mehr daran erinnern, wie Sie dorthin gelangt sind. Rezensenten möchten nur den minimalen Änderungssatz sehen, der das Projekt vom Pre-Feature zum Post-Feature bringt, vielleicht mit ein paar wichtigen Meilensteinen dazwischen. Wie gehen Sie damit um? Sie könnten warten, bis die Funktion zu 5 % geschrieben und funktionsfähig ist, aber das ist eine gefährliche Situation, wenn Sie sich mitten in der Entwicklung befinden.

Git kommt mit „git rebase –interactive“ erneut zur Rettung und ermöglicht es Benutzern, den Commit-Verlauf interaktiv zu bearbeiten. Sie können Commits aus dem Verlauf neu anordnen, bearbeiten, löschen oder „unterdrücken“. Beachten Sie das interaktive Rebasing Ändert Ihren Git-Verlauf. Das macht sie potenziell sehr gefährlich. Wenn Sie nicht aufpassen, können Sie Ihr Repo hier ernsthaft beschädigen.

Ich empfehle, den Git-Remote-Host so einzurichten, dass Entwicklern nur „Rewind“-Berechtigungen für Zweige gewährt werden, die einer Vorlage wie „dev/*“ entsprechen. Dadurch bleiben der Hauptzweig und andere wichtige Kontrollpunkte intakt, egal was Ihre Entwickler tun. In meinen Projekten ist „Zurückspulen“ nur für Zweige zulässig, die mit „tmp/*“ und „dev/*“ übereinstimmen. Sobald sich die Änderungen auf einen gemeinsam genutzten Funktionszweig oder „Hauptzweig“ beziehen, ändert sich der Verlauf nicht mehr! Wenn möglich, führen Sie diese Idee zu einer logischen Konsequenz, indem Sie alle Pushs an den „Hauptzweig“ verbieten, es sei denn, sie stammen von einer akzeptierten Pull-Anfrage.

Schauen wir uns noch einmal unseren Beispiel-Feature-Zweig an. Hier sehen Sie, wie der Verlauf nach einer Bereinigung aussieht:

$ git rebase –interactive main..feature_branch
$ git log –oneline –graph feature_branch
* (feature_branch) Refactor-Anzeigetreiber.
* Die Anzeige wird Seite für Seite gerendert.
* (hauptsächlich) …

Die beiden Bugfix-Commits wurden in ihren übergeordneten Commits zusammengefasst. Dies sorgt für einen schönen, sauberen Verlauf, der deutlich zeigt, dass eine neue Funktion in die Codebasis eingeführt wird, ohne den Lärm von Funktionsentwicklungsfehlern.

Das Führen einer zuverlässigen Historie ist ein Grund für den Einsatz eines VCS – das Konfigurationsmanagement ist eine wichtige Anforderung der IEC 62304 für Software für medizinische Geräte. Verwenden Sie interaktives Rebasing, um Ihren Verlauf klar zu machen und leicht zu sehen, wie sich die Software zwischen zwei Releases weiterentwickelt hat.

Fazit

Die Aufrechterhaltung einer klaren Historie ist ein entscheidender Aspekt der Softwareentwicklung für medizinische Geräte. Bei der Entwicklung spannender und weitreichender Funktionalitäten für Medizinprodukte sorgen der leistungsstarke Staging-Bereich und die interaktiven Rebasing-Funktionen von Git dafür, dass Sie schnell vorankommen und weniger kaputt gehen.

Bild: Adobe Stock

Levi Puckett ist ein Software IngenieurIn bei Starfish Medical. Mit einem Abschluss in Elektrotechnik schließt er die Lücke zwischen Elektronik und hochwertiger Embedded-Software. Levi arbeitet auf allen Ebenen der Software für medizinische Geräte und unterstützt Unternehmen bei der Entwicklung effektiver, innovativer und sicherer Software für ihre neuen medizinischen Geräte.



Teile das…

spot_img

Neueste Intelligenz

spot_img