Buna Basın: Jon Martin ile WordPress Yapılarında Zaman Öldüren Teknoloji Borçlarından Kaçınmak

WMR'nin WordPress topluluğu podcast'i Press This'e hoş geldiniz. Burada ev sahibi David Vogelpohl, WordPress geliştiricilerinin karşılaştığı en büyük sorunlar hakkında konuşmak için topluluğun dört bir yanından konuklarla oturuyor. Aşağıdaki orijinal kaydın bir transkripsiyonudur.

RedCircle tarafından desteklenmektedir

David Vogelpohl: Herkese merhaba ve WordPress topluluğu WMR'de yayın yapan Press This'e hoş geldiniz. Bu, sunucunuz David Vogelpohl, WP Engine'deki rolüm aracılığıyla WordPress topluluğunu destekliyorum ve her hafta basında duyduğumuz topluluğun en iyilerini size ulaştırmayı seviyorum, bunu bir hatırlatma olarak, beni Twitter'da bulabilirsiniz @wpdavidv veya iTunes, iHeartRadio, Spotify'da buna basmak için abone olabilir veya en son bölümleri wmr.fm'den indirebilirsiniz. Bu bölümde, en sevdiğim konulardan biri hakkında konuşacağız ve bu, WordPress yapılarında teknoloji borcunu öldürmekten kaçınmaktır. Ve bu sohbet için bize katılarak Jon Martin'e hoş geldiniz demek istiyorum. Jon, Press This'e hoş geldiniz.

Jon Martin: Çok teşekkürler, burada olmak güzel.

DV: Gösteriden önce Hallum'u telaffuz etme alıştırması yaptığımı biliyorum ama tabii ki ilk başta her şeyi berbat ettim John bunun için özür dilerim. Harika, bu yüzden John'u dinleyenlerin teknoloji borcunun etkisi hakkındaki düşüncelerini WordPress geliştirme ekiplerine, teknoloji borcuna sahip olmak ne anlama geliyor ve bu sizi nasıl etkiliyor gibi paylaşacak. Her projede teknoloji borcunuzu azaltmayı nasıl düşünebilirsiniz. Ve sonra neden teknoloji borcuyla ilgili hususları müşterilerinizle paylaşma sorumluluğunuz var?

JM: Serbest çalışan bir ajansta çalışıyorsanız. Bu yüzden teknoloji borcunu öldürmeyi seviyorum. Onu ortadan kaldırmayı seviyorum, en sevdiğim konulardan biri.

DV: John'un konuyla ilgili düşüncelerine ineceğiz ama buna başlamadan önce John, sana her konuğa sorduğum aynı soruyu soracağım Bana kısaca WordPress başlangıç ​​hikayenden bahset. WordPress'i ilk ne zaman kullandınız?

JM: Yani 2010'ların başında olurdum, o dönem için doğru ifadeden gerçekten emin değildim. Bu yüzden aslında kendim başladım ve 2008'de nasıl bir ajans kurduğumuzun CEO'su oldum. O zamanlar WordPress hala bir blog platformuydu. Üzerinde çok zengin içeriğe sahip web siteleri yapıyorduk. Yani biraz kaba bir kelime ama o zamanlar Joomla kullanıyorduk. Ama sonra yerine

DV: Joomla kirli bir kelimedir. Tüm açık kaynaklı CMS'leri kişisel olarak seviyorum.

JM: Evet, bunun harika bir proje olduğunu söylemek isteriz. Bence bizim için en önemli şey, WordPress özel site desteği yayınladığında Joomla'nın gerçekten güçlü olduğu zaman içinde. İşte o zaman WordPress'te işler benim için gerçekten değişti, bu da onu bir blog platformu olarak bilindiği için bundan, sizin için olsun, gerçekten küçük olsun, her türlü siteyi yapabileceğiniz tam teşekküllü bir CMS olmaya yükseltti. tek kişilik bir işletme veya serbest çalışan ya da her neyse, devasa kurumsal düzeyde, karmaşık web sitelerine kadar. Ve bence gerçekten, gerçekten benim için, bu onların adına çok iyi bir karardı çünkü WordPress'in şu anda bu kadar popüler olmasının bir nedeni de bu. Yani evet, o burada kullanmaya başladığı zamandı. Sasha bundan önceki hikaye gerçekten benim ve şimdi birlikte nasıl bir grupta olduğumuzun CEO'su. Ve şu parlak fikrimiz var, Biliyor musun, yolda daha çok eşit zaman harika ve şu anki işlerimden zaman ayırmak gerçekten zor. Biz de şöyle düşündük, Biliyor musunuz, bir ajans kurup web geliştiricileri olalım çünkü bu o kadar zamanı geri almanıza gerçekten yardımcı olacak, bu harika bir karardı. Bundan gerçekten çok memnunum ama aynı zamanda kesinlikle naif bir karar çünkü kendin için çalışmanın sana daha fazla zaman kazandıracağını düşünmek kesinlikle bir hataydı ve sanırım biraz sonra anlıyoruz. Ve bu noktadan önce, bilirsiniz, SQL hakkında biraz bilgim vardı ve o zamandan beri bilgisayarlar yapıyorum, aslında grafik kartı renkleri çok desteklediğinden beri. Yani CGA'nın ne olduğunu bilen başka biri için bu, orada kaç yaşında olduğumu bilmenize yardımcı olacaktır. Ama evet, gerçekten, CPT'ler çıktığında öyleydi. O yağ bizim için her şeyi değiştirdi. WordPress'i hemen hemen bir gecede kullanmaya başladık, aslında bu bizim seçtiğimiz CMS oldu ve o zamandan beri geriye bakmadık ve bilirsiniz,

