Pragmatik Programcı–Daha İyi Bir WordPress Geliştiricisi Olmak İçin İpuçları

Tamam, itiraf edeceğim: Netflix'e abone olduğumdan beri eskisinden çok daha az okuyorum. Artık sevmediğimden değil, Netflix'in harika programlarına bağımlı olduğumdan mı? Sanırım bu şekilde zihnini boşaltmak daha kolay… Ama beni yanlış anlama—hala okumaktan zevk alıyorum ve her zaman günümde birkaç sayfa okumak için boş dakikalar bulmaya çalışıyorum. Bazen eğlenmek için, bazen de yeni şeyler öğrenmek için okurum.

Geçenlerde Andrew Hunt ve David Thomas tarafından “Pragmatik Programcı: kalfadan ustaya” adlı bir kitap okudum. Programlama becerilerimi geliştirmek için bana bazı ipuçları, püf noktaları ve iyi uygulamalar öğretebilecek bir kitap arıyordum, bu yüzden onu gördüğümde ve Amazon'daki incelemeleri okuduğumda rafımda bulundurmanın iyi olacağını düşündüm. (Gelecekte gözden geçireceğim Temiz Kod ile birlikte… okuduktan sonra tabii ki?). Kitabı oldukça beğendim ve bu yüzden tartıştığı konuları, nasıl düzenlendiğini, en çok sevdiğim birkaç ipucu örneğini ve böyle bir kitabın WordPress'inizi geliştirmenize nasıl yardımcı olabileceğini sizinle paylaşmaya karar verdim. Beceriler.

Kitaba Genel Bakış

Sadece 260 sayfa ile The Pragmatic Programmer kolayca okunabilir. Ancak kısalığına aldanmayın: kitap karmaşık kavramları sade bir İngilizceyle açıklıyor, ancak bu kavramların gerçekten içine batmasını istiyorsanız, onu dikkatlice okumanız ve sindirmeniz gerekir. Hepsini bir kerede okumayın – gözden geçirin ve belirli bir sorunuz olduğunda ona geri dönün. Bunu bir “referans kitabı” olarak düşünün: ezberlemenize gerek yok – kapsadığı konuları hatırlamanız ve ihtiyacınız olduğunda ihtiyacınız olanı okumanız gerekiyor.

Bu kitap, yazarların karşılaşabileceğimiz yaygın sorunları tanımladığı ve size bunların nasıl üstesinden gelineceğini (veya olayları nasıl önleyeceğinizi) gösterdiği harika bir "örnekler" koleksiyonudur. Örneğin, 2. bölümde ( Pragmatik Bir Yaklaşım ), çoğaltmanın kötülükleri tartışılmaktadır. "Kodu çoğaltmamanız gerektiğini" zaten bildiğinize eminim, değil mi? Burada yeni bir şey yok. Ancak kitap bir adım daha ileri gidiyor ve çoğaltmanın neden oluştuğunu, hangi tür çoğaltmaların var olduğunu, bunları tespit edip önlemek için neler yapabileceğinizi açıklıyor… Yani, önceden biliyor olabileceğiniz ama belki de bilmediğiniz şeylerin ayrıntılı bir görünümünü sunuyor. tamamen farkında.

Tüm ipuçları, püf noktaları ve yorumlar aşağıdaki bölümlerde düzenlenmiştir:

