Bilimsel yazılım için sürekli entegrasyon

Ben yazılım mühendisi değilim. Ben jeoloji alanında doktora öğrencisiyim.

Neredeyse iki yıl önce bilimsel bir yazılım programlamaya başladım. Asla sürekli entegrasyon (CI) kullanmadım, çünkü ilk başta onun var olduğunu bilmiyordum ve bu yazılım üzerinde çalışan tek kişi bendim.

Artık yazılımın temeli çalıştığından başka insanlar onunla ilgilenmeye başlıyor ve yazılıma katkıda bulunmak istiyor. Plan, diğer üniversitelerdeki diğer kişilerin çekirdek yazılıma eklemeler gerçekleştirmesidir. (Hata yapabildikleri için korkuyorum). Ek olarak, yazılım oldukça karmaşıklaştı ve test edilmesi zorlaştı ve zorlandım ve üzerinde çalışmaya devam etmeyi planlıyorum.

Bu iki nedenden dolayı, şimdi CI kullanmayı daha fazla düşünüyorum. Hiçbir zaman yazılım mühendisliği eğitimi almadığımdan ve çevremdeki hiç kimse CI'yi duymadı (biz bilim insanlarıyız, programcı yok) projeme başlamak için zor buluyorum.

Tavsiye almak istediğim birkaç sorum var:

Öncelikle, yazılımın nasıl çalıştığının kısa bir açıklaması:

• Yazılım gerekli tüm ayarları içeren bir .xml dosyası ile kontrol edilir. Yazılımı, sadece yolu .xml dosyasına bir giriş argümanı olarak geçirerek başlatırsınız ve çalışır ve sonuçları ile birlikte birkaç dosya oluşturur. Tek bir çalıştırma ~ 30 saniye sürebilir.

• Bilimsel bir yazılımdır. Neredeyse tüm fonksiyonlar, türleri çoğunlukla oldukça karmaşık olan sınıflar olan çoklu giriş parametrelerine sahiptir. Bu sınıfların örneklerini oluşturmak için kullanılan büyük kataloglara sahip birden fazla .txt dosyam var.

Şimdi benim sorularıma gelelim:

1. birim testleri, entegrasyon testleri, uçtan uca testler? : Yazılımım şu anda yüzlerce işlev ve ~ 80 sınıfından oluşan yaklaşık 30.000 satırlık bir kod satırında. Halen uygulanmış olan yüzlerce fonksiyon için birim testleri yazmaya başlamam biraz garip geliyor. Bu yüzden sadece bazı test durumları oluşturma hakkında düşündüm. 10-20 farklı .xml dosyası hazırlayın ve yazılımı çalıştırın. Sanırım bu baştan sona test denilen şeydir? Sık sık bunu yapmamanız gerektiğini okudum, ancak zaten çalışan bir yazılımınız varsa başlangıç ​​olarak sorun değil mi? Yoksa zaten çalışan bir yazılıma CI eklemeyi denemek aptalca bir fikir mi?

2. İşlev parametrelerini oluşturmak zorsa birim testlerini nasıl yazabilirsiniz? Ben bir işlevi olduğunu varsayalım double fun(vector<Class_A> a, vector<Class_B>)ve genellikle, ben tür nesneler oluşturmak için birden fazla metin dosyaları ilk okuma gerekir Class_Ave Class_B. Class_A create_dummy_object()Metin dosyalarını okumadan gibi bazı kukla fonksiyonlar yaratmayı düşündüm . Ayrıca bir tür serileştirme yapmayı da düşündüm . (Yalnızca çoklu metin dosyalarına bağlı olduklarından, sınıf nesnelerinin oluşturulmasını test etmeyi planlamıyorum)

3. Eğer sonuçlar oldukça değişkense testler nasıl yazılır? Yazılımım büyük monte-carlo simülasyonlarını kullanıyor ve yinelemeli çalışıyor. Genellikle, ~ 1000 yinelemeye sahipsiniz ve her yinelemede, monte-carlo simülasyonlarına dayanan ~ 500-20.000 nesne yaratıyorsunuz. Bir yinelemenin sadece bir sonucu biraz farklıysa, tüm gelecek yinelemeler tamamen farklıdır. Bu durumla nasıl başa çıkıyorsunuz? Sanırım bu, uçtan uca testlere karşı büyük bir nokta, çünkü sonuç oldukça değişken.

CI ile ilgili herhangi bir diğer tavsiye son derece takdir edilmektedir.

