En Kötü Beş WordPress Geliştirme Hatam

Veya Daha Önce Depoladığım Tüm Sunuculara: Yaptığım En Kötü Beş WordPress Hatasına Dehşet İçinde Bir Bakış

Geliştiriciler olarak, kariyerimizin farklı noktalarında farklı türde hatalar yapıyoruz. Özellikle WordPress geliştirmede, WordPress kod tabanına olan aşinalığımız arttıkça farklı türde hatalar yapıyoruz.

Birkaç yıl önce Matt Mullenweg'in çoğu insanın hatalarını tekrarladığını, daha akıllı insanların hatalarından ders aldığını ve aramızdaki en zeki insanların başkalarının hatalarından ders aldığını söyleyen bir şey söylediğini duydum. Bunu daha çok sevdim ve bir sonuç ekleyeceğim: Herkes hata yapar, alçakgönüllü insanlar bu hataları özel olarak paylaşır ve aramızdaki en cesurlar onları yazıp bir blogda yayınlar!

Ama daha sonra düşünmek için zaman var. Bu makaleyi okuyorsunuz çünkü bir tren kazası duymak istiyorsunuz ve ben mühendisim. Daha fazla giriş yapmadan, bir WordPress geliştiricisi olarak yaptığım en utanç verici beş hataya dehşet içinde bir göz atmak için bana katılın.

WordPress Core'un Saldırıya Uğramış Bir Sürümünü Güncellediğim Zaman

Son derece belirsiz CraigsList kodlama işlerinden gerçek bir canlı ajansta çalışmaya yeni mezun oluyordum. ben gelmiştim! Kanepemden başka bir yerde, pijamalarımdan başka bir yerde çalışıyor olacağım için gergindim. Ancak o zaman bile, WordPress'i genellikle WordPress Doing It Wrong'dan tanıyordum ve WordPress'in en iyi uygulamalarıyla övünmeyi asla “çekirdeği kırmak” gibi hoş bir şekilde kendi kendini yüceltme buldum.

Bu ajanstaki ilk WordPress geliştirme görevim, o zamanki becerilerim için oldukça karmaşık olan, durdurulan bir projeyi sürdürmekti. WordPress kayıt ve giriş akışında birçok özelleştirme içeriyordu. Önceki geliştiricinin, yalnızca çekirdek wp-login dosyalarını düzenleyerek önemli ilerleme kaydettiği biliniyordu.

Bunun sürdürülemez olduğunu biliyordum, bu yüzden ilk işim bir yedekleme/geri yükleme eklentisi kurmak ve WordPress çekirdeğini yeni indirilmiş bir sürümle değiştirmekti. Projede henüz çok etkileyici hiçbir şey yapılmadığından ve filtreler aracılığıyla mevcut özellik setini taklit edebileceğimden emindim.

Yeni işverenim çıldırdığı için, o noktada sahip olabileceğim veya olmayabileceğim herhangi bir kodlama yeteneği hızla alakasız hale geldi. “Çekirdek hacklemenin” önemini anlamadı ve ben bunu sindirilebilir bir şekilde açıklayacak kadar olgun değildim. Alnını geçici olarak soğutan tek şey, yüklediğim yedekleme/geri yükleme eklentisi aracılığıyla geri dönebileceğime dair güvence vermemdi.

Bunun nereye gittiğini tahmin edebilir misin?

Bu eklenti, kaderin sahip olacağı gibi, yalnızca wp-content klasörünü yedekledi. Bu çekirdek dosyalarda WordPress hack'leri ne olursa olsun sonsuza kadar gitmişti. Ona gönderdiğim e-postayı hala hatırlıyorum (bu noktada beni uzun zamandır ev ofisime geri göndermişti):

Arkadaşlar yedekleme yapamıyorum.

Filtreler ve eylemler aracılığıyla istediği özellik setini tamamlamaya gerçekten hazırdım ama o bunu duymadı. Beni hemen kovdu, dava etmekle tehdit etti ve iki haftalık çok sıkı çalışmam için bana hiç ödeme yapmadı. çok aşağılandım.

