Tüm gelişiminiz dallardayken nasıl refactor yapılır?

Şirketimde tüm gelişimimiz (hata düzeltmeleri ve yeni özellikler) ayrı branşlarda yapılıyor. Tamamlandığında, onu o dalda test eden QA'ya gönderiyoruz ve bize yeşil ışığı yaktıklarında, onu ana şubemizle birleştiriyoruz. Bu, bir gün ile bir yıl arasında bir yer alabilir.

Bir dalda yeniden yapılanmayı sıkmaya çalışırsak, ne kadar süre "çıkacağını" bilmiyoruz, bu yüzden tekrar birleştirildiğinde birçok çatışmaya neden olabilir.

Örneğin, bir işlevi yeniden adlandırmak istediğimi varsayalım çünkü üzerinde çalıştığım özellik bu işlevi çok fazla kullanıyor ve adının amacına tam olarak uymadığını öğrendim (yine, bu sadece bir örnek). Bu yüzden etrafa gidiyorum ve bu fonksiyonun her kullanımını buluyorum ve hepsini yeni isimlerine göre yeniden adlandırıyorum ve her şey mükemmel çalışıyor, ben de onu KG'ye gönderiyorum.

Bu arada, yeni bir gelişme yaşanıyor ve yeniden adlandırılan işlevim, ana hatlardan ayrılan dalların hiçbirinde mevcut değil. Sorunum yeniden birleştiğinde, hepsi parçalanacak.

Bununla baş etmenin bir yolu var mı?

Yönetimin yalnızca refactor-yalnızca bir sorunu onaylaması gibi değil, bu yüzden diğer işlerle sıkılması gerekiyor. Doğrudan ana üzerinde geliştirilemez, çünkü tüm değişikliklerin QA'dan geçmesi gerekir ve hiç kimse ana önemsiz pislik olmak istemez, böylece biraz gerekli olmayan yeniden düzenleme yapabilir.

Bu ortamda yeniden düzenlemeyi zorlaştırmak için bir araya getirilen çeşitli sorunlar var. Buna karmakarışık teknik olmayan bazı problemler var ("ama bu bir yönetim sorunu ve henüz kazanmadığım bir savaş").

İlk bakılması gereken sorun uzun süredir devam eden şubedir. Bu dallar, geliştiricinin görüşü dışındaki değişiklikleri takip etmekte zorlanıyor. Bunu ele almak için:

• Kod tamamlandığında - bir kez daha verin (isterlerse müşteri desteğinin bakmasına izin verin), ancak çabucak gelişmesi için birleştirin, böylece bağımlı olan diğer değişikliklerin alınabilmesi ve bu çatışmanın erken tanımlanması gerekir süreç içerisinde.
• Bazı nedenlerden dolayı, bir yeniden bağlama işlemi devam ederken bir braşun uzun sürmesi durumunda, değişiklikleri almak ve yeniden toplamak için ahırdan şubeye birleşme iyi bir uygulama olma eğilimindedir. Çoğu zaman bu özellik, özellik dalından sabit dalına birleşme konusundaki çatışmaları ve sürprizleri en aza indirir.
• Tüm dış entegrasyon testlerinin özelliklerde değil bültenlerde yapılması gerekiyor . Bu ortamda özellikler sisteme tam olarak entegre olabilir veya olmayabilir. İzolasyonda özellik üzerinde bir akıl sağlığı kontrolü yapılması mümkün olmakla birlikte, piyasaya sürüldüğünde sorunları tanımlamaz.
• Kod tamamlama zamanından birleşmeye (gelişmesine izin verin - master / stable / release'ten dallanma) en son geliştirme değişikliklerini almama konusunda kendi sorunları vardır) çok uzun olmamalıdır. Ne kadar uzun süre beklerseniz, o kadar fazla bilgi kaybedilir ve kodun diğer kod satırlarıyla bütünleşmesi zorlaşır.

Buna karıştıran bir diğer konu da, yukarıdaki hususlara değindiğim: Şubenin zaman içindeki değişen rolü. Geliştiricilerin taahhüt ettiği bir geliştirme dalı olarak başlar ve daha sonra bir test alanı haline gelir (burada tüm uygulama için anlamlı olabilecek hangi test yapılıyor?). tekrar test edildi?).

Daha kısa bir özellikle, zamanın bitimine başlaması ile yeniden yapılanma işleminin diğer dallar tarafından alınabilmesi daha kolaydır.

Geliştiricileri tüm çevreye ulaşmaya teşvik edin. Sadece kiraz toplama değişiklikleri yol açabilir ... ilginç geliştirici ortamlar diyelim. Vişne toplamanın kullanımları olmasına rağmen, bir dalın içine değişiklik yapmanın varsayılan modu olması endişe verici olabilir.

Yeniden düzenleme, ideal olarak sürekli yapılan bir işlemdir veya sürekli olarak bir aksaklık süresinin olmadığı durumlarda sürekli yapılmaz. Şube, basit bir yeniden düzenleme işlemi yapın, her şeyin hala çalıştığını doğrulamak için ünite testlerini yapın (ünite test edildi, değil mi? Doğru? ) Ve sonra tekrar kararlı hale getirin. Diğer geliştiricilerin, yeniden dalladığınız değişiklikleri kendi şubelerine çekmeleri için bilgileri iletin.

Geliştiricilerin kodun kalitesine sahip olması önemlidir. Özelliklerin yönü dışardan gelirken ve zaman tahsisleri çoğu zaman kendimize ait olmasa da, kod kalitesi gurur duymak ve zaman kazanmak için gerekli olan bir şeydir.