1. Pragmatik Bir Felsefe. Yazarların pragmatik bir programcının sahip olması gereken özellikleri tanımladığı giriş bölümü.
2. Pragmatik Bir Yaklaşım. Becerilerinizi geliştirmenize yardımcı olacak ipuçları ve püf noktaları. Bu bölüm, kod çoğaltma, prototipler, tahminler vb. gibi konuları kapsar.
3. Temel Araç. Burada, araç kutunuzda ihtiyaç duyduğunuz araçların ayrıntılı olmayan bir listesini ve bunların arkasındaki mantığı bulacaksınız. Düz metin kodlayıcılar, CVS veya kod oluşturma araçları bu tür araçlara örnek olarak verilebilir.
4. Pragmatik Paranoya. Bence bu, kitabın en ilginç bölümlerinden biri. Sert bir gerçeği kapsıyor – kodunuz kusurlu olacak ve onunla yaşamayı öğrenmeniz gerekiyor. Burada, bu kusurların nasıl azaltılacağına (ancak kaldırılmayacağına) ilişkin örnekler bulacaksınız.
5. Bükün veya Kırın. Beğenseniz de beğenmeseniz de kod değişecektir. Bu nedenle, korunabilecek bir kod yazmanız çok önemlidir. Yazarların 5. bölümde tartıştıkları şey budur.
6. Siz Kodlarken. Kod yazarken akılda tutulması gereken bazı ipuçları. Bunun da harika bir bölüm olduğunu düşünüyorum, çünkü teoriyi (bir algoritmanın maliyetinin nasıl tahmin edileceğini) pratikle (kod nasıl yeniden düzenleneceğini) birleştiriyor.
7. Projeden Önce. Kodlamayı seven ama müşterilerle konuşmaktan nefret eden programcılardan biriyseniz… bu sizin bölümünüz. Burada projenin gereksinimlerini nasıl elde edeceğinizi, bu süreçte ortaya çıkabilecek sorunları ve yine bunları nasıl aşacağınızı öğreneceksiniz.
8. Pragmatik Projeler. Kitabın son bölümü aslında okuduğunuz her şeyi özetliyor. Ekip, otomasyonlar, testler… harika bir programcı/ekip oluşturan en önemli parçalar bu son bölümde yeniden ziyaret ediliyor.

Son olarak, kitabın ayrıca ilgili cevaplarıyla birlikte birkaç alıştırma (yaklaşık 40) içerdiğine dikkat edin. Öğrenmek için bunların hiçbirini yapmanıza gerek yok, ama bence yine de onlara sahip olmak iyi – tüm konuları doğru anlayıp anlamadığınızı kontrol etmenize yardımcı olacaklar ve size yeni- edinilmiş beceriler. Ayrıca açıklamalar o kadar iyi yazılmış ki onları da okumaya değer!

En İyi 3 İpucu

Kitapta projelerinizin başarılı olmasına yardımcı olacak pek çok ipucu ve püf noktası var. Hepsi mükemmel, ama bence dürüst bir incelemenin ilk üç listeye ihtiyacı var, bu yüzden… Kitaptaki en iyi 3 ipucu burada! (bana göre tabi)

? Bronz. "Çoğalmanın Kötülükleri".

Bundan birkaç satır yukarıda bahsetmiştim, bu yüzden bunun en sevdiğim ipuçlarından biri olduğunu tahmin edebilirdiniz. Kitap, çoğaltmanın neden olduğu sorunları ayrıntılı bir şekilde açıklıyor. Ancak bu konuyla ilgili en çok hoşuma giden şey, yinelemenin neden gerçekleştiğine ilişkin açıklama.

Hunt ve Thomas'a göre, gördüğümüz çoğaltmaların çoğu aşağıdaki kategorilerden birine giriyor:

• Zorunlu çoğaltma. Geliştiriciler başka seçeneklerinin olmadığını düşünüyorlar—ortam çoğaltma gerektiriyor gibi görünüyor. Örneğin, kodu yorumlamamız gerekiyor, değil mi? Bu, kod ve yorumlarda aynı bilgiye sahip olduğumuz anlamına gelir. Veya bir veritabanı girdisiyle eşleşen bir sınıfa ihtiyacımız var; bu, belirli bir sınıfın ilişkili alanlarının veritabanı şemasında ve sınıfın kendisinde çoğaltıldığı anlamına gelir.
• Yanlışlıkla çoğaltma. Geliştiriciler, çoğaltma bilgileri olduklarının farkında değiller. Yazarların verdiği örnek harika: Line adında şu niteliklere sahip bir sınıfınız var: start , end ve length . Harika, değil mi? Eh, length bir tekrardır, çünkü diğer iki özellik kullanılarak hesaplanabilir: start ve end .
• Sabırsız çoğaltma. Geliştiriciler daha kolay göründüğü için tembelleşir ve çoğalır. “Bu işlevin küçük bir değişiklikle yeni bir sürümüne mi ihtiyacınız var? Pekala, kopyalayın ve küçük değişikliği uygulayın!”
• Geliştiriciler arası çoğaltma. Bir ekipteki (veya farklı ekiplerdeki) birden fazla kişi bir bilgiyi kopyalar. Tüm ekip üyeleriniz ve ekipleriniz arasında kaynak paylaşımını teşvik etmelisiniz, aksi takdirde yinelenen şeylerle karşılaşabilirsiniz.

