Büyük ölçekli yazılımlar için mutlak sıfır hata durumuna ulaşmak mümkün müdür?


71

Örneğin 20-30 milyon dolarlık kod satırından bahsediyorum, örneğin Autodesk Maya ölçeğinde ve karmaşıklığında yazılım.

Geliştirmeyi olması gerektiği gibi dondurursanız, böyle bir şey bilgisayarlar tarafından doğrulanabiliyorsa, tüm hataları tek bir hata oluşmayacak kadar düzeltebilir misiniz? Sorunsuz bir sistemin varlığına karşı ve onun argümanları nelerdir?

Çünkü yaptığınız her düzeltmenin daha fazla hata yarattığına dair bir fikir var, ama bunun doğru olduğunu sanmıyorum.

Hatalarla, kullanıcı arabirimindeki en basit yazım hatalarından, geçici çözümü olmayan daha ciddi koruyucu hatalardan bahsediyordum. Örneğin, belirli bir komut dosyası işlevi normalleri yanlış hesaplar. Ayrıca geçici çözümler olsa bile, sorunun hala giderilmesi gerekiyor. Böylece, verilen işlevi kullanmak yerine bu belirli şeyi manuel olarak yapabileceğinizi söyleyebilirsiniz, ancak bu işlevin hala düzeltilmesi gerekir.


11
"birkaç iyi programcı tarafından söylendi" - bana üst programcı gibi gelmiyorlar. En iyi korsanlara benziyorlar. Bir programcının İLK SORUMLULUKLARINDAN biri, kodlarının ne yaptığını ve sistemi bir bütün olarak nasıl etkilediğini anlamaktır. Bu nedenle TDD, tasarım kalıpları vb. Var. Bu yapılamazsa, sistem önemsizdir - gelişim süreci kaotik, gelişigüzel, disiplinsiz, bilimsel olmayan bir şekilde yapılmıştır.
Vektör

51
Henüz bir hatanın olduğunu bilmiyorsanız, hala bir hata mı var?
Blrfl

5
@Blrf: Daha da önemlisi, Son kullanıcı bir hata olduğunu bilmiyorsa, var mı?
mattnz

40
“Yazılım tasarımı yapmanın iki yolu var. Bir yol, o kadar basit hale getirmek ki açık bir şekilde hiçbir eksiklik yok. Ve diğer bir yol o kadar karmaşık hale getirmektir ki, bariz bir eksiklik yoktur. ”- CAR Hoare
Andrew Lewis,

5
Öyle, ama birçok insan temel inançlarının sorgulanmasını istemiyor.
Joan Venge

Yanıtlar:


92

Mikey'nin belirttiği gibi, hatasız kod yazmak amaç değildir. Hedeflediğiniz şey buysa, sizin için çok kötü haberlerim var.

Kilit nokta, yazılımın karmaşıklığını büyük ölçüde hafife almaktır.

İlk önce ilk şeyler - Programınızın nasıl çalıştığının büyük resmini yok sayıyorsunuz. Mükemmel bir sistemde yalıtımlı olarak çalışmaz. "Hello World" programlarının en temel bile bir işletim sistemi üzerinde çalışır ve bu nedenle, en basit programlar bile işletim sisteminde bulunabilecek hatalara karşı hassastır.

Kütüphanelerin varlığı bunu daha karmaşık hale getirir. İşletim sistemleri oldukça kararlı olma eğilimindeyken, kütüphaneler kararlılık söz konusu olduğunda karma bir çantadır. Bazıları harika. Diğerleri ... çok değil ... Kodunuzun% 100 hatasız olmasını istiyorsanız, o zaman karşı koyacağınız her kütüphanenin tamamen hatasız olmasını sağlamanız gerekir, ve çoğu zaman bu sadece kaynak kodunuz olmayabilir.

Sonra düşünülmesi gereken konular var. Çoğu büyük ölçekli program her yerde yivler kullanır. Dikkatli olmaya ve yarış koşullarının ve kilitlenmenin yaşanmayacağı şekilde iplikler yazmaya çalışıyoruz, ancak kodun her olası birleşimini test etmek mümkün değil. Bunu etkin bir şekilde test etmek için, CPU'dan geçen olası tüm emir sıralarını incelemeniz gerekir. Bu konuda matematiği yapmadım, ancak tüm olası satranç oyunlarını sıralamanın daha kolay olacağını düşünüyorum.

Makinenin kendisine baktığımızda işler zordan imkansız hale gelir. CPU'lar mükemmel değil. RAM mükemmel değil. Sabit sürücüler mükemmel değil. Bir makine içerisindeki bileşenlerin hiçbiri mükemmel şekilde tasarlanmamıştır - "yeterince iyi" olacak şekilde tasarlanmıştır. Mükemmel bir program bile makinenin hıçkırıklarından dolayı başarısız olur. Durdurmak için yapabileceğin bir şey yok.

Alt satır: "Hatasız yazılım" yazabilir misiniz?

HAYIR

Size aksini söyleyen herhangi biri clueless değildir.

Sadece anlaşılması ve bakımı kolay bir yazılım yazmaya çalışın. Bunu yaptıktan sonra bir gün diyebilirsin.


EDIT: Bazı insanlar tamamen göz ardı ettiğim mükemmel bir nokta hakkında yorum yaptı: derleyici.

Eğer derlemede yazmıyorsanız, derleyicinin kodunuzu bozması tamamen mümkündür (kodunuzun "mükemmel" olduğunu kanıtlasanız bile).

En yaygın kullanılan derleyicilerden biri olan GCC'deki hataların listesi: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---


8
Cevap hala "hayır" dır, çünkü her zaman bir şeyin çalıştığı yerde "hatalar" olacaktır - sadece bir müşteri veya ürün sahibinin çalışmasını istemediği gibi. Bazılarımız bu özellik isteklerini arayabilir veya davranış değişikliği veya işlevsellik ekleme taleplerini söyleyebilir - ancak her gün "hata" tarafından rahatsız edilen kişiye, onları rahatsız eden şey bir hatadır. (Bu, bazı böceklerin sahibinin gözünde olduğunu söylemenin uzun bir yoludur.) HATA ÜCRETSİZ KODU imkansızdır. Amaçlanan amacı yerine getirmek için yeterince iyi olan kodu hedefleyin.
Çabuk_ancak

