NASA'nın Yazılım Geliştirme İçin 10 Kuralı

• NASA'nın yazılım geliştirme için 10 kuralına dair eleştirel bir analiz
  • Bu kurallar son derece kritik gömülü sistemler (ör. uzay aracı yazılımları) için tasarlanmıştır
  • Ancak bu kuralların başka geliştirme ortamlarında da uygun olup olmadığı veya başka dillerde (C dışındaki dillerde) uygulanabilir olup olmadığı tartışılmalıdır

1. Basit kontrol akışını koru (goto, setjmp/longjmp, özyineleme yasak)

• Bu kural, istisna işleme (setjmp()/longjmp()) ve özyinelemeyi yasaklar.
• Özyineleme mutlaka verimsiz değildir. Uygun yöntemler kullanılırsa özyinelemede de sonlanma garanti edilebilir.
• Özyinelemeyi zorla döngüye dönüştürmek, bakımı zor kodlara yol açma riski taşır.

Eleştiri:

• Sonlanma garantisi önemlidir, ancak aşırı kısıtlamalar okunabilirlik ve bakım yapılabilirliği zedeleyebilir.
• Koşulsuz özyineleme yasağı, gereksiz karmaşıklığa yol açma potansiyeli taşır.

2. Tüm döngülerin açık bir üst sınırı olmalı

• Derleyicinin döngü tekrar sayısını statik olarak analiz edebilmesi gerekir.
• Ancak yalnızca bir üst sınır koymak, gerçek çalışma süresini garanti etmeye yetmez.
• Özyineleme derinliğine sınır koymak da döngü üst sınırı koymak kadar güvenli olabilir.

Eleştiri:

• Sadece üst sınır koymak, pratikte uygulanabilir yürütme süresini garanti etmez.
• Üst sınır belirlenmiş olsa da değer çok büyükse, fiilen sonsuz döngüden pek farklı olmayabilir.

3. Başlatmadan sonra dinamik bellek ayırma yasak

• Gömülü sistemlerde bellek sınırlı olduğundan, amaç bellek yetersizliğinden kaynaklanan çökmeleri önlemektir.
• Ancak elle bellek yönetimi yerine öngörülebilir dinamik ayırma daha güvenli olabilir.
• Örneğin gerçek zamanlı çöp toplayıcı (RTGC) kullanılırsa dinamik ayırma da öngörülebilir hale getirilebilir.

Eleştiri:

• Dinamik ayırmayı tamamen yasaklamak yerine, bellek kullanım kalıplarını analiz ederek güvenliği sağlamak daha iyi bir yaklaşım olabilir.
• Modern statik analiz araçları (SPlint vb.) kullanılarak dinamik bellekle ilgili hatalar önceden tespit edilebilir.

4. Fonksiyon boyutu bir A4 sayfasıyla sınırlı olmalı (yaklaşık 60 satır)

• Mantık, fonksiyon çok uzarsa okunabilirliğin düşmesidir.
• Ancak modern geliştirme ortamlarında kod katlama özellikleri bulunduğundan, fonksiyon uzunluğundan çok mantıksal birimlerin boyutu daha önemlidir.

Eleştiri:

• Fiziksel boyut (satır sayısı) yerine mantıksal karmaşıklık ölçüt alınmalıdır.
• Fonksiyonları küçük parçalara bölmek başlı başına amaç haline gelmemelidir → aksine bakımı zorlaştırabilir.

5. Her fonksiyonda en az iki assert ifadesi kullan

• assert, hata ayıklama ve belgeleme açısından çok faydalıdır.
• Ancak koşulsuz sayı zorlaması verimsiz olabilir.

Eleştiri:

• assert sayısından çok, veri geçerliliği kontrolünün nerelerde gerektiğini netleştirmek önemlidir.
• Tüm parametreleri ve dış girdileri doğrulamak daha pratiktir.

6. Veri nesnelerinin kapsamını en aza indir

• Yerel değişken kullanımını teşvik eden iyi bir ilkedir.
• Ancak yalnızca değişkenlerin değil, tiplerin ve fonksiyonların kapsamı da en aza indirilmelidir.

Eleştiri:

• Ada, Pascal, JavaScript ve fonksiyonel dillerde tipler ve fonksiyonlar da yerel olarak tanımlanabilir → bu, NASA kurallarından daha iyi bir yaklaşımdır.

7. Fonksiyon dönüş değerleri ve parametre geçerliliği mutlaka doğrulanmalı

• Dönüş değerleri mutlaka kontrol edilmelidir.
• Ancak her durumu kontrol etmek pratikte zordur.