DV: Bu soruyu size sorduğum tüm insanlardan çok azı, materyal özel gönderi türlerinin WordPress başlangıç ​​hikayelerine göre nasıl olduğu konusunda gerçekten ipucu verdi. Ve komik. Benzer bir hikayem var. 2010'da bir ajans kurdum. Sizden biraz sonra ama özel gönderi bir şekilde içeri girdi. Joomla ile oluşturmaya başladık ve benzer nedenlerle WordPress'e geçtik, ancak bu özel gönderi türleri ve özel metaydı. Kabul ettiğim ve aslında bu şekilde sunduğum alanlar, WordPress'in gerçekten gerçek bir CMS haline geldiği bu tür bir andı. WooCommerce ortaya çıktıktan bir yıl sonra WP Engine, diğer birçok WordPress alanı markası ortaya çıktı, bu çok dönüştürücü bir zaman. Köken hikayenizin kökü olan bir tür referansınızı duymak ilginç. Yine de bana nasıl olduğunu söylüyorlardı ve bilirsin, eğer istersen oradaki kuruluş anını, ama bana kısaca nasıl olduğunu ve ne yaptığını anlatır mısın?

JM : Evet, tabii. Yani aslında, bulduğumuz ajans daha sonra böyle değildi. Tamam tamam. Bunun ana nedeni aslında, bilirsiniz, o eski günlerde geri döndüğünüzde, bilirsiniz, web siteleri yapıyoruz ile SEO yapmak ve tüm bu tür şeyler arasında çok belirgin bir fark vardı. Ve aslında dünya çapında pek çok entegre yaklaşım ve kullanıcı deneyimi gibi şeyler hakkında düşünmek değildi ve SEO ve geliştirme ile nasıl çalışır, tüm bu tür şeyler. Yani, aslında bu yüzden daha sonra sona erdik. Daha sonra, Allen Milan ile yaklaşık 20 yıldır birleştik ve kurucumuz, SEO'nun bir şey olmaya başladığı başlangıçta hemen hemen kuruldu. Yani evet, bu yüzden iki ajansı birleştirdik. Altı, yedi yıl önce, belki biraz daha uzun. Veri hafızam pek iyi değil, itiraf etmeliyim. Ve sonra gerçekten, evet, bu bizim yaklaşımımız oldu, insanların çizgiyi görmelerine yardımcı olmak için tüm bu farklı disiplinleri bir araya getirmekle ilgili bu tam entegre yaklaşım mı? Şimdi PPC, SEO, dijital PR yapıyoruz, açıkçası, web tasarımı ve marka uzantıları, dijital strateji ve tüm bu tür şeyler, bugünlerde gerçekten iyi bir dijital varlığa sahip olmak için ihtiyacınız olan tüm bu disiplinler var. Oradaki rolünüz nedir, şirket mi? Yani benim iş unvanım teknik direktördü. Bu yüzden dürüst olacağım, yaptığım her şeyi tam olarak kapsamıyor. Geliştirme ekibini uzun süre yönetiyorum. Yani tüm WordPress olacak olan benim yönetimim altındaydı. Takımda Julio ve benim ilk başladığımızda çalıştığımızdan çok daha iyi geliştiricilere sahip olduğumuzu söylemekten memnuniyet duyuyorum, bu günlerde çok daha iyi olmamızın nedeni bu. Ve bazı şeyleri biraz daha anlıyoruz. Bu yüzden geliştirme ekibini uzun bir süre daha yakın zamanda bir veri ekibi maliyetiyle yönetiyorum. Yani bu, makine öğrenimi ile oynayabileceğim anlamına geliyor, Python, Bartek ve diğerleri oynuyor, ancak bunların hepsini oynamayı hayal etmem gerekiyor.

