Yan etkileri en aza indirin (ideal olarak hiçbiri yoktur)
Kendi kapsamı dışındaki durumlarda 3 değişikliğe neden olan bir işlev, yalnızca bir şeyi girip çıkaran ve başka bir şey çıkaran birinden daha fazla mantıklı olmak ve sürdürmek için daha zordur. İşlevin ne yaptığını bilemezsiniz, ne yaptığını ve bunun diğer tüm ilgili işlevleri nasıl etkilediğini hatırlamanız gerekir.
OOP için yan etkileri en aza indirmek aynı zamanda daha az üyeli ve özellikle de sınıfın durumunu değiştirebilen daha az üye olan sınıflar anlamına gelir, çünkü üye işlevler kendi başlarının ötesindeki durumları değiştirebilir ve yan etkilere sahip olabilir (örneğin sınıfın içini değiştirebilirler). Ayrıca, kendileri için daha az veri üyesi olan sınıflar anlamına gelir, böylece bu yöntemlerin tahrif edilmesi için daha az durum ve neden olabilecekleri daha az yan etki söz konusudur.
Basit bir örnek olarak, sortedikili ya da doğrusal arama yapıp yapmamayı belirlemek için kullandığı bir durumu koruyabilecek süslü bir veri yapısı tasarlamaya çalıştığınızı hayal edin . Böyle bir durumda, tasarımı iki sınıfa ayırmak faydalı olabilir. sortedSıralanmamış sınıfa çağrı yapmak , içeriğini daima düzenli tutan başka bir sınıfın veri yapısını döndürür. Artık daha az yan etkiye sahipsiniz (bu nedenle daha az hata eğilimli ve kodları anlamak daha kolay) ve daha yaygın olarak uygulanabilir kod (eski tasarım, hem sıralanmasına gerek olmayan küçük diziler için hem işleme hem de insan entelektüel verimliliğine zarar verecekti).
Gereksiz Dış Bağımlılıklardan Kaçının
Nispeten basit bir görevi gerçekleştirmek için 13 farklı kütüphaneyi kullanarak, maksimum kod kullanımıyla hayal edilebilecek en kısa kodları uygulayabilirsiniz. Bununla birlikte, bu, entelektüel ek yükü okurlarınıza daha sonra 13 farklı kütüphanenin en azından bir kısmını anlamalarını sağlayarak aktarır. Bu doğal karmaşıklık, bir düzine başka kütüphanenin çalışmasını ve oluşturulmasını gerektiren bir üçüncü taraf kütüphanesini inşa etmeye ve anlamaya çalışan herkes tarafından hemen takdir edilmelidir.
Bu muhtemelen çok tartışmalı bir bakış açısıdır, ancak nihai sonucun iyi bir şekilde test edilmesi şartıyla, karşı uçta mütevazı bir kod çoğaltmayı tercih ederim (defalarca çoğaltılmış test edilmemiş hatalı koddan daha kötü bir şey yoktur). Seçim, bir vektör çapraz ürününü hesaplamak veya sadece 3 satır kodunu kaldırmak için epik bir matematik kütüphanesini çekmek için 3 satırlı kopyalanmış kod arasındaysa, tüm ekibiniz bu matematik kütüphanesinde bulunmadığı sürece, ilkini öneririm. Bu noktada, ayrıştırma avantajları karşılığında yeterince önemsizse, 1 yerine sadece 3 satır kod yazmayı düşünebilirsiniz.
Kod tekrar kullanımı dengeleyici bir eylemdir. Çok fazla yeniden kullanın ve entelektüel karmaşıklığı, bir veya çok daha fazla şekilde aktarın, çünkü yukarıda kaydettiğiniz bu 3 basit kod satırında, okuyucuların ve bakıcıların 3 kod satırından çok daha fazla bilgi anlamalarını isteme pahasına gelir. . Ayrıca, kodunuzu daha az kararlı hale getirir, çünkü matematik kitaplığı değişirse, kodunuz da değişebilir. Yeniden kullanımın çok az olması ve entelektüel ek yükü çarpmanızın yanı sıra, kodunuzun merkezi iyileştirmelerden yararlanmak için sona ermesidir, bu nedenle dengeleyici bir eylemdir, ancak dengeleyici bir eylem olduğu fikri her küçük mütevazı kopyalamanın önünü kesmeye çalıştığından bahsetmeye değerdir. sonuçta, diğer uçtan daha fazla olmasa da bakımı zor olan bir sonuç elde edilir.
Zırvalamayı Test Et
Bu verilen bir kuraldır, ancak kodunuz tüm giriş durumlarını ele almıyorsa ve bazı son durumları özlüyorsa, başkalarının, gözlerine ve ellerine aktarılmadan hemen önce bile alamadığınızı yazdığı kodu korumasını nasıl beklersiniz? Her şeyden önce hiç doğru olmayan kodlar yerine, mükemmel çalışan kodda değişiklik yapmak yeterince zor.
Bunun ötesinde, kapsamlı testlerden geçen kod genellikle daha az değişiklik yapmak için nedenler bulacaktır. Bu, bakımdan daha fazla elde etmek için daha fazla kutsal bir kâseye sahip olan stabilite ile ilgilidir, çünkü hiçbir zaman değiştirilmesi gerekmeyen kararlı kod hiçbir bakım maliyeti gerektirmez.
Arayüz Dokümantasyonu
Her ikisini de belgelemek için eşit zaman ayıramazsanız, "ne işlerinin" üzerinde "işlerin nasıl yapıldığını" önceliklendirin. Tüm olası girdi vakalarında ne yapacağına (ya da en azından ne yapması gerektiğine) yönelik niyetlerinde açık olan net bir arayüz, sadece nasıl yapıldığını anlamada rehberlik edecek olan kendi uygulamasına bir bağlam açıklığı getirecektir. Kodu kullanmak için değil, aynı zamanda nasıl çalıştığını.
Bu arada, insanların ne yapması gerektiğini bile bilmediği bu niteliklerden yoksun olan kod, uygulama detaylarının ne kadar iyi belgelendirildiğine bakılmaksızın SOL. Kaynak kodun nasıl uygulandığına dair 20 sayfalık bir el kitabı, ilk etapta nasıl kullanılması gerektiğini ve tüm olası senaryolarda ne yapması gerektiğini bile bulamayan insanlar için değersizdir.
Uygulama tarafı için, diğerlerinden farklı yaptıklarınızı belgelemeye öncelik verin. Örnek olarak, Intel, ışın çekirdeği çekirdekleri için sınırlayıcı bir hacim hiyerarşisine sahiptir. Bu alanda çalıştığım için, kodlarının bir bakışta, belgelere göz atmadan ne yaptıklarının bir kısmını tanıyabilirim. Ancak, BVH'yi geçme ve ışın paketlerini kullanarak paralel olarak kesişme yapma fikri olan benzersiz bir şey yaparlar . Bu onların belgelerine öncelik vermelerini istediğim yer çünkü kodun bu kısımları çoğu tarihi BVH uygulamasında egzotik ve sıradışı.
Okunabilirlik
Bu kısım çok öznel. İnsan düşünce süreçlerine yakın bir türün okunabilirliğini pek umursamıyorum. Yazarın bir sorunu çözmek için tuhaf ve kıvrımlı düşünce süreçleri kullanması durumunda, en üst düzeydeki şeyleri açıklayan en iyi belgelenmiş kodun izlenmesi benim için hala zor. Bu arada, 2 veya 3 karakter ismi kullanan kısa ve öz kodlar mantığın çok basit olup olmadığını anlamak için daha kolay olabilir. Sanırım, başkalarının neyi tercih ettiğini gözden geçirip, görebileceksiniz.
Çoğunlukla sürdürülebilirlik ve daha da önemlisi istikrarla ilgileniyorum. Değişim için sebep bulamayan kod, bakım masrafları sıfır olan koddur.