Programvare for medisinsk utstyr er svært variert. Fra lav-nivå firmware-drivere til dataanalyse og AI, til nettutvikling og cybersikkerhet, teknologiene spenner vidt, hver med sine egne særheter.

I all denne variasjonen er én teknologi allestedsnærværende: Git! Ditt versjonskontrollsystem (VCS) er alltid der, og det er verdt å bruke litt tid på å virkelig bli kjent med det. Hvis du går utover det grunnleggende, vil Git hjelpe deg med å utvikle programvare for medisinsk utstyr raskere uten å ofre sporbarhet.

Programvare for medisinsk utstyr krever ekstra lag med ansvarlighet utover de vanlige beste praksisene for programvare. Et eksempel er knyttet til konfigurasjonsadministrasjon og å holde oversikt over hva som endret seg mellom programvareversjoner, noe som innebærer å holde en klar historikk over programvarens utvikling.

Du må bruke litt tid på å lage din egen mentale modell for hvordan Git fungerer for å få mest mulig ut av det. La oss dykke ned i tre øyeåpnende erkjennelser som hjelper meg å bruke Git bedre.

1. Du trenger ikke forplikte deg til alt!

På sitt beste kommer Git ut av veien. Stedet jeg ønsker å være som programmerer er i "kodemodus" - hvor jeg mister oversikten over tid som hacker bort en ny funksjon, eller feilretting, eller kanskje begge deler. Det er en spenning her mellom å få skrevet koden og å bygge en fornuftig historie for fremtidige anmeldere. Det siste jeg vil gjøre er å avbryte programmeringen min for å tenke på VCS og hvordan endringer kommer til å se ut for en anmelder. Tross alt er det god praksis å gjøre forpliktelser små og selvstendige.

Si at du lar deg rive med programmeringen og har gjort et par urelaterte endringer uten å forplikte noen av dem. Hva gjør du? Git skiller "arbeidskopien" - der alle lokale, uforpliktede endringer er - fra "oppsamlingsområdet" - der du legge til endringer du ønsker å bli forpliktet til.

Her er et eksempel for å illustrere hvordan du bruker oppstillingsområdet når du jobber med et prosjekt med en SPI-driver, en skjermdriver og litt forretningslogikk. Kanskje er kildene organisert slik:

Du har med glede bygget ut SPI-driveren din, men underveis har du en idé for å gjengi sider mer jevnt på skjermen. Du slipper inn noen få endringer i skjermdriveren din, og nå har du endringer i både spi.c og display.c. Hvis du begår alt på en gang ("git add .") så floker du sammen endringer som ikke er relatert, noe som ikke er god git-hygiene. Hva om du introduserte en feil mens du prøvde å være smart med skjermdriveren? Du må tilbakestille denne oppdateringen og deretter velge ut delene som bare er relatert til SPI for å redde dem fra å bli droppet. Kjipt!

Bruk i stedet Gits kraftige scene område å erte ut atomendringer fra arbeidskopien. Ved å bare legge til endringer relatert til SPI først, forplikte disse, deretter ved å legge til skjermdriverendringer, har du opprettet to commits som er fine og uavhengige, men som kommer fra samme arbeidskopi!

Legg merke til hvordan du ikke trenger å tenke på hva din neste forpliktelse vil være før du du gjør endringene. I stedet kan du gå tilbake til koding og bygge forpliktelser fra endringene dine senere! Git straffer deg ikke for å gå deg vill i programmeringen; det hjelper deg å plukke opp bitene etter en koffeinfylt feilrettingsøkt.

Når atomendringene er lokalisert til individuelle filer, er det enkelt å erte uavhengige endringer i forskjellige commits. Men hva om det er endringer i app.c som gjelder både SPI og skjermendringer? Nok en gang har Git det dekket.

2. Legge til individuelle endringer med –patch

Å lære om oppsetningsområdet er én ting, men å innse at du kan filtrere gjennom endringer fra i en enkelt fil åpner en ny verden av kapasitet. "git add"-kommandoen har et "–patch/-p"-alternativ som tar deg stykke for stykke gjennom filene du har sendt til den, slik at du bare kan trekke inn det du trenger for commit. Du kan bli veldig spesifikk med tillegg, dele opp medfølgende hunks og til og med håndplukke linjer ved å redigere dem. En bonus med å bygge forpliktelser stykke for stykke er at du sannsynligvis vil skrive en bedre commit-melding, fordi endringene vil være friskt i minnet.

Tips: bruk "singleKey" konfigurasjonsalternativ for å gjøre navigeringshunk raskere (git config –global interactive.singleKey true). Du trenger Term::ReadKey-modulen for at dette skal fungere.