? Gümüş rengi. “Bu Sadece Bir Görünüm”.

Başlarda bize bir programı tek bir büyük ayna olarak yazmamamız, “böl ve fethet” ve onu her birinin kendi sorumluluklarına sahip olacak “modüllere” ayırmamız gerektiği öğretildi. Tüm modüllere sahip olduğumuzda, bunların birbirleriyle konuşmalarını sağlamak ve tüm kurulumu düzenlemekle ilgili. Söylemesi yapmaktan kolay…

5. bölümde bu konuyu kapsayan bir bölüm bulacaksınız. Özellikle, yazarlar “olaylar” kavramından bahseder ve Model-View-Controller modelini tanıtırlar. Bu paradigmalar, özellikle Backbone, React veya Angular gibi çerçevelerin yükselişinden bu yana günümüzde yaygın olarak kullanılmaktadır. Bu yüzden bu konunun gümüş madalyamı hak ettiğini düşündüm.

Olaya dayalı bir mimari, yayın ve abonelik kavramlarını kullanır. Esasen bu, bir bileşenin diğerine abone olmasına ve ne zaman değiştiğini algılamasına izin verir, çünkü ikincisi ilgili bir şey olduğunda bir olay yayınlayacaktır. Bu mimari, bileşenleri ayırmayı çok kolaylaştırır; yayıncı, dinleyicileri konusunda tamamen agnostiktir. Bu temel ilkeler, bir görünümün bir modeldeki değişiklikleri dinlediği ve yeni durumu ekranda yeniden oluşturarak bunlara tepki verdiği bir Model-View-Controller uygulamasının oluşturulmasını kolaylaştırır.

? Altın. “Test Edilmesi Kolay Kod” ve “Acımasız Test”.

Ve altın kupa… ? test yapmak! Kodunuzu test etmenin her zaman kolay olmadığını biliyorum, ancak bunun hakkında zaten konuştuk ve bunun çok önemli olduğunu biliyorsunuz . Yazarların 6. bölümde yazdığı gibi, yazılım geliştirmede test etme çok önemli bir rol oynar.

Öncelikle, kodunuzun test edilebildiğinden emin olmanız gerekir. Bunun için, net sorumlulukları olan ve iyi tanımlanmış bir girdi ve çıktı seti olan küçük kod birimleri yazmalısınız. Ardından, belirli bir girdi verildiğinde doğru çıktıyı aldığınızı doğrulayan basit testler yazabileceksiniz.

Ayrıca bir test kültürünü teşvik etmeniz gerekir. Yazdığınız tüm yazılımlar sonunda siz ve ekibiniz tarafından değilse de kullanıcılarınız tarafından test edilecektir. Bu yüzden ekibinizdeki herkesin gemide olduğundan emin olun ve onları en kısa sürede kodlarını test etmeye davet edin. Bölüm 8 bunu oldukça iyi özetliyor:

Çoğu geliştirici testten nefret eder. (…) Pragmatik Programcılar farklıdır. Hatalarımızı şimdi bulmaya çalışıyoruz, bu yüzden başkalarının hatalarımızı daha sonra bulması utancına katlanmak zorunda değiliz.

Henüz ikna olmadınız mı? Kitaptaki 62. ipucu her şeyi söylüyor:

Erken Test Edin. Sıklıkla Test Edin. Otomatik Olarak Test Edin.

Pragmatik WordPress

Pragmatik Programcı , WordPress odaklı bir kitap değildir , ancak içeriği yine de geliştirmelerimize kolayca uygulanabilir. Örnek olarak en sevdiğim üç ipucunu al; kesinlikle daha iyi eklentiler ve/veya temalar yazmana yardım edecekler. Bir "yolcu" programcısı kod yazmada en iyisi olabilir. Bir "usta" programcı, üzerinde çalıştığı projeleri derinlemesine anlar, tekrarları önler, son kullanıcıları anlar ve yardımcı olur, sorunların olmasını önler, harika belgeler yazar, kodlarını test eder…

Son tavsiyem: Bu kitabı kendi rafınıza ekleyin. Eğer bir "felsefi sorunuz" varsa, ihtiyacınız olan cevaba sahip olabilir mi?

"Pragmatik Programcı: kalfadan ustaya" kapağından Öne Çıkan Resim.