Temiz Kod–Daha İyi Bir WordPress Geliştiricisi Olmak İçin İpuçları (II)

Birkaç ay önce, dediğim gibi, iyi tavsiyeler ve en iyi programlama uygulamalarını içeren bir kitap olan “Pragmatik programcı: kalfadan ustaya” hakkındaki fikrimi sizinle paylaşmıştım. Kitabı henüz okumadıysanız, hemen okuyun, çok keyifli ve öğretici. Her neyse, bir önceki yazımda rafta beni bekleyen ikinci bir kitabımın olduğunu da söylemiştim: Clean Code, hatırladın mı? Eh, onu zaten okuduğumu söylemekten mutluyum ve onu “Pragmatik programcıdan” daha çok seviyorum! Hadi kitaba bir göz atalım ve bence en iyi yanları neler ?

Kitaba Genel Bakış

Clean Code çok ilginç bir önermeye dayanmaktadır: “hatta kötü kod çalışır”. Yani, kod temiz ve düzenli olmasa bile, kaotik ve anlaşılması zor ise, kötü yazılmışsa… bunların hiçbiri onun işleyişi üzerinde olumsuz bir etkiye sahip olmak zorunda değildir – kod olması gerektiği gibi çalışabilir. Şimdi, benimle ve kitabın yazarı Robert C.”Uncle Bob” Martin ile bu tür kodlarla uğraşmanın herhangi bir programcı için büyük bir sorun olacağı konusunda hemfikir olacaksınız, değil mi? ?

Yazılım bileşenleri herhangi bir şirkette son derece önemli bir rol oynamaktadır. Kaynak kodunuz temiz ve düzenli değilse, her değiştirmeniz, uyarlamanız veya düzeltmeniz gerektiğinde ona yatırım yapmak zorunda kalacağınız zaman ve acımasız kaynaklar acımasız olacaktır ve hatta şirketin mali durumunu mahvedebilir. İşte bu yüzden bu kitap size temiz kodun nasıl yazılacağını ve geliştirilebilecek kodların nasıl tespit edileceğini öğretiyor.

Kitap üç bölüme ayrılmıştır. İlk olarak, bir kaynak kodunu temiz yapan ilkeleri, standartları ve iyi uygulamaları tanımlar. İkinci bölümde, kötü yazılmış koddan başlayıp zarif ve verimli bir çözüme ulaşana kadar yavaş yavaş cilaladığınız birçok vaka incelemeniz (giderek daha karmaşık) var. Son kısım, bir parçanın ne zaman ve nasıl geliştirilebileceğini tespit etmenize yardımcı olan vaka çalışmaları oluşturulurken toplanan buluşsal yöntemlerin ve "kokuların" bir listesidir. Başka bir deyişle, kodun nasıl yazılacağını, okunacağını ve temizleneceğini açıklayan bir bilgi tabanıdır.

Kitabı dikkatlice okursanız ve içerdiği tüm dersleri öğrenmeye çalışırsanız, sonunda onu anlamaktan uzaklaşırsınız:

• İyi ve kötü kod arasındaki fark nasıl anlaşılır
• İyi kod nasıl yazılır ve kötü kod nasıl iyi koda dönüştürülür
• İyi isimler, iyi işlevler, iyi nesneler ve iyi sınıflar nasıl oluşturulur?
• Maksimum okunabilirlik için kod nasıl biçimlendirilir
• Kod mantığını engellemeden tam hata işleme nasıl uygulanır?
• Test odaklı geliştirme nasıl birim test edilir ve uygulanır

Oldukça havalı, ha?

Kitap aşağıdaki bölümler halinde düzenlenmiştir:

1. Temiz Kod. Anlaşılmaz kod ile temiz kod arasındaki farka giriş. Bence bölümü açan resim oldukça komik ve kitaptan ne bekleneceğini açıkça gösteriyor:
   

   
   

