Yazılım hatalarının ana nedeni (ve bunların nasıl en aza indirileceği) olarak düşünüyorsunuz [kapalı]

Kusuru şöyle tanımlarım :

"uygulama tasarım veya kod içinde gereksinimlerine göre çalışmasını engelleyen bir şey."

İnsan faktörü, test eksikliği, prototip eksikliği ve bunları hafifletmek için olası fikirler gibi kusurların nedenleri hakkında fikir arıyorum.

Yazılım hatalarının başlıca nedeni yorumlamadır.

Bir özelliğin müşteri yorumu, tasarımcı yorumundan farklıdır.

Tasarımcı yorumu, programcı yorumundan farklıdır.

Çoğu metodoloji bu etkiye karşı koymanın yollarını icat etmiştir. Ama sonuçta biz sadece insanız ve kusursuz değiliz. Ayrıca, çoğu zaman bir zaman baskısı vardır ve çoğu metodoloji büyüsü baskı altındayken sıklıkla atlanır.

Test sadece sorunları erken tespit edebilir. Ancak test edenler bile insan ve% 100'ü test etmek imkansız. Eğer evren bitmeden salıvermek istiyorsan.

Yazılım hatalarının başlıca nedeninin programcı olduğunu düşünüyorum.

Diyerek değil sadece komik olmak, ama işimde gözlenen ettik büyük sorunlardan biri olduğu için kötü şartlar projede önemli kusurları ve kullanılabilirlik sorunlarını neden sorun alanının zayıf anlayışı ile birleştiğinde, toplama.

Bunun bir kısmı, son kullanıcının terminolojisini öğrenmek / anlamak istememek ve yanlış anlamalara neden olmaktan kaynaklanmaktadır.

Bunun bir kısmı, teknolojinin çok erken sürecinden bahsettiğiniz şeyden veya neden önemli olduğu hakkında bir fikri olmayan kişilere gelir.

Bunun en iyi örneği, soruların / cevapların karakterlerde ne kadar süreceğini anlamaya çalışan programcılardan birini duyduğum zamandı ... Veritabanında hangi boyut alanını kullanacağını anlamaya çalıştığını biliyordum, ancak Bunu talep eden departman, bunun neden önemli olduğunu veya boşlukların sayıldığını en sisli değildi. Bizim için bu açık görünüyor, ama onlar için gerçek bir vahiydi.

Kusurların birincil nedeni kötü yönetimdir ;)

Cidden, iyi durumda çalışan, fazla çalışması, kaliteyi kesmesi, uygun araçlara sahip olması, sessiz çalışma koşullarına sahip olması vb.Gibi bir geliştirici, sert baskı altında çalışan birinden daha az hata üretecektir.

Ayrıca kötü geliştiriciler işe yönetim de hata sayısını artırmaya yardımcı olur.

Kötü yönetim .

(yasal uyarı: Geliştiricileri işe almam ve yönetmem gerekiyor)

Herhangi bir birincil neden görmüyorum - ama belirtilmeyen bir neden, diğer kodlarla kasıtsız birleştirme . Görünmez yan etkileri olan, soyutlama katmanlarından kopan kod yazmak, veriler hakkında varsayımlar yapar (değişkenler olmaz, sabitler değildir ve bir kullanıcının girdisi güvenli değildir), endişelenmesi gerekmeyen şeylerle boğuşur kendisi ile, vb.

Çalıştığım geliştirme uygulamalarının çoğu azaltılmakla sınırlı N, çünkü bir programın karmaşıklığı en azından O(N^2)ve muhtemelen O(k^N). Tanımlama Nokuyucu için bir alıştırma olarak kaldı, ama burada siklomatik karmaşıklık gibi şeyleri düşünüyorum. Kapsülleme mantığı ve veri, sorunu bölümlere ayırarak N'yi azaltma etkisine sahiptir.

Her şeyi düşünememe.

Eksik olmak

İletişim boşluğu. İhtiyaçların toplanmasında. Zamanlanmış. Tasarım belgesinde. Fonksiyonel spesifikasyonda. Kodda (programcının istediği ve derleyiciye söylediği arasındaki boşluk).

Sosyal görgü kuralları. Sosyal olarak kabul edilemez birisini aramak kabul edilemez.

Onları tam olarak anlamadan acele etme. Fonksiyonel gereksinimleri veya teknik mimariyi tam olarak anlamadan kod yazmaya başlanması.

Programlama neredeyse otomatik olmalıdır, sadece açık olan ve zaten akılda tutulmuş olanı yazınız. Uygulamada, kodun tam olarak ne yapması gerektiğine bakmak için kodda bir sürü kusur görüyorum. Bunu kendim defalarca suçlu buldum.