DV: Harika ayrı müşteriler yapmak, yol boyunca bazı teknik borçlarla sonuçlanacak. Ve bu yüzden nasıl düşündüğünüzü merak ediyorum, yaygın teknik borç türleri nelerdir ve belki de WordPress'e özgü. Bir dakikalığına bunlar, ama, bunu düşündüğünüzde nasıl düşünüyorsunuz, bilirsiniz, teknoloji borcunuzu nasıl ve nasıl yönetiyorsunuz, sanki WordPress'te yerleşik türlere kilitlemişsiniz gibi?

JM: Evet, yapıyoruz. Yani, değil. Şart değil. Bir şeyleri kategorize etmek zorunda olmadığımız veya kategorize etmek için bölgesel bir süreçten geçmediğimiz bir dil yapıyoruz, ama gerçekten, bunlar üç farklı kovaya düşüyorlar. Bunlardan biri, mevcut kodların üzerine kötü kod oluşturmanızdır ve bunun nedeni, geçmişte Miras web sitelerinden ve nedeni ne olursa olsun başka birinden kaynaklanan bir sorun olabilecek bazı hatalar yapıyor olmanız olabilir, yani işte bu. bir nevi ilk kova. İkincisi, gerekli olmayan ve belki de şu anda gerekli olmayan kod oluşturmaktır. Biliyorsunuz, hepimizin birlikte çalıştığımız müşterilerden ve markalardan belirli bir şey için gerçekten istekli oldukları özellik isteklerinin sonuna geldik, ancak gerçek değeri elde etmek açısından aslında doğru şey olmayabilir. müşteriler için. Ve sonra, aslında gördüğümüz en büyüğü olan üçüncüsü, aslında gerçekten farklı bir platformda olması gereken özellikler oluşturmak. Bu tür bir mimari parçayı anlamak, tamam, burada bağladığımız farklı bitler nelerdir, burada bir CRM, burada web sitesi, temelde gerçekten işi pazarlamakla ilgili. İşte sipariş karşılama platformunuz, hepsi birbirinden farklı.

D V: Sana sorayım, burada senin gibi temel bir soru sorayım, üç tür sesi listelediniz, bunlar gibi üç tür teknoloji borcundan kurtulmak istiyorsunuz, kötü kod üzerine kötü kod yazmaktan kurtulmak istiyorsunuz. kod, başka bir platformda yapılabilecek gerekli özellikler değil. İstediğiniz değerli olan dördüncü bir kova benzeri özellikler ve bu nedenle bu durumda iyi olabilecek teknoloji yok mu? Bunu söylemek adil olur mu? Bu dördüncü kova.

JM: Evet. %100 Demek istediğim, tüm teknik borçlar kötü değildir. Yapacağınız hemen hemen her özelliğin bir tür teknik borç tahakkuk ettireceğini kabul etmeniz ve bu teknik borcun iyi olup olmadığı hakkında bir arama yapmanız gerekiyor. Bazıları iyi, bazıları kötü ve daha önce söylediğim anahtar kelimenin değerle ilgili olmasına gerçekten bağlı. O şey için ihtiyacın olan değeri alacak mısın? Daha da önemlisi, müşteri, nihai müşteri sizin müşteriniz değil, onların müşterisi mi? Değerini anlayacaklar mı? Bu teknik borcu kabul edip etmeme konusunda genellikle oldukça iyi bir Yol Gösterici Işıktır.

DV: Evet, biraz derinlere dalmak istiyorum, bilirsiniz, bu alıntı hakkında nasıl düşündüğünüzü, kabul edip etmemenizin uygun olduğu zamanlar için buna değer bir formül ama nasıl düşündüğünüzü iyi anlamak için düşünmek güzel teknoloji borcunun farklı türleri ve özellikle kaldırmak için optimize etmek isteyebilecekleriniz. Bundan sonra yapmak istediğim şey, sizi bu alana odaklanmak için aşırıya kaçan bir şey olup olmadığı konusunda bir anlayış elde etmek, ancak ilk molamızı vereceğiz ve hemen dönecek. Ticari bir mola verme zamanı. Bir an için daha fazla baskı için bizi izlemeye devam edin. Herkese merhaba. W EMR'deki WordPress topluluğu podcast'lerine tekrar hoş geldiniz Bu, sunucunuz David Vogel. Paul. John Martin ile teknolojiyi öldürerek zamanı boşa harcamak için röportaj yapıyorum. John, aradan hemen önce, ortadan kaldırmak isteyebileceğiniz üç tür teknoloji borcunu düşünme şeklinizin, üzerinde çalıştığınız sitenin başarısı için gerekli olmayan kötü kod oluşturma kodu üzerine kötü kod oluşturmak olduğunu açıklıyordunuz. Ve sonra belki başka bir platformda daha iyi sunulabilecek özellikler için kod oluşturmak. Yine de, buna değer formüle girmeden önce. Merak ediyordum, belirli bir zamanım var mıydı ve yolculuğunuz belirli bir teknik borç örneği mi, bu tür bir yüzey sizin için bunun birincil odak alanı mı?

