Mühendisliğe karşı sağlam kod yazma

Siz mühendisliğe izin vermeden mümkün olan en sağlam kodu yazdığınızı nereden biliyorsunuz?

Kodumun alabileceği her olası yol hakkında kendimi çok fazla düşünürken buluyorum ve bazen zaman kaybı gibi geliyor. Sanırım yazdığınız program türüne bağlı, ancak hiçbir zaman olmayacak durumları dikkate alarak zamanımın çoğunu kullanmak istemiyorum.

Siz mühendisliğe izin vermeden mümkün olan en sağlam kodu yazdığınızı nereden biliyorsunuz?

Sağlam kod olarak ne düşünüyorsunuz? Zaten gelecekteki kanıtı olan ve her durumla başa çıkabilecek kadar güçlü olan bir kod mu? Yanlış, kimse geleceği tahmin edemez! Ve yine yanlış, çünkü karmaşık ve sürdürülemez bir karışıklık olacak.

Çeşitli prensipleri takip ediyorum: Her şeyden önce YAGNI (henüz) ve KISS , bu yüzden gereksiz kod yazmıyorum. Bu aynı zamanda etkili bir şekilde mühendisliği önler. Uzantılara ihtiyaç duyulduğunda uygulamayı yeniden değerlendiririm. Modern yeniden düzenleme araçları, kolayca arabirimler oluşturmanıza ve daha sonra ihtiyaç duyduğunuzda uygulamaları değiştirmenize olanak sağlar.

Sonra yazdığım kodu olabildiğince sağlam hale getirmeye çalışıyorum, programın alabileceği (ve aynı zamanda durumları) alabildiği yolları ve biraz Spartalı programlamayı ortadan kaldırmak da dahil . Büyük bir yardım, dış durumlara dayanmayan ya da en azından başarısız olduklarında programı tutarsız bir durumda bırakmayan "atomik" işlevler / yöntemlerdir. Bunu iyi yaparsanız, spagetti koduyla sonuçlanma ihtimaliniz çok düşüktür ve bu da sürdürülebilirlik için bir nimettir. Ayrıca, nesne yönelimli tasarımda, SOLID ilkeleri sağlam kodlar için harika bir rehberdir.

Gerçekten, çoğu zaman karmaşıklığı azaltabileceğinizi, örneğin program yollarının veya durumların birleştirici patlamalarını, mümkün olan en düz yol olarak nasıl tasarlayabileceğinizi düşünerek öğrendim. Alt rutinlerinizin en iyi sıralamasını seçip bu amaç için tasarlayarak olası kombinasyonları minimumda tutmaya çalışın.

Sağlam kod her zaman basit ve temiz bir koddur, ancak basitlik her zaman kolay elde edilemeyen bir özelliktir. Yine de bunun için çaba göstermelisin. Her zaman sadece mümkün olan en basit kodu yazın ve başka seçeneğiniz olmadığında karmaşıklık ekleyin.

Sadelik sağlam, karmaşıklık kırılgandır.

Karmaşıklık öldürür.

Odaklanıp dengede durmaya çalışıyorum

• Mevcut tüm kullanım durumlarında olası tüm uygulama yollarını kullanmak (bu "sağlamlık" kısmıdır),
• özelliklerin / gereksinimlerin sağlanması Öngörülebilir bir gelecekte ortaya çıkacağından eminim ve
• Kod tabanının uzun süreli bakımı için gerekli olacak deneyimlerden bildiğim şeyler (ör. kodu temiz ve test edilebilir tutmak).

Bulanık bir sınır bölgesi - bazen gereksiz bazı işler yapmayı başarabiliyorum, bazen daha sonra gerekli olacağı bir şeyi yapamıyorum. Eğer özler büyük değilse, ben iyiyim. Her halükarda, hatalarımdan ders almaya gayret ediyorum.

Sağlam ve mühendislik işleri arasındaki fark, olası tüm kullanım durumlarını, hatta tuhaf ve saçak kullanım durumlarının bile OLMALI OLDUĞU GELİŞTİRİLMESİ ile arasındaki farktır. Nazikçe demek istediğimde, kullanıcı tuhaf bir istisna vakasına girer veya tanımlanmamış desteklenmeyen veya belirtilmeyen bir özellik gerektiren bir duruma girer ve kod, desteklenmeyen işlevsellikten çökmeden veya kullanıcıyı bilgilendirmeden zarif bir şekilde çıkar.

Öte yandan, aşırı mühendislik, ihtiyaç duyulmamış veya talep edilmemiş özelliklerin tam olarak uygulanması alanına girebilir (bazı özellikler müşterinin İHTİYACI yapar, ancak asla istenmez!) VEYA aşırı karmaşık bir tasarım ya da aşırı karmaşık bir yapı elde edilerek tanımlanabilir. nispeten basit bir problemi işlemek için kod.

1) Gereksinimleri alın.

2) Gereksinimleri karşılamak için minimum kodu yazın. Bir şey belirsiz ise, bilinçli bir tahmin yapın. Eğer durum bu ise süper belirsiz 1'e geri dönün.

3) Teste gönderin.

4) Eğer test edenler bunun iyi olduğunu söylüyorsa, onayınızı belgeleyin. Bir şey kapalıysa, 1'e geri dönün.

Testleri öngörmeye değil, testleri geçmeye odaklanın. Eğer test cihazınız yoksa, test edin! Bunlar yalnızca kod doğruluğunu onaylamak için değil aynı zamanda tüm geliştirme süreci için de önemlidir.

Öncelikle, verileri olabildiğince normalize edin (gereksiz değil). Veriler tamamen normalize edilmişse, verilere yapılan tek bir güncelleme tutarsızlığa neden olamaz.

