Yarım özelliğin uygulanması için doğru yaklaşımı nasıl öğrenirim? [kapalı]

Bir geliştirme ekibine liderlik ediyorum ve ürünümüzü mümkün olduğunca sık yayınlamak istiyorum (Sürekli Teslimat).

Birçok durumda, uygulanması, sürümler arasındaki süreden daha uzun süren bir özellik uygulamalıyız. İnsanların kodlarını günlük olarak yapmasını istiyorum (Sürekli Entegrasyon).

Çoğu zaman yeni bir özellik uygulamak, mevcut özelliğin değiştirilmesini gerektirir ve yeni özellik henüz tamamlanmamış olsa bile, mevcut özelliklerin yine de çalışması gerekir.

Geliştirici doğru yaklaşımı kullanıyorsa, mevcut özellikleri dikkatlice ayarlayabilir ve yukarıdakilerin hepsi sorun değildir.

Ancak gerçekte doğru yaklaşım NEDİR? Kendi programlama uyum zihnim, her bir vaka için ne yapacağımı söylüyor, ancak daha fazla öğrenmem gerekiyor ve okuyabildiğim ve okumak için takım üyelerine başvurabileceğim bazı okuma materyallerine ihtiyacım var. Ya da bu yaklaşımı öğrenmenin doğru yolunu öğrenmek için başka herhangi bir yöntem yapacağız.

İşte soru bu. Ekip üyelerinin yarım özelliğin uygulanması için doğru yaklaşımı öğrenmelerini nasıl sağlarım?

Bununla ilgili stratejileri olduğunu iddia eden kişileri aradım, ancak konuyla ilgili birkaç rastgele düşünce yazan insanlar dışında henüz bulamadım. Belki de doğru arama kelimeleri kullanmıyorum ya da hiç kimse bu konuda yetkili yönergeler yapmamıştır.

Zaten buradaki diğer cevaplardan farklı bir görüş alıyorum. Geliştiricilerden gelen değişiklikleri mümkün olan en kısa sürede entegre etmek ve birleştirilmiş kod karışımını test etmeye devam etmek istediğinizi kabul ediyorum.

Ancak, bu öğleden sonra serbest bırakıldığımız için bu sabah gemi kodu hakkının geliştiğini kabul etmiyorum. Bu hayal kırıklığına uğramış müşteriler için bir reçetedir.

Çözüm, sürüm kontrol ağacınızda dallara sahip olmak ve doğrulanmış deltaları geliştirme dalından serbest bırakma dalına yükseltmek için ayrı bir işleme sahip olmanızdır.

Bu şekilde her iki dünyanın da en iyisini elde edersiniz. Sürekli entegrasyon yapan geliştiricileriniz var ve bunun getirdiği avantajlar, düzenli olarak müşteriye düzenli olarak kod gönderimi yapıyorsunuz ve geliştirici dalında tamamlanmış özellikleri test eden yeni bir süreciniz var ve testi geçtiklerinde onları serbest bırakılan ürünün bir parçası haline getirin .

Bu tür süreçleri iyi destekleyen tanıdığım iki araç var. Geliştirme yapınız basitse, git-flow ile git-flow küçük ve orta ölçekli ekiplerde (belki de 20 geliştirici) iyi çalışan bir dallanma yapısı uygular.

Daha büyük geliştirme ekipleri için veya ürününüzün birden fazla 'dönüşünü' desteklemek için daha karmaşık bir dallanma stratejisine ihtiyaç duyulduğunda, accurrev en iyisidir. Değişiklikleri yönetmekle ilgilenmeyen geliştiriciler, alt versiyondan daha zor olduğundan şikayet edecekler ... ancak karmaşık geliştirme ortamlarını destekliyor.

Burada iki sorun var: biri yarım özellik uygulamak; Diğeri ise sürekli geliştirme sırasında nakliye ürününün çalışmasını sağlamaktır.

Bir özelliğin yarısını uygulama