6
Bir adım daha ileri gideceğim: kodda gizli hatalar olabilir, örneğin, bir girişi kontrol etmek için doğru şekilde aralık içermeyen bir kodunuz olabilir. Girdi, herhangi bir nedenden dolayı hiçbir zaman menzil dışındaysa, böcek asla kendini göstermez. Ardından, bakım veya özellik değişiklikleri sırasında bir gün, bu kod parçası, ara sıra aralık dışı bir değerle egzersiz yapan DOES'ten başka bir yerden çağrılır. Böcek şimdi kendini gösterir - ama başından beri oradaydı. Tüm bunlarda delilik derecelerine sahip olabilirsiniz - ancak her yanlışlığın olasılığını ortadan kaldırmak hala mümkün değil.
Çabucak_ancak

11
@ JohnR.Strohm 556 kodlu bir program olan 'mesaj akış modülatörü' programının neden teorik 20 milyon hat sistemi ile ilgili bir sorusu olduğunu düşündüğünüzden emin değilim. Belki de, küçük programın doğruluğunu kanıtlamak zor olsa da, büyük bir programın doğruluğunu kanıtlamak astronomik olarak zor olacaktır.
Eric King,

9
Asıl soru böyle olmasa da, 'teorik olarak mümkün' ile 'pratikte mümkün' arasında devasa bir fark olduğunu belirtmek isterim. Hatasız bir 20 milyon satırlık kod üssü tartışmalı olarak teorik olarak mümkün olsa da, bugünün pazarında neredeyse kesinlikle pratik bir olanaksızlık. Kim bilir gelecek ne gösterecek.
Eric King,

4
@ JohnR.Strohm Makaleyi daha dikkatli okumalısınız. Kendilerini söylerler: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- anlam, hatasız olduğu kanıtlanamaz, aksine böceklerden daha az olması muhtemeldir. Aksine TDD gibi.
Izkata

27

Matematiksel olarak OLABİLİR Eğer 'böcek' nasıl tanımladığınıza bağlı olarak, bu tür karmaşıklık 'bugless' yazılım yazmak mümkün. Bunu kanıtlamak , her kod satırını mümkün olan her şekilde - mümkün olan her kullanım durumunda uygulayacak bir test sistemi tasarlayarak, MIGHT olarak da mümkün olabilir. Ama emin değilim - karmaşık hesaplamalar yapan bir sistemle uğraşıyorsanız, bir 'sonsuzluk problemi' ile karşılaşabilirsiniz ...

Pratik olarak konuşursak, konuştuğunuz boyut ve kapsamda bir sistemde, bu MEMNİRLİDİR . Böyle bir 'hatasız' sistem yazmak ve bunun katlanarak daha fazla zaman alacağını kanıtlamak için bir sistem yazmak 1000 yıl alabilir: olası her kullanım vakasını bulmanız ve her birini test edecek bir sistem yazmanız gerekir. birincisi - ve her kullanım durumunu, konuştuğunuz büyüklük ve kapsamda bir sistemde ele aldığınızı, makul bir süreye benzeyen herhangi bir şeyde bulunduğunuzu belirlemenin bir yolu olduğuna inanmıyorum.

IMO, sorunuz biraz yanlış yönlendirildi: Geliştiriciler olarak hedefimiz 'bugless' yazılımı yazmak değil. Hedefimiz KULLANILABİLİR, ESNEK, KOLAY BAKIMLI bir yazılım yazmaktır .

Kullanılabilir: Sistem, tasarlandığı temel gereklilikleri yerine getirir. Hatalar olabilir - ancak bunlar 'uç durumlarda' olacaktır - sistemin temellerini tehlikeye sokacak hatalar değil, aykırı değerler veya sıkıntılar - sağlam.

Sürdürülebilir: Hatalar kolayca izole edilebilir ve düzeltilebilir ve yeni hatalar YAPMAYIN.

Esnek: Sisteminiz, önemli ölçüde yeniden tasarlanma ve aksama süreleri olmadan kolayca değiştirilip genişletilebilir: Çoğu değişiklik, zaten iyi tasarlanmış desen ve çerçevelerinize uyan yeni bir sınıf veya modül eklemenizi gerektirir.

İyi tasarım uygulamaları, iyi kontrol uygulamaları, iyi ekip çalışması, vicdanlı geliştiriciler - İYİ YAZILIM için formül budur . ( MÜKEMMEL değil - ama İYİ )


3
“Bunu kanıtlamak, her kod satırını mümkün olan her şekilde - mümkün olan her kullanım durumunda uygulayacak bir test sistemi tasarlayarak matematiksel olarak da mümkün olabilir”. Dolayısıyla doğruluğu kanıtlamak için genel bir algoritma mevcut değildir.
Giorgio

3
Düzeltme: DOĞRUDANIN FORMAL MATEMATİKSEL KORUNMASI İLE TAMAMEN hatasız bir yazılım elde edildi. 1982 yılında yapıldı. Google "mesaj akış modülatörü".
John R. Strohm

6
@ JohnR.Strohm: Doğru değil. İşte sadece bir alıntı - benzer kaygıları dile getirdiği birkaç makale ve birkaç yer var: “Sıkça ortaya çıkan bir soru“ Doğrulayıcıyı doğruladınız mı? ”Dır. Akademisyenler. Elbette, eğer bir makine "Hiç yalan söyler misin?" sorusuna cevap verirse, cevap bir insan soruyu yanıtladığından daha bilgilendirici olmaz. "
Vektör

1
Herhangi bir giriş programı ve herhangi bir giriş özelliği için çalışacak genel bir algoritma olmadığını kastediyordum. Yalnızca belirli vakaları ele alabilirsiniz (örneğin, örneğiniz).
Giorgio