Alternativet "–patch" er tilgjengelig på flere kommandoer enn bare "legg til". Vil du kaste en spesielt passiv aggressiv kommentar fra en fil? "git reset -patch"! Eller vil du bare lagre en linje eller to i oppbevaringen til senere? "git stash -patch"!

3. Git-historie

"Historien vil være snill mot meg, for jeg har tenkt å skrive den."

• Du, åpner din neste PR

Nå som du enkelt setter sammen atomforpliktelser, kan du se på det større bildet av historien du forteller med Git-historien. For eksempel har du jobbet med en ny funksjon i et par dager i det velkjente "to skritt fremover, ett skritt tilbake"-mønsteret med å jobbe ny funksjonalitet inn i programvaren.

Du introduserer en ny modul til kodebasen din, men forårsaker utilsiktet en feil et annet sted. Så du fikser denne feilen og forplikter deg De Endringer. Dette mønsteret med å introdusere ny kode og deretter fikse feil eller regresjoner du tidligere introduserte fortsetter en stund. Endelig har du lappet det hele og den skinnende nye funksjonen din er klar til å bli slått sammen tilbake til "hoved"-grenen.

Kanskje funksjonsgrenen ser litt slik ut:

Når du slår sammen denne grenen, vil den bære all denne historien med seg. Det er historie det ingen bryr seg om. Om 5 år når du gjennomgår prosjektets historie, vil ingen bry seg om feil som ble introdusert i én commit og fikset i neste commit. Du vil bry deg om disse forpliktelsene som sjekkpunkter under utviklingen, men så snart alt fungerer, trenger du ikke å huske hvordan du kom dit. Anmeldere vil bare se det minimale endringssettet som får prosjektet fra pre-feature til post-feature, kanskje med et par viktige milepæler i mellom. Så hvordan takler du dette? Du kan vente med å forplikte deg til funksjonen er 100 % skrevet og fungerer, men det er et farlig sted å være midtveis i utviklingen.

Git kommer til unnsetning igjen med "git rebase –interactive", som lar brukere interaktivt redigere commit-historikk. Du kan omorganisere, redigere, slippe eller "squash" forpliktelser fra historien. Merk at interaktiv rebasing endrer Git-historikken din. Det gjør dem potensielt svært farlige. Du kan alvorlig skade repoen din her hvis du ikke er forsiktig.

Jeg anbefaler å sette opp git-fjernverten til å bare tillate "spol tilbake"-tillatelser til utviklere på grener som samsvarer med en mal som "dev/*". Dette vil holde hovedgrenen og andre viktige sjekkpunkter intakte uansett hva utviklerne dine gjør. På mine prosjekter er "spoling tilbake" kun tillatt på grener som matcher "tmp/*" og "dev/*". Når endringene er på en delt funksjonsgren eller "hoved", vil ikke historien endres lenger! Der det er mulig, ta denne ideen til sin logiske konklusjon ved å forby alle push til "hoved"-grenen med mindre de kommer fra en akseptert pull-forespørsel.

Ved å gå tilbake til vår eksempelfunksjonsgren, her er hvordan historien ser ut etter en opprydding:

De to feilrettingsbekreftelsene ble klemt inn i foreldrebekreftelsene deres. Dette gir en fin ren historie som tydelig viser en ny funksjon som blir introdusert til kodebasen, uten støy fra funksjonsutviklingsfeil.

Å holde en pålitelig historikk er en grunn til å bruke en VCS – konfigurasjonsadministrasjon er et nøkkelkrav i IEC 62304 for programvare for medisinsk utstyr. Bruk interaktiv rebasing for å gjøre historikken din klar og enkel å se hvordan programvaren utviklet seg mellom to utgivelser.

konklusjonen

Å opprettholde en klar historikk er et kritisk aspekt ved utvikling av programvare for medisinsk utstyr. Når du utvikler spennende og omfattende funksjonalitet for produkter for medisinsk utstyr, vil Gits kraftige iscenesettelsesområde og interaktive rebasing-funksjoner holde deg i bevegelse raskt og bryte mindre.

Bilde: Adobe Stock

Levi Puckett er en Software Engineer hos Starfish Medical. Med en grad i elektroteknikk bygger han bro mellom elektronikk og innebygd programvare av høy kvalitet. Levi jobber på alle nivåer av programvare for medisinsk utstyr, og hjelper bedrifter med å utvikle effektiv, innovativ og sikker programvare for deres nye medisinske utstyr.



• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://starfishmedical.com/blog/3-git-tips-to-improve-medical-device-software/