Bilimsel yazılımı test etmek, hem karmaşık konu hem de tipik bilimsel gelişim süreçleri nedeniyle (diğer bir deyişle test edilebilir bir tasarımla sonuçlanmayan, çalışana kadar kesmek) zordur. Bu, bilimin tekrarlanabilir olması gerektiğini düşünerek biraz ironik. “Normal” yazılıma göre değişiklik, testlerin faydalı olup olmadığı değil (evet!) Değil, hangi test türlerinin uygun olduğu.

Rasgele kullanım: Yazılımınızın tüm çalıştırmaları tekrarlanabilir olmalıdır. Monte Carlo tekniklerini kullanıyorsanız, rasgele sayı üreteci için belirli bir tohum sağlamanız mümkün olmalıdır.

• Bunu unutmak kolaydır; örneğin rand(), küresel duruma bağlı olan C'nin fonksiyonunu kullanırken .
• İdeal olarak, rastgele bir sayı üreteci, işlevleriniz arasında açık bir nesne olarak geçirilir. C ++ 11'in randomstandart kütüphane başlığı bunu çok daha kolaylaştırıyor.
• Yazılımın modülleri arasında rastgele durumu paylaşmak yerine, ilk RNG'den rastgele bir sayı ile ekilmiş ikinci bir RNG oluşturmayı faydalı buldum. Ardından, diğer modül tarafından RNG'ye yapılan taleplerin sayısı değişirse, ilk RNG tarafından üretilen dizi aynı kalır.

Entegrasyon testleri mükemmel. Yazılımınızın farklı parçalarının doğru bir şekilde bir arada oynadıklarını doğrulamakta ve somut senaryolar çalıştırmak için iyidirler.

• Asgari bir kalite seviyesi olan “çökmez” zaten iyi bir test sonucu olabilir.
• Daha güçlü sonuçlar için, sonuçları bazı temel değerlere göre de kontrol etmeniz gerekir. Bununla birlikte, bu kontrollerin biraz toleranslı olması gerekir, örneğin yuvarlama hatalarını hesaba katacaktır. Tam veri satırları yerine özet istatistiklerini karşılaştırmak da faydalı olabilir.
• Bir taban çizgisine karşı kontrol yapmak çok kırılgansa, çıkışların geçerli olduğunu kontrol edin ve bazı genel özellikleri sağlayın. Bunlar genel (“seçilen yerler en az 2 km uzakta olmalıdır”) veya senaryoya özgü olabilir, örneğin “seçilen bir alan bu alanda bulunmalıdır”.

Entegrasyon testlerini çalıştırırken, bir test çalıştırıcısını ayrı bir program veya komut dosyası olarak yazmak iyi bir fikirdir. Bu test çalıştırıcısı gerekli kurulumları yapar, test edilecek çalıştırılabilirleri çalıştırır, sonuçları kontrol eder ve daha sonra temizler.

Ünite test tarzı kontrolleri bilimsel yazılıma eklemek oldukça zor olabilir çünkü yazılım bunun için tasarlanmamıştır. Özellikle, test edilen sistem birçok dış bağımlılığa / etkileşime sahip olduğunda birim testleri zorlaşır. Yazılım tamamen nesne yönelimli değilse, genellikle bu bağımlılıklarla alay etmek / saplamak mümkün değildir. Saf matematik işlevleri ve yardımcı işlevler dışında bu tür bir yazılım için birim testlerinden kaçınmanın en iyi yolunu buldum.

Birkaç test bile testlerden daha iyidir. Sürekli bir entegrasyon için şimdiden iyi bir başlangıç ​​olan “derlemek zorunda” çekiyle birlikte. Her zaman geri gelip daha sonra daha fazla test ekleyebilirsiniz. Daha sonra, daha fazla geliştirme etkinliği elde ettikleri için, kodun kırılması daha muhtemel olan alanlarına öncelik verebilirsiniz. Kodunuzun hangi bölümlerinin birim testleri kapsamında olmadığını görmek için kod kapsamı araçlarını kullanabilirsiniz.

