Haftanın Makalesi (I): "Best Practices for Scientific Computing"

Uzun bir süredir tez çalışmalarımda, kendi araştırmalarımda, aldığım derslerin projelerinde ve verdiğim derslerin uygulamalarında bilgisayar kodu yazıyorum. Çoğu zaman fiziksel/bilimsel bir problemi çözmek üzerine olan bu kodların yapısı genelde "günü kurtaran", bir şekilde çalışıp bir sonuç üreten tipte oluyor. Bu haliyle çoğu zaman içinde kendini tekrar eden kod kümeleri barındıran, nerede-ne yaptığı belli olmayan, iyi belgelenmemiş ve başka birisi aldığında bırakın tekrar çalıştırıp aynı sonuçları üretebilmeyi kodu okuyup ne yaptığını dahi anlaşılmayacak kadar karmaşık türde kodlar yazdığını fark ediyor insan. Küçük çaplı çalışmalarda "iş gören" kodlar, problem biraz karmaşıklığında tam bir baş belasına dönüşebiliyor ve o anda artık biraz "iyi alışkanlıklar" (best practices) takip edip hayatı kolaylaştıran yöntem ve araçlara yönelmek durumunda kalınıyor. Bu hafta okuyup kısaca özetleyeceğim  G. Wilson ve arkadaşları tarafından 2014'de yayınlanan "Best Practices for Scientific Computing" makalesinin temel fikri de tam olarak bu.

Yazarlar öncelikle bilimsel amaçla yazılan programların bir bilim insanı için başka bir tür "deney aracı" olduğunu ve tıpkı fiziksel bir deney aracı gibi yapılandırılıp, kontrol edilerek dikkatli bir şekilde kullanılması gerektiğini belirterek başlıyorlar. Sonrasında da  bilimsel kod yazımında dikkat edilmesi önerilen sekiz maddeyi sıralıyorlar:

1- Yazdığınız kodu bilgisayarlar için değil, insanlar için yazın.

• Yazılan kodu başkalarının veya özellikle gelecek bir zamanda kendisinin anlayabilmesi için insanların anlık hafızalarının kısıtlılığı, örüntü tanıma becerilerinin hassas bir şekilde ayarlanmış olduğu ve dikkat sürelerinin kısa oluşunu göz önüne alarak yazmak gerektiği vurgulanıyor. Bunun için verilen temel öneri kodu tıpkı bir makaledeki bölümler gibi, belirli amaçlar için oluşturulmuş fonksiyonlara bölmek.
• Programda kullanılan isim ve etiketleri ayırdedilebilir, tutarlı ve anlamlı bir şekilde vermeli.
• Kodun her bölümünde stil ve formatı koruyarak ilerlemeli.

2- Bırakın bilgisayarlar işi yapsın.

• Gerçekleştirilmesi hedeflenen prosedürü tekrar tekrar elle yapmak yerine bir script ile çalıştırılacak komutları otomatize etmeyi ve "build tool"lar kullanmayı öneriyorlar.

3- Değişiklikleri ufak ufak yapın.

• Küçük adımlarla, sık sık geri bildirim alarak düzenlemeler yapıp ilerlemeyi öneriyorlar. Her iterasyonda çalışan bir program yazmak amaç ve her iterasyondaki değişiklikleri kaydedip gerektiğinde geriye almak için de GitHub gibi versiyon kontrol sistemleri kullanmayı öneriyorlar.

4- Kendinizi (ya da başkalarını) tekrar etmeyin.

• Bu prensip hem veri için hem de kod için geçerli. Sistemdeki her bir verinin tek bir temsili bulunması gerek; yani kodun bir yerinde değişiklik yapıldığında bu değişiklik tüm her yere paralel olarak yansıması gerek. 
• Kopya-yapıştır yapmak yerine kodu modüler hale getirmek, fonksiyonlar ve class'lar ile ilerlemek en sağlıklısı.

5- Hatalar için önceden plan yapın.

• Hatalar kaçınılmaz, sadece onlara karşı "hazırlıklı" olmak gerekiyor. Bunun için "savunmacı programlama" yöntemi geliştirmeyi öneriyorlar. Kodun içine yanlış gitmesi muhtemel durumları kontrol amaçlı "assertion"lar ekleyip gerektiği durumda müdehale etmek gerekiyor. Assertion'lar program içinde örneğin belirli değişkeni, bir fonksiyon çıktısını kontrol edip programın devamını sağlayan mantıksal ifadeler. Bu ifadeleri kullanmanın kodun bölümlerine açıklama yazmaktan daha fazla anlaşılırlık kattığını söylüyorlar.
• Otomatik testler uygulamak için standart test kütüphaneleri kullanmayı ve bugları bulmak için sembolik debugger'lar kullanmayı öneriyorlar.

6- Programı ancak doğru çalıştıktan sonra optimize edin.

• Araştırmalarda kod yazan kişilerin kullandıkları dilden bağımsız olarak birim zamanda neredeyse aynı satır sayısında kod yazdığını gözlemişler. Buradan yola çıkarak kodu öncelikle daha az satır kodla yazılabilecek Python, R gibi "yüksek-seviyeli" dillerde prototipleyip ardından daha iyi performans için C, Java gibi düşük seviye dillere geçmeyi öneriyorlar.

7- Tasarım ve amacı dokümante edin, çalışma prensibini değil.

• Yazılan kodu açıklamak için bir paragraf adım adım nasıl çalıştığını anlatmak yerine, kullanılan arayüzleri açıklayıp amaç ve nedenlerini açıklamak gerektiğini vurguluyorlar. Nasıl çalıştığının adım adım anlatılması gereken kodun tekrar geri dönülüp buna ihtiyaç kalmayacak şekilde tekrar düzenlenmesi gerektiğini söylüyorlar.
• Dokümantasyonu yazılımın içine gömmeyi öneriyorlar ayrı bir yerde tutmak yerine (örneğin Jupyter Notebook'larda olduğu gibi); böylece program başkaları tarafından modifiye edildiğinde paralel olarak dokumantasyonun da güncellenebileceğini ekliyorlar.

8- Birlikte çalışın.

• Yazılan programları proje üzerine çalışan kişiler arasında incelenip, gözden geçirilmesini öneriyorlar. Hatayı çok daha aza indirmek için aynı kod üzerinde beraber çalışmayı öneriyorlar.

Araştırmalarda bu tip "iyi alışkanlıkları" edinmek için gerekli öğrenme ve bunları uygulama sürelerinin, sonunda elde edilen verimlilik ile fazlasıyla karşılandığı belirtiliyor. Makalenin başında tıpkı laboratuardaki deneylerde olduğu gibi standartları birebir uygulamanın her zaman mümkün olmadığını ve bu alışkanlıkların hepsini bir anda uygulamaya çalışmaktansa teker teker çalışma rutinlerine entegre edilmesi gerektiğini ifade ediyorlar.

Bu yazıyı okuyup, konuyla uğraşan kişilerin bu tip "iyi alışkanlıklar" önerileri varsa da duymayı çok isterim!

Makaleyi okumak için:  "Best Practices for Scientific Computing" (PLOS Biology - Open Access)