JM: Evet, kesinlikle. Yaklaşık dört ya da beş yıl önce bana bunu düşündürmeye başlayan gerçek bir dönüm noktası projesi var. Bir sürü başka vaka gördüm. İşletmeler için her zaman, sadece WordPress üzerinden her türlü şey aracılığıyla değil, aslında işletmeler operasyonel süreçleri aracılığıyla da tahakkuk eder. O güverteyi yarattığınız yerde teknik bir şey olmanız gerekiyorsa. Birincisi, aklımda gerçekten öne çıkan hikaye, müşteri, nispeten küçük bir şirketle çalışıyoruz, onlar için çok fazla ücretli medya çalışması yaptık. Esasen çevrimiçi bir şeyler satarak satmak. Bir e-ticaret işiydi. Ve geleneksel türde bir posta siparişi vardı, ancak işlerinin çoğu ve çevrimiçi olarak daha fazla trafik çekmeye çalışıyorlardı, bu nedenle posta yoluyla gitmek zorunda kalmadılar, web sitesi aracılığıyla yönetilecekler ve bize geldiler çünkü onlar onlar için yapılmış bir site vardı tamamen ısmarlama. Ve o noktada yaklaşık 10 yıldır varlar. Bu yüzden biraz sürünmeye başlayarak oldukça yaşlandı. Bilirsin, standartlar ve devam et. Teknoloji ilerledi, biraz yeniden düşünmenin zamanı geldi. Böylece müşteri bizimle oturdu, web sitesinde yaptıkları tüm farklı şeyleri sorgulamaya başladılar. Ve benim için çok hızlı bir şekilde, web sitesinde yerleşik olarak bulunan her türlü iş mantığı ve işle ilgili operasyonel şeyler olduğunu anladım. Ve bu, siparişlere yol açan ve tedarikçilerle çalışma biçimlerine oldukça özgü olan bir mantıktı. Bu yüzden ayrıntılara girmeyeceğim, ancak tedarikçiler ile siparişleri nasıl yerine getirdikleri ve tüm bu tür şeyleri göndermeden önce mağazalarına gönderilip gönderilmediği arasında oldukça karmaşık bir anlaşmam var. Yani her şey oldukça karmaşık. Şimdi, işletme sahibi ve nasıl çalıştıklarıyla ilgili öncekiler, sonunda, her şeyi hemen hemen yöneten bir sistem kurdular ve o zamanlar gerçekten çok iyi bir sistemdi ve bu işin büyük ölçüde büyümesine gerçekten yardımcı oldu. Şimdi, gerçekten düşünmedikleri şey, tüm web sitelerinin, tıpkı herhangi bir yazılım gibi ve pazarlama dünyasında bir noktada hayata geçecekleri bir raf ömrüne sahip olduğudur. Bu raf ömrü, örneğin, bir işletme olarak bir CRM'ye yatırım yaparsanız, normalde oldukça uzun bir süre için tekmelemeye devam edecek, şimdi daha fazla web sitesi olmasa da, yaklaşık 10 yıl ile karşılaştırıldığında, bu raf ömrü gerçekten nispeten kısadır. Genel olarak iki ila beş yıl arasında konuşursak, en azından büyük markaların her üç yılda bir yeniden inşa etme eğiliminde olduğunu görüyoruz. O zaman sorun şuydu ki, tüm bu karmaşık mantığı mevcut web sitesine yerleştirdiler ve tüm web sitesini yeniden inşa etmek zorunda kaldılar. Ve aniden tüm bu iş mantığını da yeniden inşa etmeniz gerekiyor. Şimdi, projeye maliyet getirdik ve temelde, zaten sahip olduğumuz şeyi yeniden inşa etmek için temelde yıllık cironun yaklaşık yarısı oldu. Ve bu beni gerçekten bu şey hakkında düşünmeye başladı, o kadar iyi, tamam, eğer soruna orijinal olarak farklı bir şekilde yaklaşıyorlarsa, örneğin, bir web sitesinde elde etmeye çalıştığımız farklı şeyler hakkında düşünelim. Biliyorsunuz, bu pazarlamadan, ürün satmak içindi. Bu, siparişlerin yerine getirilmesi için, tüm bu şeyleri tedarik ederek iş sürecimi yönetmek için en iyisi ve bu konuda biraz daha modüler bir şekilde düşündüm, o zaman bu müşteri için çok farklı bir durum olurdu, o oradaydı . Bu onlar için gerçek bir problemdi çünkü esasen para kazandıkları bir web siteleri vardı. Oldukça eski olduğu için çok gıcırdıyordu. Ama aynı zamanda, tüm web sitesini yeniden inşa etmek çok pahalıya mal olacak ve projeyi çok, çok karmaşık hale getirecekti. Zaten sahip olduklarını denemek ve kullanmak ve entegre etmek için sonuna kadar oldukça zeki ama aynı zamanda hoş olmayan bir iş bulmayı başardık ama alıntı yapamıyoruz ama bilirsiniz, sonuçta çok daha acı verici, çok daha yavaş ve çok daha fazlası oldu. olması gerekenden pahalı. Eğer bu mimari orijinal olarak düşünülmüşse.