Manuel test: Özellikle karmaşık problem alanlarında, her şeyi otomatik olarak test edemezsiniz. Örneğin şu anda stokastik bir arama problemi üzerinde çalışıyorum. Yazılımımın her zaman aynı sonucu ürettiğini test edersem, testleri bozmadan geliştiremem. Bunun yerine, manuel testler yapmayı kolaylaştırdım : Yazılımı sabit bir tohumla çalıştırıyorum ve görselleştirme alıyorumSonuç (tercihlerinize bağlı olarak, R, Python / Pyplot ve Matlab, veri kümelerinizin yüksek kalitede görselleştirmelerini kolaylaştırır). Bu görselleştirmeyi, işlerin çok yanlış gitmediğini doğrulamak için kullanabilirim. Benzer şekilde, yazılımınızın ilerlemesini kayıt çıktısı üzerinden izlemek, en azından günlüğe kaydedilecek olay türünü seçebiliyorsam uygulanabilir bir manuel test tekniği olabilir.

Zaten uygulanmış olan yüzlerce fonksiyon için birim testleri yazmaya başlamam biraz garip geliyor.

Söylenen işlevleri değiştirirken testleri (genellikle) yazmak isteyeceksiniz . Arkanıza yaslanıp mevcut işlevler için yüzlerce birim sınaması yazmanıza gerek yoktur, bu (büyük ölçüde) zaman kaybı olur. Yazılım (muhtemelen) olduğu gibi çalışıyor. Bu testlerin amacı gelecekteki değişikliklerin eski davranışları bozmadığından emin olmaktır . Belirli bir işlevi bir daha asla değiştirmezseniz, muhtemelen test etmek için zaman ayırmaya değmeyecektir (şu anda çalışıyor, her zaman çalıştı ve muhtemelen çalışmaya devam edecek). Eski Kodla Etkili Çalışmayı Okumayı ÖneriyorumMichael Feathers tarafından bu cephede. Bağımlılık kırma teknikleri, karakterizasyon testleri (regresyon davranışını korumanızı sağlamak için test paketine kopyala / yapıştır işlevi çıktısı) ve çok daha fazlası dahil olmak üzere zaten var olan şeyleri test etmek için bazı genel stratejileri var.

İşlev parametrelerini oluşturmak zorsa birim testlerini nasıl yazabilirsiniz?

İdeal olarak, yapmazsınız. Bunun yerine, parametrelerin oluşturulmasını kolaylaştırırsınız (ve böylece tasarımınızın test edilmesini kolaylaştırır). Kuşkusuz, tasarım değişiklikleri zaman alır ve bu yeniden yapılandırmalar sizinki gibi eski projelerde zor olabilir. TDD (Test Odaklı Gelişme) bu konuda yardımcı olabilir. Parametrelerin oluşturulması süper zorsa, ilk test tarzında test yazarken bir sürü sorun yaşayacaksınız.

Kısa vadede, alay kullanın, ama alaycı cehenneme ve uzun vadede onlarla birlikte gelen sorunlara dikkat edin. Bir yazılım mühendisi olarak büyüdüğüm gibi, alayların hemen hemen her zaman daha büyük bir problemi sarmaya çalışan ve ana konuyu ele almayan küçük bir koku olduğunu fark ettim. Buna "sarılı sarmak" demekten hoşlanıyorum, çünkü halınıza bir parça köpek kakasına bir kutu folyo folyo koyarsanız, hala kokuyor. Yapmanız gereken aslında ayağa kalkmak, kakayı avlamak ve çöpün içine atmak ve sonra çöpü dışarı çıkarmaktır. Bu açıkçası daha fazla iş ve elinizde bazı dışkı maddeleri almak için risk alıyorsunuz, ancak uzun vadede sizin ve sağlığınız için daha iyi. Sadece bu kakaları sarmaya devam edersen, evinde daha fazla yaşamak istemezsin. Alaylar doğada benzer.

Örneğin, Class_Abaşlatması zor bir durumunuz varsa, 700 dosya okumak zorundasınız, o zaman alay edebilirsiniz. Tek eksiği, sizin sahte güncel alır ve gerçek Class_A taklidinin daha çılgınca farklı bir şey yapar ve Testlerinizi hala olsa geçiyoruz gerektiğini başarısız olması. Daha iyi bir çözüm, bileşenlerin kullanımı / testClass_A edilmesinin daha kolay hale getirilmesi ve bunun yerine bu bileşenlerin test edilmesidir. Belki de diske isabet eden ve bir bütün olarak çalıştığından emin olan bir entegrasyon testi yazabilirsiniz Class_A. Veya belki de sadece Class_Adiskten okumak zorunda kalmak yerine basit bir dizeyle (verilerinizi temsil eden) başlatabileceğiniz bir yapıcınız olabilir.

Eğer sonuçlar oldukça değişkense testler nasıl yazılır?

Birkaç ipucu:

