WordPress Geliştiricileri: Buradan Başlayın!

WordPress geliştiricileri için başlangıç ​​kılavuzumuza hoş geldiniz! İster serbest çalışan olarak çalışın, ister bir medya ajansının parçası olun. Bu yazıda, mevcut bazı kaynaklar ve araçlarla birlikte WordPress geliştirme ile ilgili çeşitli konuları ele alacağız.
Metin, fikir üretme ve nakliye arasında akan farklı aşamalar etrafında düzenlenmiştir. Beyin fırtınası, prototip oluşturma, geliştirme ve son olarak dağıtım hakkında konuşacağız. Bütün bunlar, ürün geliştirme bağlamında. Bir fikrin ilk işaretleri ile nihai uygulaması arasında pek çok ince alan olduğuna inanıyoruz. Bazıları en iyi ihtimalle tartışılmadan bırakılır ve diğerleri mevcut WordPress literatüründe en kötü ihtimalle tamamen keşfedilmez.  

Pressidium müşterisiyseniz, yüksek düzeyde entegrasyonun avantajlarından yararlanabilmeniz için platformumuz etrafında oluşturduğumuz araçları hemen kullanmaya başlayabilirsiniz. Bu araçların neler olduğundan da bahsedeceğiz.   Lütfen bunun canlı bir belge olduğunu ve bu şekilde ele alınması gerektiğini unutmayın.

Her şeyden önce amacımız, bu belgenin bir WordPress geliştiricisi olarak uygulamanız için faydalı olması ve ikinci olarak da size sadece sizin için oluşturduğumuz birkaç harika şeyi göstermektir.

Fikirden dağıtıma  

İster yeni bir ürün üzerinde çalışın, ister müşteri işi üstlenmiş olun, fikirden dağıtıma geçme süreci 4 aşamadan oluşur. Bu aşamalar ayrık olmalarına rağmen önemli ölçüde örtüşürler ve doğrusal değildirler. Bunu metinde daha ayrıntılı olarak tartışacağız:  

1. Beyin fırtınası ve gereksinimlerin ortaya çıkarılması.
2. Prototipleme.
3. Gelişim.
4. konuşlandırma.

Serbest çağrışımsal beyin fırtınası süreci, bir ürün veya proje oluşturmaya başlamak istediğinizde ve fikirlere ihtiyacınız olduğunda kullanılır. Bununla birlikte, gereksinimlerin toplanması, bir müşteri için bir proje oluşturmakla veya bir beyin fırtınası oturumundan sonra bir fikre son vermekle görevlendirildiğinizde gerçekleşir. Belirli sorunları çözmek için daha sonra yine de beyin fırtınası oturumları ayarlayabilirsiniz, ancak bu oturumlar daha kısıtlı olacaktır.

Beyin fırtınasının temel ilkeleri iki tanedir. Miktar için gidin ve daha sonra karar vermeyi erteleyin. Geçmişte böyle bir oturumu nasıl kolaylaştırabileceğinizi, uygun zihniyeti nasıl oluşturabileceğinizi ve size yardımcı olacak bazı tuhaf araçlar hakkında yazdık.

Gereksinimleri ortaya çıkarmak

Gereksinimleri ortaya çıkarmak için kullanılan birkaç metodoloji vardır ve geleneksel olarak bu her zaman bir iş analistinin işi olmuştur. Proje gereksinimleri hakkında bilgi sağlamak müşterinin sorumluluğunda olsa da, tüm paydaşlar için ortak bir anlayış oluşturulmalıdır. Gereksinimlerin ortaya çıkarılması, gereksinimlerin toplanmasından farklı bir süreçtir. Daha çok aktif katılım yoluyla gerekli bilgileri ortaya çıkarmakla ilgilidir. Ve bu, müşterinin size söylediklerini pasif bir şekilde bir belgede toplamak ve geliştirme ekibine iletmekle ilgili değildir.

Projenin kapsamına ve doğasına bağlı olarak Kullanım Durumları, işlevselliği yakalamanın harika bir yoludur. Kullanım Durumları, bir sistemin paydaşları ile sistemin kendisi arasındaki etkileşimleri tanımlamanın bir yolu olarak UML diyagramlarında kullanılan bir tekniktir. Düz ama yapılandırılmış İngilizce ile yazılmış bir senaryolar koleksiyonu olduklarından, yalnızca daha az karmaşık olmakla kalmaz, aynı zamanda sistem işlevselliğini tartışmaya ve çizmeye başlamanın hızlı ve verimli bir yoludur.

