WordPress eklentilerini nasıl yaparız: Fikirlerden Çıkarmaya
Araştırma ve beyin fırtınası açıkça bir fikirle başlar. Takımdaki biri (genellikle Brad) yeni ürünlere fikir verecek ve bunları kişisel Trello panomuza ekleyecektir. Bazen bu kişisel deneyimlerden, bazen müşterilerden duyduğumuz şeylerden veya sadece piyasada gördüğümüz ihtiyaçlardan kaynaklanır. Bir fikrimiz olduğunda, hepimiz bunu düşüneceğiz. Genellikle bunu şirket geri çekilmesinde yapıyoruz, çünkü yeni ürünleri doğrudan beyin fırtınası yapabiliyoruz çok yardımcı olabilir. Bunun yapmak istediğimiz bir şey olduğundan emin olduktan sonra, bunun insanların satın alacağı bir ürün olup olmadığını belirlemek için araştırma yapacağız. Bir anket yapacağız, potansiyel rakipleri inceleyeceğiz ve eklentilerin veya ürünlerin genel ilgisini ölçmeye çalışacağız.
Sonra potansiyel özelliklerin beyin fırtınasına geçiyoruz. Bu muhtemelen sürecin en önemli kısmıdır, çünkü bu noktada hangi özelliklerin dahil edileceğine ve ne zaman ve tüm yönü alacağımıza karar veriyoruz. Birkaç toplantı düzenleyerek ve Google Drive’daki bir belgede işbirliği yaparak başlayacağız. Bu, herkesin giriş sağlamasını ve ürünü birkaç aşamaya ayırmasını kolaylaştırır. Eklentimiz (şimdi yayınlanmıştır), WP boşaltma SES durumunda, 1.0 halkın sürümünde olması gereken her şeye karar veriyoruz ve diğer özelliklerimiz Eklemek istiyorum. Bu, hangi işin yapılması gerektiğini (ve ne zaman) güçlendirmeye ve kapsam sürünme olasılığından kaçınmaya yardımcı olur. Çerçeve Görüntüsü Sürümün ilk kapsamını kabul ettikten sonra, Wire Frame kullanıcı arayüzünü görselleştirmeye yardımcı olmak için Balsamiq bulutunu kullanırız. Basit çerçeve görüntülerinin daha hızlı çözülebileceğini bulduk ve Photoshop’ta geçmişte yaptığı gibi yüksek maketler yapmak için Brad’e ihtiyacımız yok.
Çerçeve çizimleri yaparken, genel düzenden işlevselliğe ve hatta kullanılacak özel kopyalara kadar her şeyi dahil ediyoruz. Bu şekilde harika bir metin yazarı olma veya eklentiler geliştirirken yeni çözümler bulma konusunda endişelenmemize gerek yok. Sonra, çerçeve görüntü biraz daha pürüzsüz olduktan sonra, incelemek için açtık. Fark ettiğimiz bir şey, Balsamiq hakkındaki yorumların biraz kafa karıştırıcı olabileceğidir, bu nedenle çerçeve görüntülerini Google Drive’a dışa aktarıyoruz. Google Drive’da bulunduktan sonra, tüm ekibimiz Mockup’ın belirli bölümlerini girip vurgulayabilir ve kafa karıştırıcı ve değiştirilmesi gereken herhangi bir şey hakkında yorum yapabilir. Birkaç tur yorumdan sonra ve herhangi bir geri bildirime dayalı mockup’u güncelleyebilir. Sonunda gerçek eklenti üzerinde çalışmaya başlama zamanı. Her eklentinin eklentisini geliştirmek biraz farklıdır, ancak doğrudan tüm eklentilerimize hazırladığımız bazı şeyler vardır:
Sass’ı CSS’ye derlemek ve JS’yi küçültecek bir şey (homurdanma, yudum veya webpack gibi)
Otomatik yükleyici
Sürüm için eklentileri derlemek için bir komut dosyası oluşturun
Bunu ilk yerde olması gelecekte her şeyi düzenli tutmaya yardımcı olur. Ayrıca, UI öğesini tutarlı tutan ve başlangıç çerçevesinden ayrı olarak herhangi bir maket yapma ihtiyacını ortadan kaldıran tüm eklentilerimiz için genel bir stil kılavuzumuz var. Eklenti kodu yazarken, iki kişilik bir ekipte çalışıyoruz. Bu yöntem, bir projeye birçok geliştiriciyi atarak gelen karışıklık ve ayak izleri olmadan kodu hızlı bir şekilde yazmamıza ve gözden geçirmemize olanak tanır.
Şube gitflow yaklaşımına dayanan oldukça standart bir GitHub iş akışımız var – ana dalımız en son sürümleri ifade ederken, yeni özellikler veya hata onarımı oluşturmak için şube özellikleri geliştiririz. Özellikler veya onarımlar tamamlandıktan sonra, inceleme tarafından otomatik olarak incelenen bir gerilme isteği yaparız ve testimiz Travis’te çalıştırılır. Otomatik inceleme ve test tamamlandıktan sonra, ekipteki diğer geliştiriciler kodu manuel olarak gözden geçirecek ve yerel kurulumda test edecektir. Her şeyin yolunda olduğunu varsayarsak, PR gelişmiş olarak birleştirilir. Değilse, gözlemciler geliştiriciye geri ödev verir ve geliştirici gerekli ayarlamaları yapar. Temel özellikler yazdıktan sonra gözden geçirme ve test etme, incelemenin diğer rotasyonunun zamanı geldi. Geleneksel olarak bir ürünün her ana özelliğini kapsayan bir elektronik tablo yaptık:
Bununla birlikte, bu zaman alıcı bir süreçtir, çünkü üç ekip üyesi bir sitede, multisitus subdomain ve multisitus subdominal ağlarda sayfa çalıştıracağı için. Bu testi, başlangıçta daha fazla zaman alan ancak uzun vadede çok zaman üretecek olan otomatik gelir testi ile değiştirmeye başladık. Şimdi test sürecimiz çok daha hızlı ve çok daha havalı görünüyor:
Tüm özellikler tamamlandıktan ve iyice test edildikten sonra, son olarak eklentiyi serbest bırakma zamanı. Eklentiye bağlı olarak, önce beta olarak serbest bırakabiliriz veya doğrudan üretime serbest bırakabiliriz. Sürüm hakkında bir blog yazısı yazıyoruz, GitHub’da bir sürüm dalı oluşturuyoruz ve eklentiyi serbest bırakmak için daha önce belirtilen komut dosyası yapısını kullanıyoruz. Bu ücretsiz bir eklenti ise, Travis’i kullanarak wordpress.org’a otomatik bir uygulama bile hazırlayabiliriz. Bira içme zamanı! Sonuç Yeni ürünler oluşturmak için birçok çalışma yapılır, ancak şu anda yaptığımız süreci gerçekten seviyorum. Beyin fırtınası oturumu sırasında ve çerçeve görüntüsünde daha iyi ayrıntıları sıralamak, genellikle daha sonra ortaya çıkan rastgele soruları ve kapsam sürünmelerini ortadan kaldırmaya yardımcı olur. Bu nedenle, ürünü yapmak çok daha hızlı çalışıyor gibi görünüyor ve çok stresli değil. Yeni ürünler yaparken aynı şeyi yaşıyor musunuz, yoksa geliştirebileceğimiz bir şey var mı? Bize yorumlarda söyleyin.
