Karmaşık yazılımlar ne kadar fazlalık / sağlamlık uygulamalıdır?

Bu sorunun odağı: Bazı yazılımlar, yazılımdaki bir veya daha fazla dahili hataya rağmen "sonuçta başarılı / tatmin edici" bir sonuç elde etme şansını artırmak için "fazladan çalışma" yapar ve bu hatalar meydana geldiğinde daha uzun bir yürütme süresi gerektirir. Sonuç başarılı olursa, tüm bunlar kullanıcının bilgisi olmadan gerçekleşir.

Karmaşık yazılımın tanımı:

• Yaşam süresi boyunca 10'dan fazla geliştiricinin yazdığı (katkıda bulunduğu) kodu içerir ve aynı zaman dilimi içinde yazılmaz
• Her birinde uyarı bulunan 10'dan fazla harici kütüphaneye bağlıdır
• Tipik bir yazılım görevi (kullanıcı tarafından istenen bir sonuç elde etmek için) 10 veya daha fazla giriş parametresi gerektirir; burada birçoğu varsayılan değerlere sahiptir, ancak kullanıcının kontrole ihtiyacı varsa yapılandırılabilir.
• En önemlisi, gerçekleştirilen göreve göre uygun karmaşıklığa sahip olan, yani gereksiz yere karmaşık olmayan yazılım .

Düzenlendi: Karmaşık nedir? Lütfen Kompleks ve Karmaşık arasında büyük bir fark var . (doğrudan bağlantı)

Bu sorudaki Artıklık / Sağlamlığın tanımı :
(Yorumlara dayalı Sağlamlık eklendi)

• Geçerli parametre kümesi kullanıldığında bir yazılım görevi başarısız olursa, farklı parametreleri deneyin.
  • Açıkçası, bu "farklı" parametrelerin farklı bir kod yolu kullandıkları ve muhtemelen farklı (umarım daha iyi) bir sonuca yol açacağı bilgisi dahilinde olmalıdır.
  • Bazen bu farklı kod yolu, harici kütüphanelerin gözlemlerine dayanarak seçilir.
• Sonunda, gerçekleştirilen asıl görev kullanıcının belirtimlerinden biraz farklıysa, kullanıcı tutarsızlığı ayrıntılandıran bir rapor alır.
• Son olarak, 10 artı yapılandırılabilir parametreler gibi, fazlalık ve raporlama da yapılandırılabilir.

Bu tür yazılımlara örnek:

• Veritabanı Geçişi
  • İşletme veritabanı
  • Kaynak kontrol veritabanı vb.
• Bir Word belgesi ile bir OpenOffice belgesi, PowerPoint ve OpenOffice Draw, vb. Arasında toplu dönüştürme.
• Tüm bir web sitesinin otomatik çevirisi
• Doxygen gibi yazılım paketinin otomatik analizi, ancak analizin daha güvenilir olması gerektiği (yani yalnızca bir belge aracı değil)
• Paketlerin kaybolabileceği ve bir dizi yeniden denemenin beklendiği ağ iletişimi

Bu soru ilk olarak kasıtlı olarak kötü kodla nasıl başa çıkıyorsunuz?
ancak artık yazılım şişkinliğinin nedenlerinden sadece birine odaklanıyor. Bu soru, yeni özelliklerin eklenmesi gibi yazılım şişkinliğinin diğer nedenlerini ele almamaktadır.

Muhtemel ilgili:

• (Büyük) projelerde karmaşık kodlarla nasıl başa çıkılır?
• İnsanlar son derece karmaşık ve okunması zor kodları yazmayı ve korumayı nasıl başarıyor?

Bu bir iş sorusu, teknik bir soru değil.

Bazen araştırmacılarla veya bir prototip üzerinde kod yazıyorum, bu yüzden çok düşük sağlamlığa sahip bir şey inşa edeceğiz. Eğer kırılırsa, düzeltiriz. Yakında kodu atacaksak, fazladan sihire yatırım yapmanın bir anlamı yok.