Teknik borçlarla başa çıkmak için zaman ayırma arayışında aşağıdaki soruları yararlı bulabilirsiniz:

• Teknik borç bir özellik mi yoksa bir angarya mı (yoksa bir böcek) olarak mı planlanmalı?
• Yönetimi teknik borçlarla başa çıkmak için nasıl ikna edebilirim?
  • Altındadır bak bağlantılı buna sorular - genellikle değer gidiş ve okuma çekebilecek diğer sorularda çağırılır.

Ayrıca , kod yeniden düzenleme için en fazla çalışmayı gerektiren alanların belirlenmesine yardımcı olabilecek sonar gibi araçlara da bakabilirsiniz. Teknik borç eklentisi kod tabanı zamanla borç birikimi dışarı yardım noktasına kullanılabilecek bir şeydir.

Genellikle , teknik borçlarla ilgilenmek için yatırım getirisinin , geliştirme ekibinin özellikleri ve hata düzeltmeleri için daha hızlı bir geri dönüş süresi olduğunu belirtmek gerekir .

Genellikle akımla “paralel” olarak, yani aynı kod tabanında, ancak çekirdek uygulamadan referans almayan yeniden yapılandırılmış bir sürüm geliştiriyorum. Ve yeni bir çözüm yapıldığında ve test edildiğinde, gerçek yeniden düzenlemeye başlıyorum.

Örnek 1. Var olduğumu varsayalım, işlev, arabirim, modül ya da her neyse öyle olsun. Ve ben onu yeniden yansıtmak istiyorum. Thing2'yi aynı kod tabanında oluşturuyorum, Thing'in yeniden yapılandırılmış hali. Tamamlanıp test edildiğinde, Thing'e referans veren her şeyi Thing2 ile değiştirmeye alıyorum. Genellikle bu adım nispeten az zaman alır.

Gerçek yeniden düzenleme, takımı becermeden eşitleme yapmak için çok zaman alıyorsa, tüm ilgili özellikleri alıyorum ve bunları paralel olarak yeniden düzenliyorum.

Örnek 2. Eski renderin yenilenmiş versiyonu olan yeni render arka uçlarım var. Ancak eski render önyüzüyle uyumlu değil. Bu nedenle, ön cephede refactor gerekir. Ve yine: aynı kod tabanında. Her şey yapıldığında, sadece ön sınıf örneği sınıfını değiştiriyorum, ideal olarak kısa bir görev alacak.

Evet, yinelemeli olarak, her şeyin paralel olarak yapılması gerektiği sonucuna varılabilir . Ancak bu genellikle kod temeli üzerinde çok fazla bağlantı olduğunda veya çok hızlı değişiyorsa gerçekleşir.

Son olarak, yeni kod bütünleştirildiğinde ve iyi çalıştığında, eski özellikler kod tabanından kaldırılabilir ve eski adlar için yeni özellikler yeniden adlandırılabilir.

Genel olarak, fikir paralel olarak yeni özellikler hazırlamak ve bunları küçük bir adımla kullanmaya geçmek.

John Carmack bu (veya en azından benzer) bir yaklaşımı kullanır, belki de blog yazısı daha iyi açıklar: (link)

Gereksinim tarafında olduğu zaman teknik açıdan bir zorluk gibi görünebilir.

Gelişimin farklı branşlarda farklı gereksinimlere yönelik olması asıl zorluktur. Ekibin yöneticileri ve mimarları, farklı İş ihtiyaçlarının birlikte var olmalarını sağlayacak kararlar vermelidir.

ZBB süreci ve Co-Dev, tüm geliştiricilerin ilgili girdileriyle doğru kararlar alındıktan sonra yapıldığında "taviz verir";

_{ZBB, Sıfır tabanlı bütçeleme anlamına gelir . Eş-Dev diyerek, paralel programlamada çalışan birkaç kişiyi kastetmiştim.}

Sorun bana dallarda çok uzun süre çalıştığını gösteriyor. Uyuşmazlıkların maliyeti, herkesin bir dalda kaldığı süre ile üssel olarak artar, bu yüzden çok uzun süren çatışmalarla, yeniden yapılanma yapma şansınız çok azdır.

Sorununuz kullandığınız şube modeli. Bir dalda gelişebilir ve QA için tam ve hazır olduğunda, dal bazen Entegrasyon veya Test olarak adlandırılan bir 'ara bagaja' birleştirilir. Bir sonraki özelliği geliştirdiğinizde, bunun yerine bu ara bagajdan dallanabilirsiniz.

Bu model, farklı şubelerde paralel olarak birden fazla özellik geliştirmenize, bunları KG'ye göndermek için tüm bunları Entegrasyon şubesiyle birleştirmenize ve ayrıca tek bir sürüm bagajını korumanıza izin verir (sertifikalandırdıklarında ana bagaja gelen QA kod kodunu birleştirirsiniz). )

QA’ya gönderilen değişikliklerin büyük değişiklik yapılmadan geçirileceğini varsayıyorsunuz - QA kodu değişikliklerin yarısını kaldırma talimatlarıyla geri dönerse, geri dönmeniz gerekir, ancak bu gerçekleşmezse gerçekleşir gelişiminiz daha yumuşak. Yani, temelde, ana kodunuzun ne olacağından (yani, QA'da kodla birleştirildikten sonra), bugünkü halinden (yani şu anki ana hattan) değil, artık önceki sürümün kod tabanına karşı gelişmeyeceğinden dallar alıyorsunuz. .