Büyük bir dosyayı yeniden düzenlemeyi ele almanın en iyi yolu nedir?

Şu anda ne yazık ki, her zaman takip edilmeyen yazılım kalitesi kurallarının bulunduğu bazı dosyalara sahip daha büyük bir proje üzerinde çalışıyorum. Bu, açıkça çok sayıda farklı işlevsellik içeren büyük dosyaları (2000-4000 satırları okuyun) içerir.

Şimdi bu büyük dosyaları yeniden küçük dosyalara dönüştürmek istiyorum. Mesele şu ki, çok büyük olduklarından, farklı dallardaki birden fazla kişi (ben dahil) bu dosyalar üzerinde çalışıyor. Bu yüzden, gelişmekte ve refraktörden gerçekten dallanamıyorum, çünkü bu refraktörleri diğer insanların değişiklikleriyle birleştirmek zorlaşacak.

Elbette herkesin dosyaları geliştirmek, yeniden "dondurmak" (örneğin, artık kimsenin düzenlemesine izin vermemek), refactor ve sonra "unfreeze" işlemlerini gerçekleştirmesini talep edebiliriz. Ancak bu da pek iyi değil, çünkü bu, yeniden yapılandırma işlemi yapılıncaya kadar herkesin temel olarak bu dosyalar üzerinde çalışmalarını durdurmasını gerektirecektir.

Öyleyse refactor yapmanın, başkasının çalışmayı bırakmasını (uzun süre) veya özellik dallarını geliştirmek için geri birleştirmelerini istemiyor musunuz?

Bunun sosyal bir sorun kadar teknik olmadığını doğru bir şekilde anladınız: aşırı birleştirme çatışmalarından kaçınmak istiyorsanız, ekibin bu çatışmaları önleyecek şekilde işbirliği yapması gerekiyor.

Bu, Git ile ilgili daha büyük bir sorunun bir parçasıdır, bu dallanma çok kolaydır, ancak birleşme hala çok çaba gerektirebilir. Geliştirme ekipleri çok sayıda şube açmaya meyillidir ve daha sonra muhtemelen birleştirilmesinin zor olduğunu, muhtemelen bağlamını anlamadan Git Akışını taklit etmeye çalıştıkları için şaşırırlar.

Hızlı ve kolay birleşmelerin genel kuralı, büyüklükteki farklılıkların birikmesini önlemektir, özellikle dalların çok kısa ömürlü olması gerekir (saat veya gün, ay değil). Değişikliklerini hızlı bir şekilde entegre edebilen bir geliştirme ekibi daha az birleştirme çatışmaları görecektir. Bazı kodlar henüz üretime hazır değilse, onu entegre etmek ancak bir özellik bayrağıyla devre dışı bırakmak mümkün olabilir. Kod ana şubenize entegre edilir edilmez, yapmaya çalıştığınız yeniden düzenleme türüne erişilebilir olur.

Acil probleminiz için bu çok fazla olabilir. Ancak meslektaşlarınızdan bu dosyayı etkileyen değişiklikleri hafta sonuna kadar birleştirmelerini istemek mümkün olabilir, böylece yeniden düzenlemeyi gerçekleştirebilirsiniz. Daha fazla beklerlerse, birleşme çatışmalarının kendileri ile uğraşmak zorunda kalacaklar. Bu imkansız değil, sadece önlenebilir bir iş.

Ayrıca, büyük bağımlı kod parçalarını kırmayı önlemek ve yalnızca API uyumlu değişiklikler yapmak isteyebilirsiniz. Örneğin, bazı işlevleri ayrı bir modüle çıkarmak istiyorsanız:

1. İşlevselliği ayrı bir modüle çıkartın.
2. Çağrıları yeni API'ye iletmek için eski işlevleri değiştirin.
3. Zamanla, yeni API'ye bağlantı noktasına bağlı kod.
4. Son olarak, eski fonksiyonları silebilirsiniz.
5. (Bir sonraki fonksiyonellik grubu için tekrarlayın)

Bu çok adımlı işlem birçok birleştirme çakışmasını önleyebilir. Özellikle, yalnızca çıkardığınız işlevselliği başka biri de değiştiriyorsa çatışmalar olacaktır. Bu yaklaşımın maliyeti, her şeyi bir seferde değiştirmekten çok daha yavaş olması ve geçici olarak iki yinelenen API'niz olması. Acil bir şey bu yeniden ateşlemeyi kesene kadar, bu kadar kötü değil, çoğaltma unutulmuş ya da depremitize ve bir demet teknoloji borcu ile sona erecek.