Bu deneyimden öğrenebileceğim birçok (artık bariz) şey var. Bir yedeğin prova edilip onaylanıncaya kadar yedek olmadığı genel dersi iyi bir derstir. Ancak beni daha çok etkileyen, WordPress'te, özellikle de WordPress çekirdeğinde tam olarak nasıl yedekleme yapılacağına dair özel bir ders oldu.

Sağlam bir yedekleme/geri yükleme sistemi ile WP-Engine gibi yönetilen ortamlara gerçekten değer vermeyi öğrendim. Pek çok butik host, yedekleme yapmak için çeşitli komut satırı araçlarına ve diğer geliştirici odaklı özelliklere sahiptir, ancak WP-Engine's benim favorim. Çok büyük bir ağınız olmadığı sürece oldukça hızlıdır. Kullanıcı arayüzü basittir. Bir kullanıcı arayüzü var, nokta: WordPress kullanmayı bilen herkes bununla çalışabilir. Yani, muhtemelen çok daha hızlı olan bazı CLI yaklaşımlarının veya Plesk'te gömülü bazı belirsiz şeylerin aksine, müşterilerim bunu kullanabilir, anlayabilir, izleyebilir ve kullandığımı doğrulayabilir. Büyük bir hayranım.

Tüm Platformumuzu Kardeş Dizinine Sürüklediğim Zaman

Profesyonel iş yerinde hâlâ oldukça yeniydim ve her zaman bir Windows çalışanıydım. Ancak yeni işim bir Mac mağazasındaydı ve onunla ilgili her şeyi çok çabuk sevmeyi öğrendim. Neredeyse her şey. "Sihirli fare" ile çok fazla sorun yaşıyor gibiydim. Bluetooth bağlantımı kaybetme eğilimim vardı, bu da yeniden bağlandığında kazara ve genellikle korkutucu sürükle ve bırak eylemlerine yol açtı. Bunun da ötesinde, yeni bir ince motor beceri konusunda beceriksizdim.

Bu günlerde, WordPress geliştirme akışımız hala FTP aracılığıyla üretime dağıtmayı içeriyordu. Cyberduck masaüstümde üretime açıkken, tüm iş günlerimi kod yazarak, sohbet ederek, e-postaları yanıtlayarak, genellikle yeni sihirli farem aracılığıyla sağa sola sallayarak geçirmek benim için alışılmadık bir durum değildi. Tanrım, kulağa kötü mü geliyor! Ama böyleydi.

Bir gün tüm platformumuz gitti. Sistem yöneticimiz, bunun bir tür DDoS veya genel olarak onun seviyesinde bir şey olduğunu varsaymakta gecikmedi. Biz geliştiricilere gelince, onun içgüdülerine güvendik ve bunu yakında çözeceğini varsaydık.

Saatler geçti. Gün geldi ve gitti. Hala aşağıda.

Ertesi sabah işler düzeldi ve CTO'muz nazikçe konferans odasında ona katılmamı istedi. Sistem yöneticimiz sorunu tespit etmişti. FTP günlüklerini çekti ve kullanıcımın tüm platformumuzu bir kardeş dizine taşıdığını gözlemledi. Yani, wp-content , wp-includes altında iç içe geçmiştir.

Üzüldüm ama CTO'muz bu konuda harikaydı. Genelde yardımsever ve sorumlu bir çalışan olduğumu görebiliyordu, ancak beni pişmanlık duymanın ötesine geçmeye ve bunun bir daha olmasını engellemenin yollarını bulmaya zorladı. Gerçekten faydalı iki şey buldum.

İlki, Cyberduck'un uzaktan-uzak dosya hareketlerine hiç izin vermesini önlemek için bir CLI komutu bulmaktı. Bu iyi bir güvenlik önlemiydi ve hemen şirket politikası olarak benimsedik.