1
@Giorgio - yani IMO, iyi tasarım uygulamalarını takip etmek, matematiksel doğrulukla kendinizle ilgilenmekten çok daha önemlidir: kodunuzu, zaten orada olanlarla iyi bir şekilde bütünleşmesini ve bunlarla uyumlu olmasını sağlamak için tasarlayın; (gelecekler) ışığa gelmek.
Vektör

27

Bu makaleye göre , Uzay Mekiği için yerleşik yazılım çok yaklaştı - 420.000 hat programının son üç versiyonu yalnızca bir hatayla karşılaştı. Yazılım 260 erkek ve kadın grubu tarafından sağlandı. Bu insanların büyük bir kısmı, tek amacı hata bulmak olan doğrulayıcılardı.

Mekiğin Global Konumlandırma Uyduları ile gezinmesine izin vermek için yazılımın yükseltilmesi programın yalnızca% 1.5'ini veya 6.366 kod satırını etkiledi. Bu değişiklik için teknik özellikler 2.500 sayfadır. Tüm programın özellikleri, 30 cilt doldurdu ve 40.000 sayfa koştu, ya da her teknik sayfa için ortalama on satırlık bir kod satırı kullandı.

Bütçe bir sorun değildi - yılda 35 milyon dolar olarak, doğru şeyler yapmayı göze alabilirlerdi.


25
Her biri bir hata tespit etti . Kaç tane tespit edilemeyen hata olduğunu kim bilir? :)
Andres F.

8
Bu "bir hata" özel bir durumdu. Mekik orijinal olarak tasarlandı ve yazılım iki robot kolu için belirlendi. "Hata", ikinci kolu desteklemek için hala orada kod olmasıydı.
John R. Strohm

4
+1 1981'den 2011'e kadar 135 görevde hata
yapmadı

5
@MarkJ: Uzay Mekiği'nin gerçekten hataları olup olmadığını bilemeyiz. Her Uzay Mekiği misyonu sürekli, yüzlerce kişi tarafından yoğun bir şekilde izlenir ve kodlamadaki hatalar manuel olarak düzeltilir / geçersiz kılınır.
Yalan Ryan

2
@LieRyan Hangi sağlam sistemlerin güzel bir özelliğini gösterir - felaketle başarısız olmazlarsa ve her zaman manuel ayarlamaya izin verirlerse, bunun yerine fazlalıklı sistemler (kontrol merkezinde bulunanlar gibi) kullanabilirsiniz. Tabii ki, bu yalnızca gereksiz sistemlere sahipseniz ve gerçekten doğruluk ve tutarlılık sağlayabiliyorsanız anlamlıdır. Tipik bir iş başvurusunda, bir kaza genellikle tutarsız bir durumda işlem yapmak için tercih edilir - sıkıntı ile yanlış adama para göndermek arasındaki fark budur. Veya gönderilmeden para almak ...
Luaan

15

Esasen, hayır ama yine de elinden gelenin en iyisini yapmalısın. Nedenini açıklayacağım (ya da yeterli sabrınız yoksa sonuca atlayın)

İkili aramanın uygulanması kadar önemsiz bir problem düşünün. Çok popüler bir uygulamanın yaklaşık yirmi yıl boyunca tespit edilmeyen bir hatası vardı . Eğer yirmi satır, böceklerin yaygın olarak kullanılmasının ve hatta sözde doğrulanmasının kanıtlanması için yirmi yıl sürerse, gerçekten büyük bir programın hatasız olmasını bekleyebilir miyiz?

Yine de büyük bir programın kaç tane hata beklemesini bekliyoruz? Bulduğum bir rakam "1000 satır başına 10 hata" idi (Kod Tamamlandı 2. baskı, sayfa 517 - sadece bir örnek kullandı, herhangi bir veriyi alıntılamadı) Bu bize yazılımınızda 200 000 ila 300 000 hata veriyor. Neyse ki, programın kalitesini iyileştirmek için yollarımız var. Birim testi, kod incelemeleri ve normal manuel testlerin böcek sayısını azalttığı bilinmektedir. Yine de, numara hala yüksek olacak.

Tüm böceklerin% 95'ini çözebilirsek inanılmaz olurdu. Ve yine de yazılımda hala 10 000 ila 15 000 böcek var.

Neyse ki, yazılım yaygın olarak kullanıldığından (ve bu nedenle de geniş çapta test edildiğinden) hatalar bulunacaktır. Böylece yavaş yavaş daha az böcek alacağız. Bununla birlikte, daha az sayıda hata, diğerlerinin de bulmasının zor olduğu anlamına gelir; bu nedenle, hata onarımında doğrusal bir eğri beklemeyin. Son birkaç böcek, birkaç yıl boyunca tespit edilmekten ve kaçtıklarından kurtulabilmekten çok zorlanacak ( hiç bulundukları varsayılarak ).

