Clean Code -Tips daha iyi bir WordPress Geliştiricisi (II)
Birkaç ay önce, “Pragmatik Programcı: Günlük İşçilerden Ustaya Kadar” hakkındaki görüşümü paylaştım, dediğim gibi iyi öneriler ve en iyi programlama uygulamaları dahil. Kitabı okumadıysanız, devam edin ve hemen yapın – bu çok eğlenceli ve öğreticidir. Ancak, önceki yazımda da, beni bekleyen bir rafta ikinci bir kitabım olduğunu da söyledim: Temiz kod, hatırladınız mı? Bunu okuduğumu söylemekten mutluluk duyuyorum ve “pragmatik programcılardan” daha çok hoşuma gidiyor! Kitaba bakalım ve bence en iyi yanı nedir, ha?
Temiz Kod Kitap Özeti çok ilginç bir önermeye dayanmaktadır: “Kötü kod bile çalışıyor”. Yani, kod temiz ve temiz olmasa bile, kaotik ve anlaşılması zor olsa bile, kötü yazılmışsa … işlevleri üzerinde olumsuz bir etkisi olan bu şeylerin hiçbiri-kod olması gerektiği gibi çalışabilir. Şimdi, benimle ve kitabın yazarı Robert C. “Bob Amca” Martin, bu tür kodlarla uğraşmanın her programcı için büyük bir sorun olacağını kabul edeceksiniz, değil mi? ? Yazılım bileşeni, herhangi bir şirkette çok önemli bir rol oynar. Kaynak kodunuz temiz ve temiz değilse? Bu nedenle bu kitap size temiz bir kod yazmayı ve geliştirilebilecek kodu nasıl algılayacağınızı öğretir.
Bu kitap üç bölüme ayrılmıştır. İlk olarak, bu kaynak kodunu temizleyen ilkeleri, standartları ve uygulamaları açıklar. İkinci bölümde, kötü yazılmış koddan başladığınız ve zarif ve verimli bir çözüme ulaşana kadar yavaş yavaş cilaladığınız birçok vaka çalışması (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ı yaparken toplanan sezgisel tarama ve “kokuların” bir listesidir. Başka bir deyişle, bu, kodu nasıl yazacağını, okuyacağını ve temizleyeceğini açıklayan bir bilgi tabanıdır. Kitabı dikkatlice okursanız ve içinde bulunan tüm dersleri öğrenmeye çalışırsanız, sonunda bundan çıkacaksınız Anlama:
İyi ve kötü kodları nasıl ayırt edersiniz?
İyi bir kod nasıl yazılır ve kötü bir kod nasıl iyi bir koda değiştirilir
İyi bir isim, iyi işlev, iyi nesne ve iyi sınıf nasıl yapılır
Maksimum okunabilirlik için kod nasıl biçimlendirilir
Kod mantığını gizlemeden tam hata işleme nasıl uygulanır
Ünite nasıl test edilir ve testin yönlendirdiği gelişmeyi nasıl uygularsınız
Çok havalı, ha?
Bu kitap aşağıdaki bölümlerde düzenlenmiştir:
Temiz kod. Anlaşılamayan kodlar ve kodlar arasındaki farka giriş. Bence bu bölümü açan resim oldukça komik ve bu kitaptan ne beklendiğini açıkça açıklıyor:
Geçerli kod kalitesinin tek ölçümü: WTF/dakika. Kaynak.
İşlev. Daha iyi bir işlev yazmak için ipuçları: Kısa, atomik, basit, bazı parametreler, yan etkiler … yorumlar. Temel olarak size neden yorum kullanamayacağınızı söyleyen bölüm. Neden? Niye? Kitap okumak! ?
Biçim. Kodları biçimlendirme için diğer ipuçları (boşluklar, girinti vb.). Bu kitabı daha iyi bir WordPress geliştiricisi olmak için okursanız, bu bölümü geçebilirsiniz – WordPress zaten bunu tartışan birkaç harika stil yönergesine sahiptir.
Nesne verileri ve yapısı. Debriyajı azaltmak (hatta ortadan kaldırmak) için veri soyutlamasının bazı ipuçları ve ilkeleri.
İşleme hatası. Kodumuza etkili bir şekilde hataların nasıl ekleneceğine dair bazı yararlı ipuçları olan iyi bir bölüm (aslında favorilerimden biri). Özünde, bu üzücü bir gerçeklik içerir: Hatalar aksesuardır – buna ihtiyacımız var, ancak yazılımımızın ana işleviyle ilgili olmayabilir. Sonuç olarak, koda ekleyerek kodun “kirli” görünmesini sağlıyoruz ve karmaşık olması gerekmiyor. Bu bölüm, nasıl temizleneceğini öğretiyor.
Sınırlama. Programcıların karşılaştığı en zor sorunlardan biri (ve bu esas olarak WordPress’te geçerlidir) kütüphanelere veya dış hizmetlere bağımlılığımızdır – eğer değişirse, her şey işleyişini durdurabilir. Bu bölüm, üçüncü taraf çözümlerine güvenirken uyumluluk problemi yaşayabileceğimiz ve etkiyi nasıl ortadan kaldıracağınızı veya en aza indireceğinizi gösteren çeşitli senaryoları tanımlar.
Ünite testi. Bu bölüm hakkında söyleyebileceğim birkaç tane var – içeriğini önceki yazıda iyice tartıştık.
Sınıf. İlk bölümde, bu kitap bir kodlama yapı taşı içerir: işlev, veri yapısı, değişken vb. Temiz bir kod iyi bir organizasyon gerektirdiğinden, bu kitap da bu konuyu tartışmak için birkaç bölüm sağlar. Bu bölümde, “boyut” ve “sorumluluk” sistemi hakkında bazı temel öneriler sunarak nesne yönelimli programlama ve sınıf kavramlarına odaklanmaktadır. Bu bölüm eskisinden daha soyuttur, çünkü “sistem” kavramını, farklı bileşenler arasındaki etkileşimi, ona eşlik eden zorlukları açıklar … diğerlerinden daha karmaşık olsa bile, orantılıdır (özellikle, daha büyük yazılım bileşenleriyle çalışıyorsanız, Bilirsiniz, WordPress Core).
Dış görünüş. Bu bölümde yazar dört yönerge sunmaktadır. Onları takip edin ve kodunuz daha temiz olacaktır. Temel olarak, aşağıdaki kurallara uyursanız bir tasarımın “basit” olduğu söylenir:
Tüm testleri çalıştırın
Çoğaltma içermiyor
Programcının amacını ortaya çıkardı
Sınıf ve yöntem sayısını en aza indirin
Eşzamanlı. Bölüm, eşzamanlı sistemde ve çözümde bulunan sorunlara ayrılmıştır.
Ardışık iyileştirmeler. Yazarın kötü bir kod sunduğu ve temiz bir kod haline gelene kadar adım adım düzeltildiği bir vaka çalışması.
Junit dahili. Başka bir pratik örnek. Bu özel durumda, yazar Junit’in kaynak koduna girer ve birkaç olası iyileştirme sunar.
Serialdate. Son olarak, başka bir vaka çalışması. Bu durumda, Martin tarafından “iyi kod” olarak tanımlanan kodla başlıyoruz. Ancak bu, bazı iyileştirmeler önermesini engellemedi.
Koku ve sezgisel. Kodunuzdaki geliştirilmesi gereken bileşenleri tanımlamanıza yardımcı olacak sezgisel derleme ve fantastik koku. Sadece bu bölümü okumalısınız – size yakın tutmalı ve referans olarak kullanmalısınız. Bence bu koku ve sezgisel çok değerli! 3 En İyi İpuçları Bu kitap olağanüstü – çok iyi yazılmış ve umarım kod yazarken hepimizin bilip uyguladığımız birçok hile var … ama bence kitabı okumak ve uygulamaya istekli Ders, daha iyi bir programcı olmak için ilk adımdır. !
Şimdi, vaat edildiği gibi, burada bu kitabın en iyi 3 kısmına sahipsiniz:
? Bronz. “Yorumlar kötü kodu değiştirmez”. Martin’in dediği gibi, “Yorum yazmak için daha yaygın motivasyonlardan biri kötü bir koddur”. Bunu düşünün: Sadece yeni bir modül yazdınız ve başarılı oldu, ama temelde bir karmaşa. Öyleyse görüyorsunuz ve kendinize söyle: “Ooh, bunun hakkında yorum yapsam iyi olur!” Değil! Temizlemelisin! Birinin bir kod parçasını anlamak için asla yorum yapmamalıdır – yeterince açık olmalıdır. Bunun nedeni, kodunuzdaki yorumların iyileştirmeden daha fazla sorun yaratmasıdır. Bir yandan, yorumların süresi dolabilir ve kodu eşleştiremez. Ancak sorun olmasa bile, kodu değiştirmek, yorumları yorumlarla “senkronize” olarak güncellemeniz gerektiği anlamına gelir … ve bu ekstra iş! Öte yandan, yorumlar bir rahatsızlık olabilir.
Örneğin, bu küçük parçayı düşünün: // Çalışanın tam avantaj elde etmek için gereksinimleri karşılayıp karşılamadığını kontrol edin ((çalışan.flags & hourly_flag) && (çalışan.age> 65)) aşağıdakiler daha iyi değil mi? Eğer (çalışan.eligableforfullbefits ()), koddaki niyetlerinizin çoğunu açıklamak için yalnızca birkaç saniyeye ihtiyaç duyarsa. Birçok durumda, bu tamamen adınız yorumunuzla aynı şeyi söyleyen bir işlev yapmakla ilgilidir. Ve kodunuzu bu şekilde daha temiz ve daha iyi hale getiriyorsunuz. Ayarlar. Bazen kodunuz hakkında yorum yapmanız gerekir. Örneğin, bir ateş çıkarırsanız, kullanıcınızın etkili bir şekilde kullanabilmesi için iyi belgelenmesi gerektiği açıktır – herhangi bir yerde, dahili olarak farkında olmayabilirler. Bununla birlikte, işlevlerinizin ve parametrelerinizin adı yeterince net ve mümkün olduğunca net olmalıdır.
? Gümüş. “İşlevin yan etkileri olmamalıdır”. “Yan etkiler yalan söylüyor. İşleviniz bir şey yapmayı vaat ediyor, aynı zamanda diğer gizli şeyler de yapmayı vaat ediyor. Bu, WordPress çekirdeğinde çok şey gördüğümüz bir şey – birçok değişken ve küresel nesne var. Bu yüzden bu ipucunun tüm WordPress geliştiricileri için çok önemli olduğunu düşünüyorum – biz mümkünse yan etkilerden kaçınmalıdır.
Sadece beklenmedik yan etkilere neden olabilecek küresel değişkenler değil – bir işlevdeki çıktı parametreleri de olabilir! Bu olduğunda, bir veya daha fazla parametrenin değeri, çağrı işlevlerini çağırdıktan sonra değişir, bu da açıkça beklenmedik bir davranıştır. Genel olarak, hepimiz fonksiyon parametrelerinin yalnızca giriş değişkenleri olduğunu varsayıyoruz. Bir işlevin parametresi olarak kullanıldığında belirli değişkenlerin değişeceğini öğrenmenin tek yolu belgeleri yoluyla ve yorumların gerekli olmaması gerektiğini gördük, değil mi? Bu sorunun net bir şekilde resmini almak için aşağıdaki örneğe bakın: Genel Sınıf Kullanıcı Mahkemeleri {
…
public boolean checkpassword (String kullanıcı adı, dize parolası) {
Kullanıcı kullanıcı = useGateway.findByName (kullanıcı adı);
if (user! = user.null) {
if (user.haspassword (şifre)) {
Oturum.initialize ();
sağa dön;
}
}
yanlış geri;
}
…
} Yan etkileri görebiliyor musunuz? Uygun! Yan etkiler oturumlara çağrılar. Kullanıcı görünen işlevi arar, şifreyi kontrol etmelidir, böylece kullanıcı işlevin söylediklerini yapmasını bekler. Öyleyse neden oturumu başlattı? ? Kimse bilmiyor! İstediğimiz davranış ise, farklı bir isim daha iyi hale getirecektir: CheckPasswordandinitializasyon
? Altın. “İsimler anlamlı”. İsim yazılımdaki her şeydir. Bununla birlikte, programlama sistemi resmi dilde tanımlamaktan başka bir şey değildir, bu da kavramların ve isimlerin çok önemli bir rol oynadığı anlamına gelir. Bir an için düşün-isim her yerde! Değişkenler, bağımsız değişkenler, işlevler, sınıflar, dosyalar, dizinler … Hepsi adlandırılmıştır! Peki, nasıl bir isim vereceğinize karar vermek için ne kadar zaman harcıyorsunuz? Aklınızda görünen adını kullanıyor musunuz? Bence bu kitabın ikinci bölümü olağanüstü – tüm programcılar tarafından uygulanması gerektiğini düşündüğüm yararlı ipuçlarıyla dolu. Aşağıdakiler bu ipuçlarının bazı örnekleri şunlardır: Niyeti ortaya çıkaran bir isim kullanın. Kaç kez D adlı bir değişken ve ardından ne olduğunu açıklayan bir yorum buluyorsunuz? Bazen programcı sadece tembel … ve böyle olmamalıyız! EleedTimeIndays, DaysSinTecreation veya FilegeIndays gibi farklı isimler kullanın. Gerçek isim ne olursa olsun, açık ve anlamlı olduğu sürece.
Dezenformasyondan kaçının. İsim gerçek bilgi sağlamalıdır – yalan söyleyemezler. Örneğin, bir hesap kümemiz varsa, değişken hesap listenizi adlandırmayın – bunun gibi ad, programcıya bir liste olarak uygulandığını söyler ve belki de değildir. Daha iyi bir isim hesaplardır.
Anlamlı bir fark yaratın. Bazen, dil kısıtlamaları nedeniyle, istediğimiz kelimeyi kullanarak bir şeyi adlandıramayız. Örneğin, değişken bir isim vermek istiyorsak, sınıf, yapamayız, çünkü ayrılmış bir anahtar kelimedir. Bu sorunun üstesinden gelmek için yanlış yazım kelimeleri yapma ve buna sınıflar veya Clazz diyoruz. Bu kötü bir fikir. Bu durumda, eşanlamlılar veya benzeri kullanmalıyız. Başka bir yaygın örnek, aynı tipte iki değişkenimiz olduğu durumdur ve bunları sadece aynı adlandırırız ve sonunda sayılar ekleriz: String1 ve String2. Kaynak ve hedef dediğimiz daha iyi değil mi? İsimler doğru ayarlandıktan sonra ne yapacağını tahmin etmenin ne kadar kolay olduğuna bakın! Söz edilebilecek isimleri kullanın. Bu kitapta yer alan örnek komik: Bir şirketin genymdhms (üretim tarihi, yıl, ay, gün, saat, dakika ve ikincisi) adlı bir değişkeni var, böylece çalışanları “Gen neden emm dee aich ess “. Programcılar, tasarımcılar, analistler … Herkes aptalca adı kullanıyor ve insanlar “Hey, Mike, See! Gen-Yah-Mudda-Hims yarının tarihi için düzenlenmiştir! ” Ne?! Tabii ki, komik, ama kötü bir adlandırma seçimi. Neden Generatimestamp gibi daha iyi bir saf İngilizce adı kullanmıyorlar? “Hey, Mike, bak! Üretim süresinin damgası yarına göre düzenlendi! ”
Yöntemin adı fiil veya fiil cümlesi olmalıdır. Şaşırtıcı olmayan bir şekilde burada: WordPress’te bu kuralın birçok örneği var: Have_posts, get_the_author veya is_single.
Konsept başına bir kelime seçin.Bazen, aynı kavram farklı eşanlamlılar kullanılarak ifade edilebilir: getir, al veya al;Sil, kaldır veya çöp.Bu durumda, her zaman aynı kavramı kullanmaya çalışmalısınız.Bu şekilde, kodunuzun anlaşılması daha kolay olacak ve zihinsel iş yükünüzü azaltacaksınız. Ve daha fazlası!
Kısacası, temiz kod eğlenceli ve eğiten bir kitap.Şimdi satın almanızı ve özel kitaplığınıza eklemenizi öneririm.İçerdiği ipuçları ve püf noktaları çok değerlidir.Ve bu kitabı okumadan önce ve sonra yazdığınız kod arasındaki kalite sıçramasının çok büyük olduğunu söylediğimde inan bana.Onu okudun mu?Ne hakkında düşünüyorsun?Benim için başka önerileriniz var mı?Joel Filipe tarafından Üstün Görüntü Unplash.
