Savunma Programlaması: Paranoya mı Akıllı Kodlama mı?

Savunma Programlaması Neden Sağlam Kodlama İçin En İyi Yoldur?

Defansif Programlama tek gerçek programlamadır.

Resim Kredisi: Stardoll.com

Savunma programlaması, bir programcının sorunları önceden tahmin etmesi ve bunlarla başa çıkmak için kod yazmasıdır.

Gelecekte bir araba kazası görmek gibi… .. ve bunun için sigortalı olduğunuz için sakin kalmak gibi.

Bununla birlikte, savunma programlamasının bütün amacı beklediğiniz hatalara karşı koruma sağlamaktır. Defansif bir programcı, gerçek sorunlara neden olmadan önce önlemek için beladadır. Buradaki fikir hiçbir zaman başarısız olmayan bir kod yazmak değildir. Bu bir ütopik rüyadır. Beklenmeyen bir sorun olduğunda kodu değiştirme fikri güzel bir şekilde başarısız olur. Güzelce başarısız olmak, aşağıdakilerden herhangi biri anlamına gelebilir.

· Erken başarısız olma: Kodunuz, özellikle hesaplama açısından pahalı olanlar veya geri dönüşü olmayan bir şekilde verileri etkileyebileceklerse, tüm önemli işlemlerin önceden sonlandırılmasını sağlamalıdır.

· Güvenlikten korunma: Bir hatanın meydana geldiği durumlarda, kodunuz tüm kilitleri bıraktığından ve dosya yazmadan vb. Yenilerini almadığından emin olmalıdır.

· Açıkça hata: bir şey kırıldığında, destek ekibinin hatayı çözmesini sağlayacak çok açık bir hata mesajı ve açıklaması getirmelidir.

Tamam. Burada tartışabilirsin.

Günümüzde sorun yok. Kodum güzel çalışıyor. Neden “gelecekle ilgili beklenen” bir soruna zaman ve emek harcamalıyım? Sonuçta, “İhtiyacınız Olmayacak” (YAGNI) kullanımı tekrar tekrar yapıldı. Ve sen profesyonel bir programcısın ve istediğin koda eklemeye devam edebilecek bir hobi değilsin.

Buradaki anahtar pragmatizmdir.

Pragmatic Programmer adlı kitabında Andrew Hunt, savunma programlamasını “Pragmatik Paranoya” olarak nitelendiriyor.

Kodunuzu diğer kişilerin hatalarından ve kendi hatalarınızdan koruyun. Şüphe durumunda, doğrulayın. Veri tutarlılığını ve bütünlüğünü kontrol edin. Her hatayı test edemezsiniz, bu nedenle "gerçekleşemeyen" işlemler için iddialar ve istisna işleyicileri kullanın.

Sağlıklı Paranoid Programlama, doğru programlama türüdür. Ancak paranoya çok fazla alınabilir. Anahtar doğru dengeye vurmak.

Ve burada savunma programlaması yapmanın bazı yolları var.

Kendine Sor: Bu Başarısız Olur mu?

Her kod satırı bir şey yapar, bu nedenle ilk savunma noktası, kodun başarısız olup olmadığını, o zaman ne olacağını sormaktır.

Örneğin, aşağıdaki uyumlu olmayan kodu göz önünde bulundurun.

VAKA SY-INDEX. // Uyumsuz; WHEN DIĞER deyimi eksik
SENİN BİR.
YAZIN ‘Bir’.
2. ZAMAN.
‘Two’ yaz.
ENDCASE.

Burada aşağıdaki soruları sorabiliriz.

Sy-index 1 değilse ne olur?

Sy-index 2 değilse ne olur?

Bu sorunu çözmek için DİĞER bir açıklama ekleriz.

VAKA SY-INDEX.
SENİN BİR.
YAZIN ‘Bir’.
2. ZAMAN.
‘Two’ yaz.
DİĞER NE ZAMAN. // Uysal
YAZIN ne Beklenmeyen sonuç ’
ENDCASE.

Basit. Öyle değil mi?

Bu, iyi programcıları kod yazanlardan ve asla başarısızlığa uğramayacaklarından ayıranlardan ayıran bir düşüncedir. “Asla” her zaman beklenenden daha erken gelir ve o zamana kadar kod programın uzun süredir unutulan bir bölümüne gömülür ve hata mesajları sorunun nerede olduğu ve nasıl çözüleceğine dair hiçbir gösterge vermez.

Bu savunma amaçlı programlama tekniğinin güzelliği, kodunuza ayrıntılı bir denetim eklemek için neredeyse hiç zaman harcamamasıdır. Sen "fazla kodlama" değilsin. Siz sadece kodunuzu “güvenceye alıyorsunuz”.

