Ne kadar savunmacı olmalıyız?

Pex'i bazı kodlar üzerinde çalıştırıyoruz ve bazı iyi şeyler gösteriyor (iyi kötü şeyler, ancak üretime geçmeden önce bunları gösteriyor!).

Ancak, Pex ile ilgili güzel şeylerden biri, sorunları bulmaya çalışmaktan vazgeçmemesidir.

Bulduğumuz bir alan, bir dize geçerken boş dizeleri kontrol etmiyor olmamızdı.

Bu yüzden değiştik:

if (inputString == null)

için

if (string.IsNullOrEmpty(inputString)) // ***

Bu ilk sorunları düzeltti. Ama sonra, Pex'i tekrar çalıştırdığımızda, karar verdi:

inputString = "\0";

sorunlara neden oluyordu. Ve sonra

inputString = "\u0001";

Karar verdiğimiz şey, karşılaştığımızda varsayılanların kullanılabileceği // ***ve diğer garip girdilerin (ve bununla başa çıkmanın) neden olduğu istisnayı görmekten mutluluk duyuyoruz.

Bu yeterli mi?

Üç soru, kodlamanızda ne kadar savunmacı olduğunuzu belirlemenize yardımcı olmalıdır.

Birincisi - Kötü girdinin geçmesinin sonuçları nelerdir? Geliştiricinizin bilgisayarlarından birinde bir hata mesajı varsa, savunma için o kadar kritik olmayabilir. Müşterilerdeki finansal kesintilere, IE muhasebe bilgilerinin bozulmasına neden olabilir mi? Yaşamların risk altında olduğu gerçek zamanlı bir sistem midir? Yaşam / ölüm senaryosunda, muhtemelen gerçek özellik kodundan daha fazla doğrulama ve hata işleme kodu olmalıdır.

İkincisi, kaç kişi bu işlevi veya kod parçasını yeniden kullanacak? Sadece sen? Senin bölümün? Şirketin? Müşterileriniz? Kod ne kadar geniş olursa o kadar savunmacı olur.

Üçüncü olarak - doğruladığım girişin kaynağı nedir? Kullanıcıdan veya genel bir web sitesinden girilirse, süper savunmacı olurdum. Giriş her zaman kodunuzdan geliyorsa, biraz savunmacı olun, ancak kontrolleri yapmak için gereksiz zaman harcamayın.

Bir sisteme daha fazla hata kontrolü ve doğrulama eklemek her zaman mümkün olacaktır. Mesele şu ki, bu kodun yazılması ve sürdürülmesi, koddaki hataların neden olduğu sorunların maliyetinden daha ağır basacaktır.

Kullanıcılar kötüdür ve girdikleri her şey en üst düzeyde titizlikle kontrol edilmelidir.

Kullanıcı girdisi olmadan veya önceden dezenfekte edilmiş verilerden üretilen herhangi bir şeyin aynı seviyede kontrol edilmesi gerekmez. Buradaki sorun, bu yöntemleri kötü verilerde unutup kullandığınızda ortaya çıkar, çünkü kodun sertleştirilmediğini unutmuşsunuzdur.

Her zaman kontrol etmeniz gereken tek şey, taşmaya veya çökmeye neden olabilecek herhangi bir şeydir. Bu yöntemin ne kadar derinden gömüldüğü ve bu durumun asla oluşmayacağından ne kadar eminseniz önemli değil. Yine de Murphy'yi yatıştırmak için programlamanız gerekiyor.

Senin olman gereken kadar savunmacı olurdum. Biraz belirsiz, sanırım ama açıklamaya çalışacağım.

Bir yöntemi düzelttiğinizde, bu yöntemde giriş parametreleri varsa, bu parametrelerin ne olmasını beklediğinize karar vermeniz gerekir. Bir uygulama içindeki durumlarda ve yerlerde bu farklılık gösterecektir. Örneğin, bir yöntem veya kod parçası bir kullanıcı girişinden veri kabul ediyorsa, tüm kod tabanını kapsamak ve bir hata mesajı veya kabul edilemez verileri göstermenin güzel bir yolu aracılığıyla herhangi bir girişi buna göre işlemek istersiniz.