Karmaşık ürünler için gereksinimleri yakalamak istiyorsanız, muhtemelen tüm paydaşlarla yapılandırılmış görüşmeler ayarlamanız gerekecektir. Bunun için Kullanıcı Hikayeleri mükemmel bir yoldur. Çevik zihniyetin bir parçasıdırlar ve ortak bir anlayış oluşturmak için gereksinimler hakkında konuşmaya başlamanın gayri resmi bir yoludur. İşlevlerin kısa açıklamaları kağıt kartlara, genellikle Post-It Notlarına yazılır ve kullanıcı yolculuklarının anlatımlarını oluşturmak için bir beyaz tahtada karıştırılır. Kullanıcı hikayeleri, beyaz tahtadaki kartların katılımı, tartışılması ve manipüle edilmesi yoluyla yerinde oluşturulur. Ayrıntılar yavaş yavaş belirlenir ve sonunda ürün biriktirme listesine özellikler olarak eklenir. Jeff Patton, konuyla ilgili daha fazla bilgi edinmek ve projelerinizde kullanmaya başlamak istiyorsanız, şiddetle tavsiye ettiğimiz Kullanıcı Hikayesi Haritalama üzerine mükemmel bir kitap yazdı.

Kullanıcı hikayeleri, bir kez oluşturulduktan sonra sonsuza kadar unutulan statik bir şey değildir. Bunun yerine, prototipleme aşaması devam ederken ve ürün şekillenmeye başladıkça geliştirme ve ürün ekibinin tekrar tekrar dönebileceği dinamik bir haritadır.

Bir prototipin önemi soruları cevaplamaktır. Birkaç prototipleme metodolojisi olmasına rağmen, evrimsel olanın amaçlarımız için en uygun olduğuna ve modern Çevik yazılım geliştirme boru hatlarına uyarlanabileceğine inanıyoruz. Evrimsel prototip metodolojisinde süreç döngüseldir ve prototip her döngüde aşamalı olarak daha rafine hale gelir.

Her prototip yinelemesi, tasarım aşamasından geliştirme ve değerlendirme aşamasına geçer. Erken tasarım sorunlarını ortaya çıkarır ve insanların işaret edebileceği ve neyin geliştirilebileceği hakkında konuşabileceği somut bir şey sağlar. Değerlendirme aşamasından elde edilen içgörü , bir sonraki prototip yinelemesinde kullanılır ve döngü bir kez daha kendini tekrar eder. Böylece prototip, bitmiş bir ürün olarak olgunluğa ulaşana kadar yavaş yavaş nihai sisteme evrimleşir.

Prototip oluşturma genellikle hızlı geliştirme adımlarında gerçekleşir ve Bedrock, Sage ve Bootstrap gibi standart sistemlerin kullanılması geliştirme sürelerini büyük ölçüde azaltabilir. Yukarıda bahsedilenler gibi sistemler, eksiksiz bir uygulama iskeleti ve gerekli alet zincirini sağlar, böylece her seferinde sıfırdan başlamanız gerekmez. Evrimsel prototipler, atılan prototiplerle aynı şey değildir. İkincisi, yalnızca bir kez konsept kanıtı olarak oluşturulan ve daha sonra atılan prototiplerdir. Bir e-ticaret prototipi oluşturmak için önemli miktarda zaman harcıyorsanız, neden her şeyi bir kenara atıp sıfırdan başlamak yerine ortak işlevleri soyutlayıp gelecekte tekrar kullanmayasınız?

Pressidium Klonlamanın kullanışlı olduğu yer burasıdır. Tek bir tıklamayla bir web sitesini hızlı bir şekilde klonlamanıza ve geliştirmeye başlamanıza olanak tanır. Bu şekilde, ortak kalıp kullanarak birden fazla şablon web sitesi hazırlayabilir, bunları gerekli eklentiler, temalar ve yapılandırma ile önceden yükleyebilir ve bir projede her ihtiyaç duyduğunuzda bunları klonlayabilirsiniz. Bunları aynı şekilde farklı bir Pressidium hesabına, örneğin müşterinizinkine de kopyalayabilirsiniz. Prototipleriniz farklı bir yönetilen WordPress barındırma sağlayıcısındaysa endişelenmeyin. Sadece Geçiş Sihirbazı Aracımızı kullanın ve bunları Pressidium hesabınıza aktarın!

