Ekibimiz Daha İyi Geliştiriciler Olmak İçin Birbirlerini Nasıl Zorlar?

Delicious Brains'de çalışmaya başladığımdan beri, görünüşe göre sürekli olarak işe alım yapıyoruz. Muhtemel yeni işe alımlar, ekiple birlikte ürünlerimiz üzerinde çalıştıkları birkaç haftalık deneme sürecinden geçer. Dahili wiki'mizde, kodlama standartları ve GitHub iş akışı gibi yeni geliştiricilere yönelik beklentilerimizi belirten birkaç kılavuzumuz var, ancak Xdebug hakkında yakın zamanda yapılan bir konuşma, ekip olarak minimum bir set hakkında daha açık olmamız gerekip gerekmediğini düşünmeme neden oldu. geliştiriciler için gereksinimlerin – hem yeni hem de mevcut.

Xdebug'un Gücü

Jeff ve yargılanan yeni bir adam, izini sürmesi zor bir meseleyi araştırıyorlardı. Slack kanalına bağlandım: “xdebug?”. Jeff'in yanıtı som altın oldu:

Kimse xdebug kullanmayı bilmiyor, Lain

'Lain', sans-serif yazı tipleri kullanıldığında ismimin (Iain) büyük harfle yazıldığını pek anlayamayan insanların e-posta destek takma adımdır. TÜM beni rahatsız etmiyor. Gülmeyi bıraktıktan sonra, bunun temeline inmem gerekiyordu – herkesin Xdebug kullandığını sanıyordum?! Hatta daha önce blogda yazmıştım!

Bunun gerçekten kurmanız gerektiğini bildiğiniz şeylerden biri olduğu ortaya çıktı, ancak bunu yapmak zor ve sorun yaşarsanız kolayca unutuluyor. Dürüst olmak gerekirse, 2013'te PhpStorm'u ilk kullanmaya başladığımda eski bir iş arkadaşıma ayarlatmıştım (teşekkürler Matt) ve denemek yerine kurulumun yapılması ve faydaların hızlı bir şekilde gözden geçirilmesi paha biçilmezdi. kurulumu tek başına hackleyin.

Sanki gökyüzündeki hayali bir Xdebug-Signal'e yanıt veriyormuşum gibi, kurulum sorunlarını çözmek için hemen Jeff ve Matt ile bir Skype görüşmesine atladım. 10 dakikalık gözden geçirmeden sonra kuruldular ve dönüştürüldüler. Artık error_log( print_r( …, 1) ); !

Bu, Xdebug kullanan herkes kod sorunlarını ayıklamak için tamamen aynı şeyleri yaptığından, herhangi birinin mevcut yöntemlerine yönelik bir eleştiri olarak tasarlanmamıştır. Xdebug ile ilgili olan şey, onsuz nasıl hata ayıkladığınızı hayal edemezsiniz ve hayal etmek istemezsiniz. Alabileceğiniz veya bırakabileceğiniz parlak, yeni bir geliştirici dikkat dağıtma aracı değil. Sass'ı kullanmak istemiyor musunuz? CSS olduğu gibi harika. MAMP'tan memnun musunuz? Vagrant için endişelenme. Ancak, Xdebug o kadar güçlüdür ki, yalnızca hata ayıklamak için zamandan tasarruf etmenizi sağlamakla kalmaz, aynı zamanda günlüğe kaydetme/yazdırma işleminin yapamayacağı şeyleri yapar. Bizimki kadar karmaşık eklentilerde, kendimizi iş için en iyi araçlarla donatmamız çok önemlidir.

Sadece Xdebug'u etkinleştirmekten ve günlük dosyalarınızda büyük bir yığın izi görmekten bahsetmiyorum, aynı zamanda kod yürütmeyi kırma ve koda geçme, değişkenleri ve globalleri inceleme ve ifadeleri değerlendirme yeteneğinden de bahsediyorum. Muhtemelen günde bir kez ne kadar güçlü olduğundan bahsettiğim gibi, takımda PhpStorm'u biraz fazla sevdiğime dair uzun süredir devam eden bir şaka var:

Çoğu zaman fanatik müjdecilikle sınırda olduğumu kabul ediyorum, ancak Xdebug'un PhpStorm'a entegrasyonu harika. Bu hızlı videoyu yeniden yayınlamak için yeterince harika:

Tabii ki Xdebug, Sublime gibi diğer editörler ve IDE'lerle entegre olur, ancak PhpStorm'a eklenen diğer tüm özelliklerle, gerçekten PHP ve WordPress geliştiricileri için en iyi seçeneklerden biridir.

