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.