DV: Unutmak istediğim çok fazla projem var. Aynen öyleydi ve şimdi hayal edebiliyorum, kendimi zamanda geriye götürüyorum. Bana öyle geliyor ki, bu oldukça açık görünüyor, bence, planladığınız refactor'a göre işletmeye ne tür maliyetler getireceğini düşünmek çok önemli bir ders. Ve bana, net cevap, onu farklı şekilde tasarlamanız gerektiği gibi geldi. Ve eğer yapmanız gereken şeyi beğenecekseniz, bu belki daha açık bir yol. Ama bence birçok takım gibi teknik borç hakkında düşündüklerinde, "Tamam, peki, bu şeyi yapmak güzel olurdu, ama buna değer mi?" gibi düşünüyorlar.

JM: Bu şeyi zaman içinde sürdürmeme değer mi? Bu formül hakkında ne düşündüğünü merak ediyorum

D V: ne zaman, mesela, Teknoloji borcunu ne zaman devreye sokmak uygun olur? Ve bu formül hakkında ne kadar düşünüyorsun?

JM: Evet, gerçekten önemli bir noktaya değindiniz, bilirsiniz, geliştiricilerin doğasını düşünürsünüz, geliştiriciler buna harika şeyler yapmayı sevdikleri için girerler. Ve işte bu, bilirsiniz, motivasyonumuzun büyük bir kısmı yeni şeyler yapmayı öğrenmek, yeni teknoloji, bilirsiniz, yeni JavaScript çerçeveleri, her ne ise ve bu doğal olarak bize harika şeyler inşa etme motivasyonunu veriyor, ama bunun hakkında uzun vadeli düşünmüyoruz, biliyorsunuz, yine de koruyacağız. Biliyor musun, karım evimde jakuzi olmasını çok isterdi, ama birinin bunu temizleyeceğini biliyorum ve dürüst olacağım, onu temizleyen kimsenin bu tür bir düşünce olduğuna inanmıyorum zaten. Yani bu gerçekten, gerçekten, gerçekten çok iyi bir soru, ilk etapta buna gerçekten değer mi ve eğer bunu biraz parçalara ayırırsak, düşünebileceğiniz birkaç farklı şey var, her şeyden önce, uzun uzun düşünmek terimi, toplam sahip olma maliyeti ve onu test etme ve bakımını yapma ve sonra bunu elde ettiğimiz değere karşı tartma toplam maliyeti nedir? Örneğin, bu sorunu çözmenin gerçekten basit bir yolu olabilir. elektronik tabloları kullanmak veya belki de şirket içinden birinin kısa bir süre için bunu yönettiği biraz farklı mimari şeyler kullanmak. Ve bunu yapmak, bu gerçekten karmaşık özelliği oluşturmaktan daha ucuz ve daha etkili olacaktır. Ancak toplam sahip olma maliyetine gerçekten baktığınızda, belirli bir şeyi yapmak için haftada birkaç saat harcayan birinin maliyetinden daha pahalıya mal olacak. Beni yanlış anlama. Otomasyona büyük bir inancım var. teknolojiler, bu tür bir yöneticiden kaçınmak için mümkün olduğunca otomatikleştirilmelidir, ancak

DV: Kaydolursunuz ve değerin orada olacağından emin olmak için kodlamadan önce bir şeyi denemek için bu kılavuzdaki gibi kullanırsınız. Demek istediğim, bu faktörü basitleştirmek gibi bir fikrim var, bunun yerine bunu manuel olarak yapabilir miyiz? Sadece merak ediyorum, hiç beğenmek için bir test bakış açısıyla yaklaştınız mı, nihai geri dönüşün buna değip değmediğini görün?