İster kendi başınıza WordPress projeleri geliştirin, ister diğer WordPress geliştiricileri ve tasarımcıları ile işbirliği yapın, zanaatınızın uzun vadede sürdürülebilirliğine katkıda bulunan en önemli iki nokta şunlardır:

1. İyi yazılım alışkanlıkları uygulamak.
2. Ve her şeyin ne olduğunu, nerede olduğunu ve neden orada olduğunu bilmek.

En iyi uygulamalar, sürekli olarak bir yazılım stili kılavuzunu takip etmekten akıllıca değil temiz kod yazmaya ve üst düzey yazılım ve UI tasarım seçeneklerine kadar çeşitlilik gösterir. İkinci nokta, basitçe dokümantasyon ve bir proje içinde alabileceği birçok formdur.  

Bir yazılım stili kılavuzunu takip etmek basittir. Konuyla ilgili resmi WordPress.org kaynaklarını inceleyin ve ardından bunları kodlama stilinize dahil etmek için hangi yönergelerin sizin için anlamlı olduğuna karar verin. Alışkanlıkları değiştirmek yavaş bir süreçtir ve ilk başta küçük değişiklikler yaparak başlamalısınız. Sonuç olarak, kodunuzun uyması gereken bir dizi yönergeye sahip olmak, bir noktada kod incelemelerini tanıtmak anlamına gelir.

Kod incelemeleri, hataları ortadan kaldırmayı, kodun anlaşılması güç kısımlarını aydınlatmayı ve kodun standartlara ve sözleşmelere bağlı kalmasını sağlamayı amaçlayan kodu okumanın ve incelemenin sistematik bir yoludur. Sizin tarafınızdan değil, ekibinizdeki başka biri tarafından yapılması da en iyisidir.

Pressidium ile web sitenizi barındırın

60 GÜN PARA GERİ GARANTİSİ

PLANLARIMIZI GÖRÜN

Temiz kodu akıllıya tercih etmek, ne yazık ki ancak akıllı kodun tuzaklarına düştükten sonra takdir edilebilecek bir yazılım geliştirme “bilgelik incisidir”. Çıkarım şudur: Bazı durumlarda akıllı kodlar size "hacker" puanları ve arkanıza yaslanma ve hatta bazı durumlarda performans artışı kazandırabilse de, sonunda uzun vadede kaybedersiniz. “Hackish” ve okunması zor olan kodlar gelecekte anlaşılmaz hale gelecektir. Ve özellikle anlaşılması zor bir hatayı gidermeniz gerektiğinde size pahalıya mal olabilir. Optimize edilmiş kod yazma ile temiz kod yazma arasındaki dengeyi bulmak, kendiniz keşfetmeniz gereken bir şeydir, ancak işlerin temiz tarafında hata yapmak her zaman daha iyidir.

Ayrıca WordPress sitelerinin performansı büyük ölçüde tarayıcı önbelleğinin doğru kullanımına bağlı olduğundan, yönetilen WordPress barındırma sağlayıcınızın önbelleğe almayı nasıl kullandığını bilmek önemlidir. Kodunuz daha sonra mümkün olan en iyi performansı elde etmek için barındırma platformunuzla sinerjik olarak çalışacaktır. Ancak, web sitenizin hızını doğru bir şekilde ölçmenin sanıldığı kadar kolay olmadığını ve içinde birçok hata olduğunu unutmayın!

Bu nedenle, üst düzey en iyi uygulamalardan bahsetmişken, WordPress'in temel işlevselliğini ayırmasına ve bir REST API sağlamasına yol açan karar, kesinlikle bu tür uygulamalara bir örnek olarak düşünülebilir. Bu karar, programatik İçerik Yönetim Sistemlerine ve “başsız” WordPress uygulama geliştirmeye yönelik yeni bir döneme doğru hareketin sinyalini verdi.

  WordPress REST API'sine kısa ve öz bir giriş ve öğretici ile Postman gibi tarayıcı eklentilerini kullanarak düzeltmeye başlamanın basit bir yolunu yazdık.

  Bu yazılım tasarım kararı, aldatıcı bir şekilde basit ama güçlüydü. Bir WordPress geliştiricisi, artık web sitelerinin veya blogların çok ötesinde uygulamalar ve işlevler uygulamak için WordPress'i kullanabilir. Özellikle uygun bir örnek, Kanban prototipimizdir.

