Yazılım hatalarından öğrenin – Bölüm 1: Birim. Sayılar yanıltıcı hale geldiğinde

Yazılım hataları meydana geldiğinde, bu genellikle fark edilmeden ve göze çarpmaz, ancak bazen çok muhteşem ve pahalı olur. Mekansal misyonlardan başarısız oldu, borsanın anormal tutuklamalarına kusurlu tıbbi cihazlara kadar uzun bir ünlü yazılım arızası listesi var. Onları inceleyen herkes, ilk bakışta, bu hataların çoğunun benzersiz felaketler göründüğünü fark etti, ancak aslında iyi bilinen modellerin tekrarları.

Bu makale serisi, endüstri veya teknoloji ne olursa olsun, hala görünen ve hala pratikte görünen bu tipik hataların dokuzunu sunar. Her kategoride, seri nedenleri analiz eden ve yazılım geliştiricilerinin uzun vadede öğrenebileceklerinden kaynaklanan somut bir örnek sunacaktır.

Hesaplama sistemindeki hata

Yazılım tarihindeki en popüler fıkralardan biri Grace Hopper ve ünlü güve. 1947'de Grace Hopper, gerçek bir güvenin bir rölede yakaladığı Harvard Mark II hesaplama sistemi üzerinde çalıştı. Bir ekip üyesi onları bulup çıkardıktan sonra, “ilk gerçek hata bulundu” yorumuyla protokol kitabına yapıştırdı. Bu protokol kitabı şimdi bir Washington Smithsonian Müzesi'nde sergileniyor.

Bu bölüm bir kültür efsanesi haline geldi, ancak şu anda “böcek” kelimesi icat edilmedi. 1878'de Thomas Edison, makinelerde “böcekler” üzerine harflerle konuştu, yani küçük, hatalar bulmak zor. Ancak Grace Hopper, yazılım hatalarının bir böcek gibi bulunabilecek ve çıkarılabilecek bir şey olduğu fikrini modelledi.

Ancak gerçeklik genellikle daha incedir: böcekler esas olarak sistematik zayıflıkların belirtileridir. Neredeyse her muhteşem molada, değiştirilmiş bir şekilde birkaç kez bulunabilen bir şema var. Bu nedenle, bir görünüm sadece bireysel kazalar için değil, her şeyden önce temsil ettikleri hata kategorilerinde geçerlidir.

Bölüm 1: Birim ve Boyutlar: Sayılar yanıltıcı hale geldiğinde

Bu serinin başında, geliştiricilerin her gün açıkça bir şey olarak yönettikleri bir konu var – ve belki de bu yüzden bu kadar tehlikeli. Çok kolay hafife alınır: sayılarla yüzleşmekten bahsediyoruz.

1999'da NASA soruşturmasının Mars'ın iklim yörüngesinin kaybının her seferinde yazılım hataları örneği yoktur. Görevin amacı Mars atmosferini incelemekti. Bir ay yolculuktan sonra, prob gezegene yaklaştı ve yandı. Sebep neredeyse grotesque basitti: geliştiriciler yazılımdaki metrik ve emperyal birimleri karıştırdı. Sonuç, probu çok düşük bir bayrağa getiren sistematik bir navigasyon hatasıydı.

Bu kaza, sayıların bağlamsız tehlikeli olduğunu göstermektedir. 350 gibi bir sayı, bir hız, mukavemet veya enerjinin ölçüsü veya tamamen farklı bir şey anlamına gelebilir. Yazılım verileri ham rakamlar olarak işlediği sürece, birinin onları kötü yorumlama riski vardır. Farklı ekiplere sahip büyük projelerde, bu risk, her sayfa kimsenin bir yerde açıkça belgelenmediği veya teknik olarak garanti edilmediği örtük hipotezleri etkilediğinde artmaktadır.

Kalite sigortası açısından, bu hatalar özellikle sinsidir, çünkü entegrasyon testleri gibi birim testleri doğru bir şekilde geçebilir – yanlış birimler tutarlı Yanlışlar. Sorun genellikle sadece gerçekte, verileri daha önce varsayılan önkoşulları karşılamayan sensörler, aktüatörler veya dış sistemler devreye girdiğinde belirgindir. Bu kazanın çıraklığı açıktır: sayıların anlamı vardır. Modern diller ve programlama resimleri, bu anlamı açıkça yapmak için çeşitli yollar sunar:

• Nesneleri veya ambalaj türlerini değerlendirin: Yerine double VEYA float Ayrı bir tip gibi gelir ForceInNewton VEYA VelocityInMetersPerSecond kullanılmış. Bu, Unity'yi bilgi türünün bir parçası haline getirir. Bazı programlama dilleri, örneğin F#, dilin bir parçası olarak birimler için destek bile sunar.
• Fiziksel birimler için kütüphaneler: Otomatik dönüşümleri etkinleştirir ve doğru kombinasyonları zorlarlar.
• Arayüz sözleşmeleri ve uçtan uca testler: API tanımları birimleri adlandırmalıdır. Gerçek verilerle yapılan testler felaket getirmeden önce tutarsızlıkları ortaya çıkarır.

Bu teknik önlemlere ek olarak, ekibin kültürü de önemli bir rol oynamaktadır. Öncelikle Alan Adı (DDD) tarafından yönlendirilen tasarım yoluyla veya sadece tutarlı belgeler için ortak bir dile dikkat eden projeler, bu hatalardan çok daha sık önleyin.

Mars iklim yörüngesinin kaybı NASA'yı sert vurdu. Ancak, geliştiricilerin en azından bazı projelerde üniter hatalara daha fazla dikkat ettikleri ve o zamandan beri (umarım) bu hata sınıfını o zamandan beri daha ciddiye aldıkları gerçeğini de getirdi. Aynı şey günlük yaşamdaki yazılım ekipleri için de geçerlidir: sayıları bağlamsız geçen herkes sizi bir sonraki hataya davet eder.

Bir sonraki bölümde okuyacaksınız: taşma, aritmetik ve hassasiyet: sayılar devrildiğinde

(DSÖ)