JM: Evet. 100%. Bu yüzden Agile metodolojisine büyük bir inancım var. Ve temel olarak, Agile'ın en önemli ilkelerinden biri, doğru şeyi doğru zamanda inşa etmenizdir. Ve mümkün olduğunca çabuk değer kazanmaya odaklanırsınız. Yani minimum uygulanabilir ürünü inşa etmek istiyorsunuz. Bu, o noktada tamamen zengin özelliklere sahip bir şeye sahip olmanız gerekmediği anlamına gelir. Ama size daha sonra test etmeye başlayabileceğiniz bir platform sunuyor, bilirsiniz, gerçekten istediğiniz şeyleri ondan alıyor musunuz? Kullanıcılarınız buna yanıt veriyor mu? UX veya web geliştiricisi içinde çalışan herhangi birinin beklediğiniz şekilde, müşterilerden oldukça sık istekler alacağını bilecektir, çünkü onlar müşterilerini düşündükleri için, ama aslında gerçekten istiyorlar mı? Yani bu gerçekten iyi bir soru daha, bu uzun vadeli görüş hakkında bir kez düşündüğünüzde, web sitesini kullanacak insanlar bunu kullanacak birini biliyor muyuz yoksa isteyip istemediklerini görmek için test etmemiz gerekiyor mu? kullanmak için? Ve sonra bu testi yaptıktan sonra, bunun için neyi talep etmememiz gerektiğini ve geri çekilip yatırımımızı başka bir yere koymamız gerekip gerekmediğini bulabiliriz.

DV: Bu düşünceleri bir nevi özetlemek gibi geliyor ve uzun vadeli toplam sahip olma maliyetine bakma fikrinizi beğendim, bence takımlar çoğu zaman tanıdığınız kişilerin bile düşündüğünü, teklif verdiğini, hizmet siparişi verdiğini düşünüyor. takımlar, bu şeyin inşa etmek için kaç saat ya da hafta ya da yayılma ya da puan ya da her neyse onu düşünür. Ama sonra, bilirsiniz, bunu korumanın kaç saat, hafta, spread ya da puan alacağını bildiğinizi hesaba katmanız ve sonra bu dengeyi koruduğunuz değere karşı kullanmanız gerekir. o aktivite. Belli ki bu sağlam bir tavsiye. Ama sonra şunu da düşünüyorsunuz, Peki, varsayımlarımın doğru olup olmadığını görmek için bunu test etmek için yapabileceğim bir şey var mı? Kulağa doğru geliyor mu?

JM: Evet. Kesinlikle. Kesinlikle. Ve değinmediğimiz tek şey, biraz önce bahsettiğimiz şey, ki bu mimariyle ilgili, bunu daha iyi hale getirmek için yapılandırmanın daha iyi bir yolu var mı ve bu zamanı da nesne programlama ve benzeri şeyler için. muhtemelen biraz sonra değineceğim.

DV: Evet, mimari düşünceler de, nasıl olduğunu yazdığım gibi, özellikleri değiştirmenin bir yolu var mı? Paydaş eğitimim veya görüşmelerimdeki gibi mi, sık sık bildiğinizi söylüyorum, doğru bir şekilde mi? Konaklamanız için gerçekten neye ihtiyacınız olduğunu sorun. Ve bu yüzden onlara yalan söylemek ve gerçekten ihtiyaç duyulacak ve bu ne olacak? Soruları çok kritik buldum. Bu, bu konuda nasıl düşündüğünüzün önemli bir parçası gibi görünüyor.

JM: Evet, çünkü bu sitenin geliştirilmekte olduğu her dakika, müşterilerin önünde değer kazanmadığı bir dakikadır. Ve bu, düşünmenin kolay yolu. Mümkün olduğu kadar çabuk fırlatılmak istiyorsunuz. Ve sonra test edin, izleyin, yineleyin, öğrenin, bilirsiniz, oradan nereye gittiğinizi görün, ancak bunu doğru olduğunu düşündüğünüzden ziyade gerçek verilere dayanarak yaptığınız için. Çünkü çoğu zaman aynı değiller.

DV: Evet, bu noktayı seviyorum. Her dakika. Geliştirme aşamasında, bir an önce kullanmıyorsunuz, değil mi, anlayın ve bir tür bağla bağları, sahip olduğum başka bir mantraya ve proje yönetimi ve paydaş yönetimine geri döndüğünü söyleyeceğim, ki bu en iyi iki kelimedir ve yüzümüze yazmak için bir proje almak. Nasıl konuşabilirsin evet, paydaşlarla uğraşırken veya bir paydaşım olduğunda güçlü, güçlü bir parçam olmasını seviyorum. Peki tamam. Şimdi ekiplerin teknoloji borcunu azaltmak için neler yapabileceğinden bahsedelim. Ama bunu yapmadan önce, son molamızı vereceğiz. Ticari bir mola verme zamanı. Bir dakika içinde buna daha fazla basmak için bizi izlemeye devam edin. Herkes W EMR'deki bu WordPress topluluğu podcast'ine tekrar hoş geldiniz. Bu sunucunuz David mobile Paul, John Martin ile aradan hemen önce John'un nasıl teknoloji borcunu bitirmek için zamandan kaçınma hakkında konuşmanın ortasındayım, buna değer formülünüz hakkında biraz konuştuk, azaltma konusundaki fikirlerinizi gerçekten beğendim özellikler. TCO'yu düşünmek ve bir nevi yinelemeli bir test yaklaşımı benimsemek. Ancak şimdi ekiplerin teknik borçlarını ve WordPress yapılarını azaltmak için gerçekte neler yapabileceğini inceleyelim. Teknoloji borcunu azaltmak için en sevdiğiniz tekniklerden bazıları nelerdir?