Errare humanum est

Program Basıncı kesinlikle güçlü bir kaynaktır.

Acele eden geliştiriciler, gereksinimleri tam olarak belirtmek veya gereksinimlerin arkasındaki niyeti tam olarak anlamak için zaman ayırmazlar veya en iyi çözümü bulmak için alternatifleri tam olarak araştırmazlar veya yaptıkları değişikliklerin tüm son durumlarını ve etkileşimlerini tam olarak düşünebilirler veya tam bir test senaryosu seti geliştirin veya tüm birim testini tam olarak gerçekleştirin veya tam bir entegrasyon testi yapın ya da platform bağımlılıklarını tamamen göz önünde bulundurun veya yükleyiciyi tamamen test edin veya bir sonraki geliştiricinin anlayabilmesi için yaptıklarını tam olarak belgeleyin ....

Bahsedilmesi gereken bir diğer şey, dışarıdan bir test yapılmamasıdır. Geliştirici testleri yazıp çalıştırdığında, yorumunu sadece gerçek gereksinimi değil test eder. Geliştiriciler tarafından yazılan birim testi bazı hataları yakalamak için yararlı olsa da, çoğu hata bu testleri geçmiştir, ancak kullanıcının istediği veya ihtiyaç duyduğu şey değildir. Geliştirici dışında biri tarafından test edilmeyen herhangi bir yazılım test edilmez (Ve sadece geliştiricinin testlerini çalıştırmak demek istemiyorum).

Çünkü yazılım mühendisliği doğası gereği karmaşıktır. "Gümüş Mermi Yok" makalesi bunu tartışıyor.

İronik olarak, buradaki diğer cevapların birçoğu, bu makalenin dilinde "kazayla karmaşık" olan konulara değinirken, gerçekte yazılım geliştiricilerinin yaptığı şeylerin çoğu "esasen karmaşıktır", bu yüzden sadece yazılım zor, yazılım hataları olacak ve işimiz bununla başa çıkmak.

Yazılımın bir devlet makineleri ağı olarak anlaşılamaması, çalışmalarının altında yatan ilkeler (devletler, belirlenmesi ve geçişleri) ve devlet makinelerinin etkileşimleri.

Tüm hataları bildiren koda karşılık sessizce başarısız olan kod yazma.

"Olamayacak" veya gerçekleşmesi muhtemel olmayan şeyleri kontrol edememek büyük bir şeydir. Bazen mükemmel, iyinin düşmanıdır. İyi düşünülmüş bir istisna hiyerarşisine değmezse, bazı hızlı ve kirli işlemler her zaman hiçbir şeyden daha iyidir. Ben kocamanhızlı bir şekilde başarısız olma, ekler ve sürüm yapılarında performans üzerinde ihmal edilebilir bir etki bırakan ekler bırakma hayranı. Tüm giriş verilerini kontrol ettiğim hızlı ve kirli bir kerelik komut dosyalarında bile, genellikle sadece iddiaya eşdeğer olan ancak her zaman devam eden bir işlevle hızlı / kirli hata işleme koydum. Temel kuralım, gerçekleşme olasılığı yoksa veya bunun gerçekleşemeyeceğini düşünüyorsanız, kullanıcı dostu bir hata mesajıyla zarif bir şekilde başarısız olması gerekmez, ancak en azından bir hata mesajı ile hızlı bir şekilde başarısız olması gerekir. bir programcıya neyin yanlış gittiğine dair bazı ipuçları verir.

Düzenleme: İlgili bir yararlı taktik, büyük bir hata ayıklama aracı olarak ekleri kullanmak ve hata ayıklama oturumu bittikten sonra onları orada bırakmaktır . Bu noktadan sonra, kod tabanınız, ilgili hataların tekrar gerçekleşmesini çok zorlaştıran yerleşik bir sağlık kontrolüne sahip olacaktır. Bu özellikle birim testi zor olan kodlar için kullanışlıdır.

Yazılım hatalarının başlıca nedeni kod yazmaktır.

Daha az kod yazın ve daha az hataya sahip olursunuz ;-)

Bir düzeyde yönetim. Ama bu sadece PHB değil. Kodun kendisinin yönetimi, şirket yönetiminin bir yansıması olabilir veya olmayabilir.

Tüm "yaşam döngüsü" ne katılanların kaliteye tam olarak yatırım yapmaları ve ölmeyen bir ürün üretmeleri gerekmektedir . Yazılımın kendisi, uygun soyutlama güvenilirliği göz önüne alındığında asla kırılmayacağına dair söz verir . Bu sadece yazılım kurucularının bu mükemmel operasyona ilgi duyup duymadıkları sorusudur.