1) Ters çevrmeleri kullanın (veya daha genel olarak özellik tabanlı testler). Bu ne [1,2,3,4,5]? Fikrim yok. Nedir ifft(fft([1,2,3,4,5]))? Olmalı [1,2,3,4,5](veya buna yakınsa, kayan nokta hataları ortaya çıkabilir).

2) "Bilinen" iddiaları kullanın. Bir determinant işlevi yazarsanız, 100x100 matrisindeki determinantın ne olduğunu söylemek zor olabilir. Fakat kimlik matrisinin determinantının 100x100 olsa bile 1 olduğunu biliyorsunuz. Ayrıca, fonksiyonun tersinir olmayan bir matriste 0 döndürmesi gerektiğini de biliyorsunuz (100x100 tam 0'larla dolu).

3) Kesin varsayımlar yerine kaba armalar kullanın . Bir süre önce, görüntüler arasında bir eşleme yaratan bağlanma noktaları oluşturarak ve görüntüleri eşleştirmeleri için çözgü yapan iki görüntü kaydettiğim bir kod yazdım. Alt piksel düzeyinde kayıt olabilir. Nasıl test edebilirsiniz? Gibi şeyler:

EXPECT_TRUE(reg(img1, img2).size() < min(img1.size(), img2.size()))

yalnızca çakışan kısımlara kaydolabileceğiniz için, kayıtlı görüntünün en küçük görüntünüze eşit veya daha küçük olması gerekir ) ve ayrıca:

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

kendisine kaydedilen bir görüntünün kendisine KAPALI olması gerektiğinden, ancak eldeki algoritma nedeniyle kayan nokta hatalarından biraz daha fazlasını yaşayabilirsiniz, bu nedenle sadece her pikselin geçerli aralığın% +/- 5'i ile olduğunu kontrol edin (0-255 ortak bir aralıktır, gri tonlamalı). En azından aynı boyutta olmalı. Sadece duman testi bile yapabilirsiniz (örn. Onu arayın ve çarpmadığından emin olun). Genel olarak, bu teknik, sonucun (kolayca) test edilemeyen bir priori hesaplanamadığı daha büyük testler için daha iyidir.

4) RNG'niz için OR STORE rastgele bir sayı tohumu kullanın.

Skor yok tekrarlanabilir olması gerekir. Ancak, yeniden üretilebilir bir işlem elde etmenin tek yolunun rastgele sayı üretecine belirli bir tohum sağlamaktır. Bazen rastgelelik testi değerlidir . Bilimsel kodda rastgele oluşturulmuş dejenere durumlarda ortaya çıkan bir hata gördüm . Fonksiyonunuzu her zaman aynı tohumla çağırmak yerine, rastgele bir tohum oluşturun ve ardından bu tohumu kullanın ve tohumun değerini kaydedin . Bu şekilde, her koşunun farklı bir rastgele tohumu vardır, ancak bir çarpışma olursa, hata ayıklamak için giriş yapmış olduğunuz tohumu kullanarak sonucu tekrar çalıştırabilirsiniz. Aslında bunu pratikte kullandım ve bir böceğe çarptı, ben de söyleyeceğimi düşündüm.Dezavantajı: Test çalışmalarınızı kaydetmeniz gerekir. Upside: Doğruluk ve hata ayıklama.

HTH.

1. Test türleri

   • Halen uygulanmış olan yüzlerce fonksiyon için birim testleri yazmaya başlamam biraz garip geliyor.

     Bunu tam tersi bir yoldan düşünün: birkaç işleve dokunan bir yama uçtan uca testlerinizden birini bozarsa, sorunun hangisinin olduğunu nasıl çözeceksiniz?

     Bireysel fonksiyonlar için birim testleri yazmak tüm programdan daha kolaydır . Bireysel bir işlevin iyi bir şekilde kapsandığından emin olmak çok daha kolaydır . Ünite testlerinin kırdığınız köşe kasalarını yakalayacağından emin olduğunuzda, bir işlevi yeniden yapılandırmak çok daha kolaydır.

     Zaten var olan fonksiyonlar için birim testleri yazmak, eski bir kod tabanında çalışan herkes için mükemmel bir şekilde normaldir. Fonksiyonları ilk önce anladığınızı onaylamak için iyi bir yoldur ve bir kez yazıldığında, beklenmeyen davranış değişikliklerini bulmak için iyi bir yoldur.

   • Uçtan uca testler de faydalıdır. Yazmaları daha kolaysa, elbette, ilk önce bunları yapın ve başkalarının kırılması konusunda en çok endişe duyduğunuz fonksiyonları kapsayacak şekilde birim testleri ekleyin. Hepsini bir kerede yapmak zorunda değilsiniz.

   • Evet, mevcut yazılıma CI eklemek mantıklı ve normal.

