Software voor medische apparatuur is zeer divers. Van low-level firmware-drivers tot data-analyse en AI, tot webontwikkeling en cyberbeveiliging, de technologieën zijn zeer uiteenlopend, elk met hun eigen eigenaardigheden.

In al deze verscheidenheid is één technologie alomtegenwoordig: Git! Uw versiebeheersysteem (VCS) is er altijd, en het is de moeite waard om even de tijd te nemen om het echt te leren kennen. Als je verder gaat dan de basis, zal Git je helpen om sneller software voor medische apparatuur te ontwikkelen zonder dat dit ten koste gaat van de traceerbaarheid.

Software voor medische apparatuur vereist extra lagen van verantwoordelijkheid die verder gaan dan de gebruikelijke best practices op het gebied van software. Een voorbeeld heeft betrekking op configuratiebeheer en het bijhouden van wat er tussen softwareversies is veranderd, wat inhoudt dat er een duidelijke geschiedenis van de ontwikkeling van de software wordt bijgehouden.

Je moet wat tijd steken in het maken van je eigen mentale model voor hoe Git werkt, zodat je er het beste van kunt maken. Laten we in drie opzienbarende realisaties duiken die mij helpen Git beter te gebruiken.

1. Je hoeft niet alles te beloven!

Op zijn best gaat Git uit de weg. De plaats waar ik als programmeur wil zijn, is in de ‘codemodus’ – waar ik de tijd uit het oog verlies bij het hacken van een nieuwe functie, of het oplossen van bugs, of misschien beide. Er is hier een spanning tussen het schrijven van de code en het opbouwen van een zinvolle geschiedenis voor toekomstige recensenten. Het laatste dat ik wil doen is mijn programmering onderbreken om na te denken over VCS en hoe veranderingen eruit gaan zien voor een recensent. Het is tenslotte een goede gewoonte om commits klein en op zichzelf staand te maken.

Stel dat u zich laat meeslepen door programmeren en een paar niet-gerelateerde wijzigingen hebt aangebracht zonder dat u er ook maar één heeft doorgevoerd. Wat doe je? Git scheidt de “werkkopie” – waar alle lokale, niet-vastgelegde wijzigingen zijn – van de “staging area” – waar je toevoegen veranderingen die u wilt vastleggen.

Hier is een voorbeeld om te illustreren hoe u het verzamelgebied kunt gebruiken wanneer u aan een project werkt met een SPI-stuurprogramma, een beeldschermstuurprogramma en wat bedrijfslogica. Misschien zijn de bronnen als volgt georganiseerd:

U bent met veel plezier bezig geweest met het uitbouwen van uw SPI-stuurprogramma, maar onderweg komt u op een idee om pagina's soepeler op uw beeldscherm weer te geven. Je brengt een paar wijzigingen aan in je beeldschermstuurprogramma, en nu heb je wijzigingen in zowel spi.c als display.c. Als je het allemaal in één keer commit (“git add .”), dan verwar je veranderingen die niets met elkaar te maken hebben, wat geen goede git-hygiëne is. Wat als u een bug introduceert terwijl u slim probeert om te gaan met uw beeldschermstuurprogramma? Je zou deze patch moeten terugdraaien en vervolgens de onderdelen moeten uitkiezen die alleen verband houden met SPI om te voorkomen dat ze worden verwijderd. Lelijk!

Gebruik in plaats daarvan de krachtige Git verzamelplaats om atomaire veranderingen uit de werkkopie te halen. Door eerst alleen wijzigingen toe te voegen die verband houden met SPI en deze vast te leggen, harte door wijzigingen in het weergavestuurprogramma toe te voegen, heb je twee commits gemaakt die leuk en onafhankelijk zijn, maar die uit dezelfde werkkopie komen!

Merk op dat je niet hoeft na te denken over wat je volgende commit zal zijn vaardigheden jij brengt de wijzigingen aan. In plaats daarvan kun je later doorgaan met coderen en commits maken van je wijzigingen! Git straft je niet als je verdwaald raakt in het programmeren; het helpt je de stukken op te pakken na een sessie met het oplossen van problemen met cafeïne.

Wanneer de atomaire wijzigingen zijn gelokaliseerd in individuele bestanden, is het eenvoudig om onafhankelijke wijzigingen in verschillende commits te onderbrengen. Maar wat als er wijzigingen zijn in app.c die van toepassing zijn? zowel SPI- en weergavewijzigingen? Nogmaals, Git heeft het gedekt.

2. Individuele wijzigingen toevoegen met –patch

Leren over de verzamelplaats is één ding, maar beseffen dat je door de wijzigingen heen kunt filteren binnen één enkel bestand opent een nieuwe wereld van mogelijkheden. Het “git add” commando heeft een “–patch/-p” optie die je stuk voor stuk door de bestanden leidt die je eraan hebt doorgegeven, waardoor je alleen datgene kunt binnenhalen dat je nodig hebt voor de commit. Je kunt heel specifiek worden met toevoegingen, het splitsen van aanwezige stukken en zelfs het handmatig selecteren van lijnen door ze te bewerken. Een bonus van het stuk voor stuk bouwen van commits is dat je waarschijnlijk een beter commit-bericht zult schrijven, omdat de veranderingen vers in je geheugen zullen liggen.