Yöntem açık bir API ditto ise. Ne geldiğini kontrol edemezsiniz, bu nedenle tüm yönleri ve programı buna göre denemeyi ve kapsamayı beklemelisiniz.

Projenizin çekirdek motorunda üretilen yöntemler için burada bir karar vereceksiniz. Gelen verilerin gelmeden önce önceden tarandığını ve doğrulandığını varsayabilir miyim yoksa gerekli kontrolleri yapmam gerekir mi? Sanırım bu, yöntemin kavramsal düzeyine ve kontrol etmek için kabul edilebilir bir yer olup olmadığına bağlıdır. Düşünebileceğim şeyler:

1) Bu kontrolü yapmak için ihtiyacım olan tek yer burası mı? Bu değişkenin bu durum için birçok farklı yerde kontrol edilmesi gerekecek mi? Eğer öyleyse, kontrolü bir kez zincirden daha yükseğe yapabilir ve daha sonra geçerliliğini üstlenebilirim

2) Sistemin diğer bileşenlerinin yazdığım yöntemler ve arabirimlerle çalışması bekleniyor mu? Öyleyse, hata ayıklama onay ifadeleri, hata ayıklama istisnaları, yöntem yorumlama ve genel sistem mimarisi aracılığıyla istediğiniz sonucu kontrol edebilir veya verilerin kontrol edilmesi gerekir.

3) Kodda bu noktada başarısızlığın sonuçları nelerdir. Her şeyin başarısız olmasına neden olur mu? Herhangi bir hata başka bir yerde yakalanacak mı ve en azından bu hata yakalanacak mı?

4) Buraya bir çek koymak mantıklı mı? Bazen bir noktada olası bozuk verilerin bir kontrolünü yapmak, ancak bu noktada sorunun çözülmesine yardımcı olmak ve hata olmamasına yardımcı olmak, onu örtmeye yardımcı olabilir. Bu noktada, yalnızca asıl sorunu bulmak için farklı bir sorunu takip ederek saatler geçirebilirsiniz, çünkü kullanıcı / geliştiricinin bildirildiği kişiye kademeli olan olaylar zincirindeki veriler üzerinde geçerli bir kontrol yapıldı.

Genel olarak savunmacı bir programcıyım ancak kapsamlı TDD ve uygun birim testi ile kodları gerekli seviyelerde kontrol edebileceğinize ve daha düşük seviyeli bölümlere ulaştığında çalıştığından emin olabileceğime inanıyorum. .

Ben haftalar önce böyle böyle ekstra çalışma ile 5 dakika tespit edilmiş olabilir hatalar üzerinde geçirdim. Zihnimde bu ön çalışma her zaman buna değer. Sonunda hatayı düzeltiyor olacaksınız. Tek soru, bunun ne kadar süreceği.

Bu tür analiz araçlarının sıklıkla ortaya çıkardığı bir şey, mutlaka böcek olmayan, ancak hataların ortaya çıkma olasılığını artıran kötü programlama alışkanlıklarıdır. Böyle yaygın bir alışkanlık değişken başlatmadır. Bazen boş bir dize, bir değişken için mükemmel şekilde geçerli bir değerdir. Bu durumda, aracınızı belirli bir durumda bir hata olduğunu düşünmeyecek şekilde yapılandırmak istersiniz. Ancak, çoğu zaman boş bir dizedir değil bir değişken için geçerli bir değer, ama yoksa derleyici şikayet çünkü insanlar, yine de ayarlıyorsunuz şey orada, ya da dili otomatik olarak o geçerli olup olmadığı yolundaki boş bir dizeye başlatır.

Bu, insanları hayal kırıklığına uğratır, çünkü geçerli bir çözümü olmayan bir yakalama 22 gibi görünür, ancak çözüm kodunuzu yeniden düzenlemektir, böylece oraya koymak için geçerli bir değer olana kadar değişkeni başlatması gerekmez. Bu, biraz daha fazla ön düşünmeyi gerektirir, ancak kodunuzu çok daha sağlam hale getirir ve uzun vadede yazılması ve bakımı daha kolaydır.