Rakamlar programlarda o kadar doğal görünüyor ki, birçok geliştirici onlara matematikte olduğu gibi sezgisel olarak davranıyor: ilave, çıkarma, çarpma: Neler yanlış gitmeli? Ancak pratikte, çok sayıda tuzak saklanıyor. Depolama sınırları, yuvarlama hataları, veri türleri ve tam sayıların farklı işlenmesi arasındaki dönüşümler ve kayar noktalar tekrar tekrar felaket hatalarına yol açar.
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir. “Yazılım Hatalarından Öğren” dizisinin bölümleri:
Desen 2: Taşma, Aritmetik ve Hassasiyet: Sayılar devrildiğinde
Bunun ikonik bir örneği, 1996'da ilk Ariane 5'in başarısız olmasıdır. Başlamadan sadece 37 saniye sonra, roket yörüngesini terk etti, kontrolsüz bir şekilde ve nihayet yok olmaya başladı. Nedeni, rokette maddi bir problem veya kusur değil, atalet navigasyon yazılımındaki yazılımın bir hatasıydı.
Özellikle, sistem 64 -BIT kayma komisyon değerini 16 BIT tam sayıya dönüştürmeye çalıştı. Bununla birlikte, değer Ariane 5 için çok büyüktü ve daha sonra bir istisnayı tetikleyen bir taşma vardı. Sonuç: Tüm kontrol sistemi vefat etti. Roketin eşzamanlı olarak meydana gelen iki özdeş sistemi olduğundan, hata hemen yedeklemede tekrarlandı – bu nedenle artıklık yardımcı olamadı.
Bu şu soruyu gündeme getiriyor: Böyle bir şey neden çoklu bir uzay programında oluyor? Cevap aslında öğretici: ARIANE 5 yazılımı, öncül Model Ariane 4'e dayanıyordu. Değer alanları daha küçüktü ve 16 Bit entegrasyonu tamamen yeterliydi. Ancak Ariane 5'te hızlandırmalar başka bir alandaydı. Eski koşullar artık uyum sağlamıyor, ancak geliştiriciler ilgili kod yollarını asla kontrol etmediler – sonuçta, yazılım yıllarca güvenilir bir şekilde çalıştı.
Bu model bugün hala sayısız projede bulunabilir:
- Geliştiriciler, yeni çalışma koşulları için geçerliliğini doğrulamadan eski kod yollarının kontrolünü ele alırlar.
- Sınırda durumda, örtük dönüşümler veya eksik alan testleri taşmaya yol açar.
- Ariane örneğinde olduğu gibi, hataların tedavisi eksiktir veya çok küreseldir, burada tek bir istisna toplam bir başarısızlığa yol açar.
Uygulamada, geliştirici tamamen günlük projelerde bile bu riski tekrar tekrar karşılıyor. Tipik belirtiler:
- Ani atlamalar veya noktalardaki negatif değerler,
NaN–Inf-Yağlayıcı E değerleri- Sadece çok sayıda veya uzun vadede belirgin hale gelen sessiz yuvarlama hataları.
En kötüsü, karşı önlemlerin iyi bilinmesidir, ancak zaman ve maliyet nedenleriyle genellikle ihmal edilirler:
- Açık alan analizi: Özellikle aldığınızda, tüm değer aralıklarının hala adapte olup olmadığını kontrol edin.
- Satürn aritmetiği veya sıkılaştırma: Bir değer izin verilen alanı aşarsa, fark edilmeden bırakmak yerine maksimuma koyun veya işlemi kırın.
- “Kritik dönüşümlerde neredeyse “: Sessiz verilerin bozulmasından önce kendini gösteren hedeflenmiş bir hata daha iyi.
- Telemetri ve izleme: Çalışmadaki değer alanlarını izleyin ve anormal değerleri bildirin.
Psikolojik bileşen de ilginç: Birçok ekip testin kapsamına güveniyor ve test verilerinin genellikle çok güzel olduğu gerçeğini göz ardı ediyor. Sınır değerleri, ekstraksiyon ve olağandışı kombinasyonlar yaygındır. Mülkiyet, bulanık veya hedeflenen sınır testine dayalı ilk testler kritik durumları ortaya çıkarır.
Ariane 5 kazası, sonsuz bütçeye sahip son derece kritik projelerde bile, görünüşte önemsiz bir sayı sorununun milyar dolarlık bir felakete yol açabileceğini göstermiştir. BT toplumunda günlük yaşam için, bu her sayının bir model olduğu ve modellerin sınırları olduğu anlamına gelir. Bu sınırları bilen ve sağlayan herkes sadece anormal tutuklamaları önlemekle kalmaz, aynı zamanda ince yuvarlama hataları için saatlerce sorun çözme sorunlarından tasarruf sağlar.
Yazılım hatalarından öğrenin: Dizi
Bu makale dizisi, endüstri veya teknoloji ne olursa olsun, hala pratikte görünen ve hala pratikte görünen dokuz tipik hata sınıfı sunmaktadır. Her kategoride, seri nedenleri analiz eden ve yazılım geliştiricilerinin uzun vadede öğrenebileceklerinden kaynaklanan somut bir örnek sunacaktır.
Bir sonraki bölümde okuyacaksınız: Rekabet ve Planlama: Süreçler birbirini engellediğinde.
(DSÖ)
Bir yanıt yazın