Ayrıca yanlışlıkla yazılımın değişmemesi durumunda yeni bir hata çıkmayacağını varsayıyor gibi görünüyorsunuz. Yazılım üçüncü taraf kütüphanelerine bağlıysa, yeni sürümler bazı özellikleri bozabilir - uygulamanın kodu aynı olmasına rağmen yeni hatalar ortaya çıkar. Yeni işletim sistemleri daha önce mükemmel çalışan bir uygulamayı da bozabilir (popüler bir örnek için Windows Vista'ya bakın). Derleyici hataları, vb. De düşünün.

Kodlama araçlarının buggy yazılımı sorununu gerçekten çözüp çözemeyeceği belli değil. Herhangi bir program için durma problemini çözmek kesinlikle mümkün değildir , ancak bir programın belirtildiği gibi davrandığını kanıtlamak mümkün olabilir ... Ama sonra ne? Belki de deneme programında bir hata var. Belki şartnamenin kendisinde bir hata vardır.

Çok açık bir şekilde, böcek sayısını büyük ölçüde azaltabiliriz, ancak bu sıfıra ulaşmamız gerçekten mümkün değil.

Çünkü yaptığınız her düzeltmenin daha fazla hata yarattığına dair bir fikir var , ama bunun doğru olduğunu sanmıyorum.

(vurgu eklendi)

Haklısın. Bu ifade yanlıştır. İşte bir örnek:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

Şimdi bu hatayı düzeltelim:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

Görmek? Bir hatayı düzelttik ve yenilerini tanımadık.

Bununla birlikte, bir hatayı her düzelttiğinizde yeni bir tane yaratma riskiyle karşı karşıya kalmanıza rağmen, bu risk hafifletilebilir (örneğin, birim testlerinde) kesinlikle doğrudur.

Diyelim ki düzeltdiğim her 100 hata için, yanlışlıkla yeni bir tanesini tanıtıyorum. 10 000 hatayı düzeltirsem, 100 yeni hatayı tanıtırım. Ve eğer bu yeni hataları düzeltirsem, bir böcek tanıtırım. Ama ne olmuş yani? Program şimdi 9 999 daha az hataya sahip, bu yüzden muhtemelen olduğundan daha iyi (yeni hatanın öncekilerden 10 000 kat daha kötü olmadığını varsayarak).

Ayrıca, bir hatayı düzeltmek yenilerini ortaya çıkarabilir . Ancak bu hatalar da düzeltilebilir. İşleri doğru yaparsanız, sonunda yazılım başladığından daha iyi bir durumda olacaktır.

Birkaç üst programcı tarafından OP'de bahsettiğim nosyondan dolayı pek çok hatayı düzeltmemenin daha iyi olacağı konusunda yaşlıydım.

Bu davranış ihmal edicidir. Bir hata varsa ve düzeltebilirsiniz. Yap. Elbette yenilerini eklememek için elinizden gelenin en iyisini yapmalısınız, ancak düzeltdiğim her 10 ciddi hata için küçük bir hata tanıttıysam, bu hata düzeltmeyi durdurmak için geçerli bir neden değildir. Aslında, hataları düzeltmek için iyi bir nedendir .

Böylece daha az hata giderirsiniz, daha az hata gelecekte size geri döner

Ne kadar az hata giderirseniz, yazılımınızdaki hata o kadar fazla kalacaktır, bu da kullanıcılarınızı rahatsız edecektir. Gerçekten, "gelecekte size geri dönmeyecekler". Geri dönmeyecekler, çünkü ilk başta hiç ayrılmadılar. “Geri gel” kavramı, gerileme ile ilgilidir. Yine, gerileme riskini azaltmak mümkündür.

Bazı hatalar düzeltilemez çünkü o kadar yaygın bir şekilde kullanıldı ki, insanlar onlara güvenmeye başladılar ve hatayı düzeltmek bu kullanıcılar için programı bozacaktı. Olur. Ancak, bu durumda gerçekten hata olarak kabul edilebilir mi?

"Bir hatayı düzeltmek, bir hatayı düzeltmek" zihniyeti , o kadar okunaksız ve anlaşılmaz olan “Korkunç Canavar” kodu ile ilişkili olabilir . Kod üssünüzde bir canavar varsa, önce herhangi bir şey yapmadan önce onu canavardan çıkarmanız gerekebilir.

Eğer korkunç bir programcı iseniz Son olarak, bu şey risk var sen dokunma yeni böcek yaratır. Bu tabii ki kıdemli programcıları gerginleştirir. Ancak, "Hiçbir şey yapma. Hiçbir şeye dokunma. Nefes bile almayın" diyerek. muhtemelen sağlıklı bir çalışma ortamı yaratmanın doğru yolu değildir. Eğitim daha iyi.

Sonuç:

  • Tonlarca yeni özellik almaya devam eden, ancak hata düzeltmeleri yapılmayan bir yazılım kaçınılmaz olarak emecektir.
  • Orta düzeyde yeni özelliklere sahip olan ancak hatalarını gideren yazılımın kullanılabilir olma şansı daha yüksektir.
  • Çok az böcek sahibi olmaya çalışanlar (ortalama olarak) umursamayanlardan daha az böcek kullanırlar.
  • Bir programın sonunda hatasız hale gelmesini beklemek mantıklı değildir.
  • Üst düzey programcılar mutlaka yetkili değildir.
  • Hatalarını düzelt.
  • Yazılımınızın kalitesini artıran metodolojileri benimseyin.

+1: İkili arama örneğini kendim aradım, dövüldüm;) 20 yıl boyunca geniş çapta tartışılan ve dolaştırılan kod 20 satırlık bir hata tutarsa, 20 milyon satırlık bir kod kodu için ne kadar zamana ihtiyacınız olacak? en az düzine meşgul insan hiç bakacak?
scrwtp

Teşekkürler. Acaba bu ikili arama hatasının (daha önce hiç duymadığım), çok fazla kod yazmayı düşünmeden kopyalayan insanlarla ilgili olup olmadığını merak ediyorum. Ayrıca, numaralandırmak için bile mümkün olan bu kadar fazla böcek varsa, belki kullandığımız araçlar ve uygulamalar uygun değildir?
Joan Venge

1
@JoanVenge Bu zor böcek bulmak için nasıl olabileceğini göstermek için bu örnek alıntı. Bu durumda, kopya yapıştırma işlemi aslında doğru bir şey olduğu için yapılması doğru bir şeydi ve sıfırdan yazılmış uygulamaların büyük olasılıkla daha fazla hataya sahip olacağı kesindi. Kullandığımız araçlar ve uygulamalar - genel olarak bir endüstri olarak - kesinlikle uygun değil. En iyi uygulamaların göz ardı edilmesi kolaydır ve kötü alışkanlıkların korunması kolaydır. Sonuçta, böcekler her zaman var olacaktır çünkü insanlar mükemmel değildir. Ancak, elimizden gelenin en iyisini yaparak ve kaliteli eğitim konusunda ısrar ederek böcek sayısını azaltabiliriz.
luiscubal