Görevler, sütunlar ve değer akışı içeren bir Kanban panosunu modellemek için kategoriler ve gönderiler gibi WordPress varlıklarını kullandık. Her şeyi birbirine bağlayan bir Kanban Sütunları ve Kartları API'si çizdik.

belgeler

En iyi yazılım uygulamalarının, basit kod yorumlarından proje çıktılarına ve sonuç olarak ürün kopyalamaya kadar daha iyi belgeler yazmaya elverişli olduğu iddia edilebilir.  

Nereden bakarsanız bakın, belgeler bir varlıktır.  

Teknik belgeler söz konusu olduğunda, yazılı olarak kullanılan dil, günlük iletişim kurarken veya işte kullandığınızdan kesinlikle farklıdır. Bu yazı biçimine teknik yazı denir ve yalnızca bilgisayarlarda veya yazılım mühendisliğinde kullanılmaz. Aslında hukuk, tıp, havacılık vb. gibi teknik kavramları uzman bir kitleye iletmesi gereken tüm mesleklerde kullanılır. Bu büyük bir konudur ve teknik yazı sertifikaları sunan bazı kolejler bile vardır. Varoluş nedeni, açık ve özlü bir dil kullanarak teknik bilgileri iletmektir. Aktif ses pasife tercih edilir, ikincisi kavramları açıklamak için açıklayıcı bir metnin gerekli olduğu durumlarda kullanılır.

Teknik bir yazarın, okuyucunun belirli bir bilgiyi ararken genellikle hüsrana uğrayan biri olduğunu akılda tutması gerekir. Sonuç olarak, yazınızın engellenmemesi gerekir. Amacı, bu süreci kolay, anlaşılır ve hatta eğlenceli hale getirmektir!  

Bir dereceye sahip olmanız veya profesyonel bir teknik yazar olmanız gerekmese de, kavramları özlü ve basit bir şekilde nasıl ileteceğinizi bilmek bir WordPress geliştiricisi olarak kariyeriniz için çok önemlidir. Bu nedenle, oluşturduğunuz (ve gurur duyduğunuz!) bir eklenti, tema veya API için belge yazmanız gerektiğinde, temel bilgilere sahip olmanız gerekir. Bu nedenle, teknik yazının 5 temel ilkesini de kapsayan WordPress eklentilerinizi ve temalarınızı belgelemek için hızlı bir kılavuz hazırladık.

Ancak belgeler burada bitmiyor. Temanızın veya eklentinizin daha büyük bir projenin parçası olduğu veya yeterince karmaşık olduğu durumlarda, ürün dokümantasyonu açısından düşünmeye başlamalısınız. Dokümantasyonun bir varlık olduğu gerçeğine ek olarak, ürün dokümantasyonu da bir pazarlama varlığıdır. Bu, MindTouch Pazarlama Başkan Yardımcısı Mike PuterBaugh'un ürün belgelerinin önemi hakkında Mashable makalesinde yaptığı aşağıdaki alıntıda uygun bir şekilde özetlenmiştir:

Bu seksi bir girişim değil, ancak size meslektaşlarınızın saygısını, daha etkili şirket yönetimini ve daha işbirlikçi bir ekip kazandıracak. Çünkü mesele bu çeyrekle veya bu yılla ilgili değil, daha çok rekabet avantajını ve uzun vadeli büyümeyi etkilemekle ilgili.

Ürün söz konusu olduğunda , en yaygın yazılı belge biçimlerinin yanı sıra, çevrimiçi yardım, stil kılavuzları, mikro içerik vb. gibi birkaç tane daha vardır. Ürün belgeleri genellikle birçok farklı kişi tarafından işbirliği içinde yazılır ve bu da fazladan bir karmaşıklık katmanı ekler. Bu şekilde de düşünmeye ve planlamaya başlamanıza yardımcı olacak kapsamlı bir kılavuz yazdık.