2. Anlamlı İsimler Fonksiyonlarımızın, değişkenlerimizin, sınıflarımızın… kısacası kodumuzun tüm bileşenlerinin anlaşılır ve açıklayıcı olduğundan nasıl emin oluruz.
3. Fonksiyonlar. Daha iyi fonksiyonlar yazmak için ipuçları: kısa, atomik, basit, az parametre, yan etki yok…
4. Yorumlar Temel olarak neden yorumları kullanmamanız gerektiğini anlatan bir bölüm. Niye ya? Kitabı oku! ?
5. biçimlendirme. Kodu biçimlendirmek için daha fazla ipucu (aralık, girinti vb.). Daha iyi bir WordPress geliştiricisi olmak için bu kitabı okuyorsanız, bu bölümü atlayabilirsiniz – WordPress'te zaten buna yönelik harika stil kılavuzları var.
6. Nesneler ve Veri Yapıları. Bağlantıyı azaltmak (hatta ortadan kaldırmak) için veri soyutlamaya ilişkin birkaç ipucu ve ilke.
7. Hata yönetimi. Hata işlemeyi kodumuza verimli bir şekilde nasıl ekleyebileceğimize dair bazı faydalı ipuçları içeren harika bir bölüm (aslında benim favorilerimden biri). Özünde, üzücü bir gerçeği kapsıyor: Hata işleme aksesuardır – buna ihtiyacımız var, ancak muhtemelen yazılımımızın ana işleviyle ilgisi yok. Sonuç olarak, onu kodumuza eklemek, kodun "kirli" ve gereksiz yere karmaşık görünmesine neden olur. Pekala, bu bölüm nasıl temiz bir şekilde yapılacağını öğretiyor.
8. Sınırlar. Programcıların karşılaştığı en zorlu sorunlardan biri (ve bu özellikle WordPress'te geçerlidir), dış kitaplıklara veya hizmetlere bağımlılığımızdır – değişirlerse işler çalışmayı durdurabilir. Bu bölüm, üçüncü taraf çözümlerine güvenirken uyumluluk sorunları yaşayabileceğimiz farklı senaryoları tanımlar ve bunların etkilerini nasıl ortadan kaldıracağınızı veya en aza indireceğinizi gösterir.
9. Birim Testleri. Bu bölüm hakkında söyleyebileceğim çok az şey var – içeriğini daha önceki yazılarda ayrıntılı olarak tartışmıştık.
10. Sınıflar. İlk bölümlerde, kitap kodlamanın yapı taşlarını kapsar: fonksiyonlar, veri yapıları, değişkenler vb. Temiz kod iyi bir organizasyon gerektirdiğinden, kitap ayrıca bu konuyu tartışmak için birkaç bölüm ayırıyor. Bu bölümde, “boyut” ve “sorumluluklar” hakkında bazı temel tavsiyelerde bulunarak, nesne yönelimli programlama ve sınıf kavramına odaklanır.
11. Sistemler. Bu bölüm öncekinden daha soyut çünkü “sistem” kavramını, farklı bileşenler arasındaki etkileşimleri, içerdiği zorlukları açıklıyor… Diğerlerinden daha karmaşık olsa bile buna değer (özellikle daha büyük sistemlerle çalışıyorsanız). WordPress Core gibi yazılım bileşenleri).
12. ortaya çıkma. Bu bölümde, yazar dört yönerge verir. Onları takip edin ve kodunuz daha temiz olacaktır. Esasen, bir tasarım şu kurallara uyuyorsa "basittir":
    • Tüm testleri çalıştırır
    • Çoğaltma içermez
    • Programcının amacını ifade eder
    • Sınıf ve yöntem sayısını en aza indirir
13. eşzamanlılık Eşzamanlı sistemlerde bulunan sorunlara ve bunların çözümlerine ayrılmış bir bölüm.
14. Ardışık İyileştirme. Yazarın hatalı bir kod sunduğu ve temiz kod haline gelene kadar adım adım iyileştirdiği bir vaka çalışması.
15. JUnit Dahili. Başka bir pratik örnek. Bu özel durumda, yazar JUnit kaynak koduna dalar ve bazı olası iyileştirmeler sunar.
16. SerialDate . Son olarak, başka bir vaka çalışması. Bu durumda Martin'in “iyi kod” olarak tanımladığı bir kodla başlıyoruz. Ancak bu, birkaç iyileştirme önermesini engellemez.
17. Kokular ve Sezgisel. Kodunuzda iyileştirilmesi gereken bileşenleri belirlemenize yardımcı olacak harika bir buluşsal yöntem ve koku derlemesi. Bu bölümü sadece okumamalısınız – onu kendinize yakın tutmalı ve referans olarak kullanmalısınız. Bence bu kokular ve buluşsal yöntemler paha biçilemez!

En İyi 3 İpucu

Bu kitap harika—çok iyi yazılmış ve kod yazarken hepimizin bilmesini ve uygulamasını istediğim birçok püf noktası var… ama sanırım kitabı okumak ve derslerini uygulamaya istekli olmak, daha iyi bir programcı olmanın ilk adımıdır. !

Şimdi, söz verildiği gibi, burada kitabın en iyi 3 bölümü var:

? Bronz. “Yorumlar Kötü Kodu Düzeltmez”.

Martin'in dediği gibi, "yorum yazmak için en yaygın motivasyonlardan biri kötü koddur". Bir düşünün: Az önce yeni bir modül yazdınız ve işe yarıyor ama temelde bir karmaşa. Bu yüzden ona bakıp kendinize şöyle diyorsunuz: “Ooh, bunu yorumlasam iyi olur!” Numara! Temizlesen iyi olur!