7
İkili arama kodundaki hatanın bu sorunun ne kadar karmaşık olduğunu gösterdiğini düşünüyorum. Aramadaki altta yatan hata, ek olarak potansiyel bir tamsayı taşmasıydı. Bu tür "hatalar" her yerdedir çünkü çoğu halk, girdilerin taşmalara neden olacak kadar büyük olmayacağı konusunda örtük (ve bazen yanlış) bir varsayıma güvenir. Gerçekten bir hata mı, yoksa sadece belgelenmiş bir arayüz sözleşmesi mi? En son ne zaman menzile girdiğiniz zaman, summanları bir tamsayı ekinde mi kontrol ettiniz veya durumdan sonra taşma olup olmadığını kontrol ettiniz?
Charles E. Grant

4
Örnek sunucularınız, programlama dili ve araç kalitesi hakkında oldukça açık bir gözlem vurgulamak için sunucular. Sağlam bir dil için üretim kalitesinde bir derleyici, ilk örneğinizi derlemeyi reddetmeli, bunun yerine ölümcül bir derleme hatası verdi. Böyle bir suistimali derlemenin MÜMKÜNDÜĞÜ bile söz konusu araçların kalitesi ve hatasız yazılım dağıtımı için kullanımlarının uygulanabilirliği hakkında bilmeniz gereken her şeyi size söyler.
John R. Strohm

12

Nedenleri değil hata içermeyen programlar yazmaya çoğunlukla ekonomiktir.

Orada olan bir programın doğruluğunu kanıtlamak için matematiksel yöntemler. Yüksek kaliteli bir Bilgisayar Bilimi dersinde bunlara değinilecektir. Özellikle bu amaç için icat edilen programlama dilleri vardır. Teoride, hata olmadan programlama olduğunu mümkün.

Evet, milyonlarca yıl önce uzak bir süpernovadan atılan bir nötrino, işlemcinize doğru yere çarptığından, bazen biraz değer değiştirebilecek kusurlu donanım var. Tamam, her teoride varsayımları ve soyutlamaları vardır. Ancak, işlemcinin reklam olarak çalıştığını varsayarsak, programın da doğru şekilde çalışmasını sağlamak için matematiksel araçlar vardır.

Bu konudaki bazı yüksek oylarla verilen cevaplar yanıltıcıdır. Örneğin, Gödel'in eksiklik teoremi ve durma problemi, örneğin herhangi bir programın doğruluğuna veya yanlışlığına karar verecek otomatik bir araca sahip olamayacağınız anlamına gelir . Ancak herhangi bir programın doğruluğuna karar vermek istemiyoruz , yalnızca belirli bir programın doğruluğunun kanıtını istiyoruz .

(Analog olarak, herhangi bir matematik teoreminin gerçeğini otomatik olarak belirlemek için bir program yazamadığınız için , bu belirli bir matematik teoremini ispatlayamayacağınız anlamına gelmez .)

Bunun yerine, sorun şudur:

Teorik olarak hatasız bir program yazmak mümkün olsa da, bunu yapmak çok pahalı olurdu . Doğruluğunun kanıtı olan bir kod yazmak , bir duvara yapışıp çıkmadığını görmek gibi bir şey atmaktan daha karmaşıktır. “Yapışıp Yapmadığını Görmek” ünite testleriyle yapılsa bile; ve pek çok programcı bunu bile yapmıyor. Çoğu programcı bunun nasıl yapılacağını bile bilmez, bu da bir şirket olarak daha pahalı olanları işe almak zorunda kalacağınız anlamına gelir.

Tüm maliyetleri göz önünde bulundurarak, tipik bir müşteri, zamanın% 99'unu (ve ek güncelleştirmeleri yükledikten sonraki zamanın% 99.9'u) iyi çalışan ucuz bir yazılımdan,% 100'ünün% 100'ünü çalıştıran, binlerce kat daha pahalı bir yazılıma sahip olmaktan daha mutludur. zaman. Ayrıca, müşteri bu yazılımı şimdi istiyor , on ya da yirmi yılda değil.

Bu nedenle, insanlar bilerek bazı böcek şansı olan, böceklerin çok sık olmadığı ve çok ciddi olmadığı ve kombinasyonun yeterince hızlı ve ucuz olduğu optimum kombinasyona ulaşmaya çalışan yazılım üretiyorlar. Gerçek hayatta en fazla kar sağlayan kombinasyon. (Bazen, rakipleriniz herhangi bir şey yayınlamadan önce bir yazılımın hataları tam olarak yayınlaması ve yalnızca rakipleriniz ilk iyi sürümlerini yayınlamaya hazır olduklarında daha iyi bir sürüm 2.0 yayınlanması anlamına gelir.)

Geliştirmeyi olması gerektiği gibi dondurursanız, böyle bir şey bilgisayarlar tarafından doğrulanabiliyorsa, tüm hataları tek bir hata oluşmayacak kadar düzeltebilir misiniz?

Matematiksel olarak konuşabilirsin. Ekonomik olarak konuşursak, neden kimse bunu yapsın? Belki yirmi yıl ve birkaç milyon dolar harcamak anlamına gelir. Bu arada, müşteriler yeni özellikler ister ve donmuş uygulamalarınız bunları sağlayamazdı. Bu yüzden, mükemmel versiyonunuz hazır olduğunda, piyasa zaten rakipleriniz tarafından alınmaktadır.

Ekonomik olarak düşünmek tamam. Paranın ve zamanın önemli olduğu bir dünyada yaşıyoruz. Ancak ekonomik nedenlerden dolayı bir şey yapmadığımız için, teoride bile bunun nasıl yapılamayacağı konusunda saçma konuşmamalıyız. Kim bilir ... belki birkaç yıl içinde doğruluğu kolaylaştırabilecek yeni programlama dilleri ve araçları olacak .


Teşekkürler, çoğu yazılımın% 99 oranında çalışmasını diliyorum, ancak OP'de olduğu gibi kullandığım çoğu büyük yazılım son derece hatalı. Ancak tekel olduğunu ve rakipleri satın almanın da bunu etkilediğini düşünüyorum. Ama amacını anlıyorum.
Joan Venge