Eleştiri:

• Çalışma zamanı hatalarını önlemek için mümkün olduğunca çok kontrol gerekir, ancak pratik sınırlar da dikkate alınmalıdır.
• Özellikle C'de dönüş değeri kontrolü önemlidir; ancak modern dillerde (Java, Rust vb.) tip sistemi kullanılarak daha güvenli işlemler yapılabilir.

8. Önişlemci kullanımını sınırla (yalnızca başlık ekleme ve basit makrolara izin verilir)

• Karmaşık makrolar, token birleştirme, değişken argümanlı makrolar (...) yasaktır.
• Ancak değişken argümanlı makrolar hata ayıklama araçları için yararlı olabilir.

Eleştiri:

• Önişlemci kullanımını kısıtlamak yerine, okunabilir makro stillerini teşvik etmek daha uygundur.
• #ifdef gibi koşullu derlemeyi engellemek, platformdan bağımsız kod yazmayı zorlaştırabilir.

9. Pointer kullanımını sınırla (çift pointer yasak, fonksiyon pointer'ı yasak)

• Fonksiyon pointer'ı kullanımını yasaklar → amaç yüksek kararlılıktır.
• Ancak fonksiyon pointer'ları callback'ler, strategy pattern ve aygıt sürücüleri için gereklidir.

Eleştiri:

• Fonksiyon pointer'ları olmadan fonksiyon seçimini switch-case ile zorlamak, kod okunabilirliğini düşürür ve bakımı zorlaştırır.
• İşletim sistemi, ağ yığını ve sürücü geliştirmede fonksiyon pointer'ları vazgeçilmezdir.
• Pointer kısıtlamasından ziyade, güvenli pointer kullanımını garanti eden yöntemler (C++ smart pointer'lar, Rust vb.) daha iyi bir çözümdür.

10. Tüm kod için derleyici uyarılarını en yüksek düzeye getir ve statik analiz araçları kullan

• Bu kural çok iyi bir öneridir.
• Derleyici uyarılarını gidermek + statik analiz araçları kullanmak = daha yüksek güvenilirlik.

Eleştiri:

• NASA'nın diğer kurallarının bazıları (ör. pointer yasağı, fonksiyon boyutu sınırı), aslında statik analiz araçlarının sınırlamalarını aşma amacı taşır.
• Ancak modern statik analiz araçları çok gelişmiştir; bu yüzden aşırı kısıtlamalar yerine daha incelikli analiz tekniklerinden yararlanmak daha faydalıdır.

[regentag]

Bunların hepsi gerçek zamanlı, gömülü sistemler açısından bakınca anlaşılır ve gerekli kurallar gibi görünüyor. Statik analiz araçları bu kuralların yerini alabilir mi?

Örneğin, dinamik tahsisata izin verildiğinde tüm kullanım senaryolarında bellek tahsisinin başarılı olacağını garanti edebilir mi?

Yazılım testini öğrenirken hep ilk günün ilk saatinde değinilen önermeler vardır. Bunlardan biri de "mükemmel test imkansızdır" olur.

[smboy86]

Karşı çıkan görüş daha çok dikkatimi çektiğine göre
sanırım bana uyan kurallar değilmiş haha

[rtyu1120]

Sadece NASA’da değil, havacılık/otomotiv gibi hayatın doğrudan söz konusu olduğu sektörlerde de benzer kodlama kurallarının sıkça uygulandığı görülüyor gibi haha

[ssssut]

https://github.com/kubernetes/kubernetes/…
Kubernetes kaynak kodunda, NASA Space Shuttle uygulama kaynak kodu yazım yöntemiyle yazıldığı söylenen 'space shuttle style' kod bloğu aklıma geldi.
İlgili HN başlığı: https://news.ycombinator.com/item?id=18772873

[GN⁺]

Hacker News yorumu

• Asıl metni okursanız, her maddenin amacını açıkladığını görürsünüz
• Asıl metin esas olarak C dilini hedefliyor ve C ile yazılmış kritik uygulamaların güvenilirliğini daha sıkı denetleyebilmek için optimize etmeyi amaçlıyor
• Asıl yazar ne yaptığını açıkça biliyor ve C kodunu doğrulamanın çeşitli yöntemlerini açıklıyor
• Asıl metindeki mantığın tamamı kusursuz biçimde anlaşılıyor
  • Muhtemelen C’yi küçük sistemlerde öğrendiğim içindir
  • İmplante edilebilir tıbbi cihazlara yönelik donanım için C öğrendim ve laboratuvarda da benzer yönergeleri izledim
• Son paragraf harika
  • Kurallar ilk başta katı gelebilir, ancak kodun doğruluğuna hayatların bağlı olabileceği durumları hesaba katmak gerekir
  • Araba emniyet kemeri gibi, başta rahatsız edici olabilir ama zamanla doğal biçimde kullanırsınız
• Bu kurallara yönelik eleştirim OP’ninkinden oldukça farklı olurdu
  • setjmp/longjmp savunan bir yazıyı en baştan ciddiye almakta zorlandım
  • Bu kalıp, ona yaklaşmış herkes için bariz biçimde sorunlu
  • Yazı, setjmp/longjmp'nin exception handling olduğunu iddia ediyor
  • Exception handling'in iyi olduğunu savunuyor
  • İkinci öncülde ciddi bir sorun var
• Döngüler için maksimum yineleme sayısı belirlenmesi kastediliyor
  • 10^90 saçma ve alakasız
  • Bu noktadan sonra yazıyı okumadım
• Kuralları eleştireceksem şu noktalara odaklanırdım
  • Fonksiyon gövdesinin uzunluğu, anlaşılma sadeliğiyle ilişkili değildir; hatta ilişki kuralın ima ettiğinin tersi olabilir
  • 2 adet assertion tamamen keyfidir; assertion yapılabilecek her şey için assertion kullanılmalıdır
  • Ada, Pascal (Delphi), JavaScript ya da fonksiyonel diller kullananlar, type ve function bildirimlerini mümkün olduğunca yerel yapmalıdır
• JavaScript’te kişisel yaklaşımım, açıkça değer yakalamak istemediğim sürece fonksiyonları iç içe tanımlamamaktır
  • Bunun nedeni eski bir zihinsel model olabilir
  • Performans profillemede, fonksiyonların her çağrıldığında yeniden tanımlandığı gösteriliyordu
  • Modern JavaScript yorumlayıcılarının artık böyle çalıştığını sanmıyorum
  • Arrow function’ların eklenmesinden sonra derin optimizasyonlar yapılmış olmalı
  • Eski alışkanlıklar kolay kaybolmuyor
  • Yerel değişkenleri yakalamayan adlandırılmış fonksiyonları dosya/modül kapsamında tutuyorum
• Diğer birçok not ilginç ve oldukça ayrıntılı
  • Yaşlı mühendislerin sevdiği türden, "teknik olarak doğru olan en iyi doğru olandır" yaklaşımı var
  • NASA kurallarının aktarmaya çalıştığı genel ihtiyat tonunu çok iyi buluyorum ve büyük ölçüde destekliyorum
• Bağlam içinde bunlar "kural"dan çok önerilen pratikler
  • Resmî "kurallar", "NPR" gibi adlara sahip belgelerde yer alır
  • Geliştiriciler bu "kurallara" uymak ya da onları görmezden gelmek zorunda değildir
• GCC, derlemeden sonra stack kullanımını ve caller-callee ilişkilerini verebilir
  • setjmp() ve longjmp() exception ele almanın kötü bir yoludur
  • Cleanup kodu çalıştırılmaz
  • Kuralın ruhu izlenirse cleanup gerektiren kaynaklar olmamalıdır
• Asıl sorun, her uygulamada farklı biçimde ortaya çıkar
  • Yineleme sınırı aşıldığında veya başlangıçta ayrılmış sabit kaynaklar yeterli olmadığında ne yapılacağı
• Günümüzde programcılar kodu ekranda okuduğu için kâğıt boyutunun artık neden ilgili olmadığının açık olmadığı söyleniyor
  • Standart sayfa ve karakter boyutuna dair tekrar vardı
  • Bu yalnızca kâğıdın sınırlarıyla değil, insanın sınırlarıyla da ilgiliydi
• Özyineleme hakkındaki kural, gerekli stack alanı için statik olarak bilinen bir üst sınırı garanti etmeye yöneliktir
  • Derleyiciye bağımlı olduğu yönündeki eleştiri doğru, ancak çalışma zamanındaki üst sınırı türetmek için bir ön koşul
  • Güvenlik açısından kritik sistemlerde garanti edilmiş yanıt süresi gerekir
• Başlık, bunun kurallara yönelik bir eleştiri olduğunu belirtmeli
• Sıkı type kullanımını teşvik ediyor
  • Tüm skaler type’lar için sıkı type kullanımı
  • İmparatorluk birimleri ile metrik birimleri karıştırmamak

[roxie]

> Başlık bunun kurallara yönelik bir eleştiri olduğunu belirtmeli

222