Ancak sisteminizin kullanıcılarının sağlam olması gerekiyorsa, bu şekilde oluşturmalısınız. Ve özellikle ihtiyaç duymadığınız fazlalık / sağlamlık türlerini göz ardı ederken uzun vadeli başarıyı en üst düzeye çıkarmaya ihtiyaç duyduğunuz şekilde sağlamlaştırmalısınız.

Genel olarak, kaba başlıyorum ve sonra zaman içinde sağlamlık ekliyorum. Normal planlama sürecinin bu kısmı gibi sık sık sorular soruyorum. Genellikle, istenen özelliklerin uzun bir listesini yaptığımız Aşırı Programlama stilinde çalışıyorum ve oraya da sağlamlık özellikleri koydum. Örneğin, "Sistem herhangi bir kutunun başarısızlığından kurtulur", "Kullanıcı Facebook kimlik bilgilerini kullanarak katılabilir" gibi şeylerle karışır. Hangisi önce gelirse, önce ben inşa ederim.

Karmaşık yazılım tipik olduğunu muhtemelen bildiğiniz gibi, ama belli ki bunu yapmak için en iyi yol olduğu için değil ama geliştiriciler, varolan kodun yerine girişimi "konulu tack" eğilimindedir, çünkü çok detaylı nasıl yazılım çalışmaları anlamak gereksiz.

Ancak, bana ne kadar fazlalık kabul edilebilir olması gerektiğini sorarsanız, hiçbirini söyleyemem. Artıklık, karmaşıklığın birçok yan etkisinden, basitliğin arkemezilerinden biridir. Tartışmalı bir şekilde, zamanın önemi büyükse basitlik arka koltuk almalıdır, ancak zamanın özü olduğunu iddia edenlerin nadiren yazılım geliştirmeye gerçekten bakan kişiler olduğunu vurguluyorum. Genellikle işinizi mümkün olan en kısa sürede halletmeniz için size örnek veren proje yöneticinizdir, böylece daha acil konulara geri dönebilirsiniz, ancak işin ne zaman yapıldığını bilmek bir programcı olarak görevinizdir. Sanırım iş, olması gerektiği gibi programa başarıyla entegre edilinceye kadar yapılmadı. Belki de program karmaşıktır,

Ancak bunu yaparken gereksiz kodlar üretmeniz gerekebilir. Proje zaten fazla yedekliyse, patronunuzun tüm projeyi yeniden yapılandırmanıza izin vermek için birkaç haftası olmadığı varsayılırsa, kalıbı sürdürmek aslında daha basit olabilir.

Edit: Sorunun yeniden ifade edilmesi ışığında, sağlamlık hakkında biraz ekleyeceğim. Bence parametre kontrolü sadece A) bir tarih değeri gibi çok özel bir formatı dize olarak kabul ettiğinizde veya B) çeşitli parametrelerin potansiyel olarak birbiriyle çatışabileceği veya birbirini dışlayabildiği durumlarda yapılmalıdır.

A) ile parametrelerin belirli bir formatla eşleşmesi için gereksinimler genellikle yöntemin gerekliliği için kritiktir (bir dizeden tarihe dönüştürme gibi). Teknik olarak, bir gereklilik olmadan programınızda hala olabilir, ancak bu olasılıkları ortadan kaldırmanızı ve yalnızca aradığınız veri türünü temsil ettiğini bildiğiniz parametreleri kabul etmenizi şiddetle tavsiye ederim (eğer bir dize yerine bir tarihi kabul edin) dönüştürme de yapılması gerekiyorsa, dizeye yönteme geçmeden önce dönüştürmek için bir yardımcı program yöntemi kullanın).

B) 'ye gelince, birbirini dışlayan parametreler kötü bir yapıyı temsil eder. Biri bir davayı ele alan ve diğeri başka bir şekilde ele alan iki sınıf olmalıdır. Fazlalıktan kaçınmak için tüm yaygın işlemler tek bir temel sınıfta yapılabilir.