Tip: gebruik de “singleKey” configuratieoptie om het navigeren door hunks sneller te maken (git config –global Interactive.singleKey true). Je hebt de Term::ReadKey-module nodig om dit te laten werken.

De optie “–patch” is beschikbaar voor meer opdrachten dan alleen “add”. Wilt u een bijzonder passief-agressieve opmerking uit een bestand verwijderen? “git reset –patch”! Of wil je slechts een paar regels in je voorraad bewaren voor later? "git stash-patch"!

3. Git-geschiedenis

‘De geschiedenis zal vriendelijk voor mij zijn, want ik ben van plan het te schrijven.’

• Jij, die je volgende PR opent

Nu je eenvoudig atomaire commits aan het samenstellen bent, kun je met Git history naar het grotere plaatje kijken van het verhaal dat je vertelt. U werkt bijvoorbeeld al een paar dagen aan een nieuwe functie in het bekende ‘twee stappen vooruit, één stap terug’-patroon van het inwerken van nieuwe functionaliteit in de software.

U introduceert een nieuwe module in uw codebase, maar veroorzaakt onbedoeld ergens anders een bug. Dus je repareert deze bug en legt je vast die veranderingen. Dit patroon van het introduceren van nieuwe code en het vervolgens repareren van bugs of regressies die je eerder hebt geïntroduceerd, blijft een tijdje bestaan. Eindelijk heb je alles gepatcht en is je glanzende nieuwe functie klaar om weer te worden samengevoegd in de “hoofd” branch.

Misschien ziet de feature branch er ongeveer zo uit:

Wanneer je deze tak samenvoegt, zal deze de hele geschiedenis met zich meedragen. Dat is de geschiedenis niemand boeit het. Als je over vijf jaar de geschiedenis van het project bekijkt, zal niemand zich meer druk maken over bugs die in de ene commit zijn geïntroduceerd en in de volgende commit zijn opgelost. Je zult deze commits belangrijk vinden als controlepunten tijdens de ontwikkeling, maar zodra alles werkt, hoef je je niet meer te herinneren hoe je daar bent gekomen. Recensenten willen alleen de minimale wijzigingen zien die het project van pre-feature naar post-feature brengen, misschien met een paar belangrijke mijlpalen daartussenin. Dus hoe ga je hiermee om? Je zou kunnen wachten met het plegen van iets totdat de functie 5% geschreven en werkend is, maar dat is een gevaarlijke plek halverwege de ontwikkeling.

Git komt opnieuw te hulp met “git rebase –interactive”, waarmee gebruikers de commit-geschiedenis interactief kunnen bewerken. Je kunt commits uit de geschiedenis opnieuw rangschikken, bewerken, verwijderen of “squashen”. Merk op dat interactief rebasen verandert je Git-geschiedenis. Dat maakt ze potentieel erg gevaarlijk. U kunt uw repository hier ernstig beschadigen als u niet oppast.

Ik raad aan om de git remote host zo in te stellen dat alleen ‘rewind’-rechten worden toegestaan ​​aan ontwikkelaars op branches die overeenkomen met een sjabloon als ‘dev/*’. Hierdoor blijven de hoofdtak en andere belangrijke controlepunten intact, ongeacht wat uw ontwikkelaars doen. In mijn projecten is “terugspoelen” alleen toegestaan ​​op vertakkingen die overeenkomen met “tmp/*” en “dev/*”. Zodra de wijzigingen zich op een gedeelde feature branch of “main” bevinden, verandert de geschiedenis niet meer! Breng dit idee, waar mogelijk, tot zijn logische conclusie door alle pushes naar de “hoofd” branch te verbieden, tenzij deze afkomstig zijn van een geaccepteerd pull-verzoek.

Als we onze voorbeeldfunctiebranch opnieuw bekijken, ziet u hier hoe de geschiedenis eruit ziet na een opschoning:

De twee bugfix-commits zijn samengevoegd in hun bovenliggende commits. Dit zorgt voor een mooie, schone geschiedenis die duidelijk laat zien dat een nieuwe functie in de codebase wordt geïntroduceerd, zonder het geluid van functieontwikkelingsfouten.

Het bijhouden van een betrouwbare geschiedenis is één reden om een ​​VCS te gebruiken – configuratiebeheer is een belangrijke vereiste van IEC 62304 voor software voor medische apparatuur. Gebruik interactief rebasen om uw geschiedenis duidelijk te maken en eenvoudig te zien hoe de software zich tussen twee releases heeft ontwikkeld.

Conclusie

Het bijhouden van een duidelijke geschiedenis is een cruciaal aspect van de ontwikkeling van software voor medische apparatuur. Bij het ontwikkelen van opwindende en uitgebreide functionaliteit voor producten voor medische apparaten, zorgen Git's krachtige staging-gebied en interactieve rebasing-functies ervoor dat je snel in beweging blijft en minder kapot gaat.

Afbeelding: Adobe Stock

Levi Puckett is een Software Engineer bij Starfish Medical. Met een diploma Elektrotechniek overbrugt hij de kloof tussen elektronica en hoogwaardige embedded software. Levi werkt op alle niveaus van software voor medische apparatuur en helpt bedrijven effectieve, innovatieve en veilige software te ontwikkelen voor hun nieuwe medische apparaten.



• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://starfishmedical.com/blog/3-git-tips-to-improve-medical-device-software/