Güçlü bir kapsayıcı tasarım bu konuda yardımcı olacaktır. Bu, özelliği açıkça tanımlanmış sınırlarıyla (ör. Bitişik kod parçalarına yönelik API'ler, veri yapıları ile ilgili beklentiler) ve uygulanan kodun nasıl ve ne zaman çağrılacağını anlamanıza olanak tanır.

Test, özelliğin diğer bölümleri için kodun alay edilmiş sürümlerini içerebilir; bu, ikinci yarıyı uygulamaya gittiğinizde geçişin düzeltilmesine yardımcı olur.

Nakliye ürününün çalışmasını sağlama

Burada birkaç seçenek var:

1. Gönderilen üründe 'özelliği' kapatın. Kodun üründe olması, kullanıcılara yürütülmesi veya sunulması gerektiği anlamına gelmez. Dezavantajı, kullanıcılarınıza artan bir değer vermeyeceğiniz ve geri bildirim almayacaksınız.
2. Özelliğin kenarlarını kullanıcılarınıza gösterin. Neye sahip olduğunuzu gösterin ve ne olacağına dair bir fikir verin.
3. Kullanıcıların yeni ve eski işlevler arasında geçiş yapmasına izin verin. Bu bazen son kullanıcı için hazır olan iki kod yolunun korunmasını gerektirir.

Son olarak, bu çözümlerden herhangi biriyle ilgili sorun yaşıyorsanız, özelliği doğru sınırlar boyunca bölüp bölmediğinizi düşünün. Eğer şeyleri farklı bir şekilde dilimlediyseniz, parçalara ayırmak daha kolay olur mu?

Ekip üyelerinin yarım özelliğin uygulanması için doğru yaklaşımı öğrenmelerini nasıl sağlarım?

Onlara öğreterek. (Yaa)

Öğrenme yinelemeyi içerecektir: bir şeyi denemek, nasıl çalıştığını görmek ve daha iyi sonuçlar elde etmek için yaklaşımlarını değiştirmek. Bu tür şeyler için, tasarım / kod incelemelerini savunurdum. Yarı özelliğin nasıl tasarlandığını / uygulandığını ve geri bildirimde bulunma fırsatını elde edersiniz. "Bu ve bu işe yaramaz çünkü CI'mızı kıracaklar; XYZ'ye ne dersin?", "Burada iyi iş, bu gerçekten temiz."

İncelemeleri ekip olarak yapmak, herkesin zaten sezgisel olarak bildiklerinizi öğrenmesine yardımcı olacaktır.

Burada size yardımcı olacak en büyük şey, bir kod alanının mümkün olduğunca diğerine müdahale etmemesi için endişelerin iyi bir şekilde ayrılmasıdır.

Bu, Bağımlılık Enjeksiyonunu kullanmanın ve arayüze programlamanın gerçekten yardımcı olduğu bir yerdir, böylece mevcut ISupportingFeature uygulamanıza sitede sahip olabilirsiniz ve daha sonra farklı bir uygulamaya bağlı INewFeature oluşturmanız gerektiğinde, yeni uygulama ve iyi test ve canlı yayınlanmaya hazır olana kadar mevcut olanı üretimde korumak. DI'nizin bir tür yapılandırma sistemi üzerinde çalıştığını varsayarsak, bu sisteminizde paralel olarak aynı koda sahip olmanızı ve her zaman sabit kod kullanmanızı sağlar.

Aslında, bu yapılandırma yaklaşımı Martin Fowler tarafından Özellik Geçişi olarak tanımlanmaktadır .

Tabii ki, sorun sadece tüm kodu her zaman dağıtıyorsanız ortaya çıkar . Bu tam olarak özellik dallarının tasarlandığı senaryo türüdür ve Bay Fowler'ın onlara kaşlarını çattığını kabul etsem de, özellikle de planlı ve düşünceli bir şekilde yaratıldığında ve kullanıldıklarında bunların o kadar kötü olduklarını bilmiyorum- yol boyunca.