2. Birim testleri nasıl yazılır

   Nesneleriniz gerçekten pahalı ve / veya karmaşıksa, sahte yazın. Polimorfizmi kullanmak yerine testleri kullanarak gerçek nesneleri kullanan testlerden ayrı olarak alayları bağlayabilirsiniz.

   Her halükarda örnekleri yaratmanın kolay bir yoluna sahip olmalısınız - sahte örnekler oluşturma işlevi yaygındır - ancak gerçek oluşturma işlemi için testler yapmak da mantıklıdır.

3. Değişken sonuçlar

   Sonuç için bazı değişmezlere sahip olmalısınız . Bunları tek bir sayısal değer yerine test edin.

   Eğer monte carlo kodunuz bir parametre olarak kabul ederse, sahte bir yalancı sayı üreteci sağlayabilirsiniz, bu da sonuçları en azından iyi bilinen bir algoritma için öngörülebilir hale getirir, ancak her seferinde aynı sayıyı döndürmediği sürece kırılgandır.

1. CI eklemek asla aptalca bir fikir değildir. Tecrübelerden, insanların katkıda bulunabilecekleri bir açık kaynak projeniz olduğunda bunun yol olduğunu biliyorum. CI, kodunuzu programınızı sonlandırırsa, insanların kod eklemesini veya değiştirmelerini engellemenizi sağlar; bu nedenle çalışan bir kod tabanına sahip olmak neredeyse paha biçilmezdir.

   Testler göz önüne alındığında, kod akışınızın olması gerektiği gibi çalıştığından emin olmak için kesinlikle bazı uçtan uca testler (bunun bir entegrasyon testlerinin alt kategorisi olduğunu düşünüyorum) sağlayabilirsiniz. Entegrasyon testlerinin bir kısmı test sırasında yapılan diğer hataları telafi edebileceğinden, fonksiyonların doğru değerleri verdiğinden emin olmak için en azından bazı temel birim testlerini sağlamalısınız.

2. Test nesnesi yaratma gerçekten zor ve zahmetli bir şeydir. Sahte nesneler yapmakta haklısın. Bu nesnelerin varsayılan, ancak son durumda, çıktının ne olacağını kesinlikle bildiğiniz değerler olmalıdır.

3. Bu konuyla ilgili kitaplarla ilgili problem, CI (ve diğer dut sapıkların) manzarasının, bir kitaptaki herhangi bir şeyin muhtemelen birkaç ay sonra güncel olamayacağıdır. Size yardımcı olabilecek kitapları tanımıyorum, ancak Google her zaman olduğu gibi kurtarıcınız olmalıdır.

4. Testlerinizi kendiniz defalarca yapmalı ve istatistiksel analiz yapmalısınız. Bu şekilde, kaç değerin ortanca / ortalamasını aldığınız bazı test durumlarını uygulayabilir ve hangi değerlerin doğru olduğunu bilmek için analizinizle karşılaştırabilirsiniz.

Bazı ipuçları:

• Bozuk kodun kod tabanınıza girmesini önlemek için CI araçlarının GIT platformunuzla entegrasyonunu kullanın.
• hakem değerlendirmesi diğer geliştiriciler tarafından yapılmadan önce kodun birleştirilmesini durdurun. Bu hataların daha kolay bilinmesini sağlar ve bozuk kodun kod tabanınıza girmesini önler.

Amon'dan önceki bir cevapta zaten çok önemli noktalardan bahsetmiştik. Biraz daha ekleyeyim:

1. Bilimsel yazılım geliştirme ile ticari yazılım arasındaki farklar

Bilimsel yazılımlar için, normalde odak noktası elbette bilimsel problemdir. Sorunlar teorik arka planı daha iyi ele almak, en iyi sayısal yöntemi bulmak vb.

Yazılım çoğu durumda bir veya sadece birkaç kişi tarafından yazılmıştır. Genellikle belirli bir proje için yazılmıştır. Proje bittiğinde ve her şey yayınlandığında, çoğu durumda yazılıma ihtiyaç duyulmaz.

Ticari yazılım genellikle uzun süre boyunca büyük ekipler tarafından geliştirilir. Bu, mimari, tasarım, birim testleri, entegrasyon testleri vb. İçin çok fazla planlama gerektirir. Bu planlama, önemli miktarda zaman ve deneyim gerektirir. Bilimsel bir ortamda normalde bunun için zaman yoktur.