1
"Pahalı" görecelidir. Hataları bulma ve sabitleme maliyetini, örneğin birkaç hastayı öldüren ve birkaçını sakatlayan bir radyoterapi makinesinin maliyeti ile karşılaştırın. (Google "Therac 25".)
John R. Strohm

6

Hayır.

David Hilbert , 1900 yılında, temel olarak dünyadan, aritmetiğin amaçlandığı gibi çalıştığını kanıtlamasını isteyen ikinci matematik problemini önerdi . Daha sonra mantıksal olarak benzer bir şey isteyen " Entscheidungsproblem " i tamamladı. Kurt_Gödel'in " ilk eksiklik teoremi " 1931'de hiçbir temel aritmetik teorisinin hem tutarlı hem de eksiksiz olamayacağını kanıtladı. Alan Turing'in Entscheidungsproblem'i " durma problemi " olarak göstermesi, konuyu doğrudan bu sorunun kalbine taşıdı; burada bir programın tamamlanıp bitmeyeceğini ispatlamanın imkansız olduğunu ispatladı. Bu belirsizliği göz önüne alındığındaAyrıca, bir programın hataları olup olmadığını ispatlamak da mümkün değildir.

Bunların hiçbiri aramızdaki uygulayıcı programcıları hiçbir hata için çaba göstermekten kurtarmaz. Sadece genel olarak başaramayacağımız anlamına geliyor.


9
Karar verilemezlik sadece genel olarak geçerlidir - ne doğru ne de yanlış olduğunu kanıtlayabileceğiniz programlar vardır. Ancak belirli bir program için doğruluk (veya daha sık: yanlışlık) sıklıkla kanıtlanabilir. Bu, sizin resmi bir dil belirtiminiz olduğunu ve ispat edilebilir derecede doğru bir derleyiciniz olduğunu varsayıyor - ikincisi, herhangi bir üst seviye programlama dili için mevcut değil.
Daniel,

İlgili teorik arka planı alıntılamak için +1. Henüz "Entscheidungsproblem" in Almancadaki gibi İngilizce olarak adlandırıldığını bilmiyordum!
Peopleware,

5
Daniel ile aynı fikirde. Buradaki zorluk tek bir örnekle ilgilidir; Durma problemleri olası tüm durumlarla ilgilidir. Önemsizce int main() { return 0; } durur ve hatasızdır .
MSalters

1
Durma Sorunu, bir programın tamamlanıp bitmeyeceğini ispatlamanın imkansız olduğunu söylemez; o diyor orada var o kanıtlamak mümkün olduğu programlar. Düzenli günlük programlar bu sınıfta değildir. "Turing'in kanıtı, algoritmaların durup durmadığını belirlemek için genel bir yöntem veya algoritma olamayacağını gösterse de, bu sorunun bireysel örneklerinin saldırıya karşı çok iyi bir duyarlılığı olabilir. Belirli bir algoritma verildiğinde, çoğu zaman herhangi bir giriş için durması gerektiğini gösterebilir, Aslında bilgisayar bilimcileri çoğu zaman bunu sadece doğruluk kanıtının bir parçası olarak yaparlar. ”
endolith

6

Errare humanum est

Gereklilikleri yerine getirdiğini matematiksel olarak kanıtlamak için kullanabileceğiniz B-yöntemi gibi resmi bir dille kod yazsanız bile ,

Resmi bir belirtim dili kullanıyor olsanız bile,

Her zaman, kullanıcının ihtiyaçlarını bir veya daha fazla beyinden bir bilgisayara çıkarmaktan oluşan bir insan adımı vardır.

Bu insan adımı hataya açık ve solucan elmanın içinde.


1
Bir program istenenin yerine ne istenirse yapıldığında hala bir hata mı var?
MSalters

Sanırım öyle ..
Joan Venge

4
@ MSalters - Tabii ki öyle. Sözleşmeye dayalı bir bakış açısıyla değil, sonunda müşteri problemini çözmedi. Bilgisayarları sorduğu, amaçladığı olmayan bir uçakla uçar mısın?
mouviciel

3

Karşılaştığım "hataların" adil bir oranı, sistem tasarımı ile müşteri beklentisi arasındaki uyumsuzluklar olarak daha doğru bir şekilde tanımlanabilir.

Şimdi, bu böcekleri isimlendirmek veya söylememek akademik olmakla birlikte, gerçek şu ki, iyi bir bakım çalışması, yanlış iletişimin ve müşteri beklentilerinin kaymasının doğrudan bir sonucu olarak ortaya çıkmaktadır.

Bir sistem bir teknik özellik yerine getirme anlamında teknik olarak, kesinlikle "doğru" olsa bile (ancak gerçek dünyadaki ticari yazılımlar için mümkün olmayabilir), o zaman yazılımın işlevini müşterinizinkiyle eşleştirmede sorun yaşarsınız. Değişen ve kötü tanımlanmış beklentiler.

Kısacası:

Hayır.


+1 Bir geliştirici ve müşteri, bir 'böceği' neyi tanımladığı konusunda oldukça farklı görüşlere sahip olabilir.
GrandmasterB

Peki ya geliştirici aynı zamanda kullanıcı ise? Genel olarak, bu insanların kullanım açısından en iyi yazılımları buldum, çünkü tam olarak bir şeyin nasıl çalışması gerektiğini, vb.
Joan Venge

2

Yeterince sıkı ve kısıtlı bir spesifikasyonunuz varsa, hatasız bir programı ispatlayabilirsiniz, ancak sistemdeki her şeyin doğru çalışmasıyla ilgili kanıtlanamayan varsayımlara dayanabilirsiniz. Bu, şartnamenin asıl sorunu kimler tarafından veya hizmeti kullanan kişi tarafından doğru olarak değerlendirileceğini ispat etmenin bir yolu olmadığı şeklinde veriliyor.