Son olarak, sürecin son aşaması olan dağıtıma geçerken, dokümantasyon bulmacasının son parçasını yerleştiriyoruz: Dağıtım Diyagramları. Bunlar, her şeyin ne olduğu ve nerede olması gerektiği konusunda net ve küresel bir fikre sahip olmanıza yardımcı olur.

  Çoğu insan UML'yi duyunca dehşet içinde çığlıklar atarak kaçacak olsa da (ve oldukça anlaşılır bir şekilde, UML'nin tam özelliği berbattır), savunması için UML, bir projeye değer katabilecek bir dizi gösterim aracı içerir. Dağıtım diyagramları, yalnızca düğümlerden ve iletişim yollarından oluşan ve size bir bakışta, projenizde bulunan farklı ortamları ve her bileşenin konuşlandırılması gereken yeri gösterebilen şaşırtıcı derecede basit bir gösterimdir.

Gelecekte UML'yi, özellikle Sıra Diyagramları adı verilen başka bir yararlı gösterimi ve ayrıca proje gereksinimlerini ortaya çıkarmak ve prototipler oluşturmak için Kullanım Durumu senaryo diyagramlarının daha ayrıntılı örneklerini inceleyeceğiz.

Modern geliştirme ve dağıtımların tümü olmasa da çoğu, git ve SVN gibi bir tür sürüm denetimi kullanır. Kaynak kod depoları, yalnızca ekipler için gerekli değildir, çünkü tek başına bir WordPress geliştiricisi olsanız bile faydaları kapsamlıdır.

Bir Pressidium müşterisiyseniz, dağıtım botu gibi harici bir hizmet kullanarak deponuzu SFTP aracılığıyla hesabınızla entegre edebilirsiniz. Alternatif olarak, dosyalarınızı hesabınıza aktarmak için SFTP'yi kullanabilirsiniz, çünkü bu en kolay ve en basit yöntemdir. Ayrıca birden çok SFTP kullanıcısı oluşturabilir ve bunları belirli web sitelerine ve ortamlara atayabilirsiniz. Bununla birlikte, web siteniz için bir hazırlama ortamına sahip olmak, geliştirme ve dağıtım sürecinizin daha akıcı olmasını ve üretim web sitenizin istenmeyen değişikliklerden korunmasını sağlar. Örneğin, web siteniz için hazırlamayı etkinleştirdikten sonra, üretimden bir kopya alabilir ve ardından geliştiriciniz için yalnızca hazırlama ortamında erişimi olan bir SFTP hesabı oluşturabilirsiniz.

DevOps hareketinin BT ortamlarına getirdiği değişikliklerden biri, birden çok ortamdan geçen basitleştirilmiş bir geliştirme hattı oluşturmaktır. Bir Sürekli Teslimat disiplini benimsemek ve yazılım değişikliklerinin aşamalı olarak ve sık sık yapılması, daha hızlı dağıtım döngüleri ve daha az hata ile sonuçlanır. Artık uygulamanızın farklı sürümleriyle ZIP arşivleri tutmanıza gerek yok. Bu şekilde kolayca izini kaybedebilir ve üretim sistemlerinize zarar verebilecek yanlış bir dizi değişiklik uygulayabilirsiniz. En iyi ihtimalle uygulamanızın düzgün çalışmamasına ve en kötü ihtimalle güvenlik sorunlarına yol açabilecek, dosya izinlerinin bozulmasıyla ilgili sorunlar yaşama tehlikesi de vardı.

sonsöz

Bir WordPress geliştiricisi olarak boş zamanınızın oldukça sınırlı olduğunu biliyoruz. Bu nedenle, aşırı bilgi yüklemesi gerçek olduğundan ve yalnızca WordPress geliştiricilerini değil tüm bilgi çalışanlarını etkilediği için her şeyi tek bir belgede birleştirdik. Başlangıçta amacımızın öncelikle yararlı bilgiler sağlamak ve ikinci olarak mevcut WordPress literatüründe yeterince temsil edilmediğini düşündüğümüz konuları ele almak olduğundan bahsetmiştik. WordPress geliştiricisi olmak bir şeydir, alakalı kalmak ve rekabetçi olmak başka bir şeydir . Bunu yapmak için, bir disiplin olarak yazılım mühendisliği hakkında çok yönlü bir bakış açısına sahip olmanız ve uzun vadede kariyerinize hizmet edecek iyi alışkanlıklar, metodolojiler ve teknikler edinmeniz gerekir.