Yeniden düzenleme nedeniyle birleştirme çakışmalarını çözme


13

Son zamanlarda genel olarak yeniden düzenlemenin nasıl ele alınacağı üzerine bir tartışmaya girdim (bu ilginç bir konudur). Sonunda şu soru gündeme geldi:

Birisi aynı kod parçası için bir özellik üzerinde çalışırken, birinin kodun bir kısmını yeniden düzenleme yaptığı için oluşan çatışmalar nasıl ele alınır?

Temel olarak, bununla etkili bir şekilde nasıl başa çıkılacağına dair hiçbir fikrim yok. Bununla ilgili izlenmesi gereken en iyi uygulamalar var mı? Tonlarca eski kodu olan bir sistem için bunun nasıl ele alınması gerektiği konusunda bir fark var mı?


Benzer bir sorum var, ancak farklı gereksinimlerle, başka bir soru ekledim. programmers.stackexchange.com/questions/109229/…
Roger CS Wernersson

Yanıtlar:


9

İyi soru. Aklıma gelen en iyi strateji:

önleme

Sürekli entegrasyon ve sık sık küçük yeniden düzenlemeler yapmanın bir kombinasyonu (nadiren büyük yeniden düzenlemeler yerine), bu tür çatışmaların maliyetini ve sıklığını en aza indirmek için uzun bir yol kat edecektir.


3

Sorunuzu cevaplamayı düşünüyorum, önce çatışmaların neden olduğunu ve birleşmenin gerçek anlamı ve süreci nedir?

Çatışmalar yalnızca iki veya daha fazla geliştirici aynı dosya üzerinde aynı anda çalışıyorsa ve her ikisi de check-in yapmaya çalıştığında ortaya çıkar. İlk geliştirici elbette herhangi bir çakışma almayacaktır. Ama ikincisi (üçüncü, dördüncü vb.) Çatışmalar yaşayacaktı. Neden, çünkü sunucuda varolan koddan kısmen veya tamamen farklı bazı kodlar var.

Bu doğada ikinci geliştiricinin ilk geliştiriciden farklı bir şey olduğu anlamına gelir. Bu fark kullanmak gibi, stil değişebilir new UserManager().GetUserName()yerine UserManager userManager = new UserManager(); userManager.GetUserName();her iki geliştiriciler onu geliştirmek için kodu yeniden nasıl farklı fikirleri vardı demek olduğunu Bahsettiğiniz düzeyine kadar.

Öte yandan birleştirme, geliştiricilerin kodlarını çakışmaları dikkate almadan check-in yapabileceği anlamına gelmez. Bunlar gerektiği ve gereken o çelişkilere çözüm. Çakışmalar önemli değilse, check-in yapabilir ve önceki kodu geçersiz kılabilir. Ancak tamamen farklı bir şey gördüklerinde, önceki geliştiriciyi aramalı ve onunla konuşmalıdırlar, böylece her ikisi de en iyi çözümü kontrol etmek için birlikte koordine edilebilirler.

Örneğin, iki geliştiriciden çevrimiçi ödeme kütüphanesini geliştirmelerini ve işlerinin çakışmasını istiyorsanız , bu en azından bazı yerlerde 2 farklı çözüm olduğu anlamına gelir. Bu nedenle, bu çözümlerden biri hakkında konuşulmalı ve daha iyi bir çözüm olarak kabul edilmelidir.

Teorik olmaktan daha gerçek olma eğiliminde olmamız gerektiğinden, bu koşulları önlemeye katılmıyorum . Bazen bir adam CSS'de gerçekten iyi, bir diğeri ASP.NET Markup'ta gerçekten iyidir. Ancak, her ikisi de giriş sayfası üzerinde çalışacak şekilde çalışması gerektiğinde çakışabilir. Yani, gerçek (ideal değil) düşünürsek, bu fenomenin (çatışma) birçok kez gerçekleştiğini görebiliriz.

Bahsetmek istediğim bir diğer nokta da, check-in işleminizde size yardımcı olacak araçlar kullanmak. Bu araçlar genellikle sunucu kodu ve geliştirici kodu arasındaki farkı görselleştirir ve hangi parçanın iade edileceğini belirlemede çok yardımcı olur.


3

Etkin görev yönetimi yoksa, çakışmalarınız olur.

Bununla birlikte, günlük bir stand-up toplantınız veya yöneticiniz varsa, bu sorunla karşılaşmanız olası değildir.

Ya günlük bir stand ile konuşun ya da bir yöneticiyle konuşun.

Bu konuşmakla önemsiz bir şekilde önlenir.


+1. Bazı geliştiriciler yöneticileri bir engel olarak görür. Ancak yöneticiler , diğer insanların çalışmasını sağlamak için gerçekten varlar ve bu, yardımcı olabilecekleri sorunun mükemmel bir örneğidir.
MarkJ

@MarkJ: Çatışmaları birleştirmenin önünde engel olan bir yönetici kötü bir şey değil. Mükemmel nokta.
S.Lott

+1 Cevabıma böyle bir şey eklemek üzereydim ama sen çivilenmiştin. Aynı bölgede başka birinin çalıştığını bildirmek için bir çatışma kullanıyorsanız, oyunda çok geç öğreneceksiniz ve ardından bununla başa çıkmanız gerekecek. Görev yönetimi ve iletişim, aynı alanda çalışan geliştiricilerin en başından beri birlikte çalışmasını sağlayabilir .
Gyan aka Gary Buyn

1

Belirli bir özelliği geliştirmek için ayrı bir ortak şubeye sahip olun, sık sık birleştirin / çekin / itin - hepsi bu.

Ve iletişim kurun . Lansman sırasında bile diğer geliştiricilerle kod hakkında konuşun. Kodlama yaparken bile)))


1

Birleştirmenin olabildiğince basit olduğundan emin olun. Yeniden düzenleme genellikle mevcut birçok satırı değiştiren oldukça mekanik bir işlemdir : Değişken bildirimlerini, boşluk değişikliklerini, biçimlendirmeyi, işlem sırasını taşıma. Özellik oluşturma genellikle çok daha yaratıcı bir girişimdir ve genellikle yeni kodun yanı sıra mevcut kodda birkaç küçük değişiklikle sonuçlanır . Yeniden düzenleme işlemini yapan geliştirici adımları kaydediyorsa (örneğin, normal ifadeler olarak), bunları diğer yoldan ziyade ekstra işlevsellik ile koda uygulamak çok daha kolay olabilir. Buna dayanarak, genel bir kural olarak önce en karmaşık değişikliği, ardından giderek daha basit değişiklikleri uygulamanız gerektiğini söyleyebilirim .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.