1

Jim Shore'nin No Bugs adlı bölümünü bu konuyla ilgili çok yararlı bir okuma olarak buldum . Kısa biçim: Böcek üretmeden gelişmek mümkün değildir - ancak mümkün olduğu kadar erken tespit edebileceğimiz şekilde çalışabiliriz.

Kodun kendisi üretimi sırasında. Örneğin, geliştirme sırasında sık sık Birim Testleri yazıp çalıştırarak, kodun yapması gerekeni yaptığını sürekli olarak temin ederiz. Ayrıca, mevcut kodu, amaçlanan sistem davranışını en açık şekilde ifade edecek şekilde sürekli olarak yeniden yazmak yararlıdır.

Bununla birlikte, sizin durumunuzda, zaten var olan bir kod tabanından milyonlarca satır koddan bahsediyorsunuz. Eğer böyle bir sistem hatasından kurtulmak istiyorsanız, her şeyden önce bu sistem için "hata" nın ne olduğunu bilmek zorundasınız. Sistemin işlevselliğini güvence altına alan post-hoc test paketleri yazabilirsiniz (henüz mevcut değilse). Bu testlerin ağı , doğru sistem davranışı için yaklaşık bir tanım görevi görebilir . Ancak kodunuz ne kadar fazlaysa, bu tür egzersizlerde o kadar çok çaba sarf edilir. Bu nedenle, çoğu şirket bir uzlaşma sağlar: sistemdeki en sinir bozucu hataları gidermek için kusur listeleri, hata listeleri ve bakım ile birlikte çalışırlar.


1

Bilgisayar parçası tarafından doğrulama hakkında.

Bilgisayar kullanarak bir programı doğrulamanın iki yolu vardır. Biri test ediyor, diğeri ispat sistemi kullanıyor.

Kapsamlı testler mümkün olmaz yapılmaz, test bir programın hataları olmadığını, sadece bazılarının olduğunu gösteremez hale gelir. (Ve testlerinizin kendilerinin böcek varlığı için test etmediğini gösterme sorununuz var).

Bir prova sistemi kullanmak için, resmi gereksinimlerden başlıyorsunuz (ve kendileri de hata olabilir, umarım gereksinimler için kullanılan dil, bir programlama dili ile orada bir hata olmadığı konusunda kendinizi ikna etmek için daha uygun olacaktır) ve programın hatasız olduğunu kanıtlayan sistemlerin yardımı (ve kanıtlama sistemlerinde hatalar sorunu var, ancak kendilerini doğruladılar). Tekniğin mevcut durumu bir C alt kümesinin derleyicisidir (ve alt küme akademik değildir, "CompCert, C'nin tüm MISRA -C 2004 alt kümesini destekler, ayrıca MISRA tarafından dışlanan birçok özellik").


Donald Knuth'dan alıntı yapmak (bellekten): Bir programın hatasız olduğunu ispatlayabilirsiniz, ancak bu hiçbir
hataya yol açmadığı

1

Hayır, çünkü uygulamanın çalıştığı bilgisayar ve yazılım ortamı, kod donmuş olsa bile değişmeye devam edecektir. İşletim sistemi, aygıtlar ve sürücüler ile birlikte yamalar ve düzeltmelerle birlikte gelişmeye devam ediyor. Bilinen bir hataya varmadığınızı düşündüğünüzde, AMD veya nVidia, video alt sistemiyle etkileşiminizi etkileyen bir video sürücüsü güncellemesi yayınlayacak. Artık uygulamanızın belirli bir video kartı veya yapılandırması (SLI® LOL) olan müşterileri için görsel kusurları (yanıp sönme, titreme veya kare hızı azaltma gibi) var.

Donanım ve işletim sisteminin yanı sıra, kontrolünüzün ötesinde de gelişecek en önemli uygulamaların altında bir dizi ara katman ürünü de var ve aynı şekilde kodunuzu sıfır hata durumuna getirdiğinizde altındaki katmanlar EOL'lenmiş oluyor.

Teknoloji, teknolojiyi kullanan işlerin yanı sıra gelişir ve “serbest bırakma” kodu fikri mümkün veya mümkün değildir. Yeni bir özellik seti isteyen işletme, "bilinen tüm hataları kovalarken kodumuz kilitlendi ve hiç kimse X ay içinde geçerli bir yazılım hatası bildirmedi" şeklinde yanıt vermeyecek. İşletme bu çizgiyi satın alsa bile, X aylar sonra yeni özelliklerin nasıl ortaya çıktığını soracaklar ve cevap olamaz "dondurarak genişletmeye karar verdik çünkü Oracle sadece bir yama yayınladı ve X'e daha fazla ay ayırmamız gerekiyor Bunu belgelemek için ".

Hayır, bir noktada işletme, teknoloji hızında ilerlemek için ihtiyacı destekleyen daha esnek bir geliştirme ekibi arayacak. Modern gelişim ekiplerinin karşılaştığı temel sorun budur.


0

Evet ama asla emin olamayacaksın. Ne kadar çok bakarsan o kadar çok bulacaksın. Sistem ne kadar ağır kullanılırsa ve kenar kasaları da o kadar fazla kullanılırsa, orijinal niyet veya şartnameyle başka bir uyuşmazlık bulabilirsiniz. Bu, bir hatanın kendisinin kesin bir şey olmadığını ima eder ve sıklıkla bazı kişilerin algılanan bir anomaliyi ne kadar kötü değerlendirdiğine bağlı olarak yorumlamaya bağlı olacaktır.

Bu bulanık bir şey. Birkaç sistem son bite kadar belirtildi. Bir sistem iyi çalışıyorsa ve kullanıcılar herhangi bir şikayete sahip değilse (hiçbir şey tarafından engellenmemişlerdir) ve tamamen buna adapte olmuşlarsa, hatasız olarak da adlandırabilirsiniz.


-2