Bir yönteme parametrelerin sayısının 10+ olduğu durumlarda, sık sık değişmeyecek tüm bu parametreleri içeren bir özellik dosyasını düşünmeye başlarım. Değişirse, varsayılanı özellik dosyasına kaydedebilir ve çalışma zamanında varsayılanı geçersiz kılmanıza olanak tanıyan bir "setPropertyName ()" yöntemi ekleyebilirsiniz.

Yazılım, kullanıcı hatalarını affetmeli ve programcı hatalarına karşı tamamen hoşgörüsüz olmalıdır.

Yani, yazılım çok sağlam olmalı ve kullanıcı giriş hataları ve sistem yapılandırma hataları gibi şeyler için sorunsuz kurtarmaya izin vermelidir. En azından hatanın nerede oluştuğunu (giriş kutusu, yapılandırma dosyası, komut satırı argümanı vb.) Ve hangi kısıtlamanın ihlal edildiğini ("X karakterden az olmalı" ") belirten samimi bir hata mesajı, geçerli seçenekler [X , Y, Z] ", vb ...) Ek sağlamlık için yazılım bir alternatif önerebilir veya makul bir varsayılan değer kullanabilir (ancak her zaman kullanıcının tam olarak belirttiklerini kullanmadığını göstermelidir).

Farklı varsayılanlara sahip otomatik bir yeniden denemenin garanti edildiği pek çok durumu düşünemiyorum, ancak bazıları var (bir iletişim bağlantısı kurmak için otomatik yeniden deneme makul görünüyor). @William ile bu 'fazlalık' seviyesinin bir iş kararı olduğuna katılıyorum.

Öte yandan, programcı hatasına karşı çalışma zamanı sağlamlığı olmamalıdır. Bir fonksiyonun parametreleri için ön koşullar varsa, bunlar çalışma zamanı kontrolleriyle değil, onaylarla kontrol edilmelidir. Aynı parametrede üç veya dört düzeyde gereksiz hata denetimi ve raporlamasını çağrı yığınına görmek benim için büyük bir hayvan huşu.

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

Bu sadece gereksiz ek bir karmaşıklıktır. Zamanlamayı, bir fonksiyonun başka bir fonksiyonun yanlış kullanılmasıyla ortaya çıkan bir hatayı nasıl ele alması gerektiğini anlayarak harcamamalısınız. Bu, bahsettiğiniz 'sağlamlık' türüyse - buna ihtiyacınız yoktur. Değiştirmeleri ve kapsamlı entegrasyon testiyle değiştirin.

Bu bir zorunluluktur.

Sağlamlık için bir gereklilik var mı?

"İletişim bağlantısı başarısız olduğunda, hatalı paketler atılır" "Bağlantı çalışmaya devam ettiğinde, iki işlem gerçekleştirilmez"

hata giderme için kullanım örnekleri olmalıdır (aksi takdirde nasıl olacağını nasıl anlarsınız?)

(Gerekirse) sağlamlığı icat etmek için programcılara bırakmak "büyülü" sistemlerle sonuçlanır.

Tüm büyülü sistemler zamanla berbat bir büyü haline gelir. Arkaplanda hata düzeltmesi hata oluşumunu gizler, böylece hatalar düzeltilmez, böylece sistem sonunda daha büyük bir entropi durumuna düşer. ve her zaman hataları düzelttiği için bok gibi çalışın. Sistemin kalıcı olarak bozulan bir duruma girmesini durdurmak için bir sınırınız olmalıdır.

Bazı işlemler, özellikle bir veritabanı gibi dış kaynaklara bağımlıysa, muhtemelen "tekrar dene" yaklaşımını garanti eder. Örneğin, bir veritabanı bağlanamazsa veya bir sorgu başarısız olursa, işlemden vazgeçmeden ve daha yüksek bir seviyeye bir hata atmadan önce işlem belirli sayıda yeniden denenebilir. Bununla birlikte, bazı mantıklarda, aynı şeyi birden çok kez denemek, genellikle gerçek sorunları gizleyen kötü kod ve büyülü düşüncenin bir belirtisidir.