İkincisi, Git aracılığıyla dağıtım yapmaya büyük ilgi duymamdı. Sonunda, Bitbucket sürümümüzü normal wp-admin güncelleme akışına dönüştürmek için bir WordPress eklentisi yazmaya başladım. O zamandan beri, üretime FTP erişimine bile sahip olmak için neredeyse hiçbir nedenimiz olmadı. Bu eklenti en sevdiğim profesyonel başarılarımdan biridir. Elbette, Git'e yakınlık bugün geliştiriciler için bir ön koşuldur.

add_filter() ile Tüm Ön Uç İçeriğini Kaldırdığım Zaman

Bu noktada WordPress uygulamalarımda gerçekten oldukça akıllı olduğumu düşündüm. Talep, belirli bir kategorideki gönderilere bir “rozet” eklemekti. Bazı nedenlerden dolayı, sadece noobların böyle bir şey için bir şablon dosyasına başka bir koşullu ekleyeceğini düşündüm, bu yüzden büyük gururla aşağıdaki filtreyi uyguladım:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Bunda yanlış bir şey görüyor musun? Gerekli gönderilerin rozetlerini uyguladığını doğrulamak için sahnelemede hızlı bir şekilde test ettim. Sonra onu dağıttım ve o gün için işten ayrıldım. Tahmin edebileceğiniz gibi, evren patladı.

Sonuç olarak, rozetsiz gönderilerin ön uçta hiçbir içerik olmadan görüntülenmesi oldu! Nedenini görebiliyor musun? Sorun, koruma durumumda $content döndürmek yerine false döndürüyor olmamdı. Ama gerçekten burada birçok hata katmanı var.

Neden yalnızca gönderilerin rozet aldığını test etmekten memnundum? Neden diğer gönderilerin zarar görmediğini de test etmedim? Neden günün bu kadar geç saatlerinde üretime geçiyordum? Neden kalite kontrolümüz tamamen benim biraz gezinmemden ve sayfayı yenilememden ibaretti?

Tüm bu soruların cevabı olgunluk olarak özetlenebilir. Görsel regresyon testi ve birim testleri gibi şeylere yatırım yapmaya geçmeden önce bu tür hataları yapmaktan bıkmamız biraz zaman alıyor. Bu özel hata, yüzlerce hata arasında çöp oldu ve sonunda devenin sırtını kırdı ve beni phpUnit ve xDebug'a çok yatırım yapmaya yönlendirdi. Buna karşılık, bu araçlar bana test edilebilir kod yazmayı öğretti, bu da muhtemelen testlerin kendisinden daha fazla hatayı önledi.

Sonsuz Döngünün İçinde Sıfıra Böldüğüm Zaman

Müşterinin isteği, WordPress blog gönderisini, tarihin "10 Kasım 2011" yerine "XYZ önce" yazacağı şekilde yeniden biçimlendirmekti. Bunu nasıl başaracağımdan tam olarak emin değildim, ancak popülaritesi giderek artan bir tarih biçimi olduğunun farkındaydım ve gerçekten de Dr. Google bana çok hızlı bir şekilde bir pasaj sağladı. Yerelimde çalıştı! Çok fazla matematik vardı, özellikle çok fazla bölme . Neden çalıştığından tam olarak emin değildim - bir sürü iç içe döngü, kalan, yuvarlama ve benzeri vardı. Ancak Google'daydı ve işe yarıyor gibiydi ve onu üretime dağıtacak kadar mutluydum.

Yaklaşık 30 dakika sonra sistem yöneticimizden düşmanca bir Skype aldım. Üretim düştü. Suda ölü. Son zamanlarda sıfıra bölüp bölmediğimi sordu ve neyden bahsettiği hakkında hiçbir fikrim yoktu. İşte olanlar.

İster inanın ister inanmayın, yeterince büyük bir örneklem büyüklüğü göz önüne alındığında, bulduğum okunamayan "yerelimde çalıştı" snippet'i bazı anormal davranışlarda bulunabiliyordu. Bazı talihsiz gün, saat ve dakika kombinasyonlarıyla sağlanan Rube Goldberg döngüleri bazen bir sayıyı sıfıra bölmeye çalışırdı. Lise matematiğinden hatırlayın:

Sıradan aritmetikte, ifadenin bir anlamı yoktur, çünkü 0 ile çarpıldığında (≠ 0 varsayarak) a veren bir sayı yoktur ve dolayısıyla sıfıra bölme tanımsızdır. - Vikipedi

Peki bu bilgisayarlar için ne anlama geliyor? Genellikle günlüklerde yalnızca bir hata mesajı, ancak benim durumumda daha kötüydü: Matematik hatası döngü mantığıma müdahale ediyor ve iç içe döngülerimin hiç tamamlanmadan çalışmasına neden oluyordu - beyaz bir ölüm ekranına yol açan sonsuz bir döngü. Ve daha da kötüye gidiyor! Döngünün her yinelemesi sıfıra bölmek için bir hata yazdığından, hata günlüğü harika oranlara ulaştı ve dosya sistemimizi engellemeye başladı. Bu, saçma bir şekilde kendi kendine yapılmış olsa da, bir DDoS saldırısının etkisine sahipti.

Bu hatanın kötü yanı, yüksek trafikli bir siteyi kaldırmasıydı. Bu hatanın iyi yanı, işe yaklaşımımı önemli ölçüde değiştirmiş olması. Her şeyden çok, anlamadan uygulamaya istekli olmamdan utandım. Her satırı anlamak için mümkün olan her türlü çabayı göstermeden, hatta gerekirse snippet'in yazarını takip etmeden bir daha asla bir snippet'e yapıştırmamaya yemin ettim.

Bunun da ötesinde, acemi geliştiriciler için çok okunabilir olmayan kodları bir daha asla göndermemeye yemin ettim. WordPress kodlama standartlarına, metin düzenleyici uzantılarına, satır içi yorum ve belge bloklarına ve hatta sekmelere karşı boşluklara, o klasik geçiş törenine kafayı taktım! Özetle, kodumu yazmanın ne kadar kolay olduğundan çok, okumanın ne kadar kolay olduğuyla ilgilenmeye karar verdim. Anlamadan yapıştırmaya karşı olan bu isyan, sonraki on yıl boyunca benim için çeşitli yazma ve konuşma fırsatlarını körükleyen bir konu olan üçüncü taraf bağımlılıklarını yönetme konusunda derin bir profesyonel ilgi duymamı sağladı.

Oh, ve bu hatayla ilgili gerçekten komik olan şey? WordPress çekirdeğinin bunun için tek satırlık bir çözümü vardır.

Herkes Bıkana Kadar Bir Projenin Kontrolden Çıkmasına İzin Verdiğim Zaman

Gerçekten büyüleyici bir projeye imza atmıştım. Teknik lider ve WordPress geliştirme mühendisi olacaktım ve bana rapor veren bir Amazon AWS Lambda geliştiricisi ve derin bir JavaScript uzmanı olacaktı. Bu, ilk defa birden fazla kişinin bana rapor vermesiydi ve açık arayla üzerinde çalıştığım en karmaşık projeydi. Bundan bir WordPress projesi olarak bahsetmek bile konuyu çok hafife almaktı, ancak WordPress her şeyi bir arada tutan yapıştırıcıydı, bu yüzden teknoloji lideri olarak hareket etmem mantıklıydı.

Birincil rolüm tipik olarak kesinlikle bir teknisyen olmak olduğundan ve ayrıca minimalizme yakınlığım olduğundan, Jira veya Basecamp gibi bir şey veya görev yönetimi için herhangi bir gerçek platform uygulamak hiç aklıma gelmedi. Projenin ilk tekrarı için işler oldukça iyi gitti. Kendi bireysel bileşenlerimiz üzerinde çalışabildik, ürün yol haritamız olarak müşteri spesifikasyon belgesine başvurabildik ve bir şeyleri bir araya getirmemiz gerektiğinde Slack aracılığıyla birbirimize ping atabildik.

