Moderatör notu
Bu sorunun zaten kendisine gönderilen on yedi cevabı vardı . Yeni bir cevap göndermeden önce, lütfen mevcut cevapları okuyun ve bakış açınızın yeterince kapsamadığından emin olun.

Robert Martin'in "Temiz Kod" kitabında tavsiye edilen bazı uygulamaları, özellikle birlikte çalıştığım yazılım türlerini ve benim için anlamlı olanları (doma olarak takip etmiyorum) uygulayanları takip ediyorum. .

Ancak fark ettiğim bir yan etki, yazdığım "temiz" kodun, bazı uygulamaları takip etmediğimden daha fazla kod olmasıdır. Buna yol açan spesifik uygulamalar:

• Kapsülleme koşullamaları

Yani yerine

if(contact.email != null && contact.emails.contains('@')

Bunun gibi küçük bir yöntem yazabilirim

private Boolean isEmailValid(String email){...}

• Satır içi bir yorumu başka bir özel yöntemle değiştirmek, böylece yöntem adının üzerinde satır içi bir yorum yapmaktan ziyade kendisini açıklar.
• Bir sınıfın değişmesi için yalnızca bir nedeni olmalı

Ve birkaç diğerleri. Asıl mesele, 30 satırlık bir yöntem olabilecek olan şey, sınıfların yerini almaktır; yorumların yerini alan ve şartlı maddeleri içeren küçük metodlar vb. Gerçekten de bir yöntem olması gerektiğinden tüm işlevselliği bir sınıfa yerleştirin.

Aşırı yapılan herhangi bir uygulamanın zararlı olabileceğinin farkındayım.

Cevap aradığım somut soru şudur:

Bu, temiz kod yazmanın kabul edilebilir bir yan ürünü mü? Öyleyse, daha fazla LOC yazıldığı gerçeğini haklı çıkarmak için kullanabileceğim bazı argümanlar nelerdir?

Kurum özellikle daha fazla LOC ile ilgilenmiyor, ancak daha fazla LOC çok büyük sınıflarla sonuçlanabilir (bu, tekrar okunabilirlik uğruna kullanım için bir kez kullanımda yardımcı işlevler olmadan uzun bir yöntemle değiştirilebilir).

Yeterince büyük bir sınıf gördüğünüzde, sınıfın yeterince meşgul olduğu ve sorumluluğunun sonuçlandığı izlenimini verir. Bu nedenle, diğer işlevsellik parçalarını elde etmek için daha fazla sınıf oluşturabilirsiniz. Sonuçta, çoğu küçük yardımcı yöntemlerin yardımıyla "tek bir şey" yapan bir çok sınıf ortaya çıkıyor.

Bu özel bir endişe ... bu sınıflar birçok küçük yöntemin yardımı olmadan hala "bir şeyi" başarabilen tek bir sınıf olabilir. Belki 3 veya 4 yöntem ve bazı yorumlar ile tek bir sınıf olabilir.

... nispeten büyük ve belgelenmemiş bir kod tabanını destekleyen, çok küçük bir ekibiz.

Bu halk bir şeyi doğru bir şekilde tanımladı: Kodun korunmasını kolaylaştırmak istiyorlar. Ancak yanlış yaptıkları yer, kodun ne kadar az olduğu varsayılmakta, bakımı o kadar kolay.

Kodun bakımı kolay olması için değiştirmesi kolay olmalıdır. Kolayca değiştirilebilen bir kod elde etmenin en kolay yolu, yaptığınız değişikliğin kırılması halinde başarısız olacak bir otomatik test setine sahip olmaktır. Testler koddur, bu yüzden bu testleri yazmak kod tabanınızı şişirir. Ve bu iyi birşey.

İkincisi, neyin değişmesi gerektiğini anlamak için, kodun hem okunması kolay hem de mantıklı olmasının kolay olması gerekir. Çok kısa kod, sadece satır sayımını sürdürmek için küçültülmüş boyutta okunması kolay olması çok düşük bir ihtimaldir. Belli ki daha uzun kodun okunması daha uzun süreceğinden etkilenecek bir uzlaşma var. Ama anlamak daha hızlı olursa, buna değer. Bu avantajı sağlamazsa, o ayrıntılılık fayda olmayı keser. Ancak daha uzun kod okunabilirliği arttırırsa, o zaman yine bu iyi bir şey.

Evet, bu kabul edilebilir bir yan üründür ve gerekçelendirilmesi, şimdi kodun çoğunu okumak zorunda kalmayacak şekilde yapılandırılmış olmasıdır. Her değişiklik yaptığınızda 30 satırlık bir işlev okumak yerine, genel akışı elde etmek için 5 satırlık bir işlev okuyorsunuz ve eğer değişikliğiniz o bölgeye dokunursa, yardımcı işlevlerden birkaçı. Eğer yeni "ekstra" sınıfınız aranıyorsa EmailValidatorve probleminizin e-posta doğrulaması ile olmadığını biliyorsanız, tamamen okumayı atlayabilirsiniz.

Ayrıca, genel programınız için satır sayınızı azaltma eğiliminde olan daha küçük parçaları tekrar kullanmak daha kolaydır. Her EmailValidatoryerde bir tane kullanılabilir. E-posta doğrulaması yapan ancak veritabanı erişim koduyla birlikte şifrelenen bazı kod satırları yeniden kullanılamaz.

Ardından, e-posta doğrulama kurallarının değiştirilmesinin gerekli olması durumunda ne yapılması gerektiğini göz önünde bulundurun; hangisini tercih edersiniz: bilinen bir yer; ya da birçok yerde, muhtemelen birkaç tane eksik?

Bill Gates, “Programlama ilerlemesini kod satırlarıyla ölçmek, uçak binasının ağırlığını ölçmek gibi bir şey” demesiyle meşhurdu.

Bu düşünceye alçakgönüllülükle katılıyorum. Bu, bir programın az ya da çok kod satırı için çaba göstermesi gerektiği anlamına gelmez, ama sonuçta bunun işleyen ve çalışan bir program yaratmanın önemli olduğu şey değildir. Sonuç olarak, ilave kod satırları eklemenin arkasındaki neden teorik olarak daha okunaklı olduğunu hatırlamaya yardımcı olur.

Belirli bir değişikliğin az ya da çok okunabilir olup olmadığı konusunda anlaşmazlıklar olabilir, ancak programınızda değişiklik yapmanın yanlış olacağını düşünmüyorum, çünkü bunu yaparak daha okunaklı hale getirdiğinizi düşünüyorsunuz. Örneğin, bir yapma isEmailValid, özellikle onu tanımlayan sınıf tarafından tam bir kez aranıyorsa gereksiz ve gereksiz olduğu düşünülebilir. Bununla birlikte isEmailValid, her bir koşulun neyi kontrol ettiğini ve neden kontrol edildiğini belirlemem gereken bir dizi ANDed koşulundan ziyade bir durumda görmeyi tercih ederim.

Başınız belaya girdiğinde isEmailValid, yan etkileri olan veya e-posta dışındaki şeyleri kontrol eden bir yöntem oluşturduğunuzda, çünkü bunların hepsini yazmaktan daha kötü . Daha da kötüsü çünkü yanıltıcı ve bunun yüzünden bir böceği kaçırabilirim.

Açıkçası, bu durumda yapmıyor olsanız da, yaptığınız gibi devam etmenizi tavsiye ederim. Değişikliği yaparak, okumayı kolaylaştırıp bırakmadığınızı her zaman kendinize sormalısınız ve durum buysa, o zaman yapın!

bu yüzden bazı geliştiriciler / yöneticiler işlerin yapılması için daha az kod yazarken değeri görüyorlar;

Bu, asıl hedefin görüşünü kaybetme meselesidir.

Önemli olan gelişme için harcanan saatleri azaltmak . Bu, kod satırlarıyla değil, zamanla (veya eşdeğer bir çabayla) ölçülür.
Bu, otomobil üreticilerinin otomobillerini daha az vidayla yapmaları gerektiğini söylemek gibidir, çünkü her bir vidayı yerleştirmek için sıfır olmayan bir süre gerekir. Bu, bilyeli olarak doğru olsa da, bir otomobilin piyasa değeri kaç tane vida ile tanımlanmamıştır. ya da yok. Her şeyden önce, bir otomobilin performans göstermesi, emniyetli ve bakımı kolay olması gerekir.

Cevabın geri kalanı, temiz kodun zaman kazanmasına nasıl yol açabileceğinin örnekleridir.

Kerestecilik

Günlüğü olmayan bir uygulamayı (A) alın. Şimdi aynı A uygulaması olan ancak günlük kaydı olan B uygulamasını oluşturun. B her zaman daha fazla kod satırına sahip olacaktır ve bu nedenle daha fazla kod yazmanız gerekir.

Ancak sorunları ve hataları araştırmak ve neyin yanlış gittiğini bulmak için çok fazla zaman harcayacaktır.

Uygulama A için, geliştiriciler kodu okumaya devam eder ve sorunu sürekli olarak yeniden oluşturmak zorunda kalır ve sorunun kaynağını bulmak için kod boyunca ilerlerler. Bu, geliştiricinin yürütmenin başlangıcından sonuna, her kullanılan katmanda test etmesi gerektiği ve kullanılan her mantık parçasını gözlemlemesi gerektiği anlamına gelir.
Belki hemen bulduğu için şanslı, ama belki de cevap aramayı düşündüğü yerde olacak.

Mükemmel bir kütük kaydı varsayarak B uygulaması için bir geliştirici günlükleri gözlemler, hatalı bileşeni derhal tanımlayabilir ve şimdi nereye bakılacağını bilir.

Bu birkaç dakika, saat veya gün kazanılan bir mesele olabilir; Kod tabanının boyutuna ve karmaşıklığına bağlı olarak.

Regresyonlar

NEM ALMA dostu olmayan A uygulamasını kullanın.
KURU olan, ancak ek soyutlamalar nedeniyle daha fazla satıra ihtiyaç duyan B uygulamasını alın.

Mantığın değiştirilmesini gerektiren bir değişiklik isteği gönderilir.

B uygulaması için, geliştirici (benzersiz, paylaşılan) mantığı değişiklik isteğine göre değiştirir.

Uygulama A için, geliştirici, kullanıldığını hatırladığı yerde bu mantığın tüm örneklerini değiştirmelidir.

• Tüm örnekleri hatırlamayı başarırsa, yine de aynı değişikliği birkaç kez uygulamak zorunda kalacak.
• Tüm örnekleri hatırlamayı başaramazsa, şimdi kendisiyle çelişen tutarsız bir kod temeli ile uğraşıyorsunuz demektir. Geliştirici nadiren kullanılan bir kod parçasını unuttuysa, bu hata geleceğe kadar son kullanıcılar tarafından görülmeyebilir. O zaman, son kullanıcılar sorunun kaynağının ne olduğunu belirleyecek mi? Öyle olsa bile, geliştirici değişikliğin ne gerektirdiğini hatırlamayabilir ve bu unutulmuş mantık parçasının nasıl değiştirileceğini bulmak zorunda kalacaktır. Belki geliştirici o zamana kadar şirkette çalışmaz ve şimdi başkası her şeyi sıfırdan çözmelidir.

Bu çok büyük bir zaman kaybına neden olabilir. Sadece gelişimde değil, avlanmada ve böceği bulmada. Uygulama, geliştiricilerin kolayca anlayamayacağı şekilde kararsız davranmaya başlayabilir. Bu da uzun hata ayıklama oturumlarına yol açacaktır.

Geliştirici değişebilirliği

Geliştirici A oluşturulmuş bir uygulama A. Kod temiz değil ya da okunabilir değil, ancak bir cazibe işlevi görüyor ve üretimde çalışıyor. Şaşırtıcı olmayan bir şekilde, hiçbir belge de yok.

Geliştirici A, tatiller nedeniyle bir ay boyunca yoktur. Acil değişiklik talebi yapıldı. Dev A'nın geri dönmesi için üç hafta daha bekleyemez.

B geliştiricisinin bu değişikliği yapması gerekiyor. Şimdi kod kodunun tamamını okumalı, her şeyin nasıl çalıştığını, neden çalıştığını ve neyi başarmaya çalıştığını anlamalıdır . Bu yaş alır, ancak diyelim ki bunu üç hafta içinde yapabilir.

Aynı zamanda, B uygulamasının (B yarattığı) bir acil durumu var. Dev B meşgul, ancak kodunu bilmese bile Dev C kullanılabilir. Biz ne yaptık?

• Eğer B'yi A üzerinde çalışmaya devam edersek ve C'yi B'ye çalışmaya koyarsak, o zaman ne yaptıklarını bilmeyen iki geliştiricimiz olur ve iş, alt-basamakta gerçekleştirilir.
• B'yi A'dan uzaklaştırıp B'yi yapmasını ve şimdi A'yı C'ye koyarsak, geliştiricinin B'sinin (veya bunun önemli bir kısmının) tamamı atılabilir. Bu potansiyel olarak harcanan günler / haftalardır.

Dev A tatilinden geri dönüyor ve B'nin kodu anlamadığını görüyor ve bu yüzden de bunu çok yanlış uyguladı. Bu B'nin suçu değil, mevcut tüm kaynakları kullandığı için kaynak kodu yeterince okunamıyordu. A kodun okunabilirliğini düzeltmek için şimdi zaman harcamak zorunda mı?

Bu sorunların tümü ve daha fazlası, zaman kaybettiriyor . Evet, kısa vadede, temiz kod şimdi daha fazla çaba gerektiriyor , ancak kaçınılmaz hataların / değişikliklerin ele alınması gerektiğinde gelecekte kâr payı ödeyecek .

Yönetimin kısa bir görevin şimdiden gelecekte size birkaç uzun görev kazandıracağını anlaması gerekir. Planlamada başarısız olmak, başarısız olmayı planlamaktır.

Öyleyse, daha fazla LOC yazıldığı gerçeğini haklı çıkarmak için kullanabileceğim bazı argümanlar nelerdir?

Benim açıklamam, yönetime ne tercih edeceklerini sormak: üç ayda geliştirilebilecek 100KLOC kod temeli veya altı ay içinde geliştirilebilen 50KLOC kod temeli bir uygulama.

Belli ki daha kısa geliştirme süresini seçecekler , çünkü yönetim KLOC'yi umursamıyor . KLOC'a odaklanan yöneticiler, neyi yönetmeye çalıştıkları konusunda bilgisiz kalırken mikro yönetmenlik yapıyor.

Daha genel bir karmaşıklığa yol açmaları durumunda "temiz kod" uygulamalarını uygulama konusunda çok dikkatli olmanız gerektiğini düşünüyorum . Erken refactoring birçok kötü şeyin kaynağıdır.

Koşullu bir işleve ayıklamak, koşullu öğenin çıkarıldığı noktada daha basit koda yol açar, ancak şimdi programın daha fazla noktasından görünen bir işleve sahip olduğunuz için daha genel bir karmaşıklığa yol açar . Bu yeni işlevin şimdi görünür olduğu diğer tüm işlevlere hafif bir karmaşıklık yükü eklersiniz.

Sana demiyorum olmamalıdır eğer gerekiyorsa dikkatlice düşünmelisiniz sadece, koşullu ayıklamak.

• Özel olarak e-posta doğrulama mantığını test etmek istiyorsanız. O zaman o mantığı ayrı bir işleve çıkarmanız gerekiyor - muhtemelen sınıf.
• Aynı mantık koddaki birden fazla yerden kullanılıyorsa, onu açıkça tek bir işleve çıkarmanız gerekir. Kendini tekrar etme!
• Mantık açıkça ayrı bir sorumluluk ise, örneğin e-posta doğrulama bir sıralama algoritmasının ortasında gerçekleşir. E-posta doğrulama sıralama algoritmasından bağımsız olarak değişecektir, bu yüzden ayrı sınıflarda olmalıdırlar.

Yukarıdakilerin hepsinde, sadece "temiz kod" olmaktan ötesi çıkarmanın bir nedeni vardır. Ayrıca, yapılacak en doğru şey olsaydı muhtemelen şüphe bile olmaz.

Şüpheniz varsa, daima en basit ve en basit kodu seçin.

Bu konuda doğal olarak yanlış bir şey olmadığını belirtmek isterim:

if(contact.email != null && contact.email.contains('@')

En azından bu sefer kullanılmış.

Bununla kolayca problem yaşayabilirim:

private Boolean isEmailValid(String email){
   return email != null && email.contains('@');
}

İzleyeceğim birkaç şey:

1. Neden özel Potansiyel olarak yararlı bir saplama gibi görünüyor. Özel bir yöntem olacak kadar faydalı mı ve daha yaygın şekilde kullanılma şansı yok mu?
2. IsValidEmail yöntemini şahsen, muhtemelen ContainsAtSign veya LooksVaguelyLikeEmailAddress olarak adlandırmazdım çünkü neredeyse hiç gerçek bir doğrulama yapmaz, belki de iyi, belki de ne yapıldığı değil.
3. Bir kereden fazla mı kullanılıyor?

Bir kez kullanılıyorsa, ayrıştırılması basittir ve bir satırdan daha azını alırsa, ikinci kararı tahmin edeceğim. Muhtemelen bir ekibin belirli bir sorunu olmasaydı, söyleyeceğim bir şey değildi.

Diğer taraftan, yöntemlerin böyle bir şey yaptığını gördüm:

if (contact.email != null && contact.email.contains('@')) { ... }
else if (contact.email != null && contact.email.contains('@') && contact.email.contains("@mydomain.com")) { //headquarters email }
else if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") ) { //internal contract teams }

Bu örnek açıkça DRY değil.

Veya sadece bu son ifade bile başka bir örnek verebilir:

if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") )

Amaç, kodu daha okunaklı hale getirmek olmalıdır:

if (LooksSortaLikeAnEmail(contact.Email)) { ... }
else if (LooksLikeFromHeadquarters(contact.Email)) { ... }
else if (LooksLikeInternalEmail(contact.Email)) { ... }

Başka bir senaryo:

Gibi bir yöntem olabilir:

public void SaveContact(Contact contact){
   if (contact.email != null && contact.email.contains('@'))
   {
       contacts.Add(contact);
       contacts.Save();
   }
}

Bu, iş mantığınıza uyuyor ve yeniden kullanılmıyorsa, burada bir sorun yoktur.

Fakat birileri "Neden @ @ kurtarıldı, çünkü doğru değil!" Diye sorduğunda. ve bir çeşit gerçek doğrulama eklemeye karar verdin, sonra çıkart!

Başkanların ikinci e-posta hesabı Pr3 $ sid3nt @ h0m3! @ Mydomain.com hesabını da hesaba katmanız ve sadece çıkıp RFC 2822'yi desteklemeye karar vermeniz gerektiğinde yaptığınız için memnun olacaksınız .

Okunabilirlikte:

// If there is an email property and it contains an @ sign then process
if (contact.email != null && contact.email.contains('@'))

Eğer kodunuz bu kadar açıksa, burada yorum yapmanıza gerek yoktur. Aslında, kodun çoğu zaman ne yaptığını söylemek için yorumlara ihtiyacınız yoktur, bunun yerine neden kullandığı :

// The UI passes '@' by default, the DBA's made this column non-nullable but 
// marketing is currently more concerned with other fields and '@' default is OK
if (contact.email != null && contact.email.contains('@'))

Yukarıdaki açıklamaların bir if ifadesi veya küçük bir yöntem içinde olup olmadığı benim için, bilgiçlik taslayandır. Başka bir yöntemin içindeki iyi yorumların ne kadar faydalı olduğunu bile iddia edebilirim, çünkü şimdi bunun nasıl ve neden yaptığını görmek için başka bir yönteme gitmek zorunda kalacaksınız .

Özetle: Bunları ölçmeyin; Metnin oluşturulduğu ilkelere odaklanın (KURU, KATI, KISS).

// A valid class that does nothing
public class Nothing 
{

}

Temiz Kod mükemmel bir kitaptır ve okumaya değerdir, ancak bu gibi konularda nihai otorite değildir.

Kodu mantıksal işlevlere bölmek genellikle iyi bir fikirdir, ancak çok az sayıda programcı bunu Martin’in yaptığı gibi yapar - bir noktada her şeyi işlevlere dönüştürmekten azalan geri dönüşler alırsınız ve tüm kod küçük olduğunda izlemesi zorlaşır adettir.

Tamamen yeni bir işlev yaratmaya değmediği zaman seçeneklerden biri, basit bir değişkeni kullanmaktır:

boolean isEmailValid = (contact.email != null && contact.emails.contains('@');

if (isEmailValid) {
...

Bu, dosyanın etrafından çok fazla atlamak zorunda kalmadan kodun kolayca takip edilmesine yardımcı olur.

Diğer bir konu ise Temiz Kod'un şu anda bir kitap olarak yaşlanması. Bir çok yazılım mühendisliği işlevsel programlama yönünde ilerlerken, Martin nesnelere durum ekleme ve nesneler oluşturma yolunda ilerliyor. Bugün yazmış olsaydı, çok farklı bir kitap yazacağından şüpheleniyorum.

Şu anda sahip olduğunuz "e-posta geçerli" koşulunun, çok fazla geçersiz e-posta adresini " @" kabul edeceği gerçeği göz önüne alındığında, bir EmailValidator sınıfı oluşturmak için her türlü nedeniniz olduğunu düşünüyorum. Daha da iyisi, e-posta adreslerini doğrulamak için iyi test edilmiş bir kitaplık kullanın.

Bir metrik olarak kod satırları anlamsızdır. Yazılım mühendisliğindeki önemli sorular:

• Çok fazla kodunuz var mı?
• Çok az kodunuz var mı?

Önemli sorular:

• Uygulama bir bütün olarak doğru tasarlanmış mı?
• Kod doğru olarak uygulandı mı?
• Kod korunabilir mi?
• Kod test edilebilir mi?
• Kod uygun şekilde test edildi mi?

Code Golf dışında herhangi bir amaç için kod yazarken LoC'ye asla bir düşünce vermedim. Kendime “Bunu daha kısa sürede yazabilir miyim?” Diye sordum, ancak okunabilirlik, bakım ve verimlilik açısından sadece uzunluk için değil.

Elbette, faydalı bir yöntem yerine uzun bir boolean işlem zinciri kullanabilirim, değil mi?

Sorunuz aslında bana yazdığım ve onların yerine bir veya daha fazla faydalı yöntem (ler) yazmam gerektiğinin farkında olduğum bazı uzun zincir zincirleri hakkında düşünmemi sağlıyor.

Bir seviyede, haklıdırlar - daha az kod daha iyidir. Gate'den alıntılanan bir başka cevap tercih ediyorum:

“Hata ayıklama, yazılım hatalarını giderme işlemi ise, programlama onları yerleştirme işlemi olmalıdır.” - Edsger Dijkstra

“Hata ayıklama sırasında acemiler düzeltici kod ekliyor; uzmanlar kusurlu kodu kaldırıyor. ”- Richard Pattis

En ucuz, en hızlı ve en güvenilir bileşenler orada olmayan bileşenlerdir. - Gordon Bell

Kısacası, ne kadar az kodunuz olursa, o kadar az yanlış gidebilirsiniz. Bir şey gerekli değilse, o zaman kesin.
Aşırı karmaşık kod varsa, gerçek işlevsel öğeler kalan tek şey olana kadar basitleştirin.

Burada önemli olan, bunların hepsinin işlevsellikten bahsettiği ve yalnızca bunu yapmak için gereken minimum seviyeye sahip olmasıdır. Bunun nasıl ifade edildiği hakkında hiçbir şey söylemez .

Temiz kod almaya çalışarak ne yaptığınız yukarıdakilere aykırı değildir. LOC'nize ekliyorsunuz ancak kullanılmayan işlevler eklemiyorsunuz.

Son amaç, okunabilir koda sahip olmak ama gereksiz ekstralar içermemektir. İki ilke birbirlerine karşı hareket etmemelidir.

Bir metafor bir araba inşa ediyor olacaktı. Kodun işlevsel kısmı şasi, motor, tekerlekler… otomobili çalıştıran şey. Nasıl ayrılacağınız, süspansiyon, hidrolik direksiyon ve benzeri şeylere daha çok benziyor, işlemeyi kolaylaştırıyor. İşlerin yanlış gitme ihtimalini en aza indirgemek için hala işlerini yaparken mekaniğinin mümkün olduğunca basit olmasını istersiniz, ancak bu güzel koltuklara sahip olmanızı engellemez.

Mevcut cevaplarda çok fazla bilgelik var, fakat bir faktör daha eklemek istiyorum: dil .

Bazı diller aynı etkiyi elde etmek için diğerlerinden daha fazla kod alıyor. Özellikle, Java (söz konusu dilin olduğundan şüpheliyim) son derece iyi bilinen ve genellikle çok sağlam ve açık ve anlaşılır olsa da, bazı daha modern diller çok daha özlü ve etkileyicidir.

Örneğin, Java'da, her biri bir alıcı ve ayarlayıcı ve bir veya daha fazla yapıcı olan üç özellikli yeni bir sınıf yazmak kolayca 50 satır alabilir; aynı şeyi tek bir Kotlin * veya Scala satırında başarabilirsiniz. (Hatta daha tasarruflu ayrıca uygun isteseydi equals(), hashCode()ve toString()yöntemleri.)

Sonuçta, Java'da, ekstra iş, gerçekten uymayan bir nesneyi yeniden kullanma, özellikleri mevcut nesnelere sıkma veya bireysel olarak bir sürü "çıplak" özellik geçirme olasılığınız; özlü, anlamlı bir dilde, daha iyi kod yazmanız daha olasıdır.

(Bu, kodun 'yüzey' karmaşıklığı ile uyguladığı fikirlerin / modellerin / işlemlerin karmaşıklığı arasındaki farkı vurgular. Kod satırları, ilkinin kötü bir ölçüsü değildir, ikincisi ile daha az ilgisi vardır. .)

Bu yüzden doğru şeyler yapmanın 'maliyeti' dile bağlıdır. Belki de iyi bir dilin bir işareti, sizi iyi şeyler yapmak ve basitçe yapmak arasında seçim yapmanıza izin vermeyen bir dildir !

(* Bu gerçekten bir fiş için yer değil, ancak Kotlin de IMHO'ya bakmaya değer.)

ContactŞu an sınıfla çalıştığınızı varsayalım . E-posta adresinin doğrulanması için başka bir yöntem yazıyor olmanız, sınıfın Contacttek bir sorumluluk üstlenmediğinin kanıtıdır .

Ayrıca, ideal olarak kendi sınıfı olması gereken bazı e-posta sorumluluklarını da yerine getirmektedir.

Kodunuzun bir birleşimi Contactve Emailsınıf olduğunun bir başka kanıtı, e-posta doğrulama kodunu kolayca test edemeyeceğinizdir. Doğru değerlere sahip büyük bir yöntemle e-posta doğrulama koduna ulaşmak için çok fazla manevra yapılması gerekir. Aşağıdaki viz yöntemine bakınız.

private void LargeMethod() {
    //A lot of code which modifies a lot of values. You do all sorts of tricks here.
    //Code.
    //Code..
    //Code...

    //Email validation code becoming very difficult to test as it will be difficult to ensure 
    //that you have the right data till you reach here in the method
    ValidateEmail();

    //Another whole lot of code that modifies all sorts of values.
    //Extra work to preserve the result of ValidateEmail() for your asserts later.
}

Öte yandan, e-posta doğrulama yöntemine sahip ayrı bir E-posta sınıfınız varsa, doğrulama kodunuzu birim sınamak için yalnızca Email.Validation()test verilerinizle basit bir arama yaparsınız .

_{Bonus İçerik: MFeather'ın test edilebilirlik ve iyi tasarım arasındaki derin sinerji hakkında konuşması .}

LOC'deki azalmanın, azalmış kusurlarla, başka bir şeyle ilişkili olmadığı bulunmuştur. Öyleyse, LOC'yi her düşürdüğünüzde, kusur olasılığını azalttığınızı varsayarsak, temel olarak korelasyonun nedenselliğe eşit olduğuna inanmanın tuzağına düşüyorsunuz. Azalan LOC, kodu iyi yapan şey değil, iyi geliştirme uygulamalarının bir sonucudur .

Tecrübelerime göre, daha az kodlu (makro düzeyde) bir sorunu çözebilen insanlar, aynı şeyi yapmak için daha fazla kod yazanlardan daha yetenekli olma eğilimindedir. Bu yetenekli geliştiricilerin kod satırlarını azaltmak için yaptıkları ortak sorunları çözmek için soyutlamalar ve yeniden kullanılabilir çözümler kullanmak / kullanmaktır. Kod satırlarını sayarak ve burada ya da oraya bir çizgi kesebilecekleri için acı çekerek zaman harcamazlar. Genellikle yazdıkları kod gerekenden daha ayrıntılıdır, sadece daha az yazarlar.

Sana bir örnek vereyim. Zaman periyotları ve nasıl örtüştükleri, bitişik olup olmadıkları ve aralarındaki boşlukların neler olduğu konusunda mantık ile uğraşmak zorunda kaldım. Bu problemler üzerine çalışmaya başladığımda, her yerde hesaplamaları yapan kod bloklarına sahip olurdum. Sonunda, çakışmaları, tamamlayıcıları vb. Hesaplayan zaman periyodlarını ve işlemleri temsil eden sınıflar oluşturdum. Ancak bu sınıfların kendileri kısaca yazılmış değildi.

Açıkça belirtildiği gibi: burada ya da daha fazla vecizle birlikte bir kod satırı keserek LOC'yi azaltmaya çalışıyorsanız, yanlış yapıyorsunuz demektir. Yediğiniz sebze miktarını azaltarak kilo vermeye çalışmak gibi. Yeniden kullanımı ve soyutlama yoluyla LOC'yi anlamak, sürdürmek ve hata ayıklamak ve azaltmak için kolay bir kod yazın.

Geçerli bir takas belirlediniz

Yani burada gerçekten bir takas var ve soyutlamanın bir bütün olarak doğası gereği . Herhangi biri isimlendirmek ve yalıtmak için N kod satırını kendi işlevine çekmeye çalıştığında , aynı anda arayan siteyi okumayı kolaylaştırır (bu ismin altında yatan tüm ayrıntılardan ziyade bir isme başvurarak) ve daha karmaşık (artık kod tabanının iki farklı kısmı arasında dolaşmış bir anlamınız var). “Kolay”, “zor” un tam tersidir, ancak “karmaşık” ın tam tersi olan “basit” ile eş anlamlı değildir. İkisi karşıt değildir ve soyutlama, bir form ya da başka bir kolaylığı eklemek için her zaman karmaşıklığı arttırır.

İş gereksinimlerindeki bazı değişiklikler soyutlamanın sızmaya başlamasına neden olduğunda, doğrudan karmaşıklığı görebiliriz. Belki de yeni bir mantık önceden soyutlanmış kodun ortasına en doğal şekilde giderdi, örneğin, soyutlanmış kod bir ağaçtan geçiyorsa ve gerçekten bir tür bilgiyi toplarsanız (ve belki de üzerinde hareket ederseniz) söyleyin. ağacı geçiyor. Bu arada, bu kodu çıkardıysanız, başka çağrı siteleri olabilir ve yöntemin ortasına gerekli mantığı eklemek diğer çağrı sitelerini kırabilir. Bakın, ne zaman bir kod satırını değiştirirsek, yalnızca o kod satırının içeriğine bakmamız gerekir; Bir yöntemi değiştirdiğimizde, bu yöntemin sözleşmesinin değiştirilmesi sonucunda kırılabilecek bir şey arayan tüm kaynak kodumuzu Cmd-F'ye koymalıyız,

Açgözlü algoritma bu durumlarda başarısız olabilir

Karmaşıklık aynı zamanda kodu belirli bir anlamda daha fazla değil, daha az okunabilir hale getirdi.. Önceki bir işte, birkaç katmana çok dikkatli ve hassas bir şekilde yapılandırılmış bir HTTP API ile başa çıktım, her son nokta, gelen mesajın şeklini doğrulayan ve ardından bazı "business-logic-layer" yöneticisine veren bir denetleyici tarafından belirlendi. daha sonra, bazı "veri erişim nesnesi" katmanına birkaç sorgulama yapmaktan sorumlu olan bazı "veri katmanlarından" istekte bulunmuşlardı. Söyleyebileceğim ilk şey, kodun% 90'ı gibi bir şey kopyala-yapıştır kazan plakasıydı, başka bir deyişle, op-op değildi. Bu nedenle, birçok durumda, herhangi bir kod geçişini okumak çok kolaydı, çünkü "ah bu yönetici, bu veri erişim nesnesine isteği iletti."lot bağlam anahtarlama ve dosyaları bulma ve bu diğer ' 'bu diğer katmanında o zaman denir X' asla bu o X'in denilen olur, bu katmanın X denir", izleme olması gerektiğini bilgileri izlemek için çalışıyor diğer katman. "

Ayrıldığımda, bu basit CRUD API'si, sayfa başına 30 satıra basarsanız, rafa 10-20 beş yüz sayfalık ders kitabı alacağı bir aşamadaydı: tekrarlanan bir ansiklopedi oldu. kodu. Temel karmaşıklık açısından, orada bir temel karmaşıklık ders kitabının yarısının bile olduğundan emin değilim; Biz sadece bunu işlemek için belki 5-6 veritabanı diyagramları vardı. Herhangi bir küçük değişiklik yapmak bir mamut girişimi oldu, öğrenmek bir mamut girişimi oldu, yeni işlevler eklemek o kadar acı vericiydi ki, aslında yeni işlevsellik eklemek için kullanacağımız şablon dosyalarına sahip olduk.

Bu yüzden, her bir parçanın çok okunaklı ve açık hale getirilmesinin bütünün çok okunaksız ve açık olmayan hale gelmesine neden olduğunu ilk elden gördüm. Bu , açgözlü algoritmanın başarısız olabileceği anlamına gelir . Açgözlü algoritmayı biliyorsun, değil mi? “Yerel olarak en fazla iyileştirici adım olan her adımı yapacağım ve kendimi küresel anlamda gelişmiş bir durumda bulduğuma güveneceğim.” Genellikle güzel bir ilk girişimdir ancak karmaşık bağlamlarda da gözden kaçabilir. Örneğin, üretimde karmaşık bir üretim sürecindeki her bir adımın verimliliğini artırmayı deneyebilirsiniz - daha büyük partiler yapın, zeminde, ellerini başka bir şeyle meşgul etmek için hiçbir şey yapmamış gibi görünen insanlara bağırın - Bu genellikle sistemin küresel verimliliğini tahrip edebilir.

En iyi yöntem: görüşme yapmak için DRY ve uzunluklarını kullanın.

(Not: Bu bölüm başlığı bir şakadır; sık sık arkadaşlarımın "X yapmalıyız çünkü en iyi uygulamaları söylesin " dediğinde , SQL enjeksiyon ya da şifre karmaşası gibi bir şeyden bahsetmedikleri zamanların% 90'ını söylerim. ya da her neyse - tek taraflı en iyi uygulamalar - ve böylece ifade, zaman zaman% 90'ına, "X yapmalıyız çünkü söylemeliyim " olarak çevrilebilir . Daha iyi bir iş çıkaran bazı işlerden gelen bazı blog yazılarına sahip olabilirler. X’ten ziyade X’le değil, genel olarak işinizin o işletmeyle aynı olduğuna dair hiçbir garanti yoktur ve genellikle X’den ziyade X 'ile daha iyi bir iş yapan başka bir işten başka bir makale daha vardır. ciddi anlamda.)

Tavsiye edeceğim şey, Jack Diederich'in Stop Writing Classes (youtube.com) adlı bir konuşmasına dayanıyor . Bu konuşmasında birçok önemli noktaya değindi: örneğin, bir sınıfın yalnızca iki genel metodu olduğunda gerçekten bir fonksiyon olduğunu ve bunlardan biri yapıcı / başlatıcı olduğunu bilirsiniz. Fakat bir durumda, konuşmaya "Muffin" olarak dizgesinin yerini aldığı varsayımsal bir kütüphanenin dict, Python'un yerleşik tipinin bir alt sınıfı olan "MuffinHash" sınıfını ilan ettiğini anlatıyor . Uygulama tamamen boştu - birisi sadece "daha sonra Python sözlüklerine özel işlevsellik eklememiz gerekebilir, şimdi tam da bir soyutlama getirelim" demişti.

Ve onun meydan okurcasına cevabı basitçe "Gerekirse daha sonra her zaman yapabiliriz" oldu.

Sanırım bazen gelecekte olduğumuzdan daha kötü programcılar gibi davranıyoruz, bu yüzden gelecekte bizi mutlu edebilecek bazı küçük şeyler eklemek isteyebiliriz. Geleceğin ihtiyaçlarını önceden tahmin ediyoruz. "Trafik, düşündüğümüzden 100 kat daha büyükse, bu yaklaşım ölçeklenmeyecektir, bu yüzden ön yatırımları ölçeklendirecek bu zor yaklaşıma koymak zorundayız." Çok şüpheli.

Bu tavsiyeyi ciddiye alırsak, “sonra” ne zaman geleceğini tanımlamamız gerekir. Muhtemelen en belirgin şey, stil sebepleriyle işlerin uzunluğuna bir üst sınır koymak olacaktır. Ve kalan en iyi tavsiyenin DRY'yi kullanmak olacağını düşünüyorum - SOLID ilkelerinde bir delik açmak için bu uzunluklar ile ilgili bu sezgilerle kendinizi tekrar etmeyin. 30 satırdan oluşan bir sezgisel yazının bir "sayfa" olması ve nesir ile benzerlik olması,

1. Kopyala yapıştırmak istediğinizde bir işleve / yönteme yönelik yeniden denetleme yapın. Kopyala yapıştırmak için ara sıra geçerli nedenler olduğu gibi, ancak bunun hakkında her zaman kirli hissetmeniz gerekir. Gerçek yazarlar, gerçekten bir temayı vurgulamaya çalışmadıkları sürece, anlatı boyunca 50 kez uzun bir cümle okumanızı sağlamaz.
2. Bir işlev / yöntem ideal olarak "paragraf" olmalıdır. Çoğu işlev yaklaşık yarım sayfa uzunluğunda veya 1-15 kod satırı olmalı ve işlevlerinizin yalnızca% 10'unun bir sayfaya ve yarım, 45 satır veya daha fazlasına kadar erişmesine izin verilmelidir. Bir keresinde 120'den fazla kod satırına gidersiniz ve bu şeyin parçalara ayrılması gerektiğini belirtir.
3. Bir dosya ideal olarak bir "bölüm" olmalıdır. Dosyaların çoğu 12 sayfa veya daha az olmalı, bu nedenle 360 ​​satır kod ve yorum içermelidir. Dosyalarınızın yalnızca% 10'unun 50 sayfa uzunluğunda veya 1500 satırlık kod ve yorum içermesine izin verilmelidir.
4. İdeal olarak, kodunuzun çoğu, işlevin temeli veya bir seviye derinlikte girintili olmalıdır. Linux kaynak ağacı hakkındaki bazı sezgilere dayanarak, eğer onun hakkında dindarsanız, kodunuzun sadece% 10'unun girintili olması durumunda taban çizgisinde 2 seviye veya daha fazlası,% 5'ten az girinti 3 seviye veya daha fazla olmalıdır. Bu, özellikle büyük bir denemede / yakalamada hata yapma gibi başka bir endişeyi "sarması" gereken şeylerin gerçek mantıktan çıkarılması gerektiği anlamına gelir.

Yukarıda da belirttiğim gibi, bu istatistikleri bu yaklaşık yüzdeleri bulmak için mevcut Linux kaynak ağacına karşı test ettim, fakat aynı zamanda edebi analojide akla durma gibi görünüyorlar.