Ancak sonuçta, herhangi bir çözüm ekibinizle koordineli bir şekilde çalışmanızı gerektirecektir.

Yeniden düzenlemeyi daha küçük adımlarla yapın. Diyelim ki büyük dosyanızın adı var Foo:

1. Yeni bir boş dosya ekleyin Barve "trunk" olarak kabul edin.

2. FooÜzerine taşınabilecek kodun küçük bir bölümünü bulun Bar. Taşıma işlemini uygulayın, bagajdan güncelleyin, kodu oluşturun ve test edin ve "bagaja" bağlı kalın.

3. 2. adımı tekrarlayın kadar Foove Bareşit büyüklüğe sahip (veya tercih boyutu ne olursa olsun)

Bu şekilde, ekip arkadaşlarınız dallarını bagajdan güncellediklerinde, değişikliklerinizi "küçük porsiyonlarda" alırlar ve tek tek birleştirebilirler; bu, tek bir adımda tam bir bölünmeyi birleştirmek zorunda kalmaktan çok daha kolaydır. Aynı şey, 2. adımda bir birleştirme çatışması olduğunda da geçerlidir, çünkü aralarında başka birisinin bagajını güncelledi.

Bu, birleştirme çakışmalarını veya manuel olarak çözülme gereksinimini ortadan kaldırmaz, ancak her çatışmayı daha yönetilebilir olan küçük bir kod alanıyla sınırlar.

Ve elbette - takımdaki yenilemeyi iletin. Arkadaşlarınıza ne yaptığınızı söyleyin, böylece belirli bir dosya için neden birleştirme çakışmaları beklemek zorunda olduklarını bilirler.

Dosyayı atomik bir işlem olarak bölmeyi düşünüyorsunuz, ancak yapabileceğiniz ara değişiklikler var. Dosya zamanla yavaş yavaş büyük oldu, zamanla yavaş yavaş küçük olabilir.

Uzun zamandır değişmeyecek bir parça seçin ( git blamebu konuda yardımcı olabilir) ve ilk önce ayırın . Bu değişikliği herkesin dallarıyla birleştirin, sonra ayrılacak en kolay kısmı seçin. Belki bir parçayı bölmek bile çok büyük bir adımdır ve önce büyük dosyada yeniden düzenleme yapmanız gerekir.

İnsanlar gelişmek için sık sık tekrar bir araya gelmiyorlarsa, teşvik etmelisiniz, sonra birleştikten sonra, değiştirdikleri parçaları ayırmak için bu fırsatı kullanın. Veya ayırma işlemini, istek çekme incelemesinin bir parçası olarak yapmalarını isteyin.

Fikir yavaş yavaş hedefinize doğru hareket etmektir. İlerlemenin yavaş olduğu hissine kapılacaksınız, ancak aniden kodunuzun çok daha iyi olduğunu fark edeceksiniz. Okyanus gemisini açmak çok uzun sürüyor.

Bu soruna normalden farklı bir çözüm önereceğim.

Bunu bir takım kodu etkinliği olarak kullanın. Herkesin kodunu kontrol edebilecek kodlarını kontrol ettirin, daha sonra hala dosyada çalışan başkalarına yardım ettirin. İlgili herkes kodunu kontrol ettikten sonra, projektörü olan bir konferans salonu bulun ve bir şeyleri etrafta ve yeni dosyalara taşımaya başlamak için birlikte çalışın.

Buna belirli bir süre ayarlamak isteyebilirsiniz, böylece sonuçta görüşünüzü sonlandırmayan bir hafta boyunca tartışmaya değmez. Bunun yerine, her şey olması gerektiği gibi görünen şeyleri bulana kadar, haftada 1-2 saatlik bir etkinlik bile olabilir. Belki de dosyayı yeniden gözden geçirmek için sadece 1-2 saat gerekir. Muhtemelen deneyene kadar bilemezsin.

Bu, refactoring ile aynı sayfada bulunan herkesin yararınadır (punta amaçlanmamıştır), ancak gerektiğinde korumak için olası yöntem gruplandırmaları hakkında başkalarından girdi almanın yanı sıra, hataları önlemenize de yardımcı olabilir.