JM: Yani kullanabileceğin her türlü teknik teknik var ve bazılarını biliyorsun, bu yüzden bilmeyeceksin, ama aslında benim için başlangıç ​​noktası, konuşmaya yönelik çok daha yumuşak bir yaklaşım. müşterilerinize. Ve en nihayetinde, müşterilerinizin bu markalar olduğunu unutmamalısınız çünkü bizler uzmanız. Bizim tavsiyemize ihtiyaçları var ve onların istediklerini yapmak için orada olduğumuz, onların bizden yapmamızı istediklerini yapmak için orada olduğumuz, ama aslında, biz orada olduğumuz tuzağına düşmek oldukça kolay. yapmak istediklerine meydan okumak ve denemek ve geliştirmek. Bu yüzden yapabileceğiniz ilk şey, onlarla bunun hakkında konuşmak ve açıklamak, tamam, bunu yaparsak, bunun uzun vadeli etkisi olacak. Biliyorsun, fazladan bir test günü daha alacak. Ne zaman bir sürüm yayınlasak, web sitesini her bakıma almamız ve tüm eklentileri güncellememiz gerektiğinde birkaç saat ya da iki saat ekleyeceğiz. Ancak bu farkındalığı artırarak, onlarla bu konuşmaları yapıyoruz. Müşterinin bu tartışmanın bir parçası olmasını sağlayabilirsiniz. Ve sonunda onlar da problem çözmenin bir parçası haline geliyorlar, müşterilerimizi her zaman eğitmek zorundayız, çünkü bizim yaptığımız bazı şeyleri bilmiyorlar. Yapsalardı, ilk etapta alet olmazlardı. Yani aslında başlangıç ​​noktası bu. İşleri basitleştirmenin yanı sıra bunu hatırladığını düşünüyor. Yine, insanlar bizim kadar teknik olmak zorunda değiller. Bu yüzden bunun hakkında konuşmak için analojiler kullanın. Evlerin her zaman harika bir enerji olduğunu düşünürüm. Herkes evde yaşıyor. Çoğu insanın bir tür ev tadilatı yapma deneyimi vardır. Bu yüzden bu enerjiyi bir şeyleri düzeltmek için kullanmak oldukça kolaydı. Yani bu gerçekten ilk noktanın türü, bir müşteri edinmek veya bu konuşmaları döngüye almak. Daha önce değindiğimiz bir sonraki şey, bu uzun vadeli görüşe veya toplam sahip olma maliyetine sahip olmaktı. Ve kendinize bu soruları sorun ve her özellik isteğini sorgulayın. Ama biraz daha teknik olmak ve bunu işte nasıl yapacağınız. Bildiğiniz WordPress standartlarını kullandığınız basit şeyler, orada standartlar var. Onlar bir neden için varlar. Şimdi, bize geliştiriciye yardımcı olacaklar ve belki bir veya iki yıl boyunca bıraktığınız bir proje üzerinde çalışıyorsunuz ve sonra ona geri dönüyorsunuz. Hafızanızı tazelemelisiniz ve standartları kullanarak onu ilk inşa ettiğinizde bulunduğunuz yere geri dönmelisiniz. Ayrıca diğer insanlara da yardım edecekler. Bu nedenle, ekip içinde değilseniz, bu, verimlilik ve belgelere yardımcı olma ve tüm bu tür şeyler açısından gerçekten, gerçekten yararlı olan herkesin çalışabileceği bu ortak dile sahip olduğunuz anlamına gelir. Yani bu, herkesin çalışabileceği standartlara sahip olarak teknik borcunuzu azaltmanın daha yumuşak bir yolu. Ayrıca, diğer bazı WordPress geliştiricilerinin bu proje üzerinde çalıştığı zamanın gelebileceğini bilmenize yardımcı olur. Ve bunu topluluğa geri ödemenin bir yolu olarak düşünmelerine ve diğer geliştiriciler için daha kolay hale getirmelerine yardımcı olur. Yani bu, bilirsiniz, standartlar etrafında iyi bir nokta ve bunu kendiniz ve başkaları için kolaylaştırın. Bir sonraki büyük hakkında daha fazla. Uzun yıllar önce The clean coder adlı harika bir kitap yazan, sevgiyle Bob Amca olarak bilinen büyük endüstri kuralları. Herhangi bir geliştiricinin bu kitabı okumasını şiddetle tavsiye ederim çünkü okumadılar. Aslında, bir geliştirme ekibi için, ekibe katılan herkes için okumayı zorunlu hale getirdim, çünkü çoğunlukla buna karşı çok iyi bir yaklaşımı var çünkü birim testi, tüm bu tür şeyler hakkında konuşuyor, ama temelde, birçoğu. Bu, kodu çok hızlı bir şekilde yineleyebileceğiniz, değiştirebileceğiniz ve içine fazladan bitler ekleyebileceğiniz esnek hale getirecek şekilde nasıl yazacağınızla ilgilidir. Bahsettiği en önemli noktalardan biri sık sık yeniden düzenleme hakkındadır ve bundan alınması gereken en önemli şey, mutlaka o kod parçasının bittiği anlamına gelmeyen bir kod parçası yazmanızdır. Daha modüler hale getirmek veya daha iyi bir test yapmak için daha taşınabilir hale getirmek için optimize etmek için yapabileceğiniz şeyler vardır, kodu yeniden düzenlemeye zaman harcamak için yapmanız gereken şey ne olursa olsun. Karşı çıktığınızda bunu yapmak gerçekten çok zor olabilir ya da bilirsiniz, belki bir bütçe için tek bir zaman dilimidir. Ama nihayetinde, teknik borç tahakkuk ettirmenizi durduracak türden bir şey ve aslında, genellikle bu şekilde zorlandığını görüyorum, ancak bir proje teslim tarihi olduğu için, o son tarihe ulaşmanız gerekiyor. Kesinlikle. Vurmanız gerekiyor, ancak daha sonra yapacağınız kötü kodu yazmaktansa kapsamı esnetmek daha iyidir,