Projenizi ticari yazılıma benzer bir yazılıma dönüştürmek istiyorsanız, aşağıdakileri kontrol etmelisiniz:

• Vaktiniz ve zamanınız var mı?
• Yazılımın uzun vadeli perspektifi nedir? İşinizi bitirdiğinizde ve üniversiteden ayrıldığınızda yazılımda ne olacak?

2. Uçtan uca testler

Yazılım gittikçe daha karmaşık hale gelirse ve üzerinde birkaç kişi çalışıyorsa testler zorunludur. Ama amon olarak önce bahsedildiği, bilimsel yazılıma birim testleri ekleyerek oldukça zordur. Yani farklı bir yaklaşım kullanmalısın.

Yazılımınız girişini bir dosyadan alıyor gibi, çoğu bilimsel yazılım gibi, birkaç örnek giriş ve çıkış dosyası oluşturmak için mükemmeldir. Bu testleri her sürümde otomatik olarak çalıştırmalı ve sonuçları örneklerinizle karşılaştırmalısınız. Bu birim testleri için çok iyi bir yedek olabilir. Entegrasyon testlerini de bu şekilde yaparsınız.

Elbette, tekrarlanabilir sonuçlar elde etmek için, rastgele sayı üreteciniz için, aynı amonun yazdığı gibi aynı tohumu kullanmanız gerekir .

Örnekler, yazılımınızın tipik sonuçlarını kapsamalıdır. Bu ayrıca parametre alanınızın kenar durumlarını ve sayısal algoritmaları da içermelidir.

Koşmak için fazla zamana ihtiyaç duymayan, ancak yine de tipik test durumlarını kapsayan örnekler bulmaya çalışmalısınız.

3. Sürekli entegrasyon

Test örneklerinin çalıştırılması biraz zaman alabileceğinden, sürekli entegrasyonun mümkün olmadığını düşünüyorum. Muhtemelen ek kısımları meslektaşlarınızla tartışmanız gerekecek. Örneğin, kullanılan sayısal yöntemlerle eşleşmeleri gerekir.

Bu yüzden, teorik arka planı ve sayısal yöntemleri, dikkatli testleri vb. Tartıştıktan sonra entegrasyonu iyi tanımlanmış bir şekilde yapmanın daha iyi olacağını düşünüyorum.

Sürekli entegrasyon için bir çeşit otomasyona sahip olmanın iyi bir fikir olduğunu sanmıyorum.

Bu arada, bir sürüm kontrol sistemi kullanıyor musunuz?

4. Sayısal algoritmalarınızı test etmek

Sayısal sonuçları karşılaştırıyorsanız, örneğin test çıktılarınızı kontrol ederken, eşitlik için değişken sayıları kontrol etmemelisiniz. Yuvarlama hataları her zaman olabilir. Bunun yerine, farkın belirli bir eşikten düşük olup olmadığını kontrol edin.

Algoritmalarınızı farklı algoritmalara göre kontrol etmek veya bilimsel problemi farklı bir şekilde formüle etmek ve sonuçları karşılaştırmak da iyi bir fikirdir. İki veya daha fazla bağımsız yol kullanarak aynı sonuçları elde ederseniz, bu teorinizin ve uygulamanızın doğru olduğuna dair iyi bir göstergedir.

Bu testleri test kodunuzda yapabilir ve üretim kodunuz için en hızlı algoritmayı kullanabilirsiniz.

Tavsiyem, çabalarınızı nasıl harcadığınızı dikkatlice seçmek olacaktır. Alanımda (biyoinformatik) teknolojinin son durum algoritmaları öyle hızlı değişiyor ki, kodunuzu prova etmek için harcadığınız enerjiyi algoritmanın kendisine harcanması daha iyi olabilir.

Yani, değerli olan şudur:

• algoritma açısından o zaman en iyi yöntem midir?
• farklı hesaplama platformlarına (farklı HPC ortamları, işletim sistemi lezzetleri vb.) geçiş yapmak ne kadar kolay
• sağlamlık - MY veri setinde çalışıyor mu?

Kurşun geçirmez bir kod temeli oluşturma içgüdüsü asildir, ancak bunun ticari bir ürün olmadığını hatırlamakta fayda var. Olabildiğince taşınabilir, hataya dayanıklı (kullanıcı türünüz için), başkalarının da katkısına uygun, sonra algoritmanın kendisine odaklanın