Sınır Koşullarını Dikkatlice Kontrol Edin.

İlk kontrol, döngüler pahalı olduğu için sınır şartına ihtiyacınız olup olmadığını tespit etmektir.

Sınır (veya kenar) koşulları, tüm eylemin gerçekleştiği yerdir. 0 ile 100 arasında döngü ve 1 ile 98 arasında döngü değerleri hemen hemen aynıdır (elbette kodlama koşulluları). Ancak döngü 0, kodun döngüye girdiği yerdir ve başlatma koşulları ayarlanır (ve muhtemelen yanlış ayarlanır). Benzer şekilde, son döngü işlerin gittiği yerdir ve döngü değerlere ne yapıyorsa durur.

En fazla bir yinelemeye sahip bir döngü, bir kod parçasını koşullu olarak yürütmek için bir IF ifadesinin kullanılmasına eşdeğerdir. Hiçbir geliştirici, böyle bir döngü ifadesinin kullanımını bulmayı beklememelidir. Yazarın ilk niyeti gerçekten şartlı olarak bir kod parçasını yürütmekse, bir IF ifadesi yerinde kullanılmalıdır.

Aşağıdaki uyumlu olmayan ve uyumlu kodu göz önünde bulundurun. Bu durumda hiç bir döngüye ihtiyacımız yok. Basit bir IF yapacaktır.

            Uyumsuz Kod Örneği
DATA kalanı TİPİ i.
20 kez yapın.
kalanlar = sy-index MOD 2.
cl_demo_output => write_text ().
ÇIKIŞ. “Uyumlu olmayan, döngü sadece bir kez çalıştırır. IF kullanabiliriz
ENDDO.
          Uyumlu Kod Örneği
DATA kalanı TİPİ i.
20 kez yapın.
kalanlar = sy-index MOD 2.
cl_demo_output => write_text ().
ENDDO.

Daima hata ayıklama döngülerinin, başlangıçta ve sondaki eforun çoğunu içerdiğini ve neyin girip neyin doğru olduğundan emin olduklarını unutmayın. Bu yüzden, sınır koşulları konusunda bir kez netleştikten sonra, kodunuzda başka hiçbir şey yanlış gidemez.

TDD Kullan (Test Odaklı Geliştirme)

TDD'nin temel fikri “önce birim testleri yaz, sonra kodu yaz, sonra refactor, sonra tekrar et”.

Birim testleri, işlevlerin beklendiği gibi çalışıp çalışmadığını kontrol eden otomatik testlerdir. İlk ünite testiniz başarısız oldu, çünkü daha önce kod kodunuz bile yoktu.

Test durum koduna bir bit ekleyin. Üretim koduna biraz ekleyin. İki kod akışı aynı anda tamamlayıcı bileşenlere dönüşür. Testler, bir antijene uyan bir antikor gibi üretim koduna uyar.

Test koduyla ilgili sorun, bu kodu izole etmenizdir. Bir işlevi başka işlevler çağırırsa, bir işlevi test etmek genellikle zordur. Bu testi yazmak için, işlevi diğerlerinden ayırmanın bir yolunu bulmalısınız. Başka bir deyişle, ilk önce sınama ihtiyacı sizi iyi tasarım hakkında düşünmeye zorlar.

Bu, kod geliştikçe işler üzerinde daha iyi kontrol sahibi olduğunuz daha iyi, ayrık bir tasarım yaratır.

Test senaryolarını önceden yazarken başlangıçta zaman alabilir ancak bu birçok yarar sağlar. Geliştiriciler, daha önce kod satırları yazdıklarını, çözümlerinin alakasız olduğunu fark ettiklerini ve daha sonra sıfırdan yeniden kodlamaya başladıklarını itiraf ediyorlar.

Eski kodlama uygulamalarından farklı olarak TDD, geliştiricilerin çizim tahtasına geri dönmelerini ve hafif, esnek bir mimari tasarlamaya odaklanabilmelerini sağlar.

Ve önceden test senaryoları yazmak gerçeği, daha sonra ortaya çıkabilecek hataları önler, böylece zamandan, emekten ve mide ekşimesinden tasarruf edilir.

Her Zaman Optimize Edilmiş Kodları Yaz.

Bazı programlar (ve programcılar) kaynakları çok sever. Ama ne zaman istersen, minimumunu kullan. Ve minimum kullanabilmek için kodunuzun mümkün olduğunca optimize edilmiş olması gerekir.

Genellikle, optimize etmenin kesin bir yolu, derleyicinin dahili olarak sağladığı optimizasyonları açmaktır.