Sorun, müşteriye ilerlemeyi göstermeye ve onun geri bildirimini uygulamaya başladığımızda başladı. Üç kişilik bir ekip olarak başlayan şey, anında yeni bir büyüklük sırasına taşındığını hissetti: Hangi geri bildirimden kimin sorumlu olduğu, bu geri bildirimi uygulamanın durumunun ne olduğu veya gerçekten kimin kiminle konuştuğu belirsizdi. . Gmail'in ileti dizisi başına 100 yanıt sınırını birkaç kez aştık!

İşler rahatsız etmeye başladı. Müşterinin proje yönünün kontrolünü kaybettiğini hissettiğini ve aynı derecede önemli olarak, proje durumunun görünürlüğünü kaybettiğini hissettiğini düşünüyorum. Amazon geliştiricim bir gün "Trello'yu kullanmamız gerekip gerekmediğini merak ediyorum" dedi.

ha , diye düşündüm. Üç kişilik bir ekibin böyle bir platforma ihtiyacı var mı? Yine, her zamanki eğilimim daha az araç, daha az ek yük ve daha az karmaşıklık tercih etmektir. Ama proje zaten hepimizi pisliğe sürüklüyordu, o halde denemenin ne zararı vardı?

Tüm e-postalarımızı, tüm teknik belgelerimizi, tüm farklı yorum konularımızı taradım ve hepsini Trello panolarında haritalandırdım. Çok daha az zihinsel yük ile iletişim kurabildiğimiz için, proje dijital mezarından hemen dirildi. E-posta gelen kutumda veya çoğunlukla kullanılmayan bir spesifikasyon belgesinde metin aramak yerine güzel panolarımız, listelerimiz ve kartlarımız vardı. Herhangi bir özelliğin durumunu görmek, geri bildirimi dahil etmek ve yeni görevleri yerine getirmek kolaydı. Sanki yavaş yavaş kör olmuştuk, o kadar yavaş ki fark etmedik ve sonra aniden tekrar görebildik .

Elbette, kod kendi kendine yazılmadı, yine de çok zorlu bir projeydi ve yine de teknik becerimizin her zerresini kullanmak zorundaydık. Ama mesele şu: Sonunda projeyi anlamak için bir altyapımız olduğu için, artık teknik becerimizi uygulamakta özgürdük .

Bu projenin müşteriyi tam anlamıyla tatmin edecek şekilde tamamlandığını söylemekten mutluluk duyuyorum. Bugünlerde Trello veya Jira'nın iki veya daha fazla kişiden oluşan ekipler için fiili bir gereklilik olduğunu düşünüyorum.

İlerleyin ve Başkalarının Hatalarından Öğrenin

Askerdeyken öğretildiğini duyduğum en zekice şeylerden biri şu: “Teğmenlerin teğmen hataları yapmasında bir sorun yok ve kaptanların da kaptan hataları yapmasında bir sorun yok. İyi olmayan şey, kaptanların teğmen hataları yapması veya teğmenlerin özel hatalar yapmasıdır.”

Diğer bir deyişle, mevcut sorumluluk seviyeniz için doğal olan yaygın hataları yapmanızda bir sakınca yoktur. Daha da önemlisi, onlardan nasıl büyüdüğünüz.

Umarım geliştiriciler olarak bizler, hata yaptıklarında başkalarına karşı şefkatli olmayı öğreniriz, umarım diğerleri de bizimle olmuştur. Hata yaptığımda meraklı ve sorumlu kalmayı umuyorum, böylece onları geride bırakmaya devam edeceğim. Her zaman, hatalarından ders çıkarabileceğim ve kendimi yapmaktan kaçınabileceğim ilham verici bir WordPress uzmanları topluluğuyla çevrili olmayı umuyorum. Ve hepsinden önemlisi, başkalarının burada paylaştığım WordPress hataları gibi deneyimlerimden öğrenebileceğini umuyorum.