Tıbbi cihaz yazılımı çok çeşitlidir. Düşük seviyeli ürün yazılımı sürücülerinden veri analizine ve yapay zekaya, web geliştirme ve siber güvenliğe kadar teknolojiler geniş bir yelpazeye sahiptir ve her birinin kendine has özellikleri vardır.

Tüm bu çeşitliliğin içinde tek bir teknoloji her yerde mevcut: Git! Sürüm kontrol sisteminiz (VCS) her zaman oradadır ve onu gerçekten tanımak için biraz zaman ayırmaya değer. Temel bilgilerin ötesine geçerseniz Git, izlenebilirlikten ödün vermeden tıbbi cihaz yazılımını daha hızlı geliştirmenize yardımcı olacaktır.

Tıbbi cihaz yazılımı, olağan yazılım en iyi uygulamalarının ötesinde ekstra sorumluluk katmanları gerektirir. Bunun bir örneği, konfigürasyon yönetimi ve yazılım sürümleri arasında nelerin değiştiğinin kaydının tutulmasıyla ilgilidir; bu, yazılımın gelişiminin net bir geçmişinin tutulması anlamına gelir.

Git'in bundan en iyi şekilde yararlanmak için nasıl çalıştığına dair kendi zihinsel modelinizi oluşturmak için biraz zaman ayırmanız gerekiyor. Git'i daha iyi kullanmama yardımcı olacak üç aydınlatıcı gerçeğe bakalım.

1. Her Şeyi Vazgeçmek Zorunda Değilsiniz!

En iyi ihtimalle Git yoldan çekilir. Bir programcı olarak olmak istediğim yer, yeni bir özelliği, hata düzeltmeyi veya belki her ikisini birden kullanarak zamanın nasıl geçtiğini anlamadığım "kod modu"dur. Kodun yazılması ile gelecekteki incelemeciler için mantıklı bir geçmiş oluşturulması arasında bir gerilim var. Yapmak istediğim son şey, VCS hakkında düşünmek ve değişikliklerin bir incelemeciyi nasıl arayacağını düşünmek için programlamamı yarıda kesmek. Sonuçta, taahhütleri küçük ve kendi kendine yeten hale getirmek iyi bir uygulamadır.

Diyelim ki programlamaya kendinizi kaptırdınız ve hiçbirini taahhüt etmeden ilgisiz birkaç değişiklik yaptınız. Ne yapıyorsun? Git, tüm yerel, kaydedilmemiş değişikliklerin bulunduğu "çalışan kopyayı", yaptığınız "hazırlama alanından" ayırır. eklemek yapılmasını istediğiniz değişiklikler.

Burada bir SPI sürücüsü, ekran sürücüsü ve bazı iş mantığıyla bir proje üzerinde çalışırken hazırlama alanının nasıl kullanılacağını gösteren bir örnek verilmiştir. Belki kaynaklar şu şekilde düzenlenmiştir:

Mutlu bir şekilde SPI sürücünüzü oluşturuyorsunuz, ancak yolda sayfaları ekranınızda daha sorunsuz bir şekilde işlemek için bir fikriniz var. Ekran sürücünüzde birkaç değişiklik yaptınız ve artık hem spi.c hem de display.c'de değişiklikleriniz var. Hepsini bir kerede işlerseniz (“git add.”), o zaman birbiriyle ilişkili olmayan değişiklikleri karıştırırsınız ve bu da git hijyeni açısından iyi değildir. Peki ya ekran sürücünüzü akıllıca kullanmaya çalışırken bir hata ortaya çıkarırsanız? Bu yamayı geri almanız ve ardından yalnızca SPI ile ilgili olan parçaları düşmekten kurtarmak için seçmeniz gerekir. Budaklı!