Yeterli disiplin ve paylaşılan ekip kültürü verildiğinde hatasız bir yazılım sunmak mümkündür . (Ve çok faktörlü modüler kod, kapsamlı bir otomatik testler paketi, kusurları denetleme ve işlemlerinizi uyarlama ve çaba ve alçakgönüllülük gerektiren ancak binlerce katı geri ödeme gerektiren diğer birçok şey)

Ancak bunu yaparken, genellikle bir 20 MLOC sistemi kurmak için yola çıkmazsınız. Eğer hatasız kod yazmak sizin hedefiniz değilse, pek çok MLOC sistemi de inşa etmemelisiniz.

Benim kendi akıl yürütmem aşağıdaki gibidir:

Bazı kişilerin yerine getirme ihtiyacı vardır. Bazı kişilerin (muhtemelen aynı, muhtemelen farklı olanları), yazılıma olan ihtiyacı karşılamak için bir bütçesi vardır. Bütün bu insanlar paralarından bir miktar faydalanmayı bekliyorlar.

Bütçeli bir kişi programcı denilen bazı insanlara (muhtemelen aynı, muhtemelen farklı) ödeme yapacak , böylece bu programcılar zamanlarının bir kısmı üzerinde anlaşılan ihtiyacı karşılayacak yazılıma dönüştüreceklerdir.

Bu nedenle bu programcılar, bir başkasının parasını ihtiyacı karşılayan yazılıma dönüştürmek için çalışmaktadır. Bu parayı iyi bir şekilde kullanmak onların sorumluluğundadır.

Bunun, sorunuzla ilgili aşağıdaki etkileri vardır:

  • Yazılımda bir hata olduğu göz önüne alındığında, bunu düzeltebilir misiniz? Bir hatayı düzeltmek için bir programlayıcıya ihtiyacınız vardır ve programcı paraya mal olacaktır. Bir programcı parayı harcamak için harcayacağına karar veremez. Bütçeyi tutan kişinin rolüdür.
  • Sonunda sabitlenmemiş hataları bırakmadan bir 20MLOC yazılımını sıfırdan oluşturabilir miyim? Şey, büyük miktarda para harcamayı amaçlayan bir 20MLOC oluşturmak için yola koyuldum. Bu finansal olarak aptalca. Ve bir günde inşa edilmedi. Ancak yazılım, yarının değil, bugünün ihtiyaçları içindir. Birçok programcı işe alarak gelişmeyi paralelleştirmek için yanlış yönlendirilmiş bir girişim olacaktır . Ama sonra, ortak bir kültür elde etmeyecek ve böcekler oluşacak, israf ve gecikme olacak ve bunları düzeltmek için para tükenecek. Henüz bu boyutta hatasız bir sistem görmedim. (Sorunsuz sistemler ve 20MLOC sistemleri gördüm, ancak bunlar aynı değildi)
  • Yazmadığım bir 20MLOC sisteminin bakımından sorumluyum. Sıfır bilinen hatalara ulaşabilecek miyim? Bu programlayıcılara bağlı değildir. Hataları düzeltmeye karar veremezler çünkü hattaki paraları değil. Kalan hataları düzeltmek için yeterli yatırım getirisi var mı? Peki, sistem bir süredir buralardaydı ve kullanıcılar buna alıştı ve günlük işlerinde avantajlarını sağlamak için sistemin tuhaflıklarını kullandı. Hataları ilke olarak düzeltirseniz, parası olan kişi , sistemden kaybolan, daha da fazla paraya mal olan belirtilmemiş bir özelliği yeniden geliştirmek için ödeme yapmak zorunda kalabilir .

Her şey parayla ilgili ve haklı olarak öyle.


-2

Evet.

Ama bildiğiniz gibi, buna değmek için çok fazla çaba gerekiyor.

Cevabımı savunmadan önce, bir hatanın ne olduğunu tanımlamalıyız:

  • Bir hata, spesifikasyona aykırı bir davranıştır.
  • Bununla birlikte, tarifnamedeki aksaklıklar (örneğin, robotiğin 0ncı kanunu) yazılım hataları olarak sayılmaz.
  • Ekstra özellikler, teknik özelliklerde yasaklanmadıkça hata sayılmaz.
  • Argüman uğruna, şartnamedeki çelişkiler de yazılım hataları olarak sayılmaz.

Şimdi, umarız bildiğiniz gibi, iyi yazılım mimarileri modülerdir, böylece her modül ayrı ayrı test edilebilir (veya manuel olarak test edilebilir veya her neyse). Disiplinli ve dikkatli testler yaparak, üzerinde hata olmayan bireysel modüller yazmak mümkündür.

"Fakat bekle!" "Bir modülün beklenmedik (ancak yine de doğru) davranışı diğerinde hataya neden olursa?" O zaman böcek ikinci modüldedir. Hatasız modüller API olarak kabul edilebilir ve bildiğiniz gibi API'ler doğru kullanılmaya özen gösterir.

Kurşun geçirmez kod yazmak, geliştiricinin tarafında ileri düzeyde vakalar ve akış mantığı bilgisi gerektirir ve çoğu yazılım geliştirici ya öğrenecek kadar akıllı değildir ya da umursamıyor. Ya da daha sık, son tarihte.

"Ama bana duracak bir yer ver, ben de dünyayı hareket ettireceğim." - Arşimet


Bu çaba gerektirir, ancak geri öder.
Laurent LA RIZZA 21:16

1
Spesifikasyon hatalarını denklemin dışında bırakırsanız, tüm yazılımınız işe yaramaz hale gelir: Spesifikasyonlar, yalnızca kullanıcı gereksinimlerini nispeten resmi bir şekilde yazmak için kullanılan araçlardır, ancak sonuçta şartnameyi değil, tatmin edilmesi gereken kullanıcıdır. Ve şartnamenin yaratılması, kodu yazmak kadar yazılım geliştirmenin bir parçasıdır. Ne de olsa, tam bir resmi şartname, son davranışın yaptığı gibi sistemin davranışını tarif eder, şartname sadece verimli bir şekilde çalıştırılamaz.
cmaster
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.