Bir kod parçasını anlamak için asla yoruma ihtiyaç duyulmamalıdır – bu kendi kendini açıklayıcı olmalıdır. Bunun nedeni, kodunuzdaki bir yorumun düzelttiğinden daha fazla sorun yaratmasıdır. Bir yandan, yorum güncel olmayabilir ve koda karşılık gelmeyebilir. Ancak durum böyle olmasa bile, kodu değiştirmek, yorumla “eşzamanlı” olması için yorumu güncellemeniz gerektiği anlamına gelir… ve bu fazladan bir iş! Öte yandan, yorumlar bir sıkıntı haline gelebilir.

Örneğin, şu küçük parçayı düşünün:

 // Çalışanın tam fayda için uygun olup olmadığını kontrol edin
if ( ( çalışan.flags & HOURLY_FLAG ) && ( çalışan.yaş > 65 ) )

Aşağıdaki yol daha iyi değil mi?

 if (çalışan.isEligibleForFullBenefits() )

Niyetinizin çoğunu kodda açıklamak sadece birkaç saniye sürer. Çoğu durumda, adı yorumunuzla aynı şeyi söyleyen bir işlev oluşturmakla ilgilidir. Ve bu şekilde kodunuzu daha temiz ve daha iyi hale getirirsiniz .

Sorumluluk Reddi Bazen, kodunuzu yorumlamanız gerekir . Örneğin, bir API oluşturuyorsanız, kullanıcılarınızın onu etkin bir şekilde kullanabilmesi için iyi belgelenmesi gerektiği açıktır; sonuçta, API'nin içindekilerden habersiz olabilirler. Ancak yine de, fonksiyon ve parametre adlarınız mümkün olduğunca açıklayıcı ve net olmalıdır.

? Gümüş rengi. “Fonksiyonların Yan Etkisi Olmamalıdır”.

“Yan etkiler yalandır. İşleviniz bir şeyi yapmayı vaat ediyor, ancak aynı zamanda başka gizli şeyler de yapıyor“. Bu açıklamaya daha fazla katılamadım. Bir fonksiyon global değişkenlere bağlı olduğunda ve bunları manipüle ettiğinde, düzensiz bir davranışı analiz etmek, anlamak ve düzeltmek çok zordur. Ve bu, WordPress Core'da çok gördüğümüz bir şey; çok sayıda global değişken ve nesne var. Bu yüzden bu ipucunun tüm WordPress geliştiricileri için çok önemli olduğunu düşünüyorum – mümkün olduğunda yan etkilerden kaçınmalıyız.

Yalnızca global değişkenler beklenmeyen yan etkilere neden olmaz, aynı zamanda bir fonksiyondaki çıktı parametreleri de beklenmeyen yan etkilere neden olabilir! Bu meydana geldiğinde, bir fonksiyon çağrıldıktan sonra bir veya daha fazla parametrenin değeri değişir ve bu açıkça beklenmeyen bir davranıştır. Genel olarak, hepimiz fonksiyonların parametrelerinin sadece girdi değişkenleri olduğunu varsayıyoruz. Bir fonksiyonun parametresi olarak kullanıldığında belirli bir değişkenin değişeceğini bilmenin tek yolu onun dokümantasyonudur ve, az önce yorumların gerekli olmaması gerektiğini gördük, değil mi?

Sorun hakkında net bir fikir edinmek için aşağıdaki örneğe bir göz atın:

 genel sınıf UserValidator {
  ...
  public boolean checkPassword(String kullanıcı adı, String şifresi) {
    Kullanıcı kullanıcı = UserGateway.findByName(kullanıcı adı);
    if (kullanıcı != Kullanıcı.NULL) {
      if (user.hasPassword(parola)) {
        Session.initialize();
        true döndür;
      }
    }
    yanlış döndür;
  }
  ...
}

Yan etkiyi görebiliyor musunuz? Kesinlikle! Yan etki, Session.initialize() çağrısıdır. Kullanıcı, görünüşe göre şifreyi kontrol etmesi gereken bir işlevi çağırıyor, bu nedenle kullanıcı, işlevin söylediği şeyi yapmasını bekliyor. Peki, neden bir oturum başlatıyor? ? Kimse bilmiyor! İstediğimiz davranış buysa, farklı bir ad daha iyi hale getirir: checkPasswordAndInitializeSession

? Altın. "Anlamlı İsimler".