Bunun yerine Git'in güçlü özelliğini kullanın sahneleme alanı çalışma kopyasından atomik değişiklikleri çıkarmak için. Önce yalnızca SPI ile ilgili değişiklikleri ekleyerek, bunları taahhüt ederek, sonra Görüntü sürücüsü değişiklikleri ekleyerek, güzel ve bağımsız, ancak aynı çalışan kopyadan gelen iki işleme oluşturdunuz!

Bir sonraki taahhüdünüzün ne olacağını düşünmek zorunda kalmadığınıza dikkat edin önce değişiklikleri siz yapın. Bunun yerine, daha sonra kodlamaya geri dönebilir ve değişikliklerinizden taahhütler oluşturabilirsiniz! Git, programlamanın içinde kaybolduğunuz için sizi cezalandırmaz; kafeinle dolu bir hata düzeltme seansından sonra parçaları toplamanıza yardımcı olur.

Atomik değişiklikler ayrı dosyalara yerelleştirildiğinde, bağımsız değişiklikleri farklı taahhütlere dönüştürmek kolaydır. Peki ya app.c'de aşağıdakiler için geçerli olan değişiklikler varsa: her ikisi de SPI ve ekran değişiklikleri? Git bir kez daha konuyu ele aldı.

2. –patch ile Bireysel Değişiklikler Ekleme

Hazırlama alanı hakkında bilgi edinmek bir şeydir, ancak değişiklikler arasında filtre uygulayabileceğinizi fark etmek bir şeydir. tek bir dosya içinde yeni bir yetenek dünyasının kapılarını açar. "git add" komutu, size ilettiğiniz dosyaları parça parça gözden geçirmenizi sağlayan ve yalnızca taahhüt için ihtiyacınız olanı çekmenize olanak tanıyan bir "-patch/-p" seçeneğine sahiptir. Eklemeler, sağlanan parçaları bölme ve hatta satırları düzenleyerek elle toplama konusunda çok spesifik olabilirsiniz. Parça parça taahhüt oluşturmanın bir bonusu da muhtemelen daha iyi bir taahhüt mesajı yazmanızdır çünkü değişiklikler aklınızda taze kalacaktır.

İpucu: “tek Tuş” yapılandırma seçeneği görüntülerin daha hızlı gezinmesini sağlamak için (git config –global Interactive.singleKey true). Bunun çalışması için Term::ReadKey modülüne ihtiyacınız olacak.

“–patch” seçeneği sadece “add” komutundan daha fazla komutta mevcuttur. Bir dosyadan özellikle pasif agresif bir yorumu atmak ister misiniz? “git sıfırlama –yama”! Veya daha sonra kullanmak üzere zulanıza yalnızca bir veya iki satır mı kaydetmek istiyorsunuz? “git stash –patch”!

3. Git Geçmişi

"Tarih bana karşı nazik olacak, çünkü onu yazmaya niyetliyim."

• Sen, bir sonraki PR'ını açıyorsun

Artık atomik taahhütleri kolayca bir araya getirdiğinize göre Git geçmişiyle anlattığınız hikayenin daha büyük resmine bakabilirsiniz. Örneğin, birkaç gündür, yazılımda yeni işlevler çalıştırmanın tanıdık "iki adım ileri, bir adım geri" modeliyle yeni bir özellik üzerinde çalışıyorsunuz.

Kod tabanınıza yeni bir modül eklersiniz, ancak istemeden başka bir yerde hataya neden olursunuz. Yani, bu hatayı düzeltin ve taahhüt edin Bu değişiklikler. Bu yeni kod ekleme ve ardından daha önce tanıttığınız hataları veya gerilemeleri düzeltme modeli bir süre daha devam eder. Sonunda her şeyi düzelttiniz ve yeni, parlak özelliğiniz tekrar "ana" dalla birleştirilmeye hazır.

Belki özellik dalı biraz şuna benzer:

Bu şubeyi birleştirdiğinizde tüm bu tarihi beraberinde taşıyacak. Tarih bu kimsenin umrunda değil. Projenin geçmişini incelediğiniz 5 yıl içinde, bir taahhütte ortaya çıkan ve bir sonraki taahhütte düzeltilen hataları kimse umursamayacaktır. Bu taahhütleri geliştirme sırasında kontrol noktaları olarak önemseyeceksiniz, ancak her şey işe yaradığında oraya nasıl geldiğinizi hatırlamanıza gerek kalmayacak. Gözden geçirenler sadece projeyi ön özellikten sonrasına, belki de arada birkaç önemli kilometre taşına götüren minimum değişiklik setini görmek istiyorlar. Peki bununla nasıl başa çıkıyorsunuz? Özellik %100 yazılıp çalışır hale gelene kadar herhangi bir şey yapmayı bekleyebilirsiniz, ancak bu, geliştirme sürecinin ortasında olmak için tehlikeli bir noktadır.

Git, kullanıcıların taahhüt geçmişini etkileşimli olarak düzenlemesine olanak tanıyan "git rebase –interactive" ile tekrar kurtarmaya geliyor. Geçmişteki taahhütleri yeniden sıralayabilir, düzenleyebilir, bırakabilir veya "ezebilirsiniz". Etkileşimli yeniden temellendirmenin Git geçmişinizi değiştirir. Bu da onları potansiyel olarak çok tehlikeli kılıyor. Dikkatli olmazsanız buradaki deponuza ciddi şekilde zarar verebilirsiniz.

Git uzak ana bilgisayarını, yalnızca "dev/*" gibi bir şablonla eşleşen dallardaki geliştiricilere "geri sarma" izinlerine izin verecek şekilde ayarlamanızı öneririm. Bu, geliştiricileriniz ne yaparsa yapsın ana şubeyi ve diğer önemli kontrol noktalarını sağlam tutacaktır. Projelerimde "geri sarmaya" yalnızca "tmp/*" ve "dev/*" ile eşleşen dallarda izin veriliyor. Değişiklikler paylaşılan bir özellik dalında veya "ana"da olduğunda, tarih artık değişmeyecektir! Mümkün olduğunda, kabul edilmiş bir çekme talebinden gelmediği sürece "ana" şubeye yapılan tüm gönderimleri yasaklayarak bu fikri mantıksal sonucuna götürün.

Örnek özellik dalımızı yeniden incelersek, bir temizleme sonrasında geçmişin nasıl göründüğünü burada görebilirsiniz:

İki hata düzeltme taahhüdü ana taahhütlerin içine sıkıştırıldı. Bu, özellik geliştirme hatalarının gürültüsü olmadan, kod tabanına eklenen yeni bir özelliği açıkça gösteren güzel ve temiz bir geçmiş sağlar.

Güvenilir bir geçmiş tutmak, VCS kullanmanın nedenlerinden biridir; konfigürasyon yönetimi, tıbbi cihaz yazılımı için IEC 62304'ün temel gerekliliklerinden biridir. Geçmişinizi netleştirmek ve yazılımın iki sürüm arasında nasıl ilerlediğini görmek için etkileşimli yeniden temellendirmeyi kullanın.

Sonuç

Açık bir geçmişi korumak, tıbbi cihaz yazılımı geliştirmenin kritik bir yönüdür. Tıbbi cihaz ürünleri için heyecan verici ve geniş kapsamlı işlevler geliştirirken Git'in güçlü hazırlama alanı ve etkileşimli yeniden temellendirme özellikleri, hızlı hareket etmenizi ve daha az kırılmanızı sağlayacaktır.

Resim: Adobe Stock

Levi Puckett bir Yazılım Mühendisi Starfish Medical'da. Elektrik Mühendisliği diplomasıyla elektronik ile yüksek kaliteli gömülü yazılım arasındaki boşluğu dolduruyor. Levi, tıbbi cihaz yazılımının her düzeyinde çalışarak şirketlerin yeni tıbbi cihazları için etkili, yenilikçi ve güvenli yazılım geliştirmelerine yardımcı olur.



• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://starfishmedical.com/blog/3-git-tips-to-improve-medical-device-software/