Bu şekilde yapmak, böyle bir şey yaparsanız, yerleşik bir kod incelemesine sahip olarak kabul edilebilir. Bu, uygun miktardaki geliştiricinin, kodunuzu teslim aldığınızda ve incelemeleri için hazır bulduğunuz anda imzalamasını sağlar. Yine de kaçırdığınız herhangi bir şey için kodu kontrol etmelerini isteyebilirsiniz, ancak inceleme işleminin daha kısa olmasını sağlamak için uzun bir yol gerekir.

Bu, işin kolayca gerçekleşmesini sağlayacak şekilde dağıtılmadığından, tüm durumlarda, ekiplerde veya şirketlerde çalışmayabilir. Ayrıca (yanlış) dev zamanın yanlış kullanımı olarak da yorumlanabilir. Bu grup kodu yöneticiden ve yeniden düzenleyicinin kendisinden katılım gerektirir.

Bu fikri yöneticinize satmanıza yardımcı olmak için, kod inceleme bitinden ve işin baştan nerede olduğunu bilen herkesden bahsedin. Dev'lerin zaman kaybettiklerini önlemek, bir dizi yeni dosyayı ararken kaçınmaya değer olabilir. Ayrıca, devlerin işlerin bitip bitmediği ya da "tamamen eksik" olduğu hakkında PO'ların önlenmesi genellikle iyi bir şeydir. (Eriyik ne kadar az olursa, IMO da o kadar iyi olur.)

Bir dosyayı bu şekilde yeniden ele geçirdikten sonra, başarılı ve yararlı olsaydı, daha fazla sayıda refaktör için daha kolay onay alabilirsiniz.

Yine de refactor'unuzu yapmaya karar veriyorsunuz, iyi şanslar!

Bu sorunu çözmek, diğer ekiplerden katılım gerektirir çünkü paylaşılan bir kaynağı (kodun kendisi) değiştirmeye çalışıyorsunuzdur. Söyleniyor, insanları rahatsız etmeden büyük monolitik dosyalara sahip olmanın "uzaklaşmasının" bir yolu olduğunu düşünüyorum.

Tek tek dosyaların boyutlarına ek olarak, büyük dosyaların sayısı kontrol edilemez bir şekilde artmadıkça, tüm büyük dosyaları bir kerede hedeflememeyi de tavsiye ederim .

Bu gibi büyük dosyaların yeniden düzenlenmesi genellikle beklenmeyen sorunlara neden olur. İlk adım, büyük dosyaların o anda ana veya geliştirme dallarında bulunanların ötesinde ek işlevler toplamasını engellemektir .

Bunu yapmanın en iyi yolunun varsayılan olarak büyük dosyalara belirli eklemeleri engelleyen taahhüt kancaları ile olduğunu düşünüyorum, ancak işlem mesajında ​​olduğu gibi sihirli bir yorumla reddedilebilir @bigfileok. Politikayı acısız ama izlenebilir bir şekilde geçersiz kılmak çok önemlidir. İdeal olarak, işleme kancasını yerel olarak çalıştırabilmeniz ve hata mesajının kendisinde bu belirli hatayı nasıl geçersiz kılacağınız anlatılmalıdır . Ayrıca, bu sadece benim tercihimdir, ancak kabul edilmeyen büyülü yorumlar veya taahhüt mesajında gerçekten ateşlemeyen hataları baskılayan büyülü yorumlar , bir tevdi zamanı uyarısı veya hatası olmalıdır; ihtiyaçları olsun olmasın.

Taahhüt kancası yeni sınıfları kontrol edebilir veya başka statik analizler yapabilir (geçici veya değil). Ayrıca, şu anki dosyadan% 10 daha büyük bir satır veya karakter sayısı seçebilir ve büyük dosyanın yeni sınırın ötesinde büyüyemeyeceğini söyleyebilirsiniz. Ayrıca, büyük dosyayı büyüten bireysel işleri çok fazla satır veya çok fazla karakter veya w / e reddedebilirsiniz.

Büyük dosya yeni işlevsellik biriktirmeyi bıraktığında, bir defada bir şeyleri yeniden değerlendirebilir (ve yeniden oluşturulmasını engellemek için aynı zamanda sabitleme kancalarının uyguladığı eşikleri azaltabilirsiniz).

Sonunda, büyük dosyalar, işleme kancalarının tamamen çıkarılabileceği kadar küçük olacaktır.

Toplantı saatine kadar bekleyin. Dosyayı bölün, kesin ve usta birleştirmek.

Diğer insanlar da değişiklikleri, sabah saatlerinde diğer dallardaki gibi özellik dallarına çekmek zorunda kalacaklar.