Verileri her zaman normalize tutamazsınız, başka bir deyişle, artıklığı ortadan kaldıramayabilirsiniz, bu durumda tutarsız durumları olabilir. O zaman yapılacak şey tutarsızlığa tahammül etmek ve üzerinde gezen ve yayan bir tür programla periyodik olarak tamir etmektir .

Bildirimler yoluyla fazlalığı sıkı bir şekilde yönetmeye çalışmak için güçlü bir eğilim vardır. Bunların sadece doğru olduklarından emin olmak zor değil, aynı zamanda çok büyük verimsizliklere yol açabilir . (Bildirimleri yazma eğiliminin bir kısmı ortaya çıkar çünkü OOP'da pratikte teşvik edilmektedir.)

Genel olarak, olayların, mesajların vs. zaman sırasına bağlı olan her şey savunmasız olacak ve tonlarca savunma kodlaması gerektirecek. Olaylar ve mesajlar, fazlalık içeren verilerin özelliğidir, çünkü tutarsızlığı önlemeye çalışarak bir kısımdan diğerine olan değişiklikleri iletiyorlar.

Dediğim gibi, fazlalık sahibi olmanız gerekiyorsa (ve şansınız oldukça iyidir), a) tahammül etmek ve b) tamir etmek en iyisidir. Tutarsızlığı yalnızca mesajlar, bildirimler, tetikleyiciler vb. İle engellemeye çalışırsanız, bunu sağlamlaştırmanın çok zor olduğunu göreceksiniz.

• yeniden kullanmak için yaz.
• testleri yaz. önemsiz, önemsiz, bazı absürd karmaşık olanlar bu koşullar altında nasıl işlendiğini görmek için. Testler ayrıca arayüzün şeklini belirlemenize yardımcı olacaktır.
• programın zorlanmaması için yazılması (örneğin iddia) Kodumun bir ton yeniden kullanımı var ve bir ton vakayı test ediyorum - gerçek uygulamadan (satır sayısına göre) daha fazla hata kontrolü / kullanımı var.
• yeniden kullanın.
• derhal yanlış giden şeyleri düzeltin.
• deneyimden öğren ve inşa et.

hatalar yol boyunca ortaya çıkacak, ancak (neyse ki) yerelleştirilecekler ve (çoğu durumda) testlerde çok erken ortaya çıkacaklar. Yeniden kullanımın diğer yararı, müşteri / arayan kişinin, uygulama tarafından getirilen hatayı kullanarak hata kontrolünün / iskelenin çoğunu kurtarabilmesidir.

Testleriniz programınızın yeteneklerini ve ne kadar sağlam olduklarını tanımlayacaktır - başarı oranlarından ve girdilerden memnun kalana kadar testler eklemeye devam edin; gerektiği gibi iyileştirilmesi, genişletilmesi ve güçlendirilmesi.

Bu ayrımı iyi tanımlanmış kod yazarak yapıyorum, ancak çok düşük çalıştırma geçişleri için mutlaka en uygun davranış değil. Örneğin, bir matrisin pozitif olarak kesin olacağından emin olduğumda (kanıtlanmış, ancak test edilmemiş) emin olduğumda, durumu test etmek için programa bir iddia veya istisna ekliyorum, ancak bunun için kendi kod yolunu yazmıyorum. Böylece, davranış tanımlanır, ancak yetersizdir.

Sağlamlık: Bir sistemin geçersiz girdiler veya stresli çevre koşulları varlığında çalışmaya devam etme derecesi. (Kod Tamamlandı 2, p464)

Buradaki önemli soru sizin için ne kadar önemli olduğunu sormak. Facebook iseniz, birisi girdiye özel karakterler koyarken web sitenizin çalışmaya devam etmesi ve aynı anda 100 milyon kullanıcı oturum açtığında sunucunuzun açık kalması çok önemlidir. Yalnızca yaptığınız ortak bir işlemi gerçekleştirmek için bir komut dosyası yazıyorsanız, umursamıyorsunuz. Arada çok sayıda seviye var. İhtiyacınız olan ne kadar sağlam olduğuna karar vermek, bir geliştiricinin öğrenmesi gereken önemli becerilerden biridir.

YAGNI ilkesi, bir programın ihtiyaç duyabileceği özellikler eklemek için geçerlidir. Ancak bu ilke sağlamlık için geçerli değildir. Programcılar, belirli bir gelecekteki uzatmaya ihtiyaç duyulma olasılığını abartmaya meyillidirler (özellikle soğuksa) ancak sorunların ters gitme ihtimalini küçümserler. Ayrıca, sonradan atlanan bir özelliğin gerekli olduğu ortaya çıkarsa, programcı daha sonra yazabilir. Sonuçta ihmal edilmiş bir hata ortaya çıkarsa, sonuçta, hasar gerekli olabilir.

Bu nedenle, olağandışı hata durumları için yapılan kontrolleri yaparken hata yapmak daha iyidir. Ancak bir denge var. Bu dengede dikkat edilmesi gereken hususlardan bazıları:

• Bu hata ne sıklıkla ortaya çıkabilir?
• Bu hatanın olmasının maliyeti nedir?
• Bu dahili mi yoksa harici kullanım mı?

İnsanların programınızı beklenmedik şekillerde kullanmaya çalışacaklarını ve yapacaklarını unutmayın. Yaptıklarında tahmin edilebilir bir şey olursa daha iyidir.

Son savunma hattı olarak, assert veya kapatmayı kullanın. Bununla başa çıkamayacağınız bir şey olursa, programı kapatın. Bu genellikle programın devam etmesini ve öngörülemeyen bir şey yapmasını sağlamaktan daha iyidir.