Derleyici optimizasyonları, çalışma süresini genellikle birkaç yüzdeden 2 faktörüne yükseltir. Bazen ürünü yavaşlatabilir, bu nedenle son çağrıyı yapmadan önce dikkatlice ölçün. Bununla birlikte, modern derleyiciler, programcılar tarafından küçük çaplı değişikliklere duyulan gereksinimin çoğunu ortadan kaldırdıkları için bu konuda yeterince başarılılar.

Standart derleyici optimizasyonlarının yanı sıra, kullanılabilecek başka birkaç ayarlama tekniği vardır.

Ortak alt ifadeler toplayın.

Pahalı bir hesaplama birden fazla yerde gerçekleşiyorsa, tek bir yerde hesaplamak ve sonucu hatırlamak daha iyidir. Bu tür hesaplamaları gerekmedikçe bir döngü içine sokmayın.

Pahalı işlemleri ucuz olanlarla değiştirin.

Dize manipülasyonu muhtemelen herhangi bir programdaki en yaygın işlemlerden biridir. Ancak, yanlış yapılırsa pahalı bir işlem olabilir. Benzer şekilde, bazı durumlarda, çarpımı bir dizi vardiya işlemi ile değiştirerek performansı artırabilirsiniz. Bunun etkili olduğu yerlerde bile (ve her zaman değildir) çok kafa karıştırıcı kodlar üretir. Öyleyse kararın okunabilirliği de göz önünde bulundurularak alın.

Döngüler ortadan kaldırmak.

Döngüler çoğunlukla genel giderlerdir. Yinelemeler fazla değilse, mümkün olan her yerde döngülerden kaçınmaya çalışın.

Önbellek sık kullanılan değerleri.

Önbelleğe alma özelliği, programların ve insanların son kullanılan verileri yeniden kullanma eğiliminden yararlanır. Yalnızca en çok kullanılan karakter veya verileri önbelleğe almak, programın performansını önemli ölçüde artırır.

Daha düşük bir dilde yeniden yazın.

Bu son çare olmalı. Düşük seviyeli diller, programcının bakış açısından daha fazla zaman harcarken, ancak daha verimli olma eğilimindedir. Bazen, önemli kodları düşük seviyeli dillerde yeniden yazarak önemli iyileştirmeler elde ediyoruz, ancak bu düşük taşınabilirlik maliyetine neden oluyor ve bakım çok zorlaşıyor. Bu yüzden kararı dikkatlice alın.

Optimizasyonda, seçimin belki de oyunun% 90'ını hatırla. Ne yaptığınıza karar vermek ve doğru yapmak için zaman ayırmaya değer. Tabii ki: Aynı zamanda kara büyünün olduğu yer!

Ve Son olarak, kimseye güvenme.

“Bilinen şeyler var; Bildiğimiz bildiklerimiz var. ”İkinci Bush yönetimi sırasında Savunma Bakanı Donald Rumsfeld bir keresinde düzenlediği basın toplantısında söyledi. “Bilinen bilinmeyenler olduğunu da biliyoruz; yani bilmediğimiz bazı şeyler olduğunu biliyoruz. Ancak, bilinmeyen bilinmeyenler de var - bilmediklerimiz bilmediğimizi. ”

Rumsfeld Irak'taki savaştan bahsediyordu, ancak aynı şey veriler için de geçerli. Özetle, bu, üzerinde tam kontrole sahip olmadığınız tüm verileri doğrulamak anlamına gelir.

Açıkçası, kullanıcı verileri her zaman şüpheli. Kullanıcılar ne düşündüğünü çok net bir şekilde yanlış anlayabilirler. Sorunları deneyin ve tahmin edin ve gelen her şeyi doğrulayın veya düzeltin.

Program ayarları verileri de hataya açıktır. INI dosyaları, program ayarlarını kaydetmenin yaygın bir yoluydu. Bir metin dosyası oldukları için, birçok kişi bir metin editörü ile manuel olarak düzenleme ve muhtemelen (muhtemelen) değerleri bozma alışkanlığı edinmiştir. Kayıt defteri verileri, veritabanı dosyaları - birisi bir gün onları ince ayarlayabilir ve bu yüzden bunları doğrulamak için öder.

Kısacası, kodunuzun ne yapılması gerektiğine dair herhangi bir ümidi varsa, gelen veriler temiz olmalıdır. Eğer “Garbage in, Garbage Out” ibaresini daha önce duyduysanız, geldiği yer burasıdır.

Edward Demming'in haklı olarak söylediği gibi.

"Allaha güveniriz. Diğerlerinin de veri getirmesi gerekiyor. ”
Yazar hakkında-:
Ravi Rajan Hindistan Mumbai'de bulunan global bir IT program yöneticisidir. Aynı zamanda hevesli bir blog yazarı, Haiku şiir yazarı, arkeoloji meraklısı ve tarih manyağı. LinkedIn, Orta ve Twitter'da Ravi ile bağlantı kurun.