DV: Sanırım, bu müşterileri de bu konuda eğitin, çünkü yeniden düzenleme yapmak istemeyen bir geliştiriciyle hiç tanışmadım. Kod. Her zaman zaman çizelgesidir. Buna karşı. Um, tamam, işte son olarak, merak ettiğim son şey, eğer bizi beğenirseniz, yük boşaltmak ve kullanıma hazır eklentileri kullanmak gibi şeyleri düşünürseniz, teknolojiden kaçınmanın başka bir yolu veya teknoloji borcundan kaçınmanın başka yolları. Sizin listenizde de var mı?

JM: Evet. %100 Yani bu iyi bir yol, ancak her ikisini de yapmanın iyi bir yolu aslında, teknik borçtan kaçınabilirsiniz. Ama siz de yapabilirsiniz ve biliyorsunuz, WordPress bir BMC biçimidir. O kadar aktif ki, aynı zamanda en büyük düşmanı da olabilir. Her şeyi yapan bir eklenti var. Ayrıca çok özel bir amaç için oluşturulmuş birçok eklenti var, ancak bunlar mutlaka sizin eklentilerinizle eşleşmez. Bu yüzden bunu özellikle, eklentileri kullanarak siteler inşa etmeyi seven ve şeylere sıfırdan bir bakış açısıyla kodlamak yerine daha fazla göster ve tıkla yaklaşımını seven bazı geliştiricilerde gördüm. İnsanlar şeylere eklenti atma eğilimindedir. 100'den fazla eklentiye sahip web siteleriyle çalıştık ve bunların çoğu artık korunmuyor. Her yerinde güvenlik sorunları var. Sen dener ve serbest bırakma oranını yaparsın. Bunu birkaç saat içinde yapabilecekken, kelimenin tam anlamıyla dört gününüzü test ederek geçiriyorsunuz. Yani eklentiler iyi veya kötü olabilir. Doğru zamanda doğru fiş harika, harika bir şeydi. WordPress'in en güçlü yanları, ancak yanlış zamanda yanlış eklenti de ciddi şekilde zarar verebilir. Ve aslında en büyük sermaye kaynaklarından biri olabilir.

DV: Kesinlikle böyle bir projem vardı. John, bu inanılmaz derecede anlayışlı oldu. Bugün bize katıldığınız için çok teşekkür ederiz.

JM : Benim için zevk.

DV: Harika. Jon hakkında daha fazla bilgi edinmek isterseniz hallam.co.uk adresini ziyaret edebilirsiniz. Herkese teşekkürler, bu WordPress topluluğu podcast'lerini WMR'de dinlediğiniz için. Yine, bu sunucunuz David Vogelpohl oldu. WP Engine'deki görevimin bir parçası olarak WordPress topluluğunu destekliyorum ve bu topluluğun en iyilerini Press This'e getirmeyi seviyorum.