İsimler yazılımdaki her şeydir . Ne de olsa programlama, bir sistemi resmi bir dilde tanımlamaktan başka bir şey değildir, bu da kavramların ve isimlerin son derece önemli bir rol oynadığı anlamına gelir. Bir saniye düşünün, isimler her yerde! Değişkenler, bağımsız değişkenler, işlevler, sınıflar, dosyalar, dizinler… hepsinin adı var! Peki, bir şeyi nasıl adlandıracağınıza karar vermek için ne kadar zaman harcıyorsunuz? Aklınıza gelen ilk ismi kullanıyor musunuz?

Kitabın ikinci bölümünün olağanüstü olduğunu düşünüyorum – tüm programcıların uygulaması gerektiğini düşündüğüm faydalı ipuçlarıyla dolu. Aşağıdakiler bu ipuçlarına sadece birkaç örnektir:

1. Niyet Açıklayıcı İsimler Kullanın. Kaç kez d adında bir değişken ve ardından bunun ne olduğunu açıklayan bir yorum buldunuz? Bazen programcılar sadece tembeldir… ve biz olmamalıyız! elapsedTimeInDays , daysSinceCreation veya fileAgeInDays gibi farklı bir ad kullanın. Açık ve anlamlı olduğu sürece gerçek adın pek bir önemi yok.
2. Dezenformasyondan kaçının. İsimler gerçek bilgi vermeli – yalan söylememelidir. Örneğin, bir dizi hesabımız varsa, değişkeninizi accountList olarak adlandırmayın – böyle bir ad programcıya bunun bir List olarak uygulandığını söyler ve olmayabilir. Daha iyi bir isim accounts olurdu.
3. Anlamlı Ayrımlar Yapın. Bazen, dil kısıtlamaları nedeniyle, istediğimiz kelimeyi kullanarak bir şeyi adlandıramayız. Örneğin, bir değişkeni class olarak adlandırmak istersek, bu ayrılmış bir anahtar kelime olduğu için yapamayız. Bu sorunun üstesinden gelmek için, kelimeyi yanlış yazıp onun yerine klass veya clazz olarak adlandırma eğilimindeyiz. Bu kötü bir fikir. Bu durumlarda eşanlamlı veya benzerini kullanmalıyız. Diğer bir yaygın örnek, aynı türde iki değişkene sahip olduğumuz ve bunları eşit olarak adlandırdığımız ve sonuna bir sayı eklediğimiz durumdur: string1 ve string2 . Bunları source ve destination olarak adlandırsak daha iyi olmaz mı? İsimler doğru bir şekilde belirlendikten sonra ne yapacaklarını tahmin etmenin ne kadar kolay olduğuna bir bakın!
4. Telaffuz Edilebilir İsimler Kullanın. Kitapta yer alan örnek çok komik: bir şirketin genymdhms (üretim tarihi, yıl, ay, gün, saat, dakika ve saniye) adında bir değişkeni vardı, bu yüzden çalışanları “gen Why emm dee aich emm ess” diyerek etrafta dolaşıyorlardı. Programcılar, tasarımcılar, analistler… herkes bu aptal ismi kullanıyordu ve “Hey Mike, bir bak! Gen-yah-mudda-hims yarının tarihine ayarlandı!”. Ne?! Elbette, komik ama kötü bir adlandırma seçimi. Neden generationTimestamp gibi daha iyi, saf bir İngilizce isim kullanmadılar? "Hey, Mike, bir bak! Nesil zaman damgası yarının tarihine ayarlandı!”
5. Yöntem Adları Fiiller veya Fiil Cümleleri Olmalıdır. Burada sürpriz yok: WordPress'te bu kuralın birçok örneği var: have_posts , get_the_author veya is_single .
6. Konsept Başına Bir Kelime Seçin. Bazen aynı kavram farklı eşanlamlılar kullanılarak ifade edilebilir: fetch , get veya retrieve alın; delete , remove veya trash . Bu gibi durumlarda, her zaman aynı konsepti kullanmaya çalışmalısınız. Bu şekilde kodunuzun anlaşılması daha kolay olacak ve zihinsel iş yükünüzü azaltacaksınız.
7. ve daha fazlası!

Benim fikrim

Kısacası Temiz Kod, eğlenceli ve eğitici bir kitap. Hemen satın alıp kişisel kitaplığınıza eklemenizi tavsiye ederim. İçerdiği ipuçları ve püf noktaları çok değerlidir. Ve bu kitabı okumadan önce ve okuduktan sonra yazdığınız kodlar arasındaki kalite sıçramasının çok büyük olduğunu söylediğimde bana inanın.

Zaten okudun mu? Ne sandın? Bana başka tavsiyen var mı?

Unsplash aracılığıyla Joel Filipe tarafından Öne Çıkan Resim.