PhpStorm ile Xdebug kurulumunu almak için bazı harika kaynaklar:

• https://www.jetbrains.com/help/phpstorm/2016.1/configuring-xdebug.html
• http://manovotny.com/setup-phpstorm-xdebug-mamp-debugging/
• http://www.sitepoint.com/install-xdebug-phpstorm-vagrant/

Kod İncelemeleri

Kod, git depolarımıza her gönderildiğinde, her zaman daha sonra gözden geçirilebilen, değiştirilebilen ve ardından develop dalıyla birleştirilebilen bir özellik/düzeltme dalı biçimindedir. Ürünlerimizin geliştirilmesi için Git Flow tekniğini kullanıyoruz.

Kod incelemeleri, deneme aşamasındaki geliştiricilere ve hatta ekibin uzun süredir üyelerine acımasız ve aşırı kritik görünebilir. Bu eleştiriler iyi niyetten geliyor: standartlarımızı yüksek tutmak ve geliştiriciler olarak birbirimizi zorlamak. Bunlar asla kişisel eleştiriler değil, açık ekip kültürümüzün doğasında bulunan yapıcı ve yardımcı bilgilerdir. Size incelemelerin odaklandığı birkaç şeyden bahsedeyim.

Kodlama Standartları

Wiki belgelerimizden biri, WordPress standartlarına oldukça yakın olan kodlama standartlarımıza odaklanmıştır. Kodlama standartlarına bağlılık, yeni kodda aradığımız şeylerden biridir, ancak bu, tüm eklenti kodlarımızın temiz ve düzenli olduğu anlamına gelmez. Genellikle, yalnızca bir taahhüt sırasında ona dokunursak eski kodu toplamaya yaklaşırız ve her zaman yeni kodun standardı karşıladığından emin oluruz. Bu şekilde eski kodumuz bile her seferinde bir işlev olmak üzere kademeli olarak iyileşir.

Kodun diğer alanlarını geliştirirken de aynı yaklaşımı izliyoruz. Mevcut bir yöntem üzerinde çalışıyorsanız ve eksik veya eksik bir PHP DocBlock'u varsa, doldurulması gerekir. Aynı şey yeniden düzenleme için de geçerli. Üzerinde çalıştığınız bir değişikliğin parçası olan mevcut kod üzerindeki küçük refactor'lar, tamamen test edildikleri sürece harikadır. Büyük yeniden düzenleyiciler genellikle ayrı, özel bir GitHub sorunuyla ele alınır.

Kod Kalitesi

Kod kalitemizi en üst seviyede tutmak için bir dizi araç kullanıyoruz. Scrutinizer, her basıldığında PHP kodumuzu sürekli olarak kontrol etmede harikadır. Bazen biraz özel ve tuhaf olabilir, ancak sonuçta faydalı bir kaynaktır.

Depolarımız Grunt'u bir görev yürütücüsü olarak kullanıyor ve JavaScript kodumuzu kontrol etmek için JSHint ve JSCS'den yararlanıyoruz.

Test yapmak

Birim testi, artık sürecimize tamamen entegre edilmiştir ve tüm genel yöntemler ve test edilebilir kodun, kodu inceleme için gönderirken karşılık gelen bir birim testine sahip olması gerekir. Aynı şey, testleri eksik olan eski kod üzerinde çalışırken de geçerlidir. Tabii ki, TravisCI çalıştığında testlerin de geçmesi gerekiyor!

İşlevsellik ve kabul testleri söz konusu olduğunda, henüz orada değiliz, ancak gelecekte eklemeyi düşünüyoruz.

Asgari Gereklilik

'Xdebug bölümünün' bir sonucu olarak, geliştirme süreci için büyük bir kazanç olduğu için herkesin hazır ve rahat olmasını sağladık. Henüz denemediyseniz veya geçmişte sorun yaşadıysanız, umarım Xdebug kullanmayı düşünürsünüz – hayal kırıklığına uğramayacaksınız.

Xdebug, tercih edilen bir editör ( öksürük , PhpStorm) ve kod inceleme standartlarımızla birlikte, geliştirme için iyi bir yerde olduğumuzu hissediyorum, ancak elbette iyileştirme için her zaman yer var, bu yüzden birbirimizi zorlamaya devam etmeliyiz. her gün kullandığımız, henüz benimsemediğimiz araçları sorgulamak ve birbirimizin kodunu eleştirmek. Bu, bir geliştirici olarak başarılı olacağınız türden bir ortama benziyor mu? İşe alıyoruz.