İyi / daha iyi kaynak kodu kontrol uygulamaları nasıl uygulanır?


28

Yanlış soruna odaklandığımdan şüpheleniyorum, bu yüzden öncelikle düşündüğüm olası en düşük çözümü sunmadan önce sorunun ne olduğunu düşündüğümü açıklayacağım.

Mevcut Durum:
Şu anda iş arkadaşlarım kod değişikliklerini ancak projenin her yerine yayılan değişikliklerle birlikte büyük parçalarda uzun süre dolaştıktan sonra yapıyorlar. Sanırım bu ilerleme, çünkü uzun zaman önce sadece bazı ağ paylaşımlarına .zip arşivleri koyuyorlardı. Yine de birleşme bir kabustur - ve açıkçası buna yetti. Ayrıca konuşmaktan, açıklamaktan ve dilenmekten bıktım. Bu sadece durmalı - sürekli "kötü adam" olmadan benden.

Benim çözümüm:
Sorunların farkında olmadığı ve / veya ilgisinin olmadığı görünüyor ve birkaç günden daha uzun sürecek herhangi bir çaba beklemiyorum ... grev, saatlerce, subversion sunucusunun yapmasını istiyorum dırdır.

Sorum şu:
Ben burada temel dışı mıyım yoksa yanlış soruna mı bakıyorum? Görünüşe göre bir şey eksik ve sorunumu çözmek için araçlara bakarak yanlış bir şey soruyorum.

Bu sorunu çözmek için bir araç mı arıyorsunuz yoksa bunu düzeltmek için ne yapmalıyım?


Çalışma şeklini geliştirmek istemeleri için bir teşviki birleştirdikleri sorunlar değil mi?
Flosculus

1
Sadece bir fikir, kodları birleştirmelerini sağlayın;) Fakat
SVN'de

5
Birisi bir birleştirme yaptıktan sonra çatışmaları çözme sorumluluğunu kim üstlenir?
Flosculus

Dallanmada yüksek olan bir yaklaşım, her iki dünyanın da en iyisini sağlayabilir; eğer bir dalda büyük bir iş yapıyorsanız ve ana şubeyi o şubeyle düzenli olarak birleştiriyorsanız (bu nedenle tüm birleştirmeler küçükse), o zaman şubeyi tekrar master olarak birleştirdiğinizde, birleştirme önemsizdir, ancak bu arada Üstat'ta ara ya da kafa karıştırıcı şekilde eksik olan bir ara devlet elde etmiş oldum. Bazı SCM'lerde diğerlerinden daha kolaydır (ışık dallanmasının nasıl olduğuna bağlı olarak), ancak herhangi biriyle çalışabilir.
Jon Hanna

Yanıtlar:


47

İnsan problemine teknik bir çözüm arıyorsunuz. Bu nadiren işe yarar.

Bunun nedeni, eğer ekip üyeleri bir şeyi kabul etmiyorlarsa (ya da sonuçları anlarlarsa), kuralları takip etmek yerine, onları atlatmaya çalışırlar. İşte tam da bu nedenle, örneğin, geliştiriciler sadece bir denetleyici tarafından uymaya zorlanmak yerine stil kurallarını kabul etmeli ve anlamalıdır.

İşte geçmişte kullandığım veya pratikte onlara fırsat vermeden düşündüğüm birkaç yaklaşım. Bazıları, bir takımdaki pozisyonunuza bağlı olarak sizin durumunuz için geçerli olmayabilir (eğer mükemmel bir üne sahip bir takım lideriyseniz, şansınızı bir lisans öğrencisi olmanıza göre daha iyi bir şekilde uygulayabilirsiniz. staj süresi boyunca bir takıma katıldım.

  1. Konuyu iş arkadaşlarınızla tartışın ve büyük taahhütlerin sonuçlarını açıklayın. Belki de karmaşık birleşmelerin nadir görülen taahhütlerin doğrudan bir sonucu olduğunu anlamıyorlar ve küçükten sık yapılan sözleşmeler birleştirmeleri (nispeten) kolaylaştıracak.

    Birleşmelerin her zaman karmaşık olduğu konusunda ikna olmuş bir sürü programcı tanıdım . Günde en fazla bir taahhütte bulundular, Visual Studio'nun fark ve otomatik birleştirme gibi güçlü araçları kullanmaktan kaçındılar ve manuel bir birleştirme pratiği yaptılar (başka hiçbir fark incelemesi olmadan "benimkini al" aslında iyi bir uygulama değilse). Onlar için bu ile ilgisi yoktu onlara ve birleştirme doğal yapısına oldu.

  2. Diğer şirketlerde neler olup bittiğine dair somut örnekler verin (özellikle iş arkadaşlarınızın saygı duyduğu şirketler ). Sadece bunun bir sorun olduğunun farkında olmayabilirler ve her bir takımın yaptığı her gün en fazla bir taahhüdün olduğuna ikna olabilirler.

    Bazı insanlar, üretime 50'ye kadar iten, 5-10 kişilik ekiplerin bulunduğunu bilmiyor; bu da kişi başına günde ortalama 5-10 komisyona dönüşüyor. Ne mümkün olduğunu ya da neden birisinin yaptığını anlayamayabilirler.

  3. Örnek olarak kurşun. Yeterince küçük kendin yap. Mümkünse, bir hafta boyunca yan yana ve birleştirmelerinizi gösteren kısa bir sunum yapın (bu tür bilgileri çıkarmanın sürüm kontrolünden kolay olup olmadığından emin değilim). Birleşmeleri sırasında yaptıkları olası hataları vurgulayın ve yaptıkları hata sayısıyla karşılaştırın (sıfıra yakın olmalıdır).

  4. “Ben söylemiştim” tekniğini kullanın , uygun . Meslektaşlarınızın acı veren bir birleşme yüzünden acı çektiğini gördüğünüzde, küçük sıklıkta komisyonların birleşmeleri (nispeten) ağrısız hale getirebileceğini yüksek sesle yorumlayın.

  5. Bir taahhütte bulunmak için asgari sürenin bulunmadığını açıklayın. Bir taahhüt, birkaç saniye içinde yapılan küçük bir değişikliğe bile karşılık gelebilir. Bir dosyayı yeniden adlandırmak, eski bir yorumu kaldırmak, bir yazım hatası düzeltmek derhal yerine getirilebilecek tüm görevlerdir.

    Programcılar ufak bir taahhütte bulunmaktan korkmamalı, aksine birçok değişikliği tek bir büyük taahhütte bir araya getirmeli.

  6. Gerektiğinde takım yerine bireylerle çalışın. Özellikle sık sık, küçük işlerde bulunmayı reddeden bir kişi varsa, neden reddettiğini görmek için bu kişiyle ayrı ayrı konuşun.

    Takımda neler olup bittiği hakkında ipucu verebilecek mükemmel geçerli sebepler verebilirler. Kendimi duymamın bazı nedenleri:

    • “Öğretmenim / akıl hocası en iyi uygulama bir günde taahhüt yapmak olduğunu söyledi.” Bu beni şaşırtmadı, verilen neyi Üniversitede hocalarımın duymak zorunda .

    • “Meslektaşlarım bana daha az taahhütte bulunmam gerektiğini söyledi.” Bunu bana bazı takımlarda da anladım ve onların anlamını anlıyorum. Çalışma arkadaşlarımla uğraşan bir kayıt tuttum (dört takım arkadaşı günde bir iş yapmadığında yapmak zor değil), çalışma arkadaşlarımı hayal kırıklığına uğrattı.

    • “Küçük taahhütlerin bir revizyon bulmayı zorlaştırdığını düşündüm.” Ekip bir şekilde açıklayıcı günlük mesajları yazmaya çaba gösterse bile geçerli bir nokta.

    • “Sürüm kontrol sunucumuzda çok fazla yer israf etmek istemiyorum.” Kişi açık bir şekilde taahhütlerin ne şekilde depolandığını (ya da depolama alanının ne kadar ucuz olduğunu) anlamıyor.

    • “Bir taahhüdün belirli bir göreve uyması gerektiğini düşünüyorum.” Sık sık verilen bir görevin, bir günde (bazı görsel yönetim yönetim kurullarında olduğu gibi) yapılması gereken bir işe karşılık gelmesi nedeniyle, bu bir tesadüf değildir. Kişi daha sonra bir backlog'daki bir görev (2 ila 8 saatlik çalışma) ve gerçekleştirilmesi gereken (birkaç saniye ila birkaç saatlik çalışma) mantıksal olarak izole edilmiş bir değişiklik arasında bir fark yaratmayı öğrenmelidir. Bu aynı zamanda 5. maddeyle de ilgilidir.

  7. Takımın daha fazla iş yapma nedenini araştırın. Sonuçlara şaşırmış olabilirsiniz.

    Son zamanlarda, farklı bir cevapta bir taahhüt hızının önemli olduğunu ve yüzlerce milisaniyenin bile geliştiricileri daha az sıklıkta işlemeye zorlayabileceğinden bahsettim .

    Diğer sebepler şunları içerebilir:

    • Bir taahhüt mesajı yazmak için aşırı karmaşık kurallar.

    • Geliştiriciyi taahhüdü bir hata izleme sisteminden bir göreve bağlamaya zorlayan kural.

    • Yapıyı kırma korkusu.

    • Şu an yapıyı kırma riskiyle başa çıkmak istememesi: Cuma akşamı ayrılmadan hemen önce bir taahhütte bulunursanız, ayrılmadan hemen önce kırılmış yapıyla uğraşmayı erteleyebilirsiniz.

    • Birleştirme yapmanın korkusu.

  8. Geliştiricilerin sıkça iş yapmanın başka yararları olup olmadığını anlamalarını belirleyin . Örneğin, bir Sürekli Entegrasyon platformu, sık sık taahhütte bulunma konusunda büyük bir teşviktir , çünkü regresyonun tam olarak nerede ortaya çıktığını tam olarak belirlemenizi sağlar .

    CI platformunu tercih etmeyi tercih ederim, derhal on beş dakika önce yaptığım bir dosyada iki yöntemde meydana gelen değişiklikten (5023) yapılan düzeltmeyi kırdım, dört düzine dosyayı kapsayan ve temsil eden değişikliklerden oluşan revizyon 5023 yerine 13 saat çalışma.


“İnsan sorununa teknik bir çözüm arıyorsun. Bu nadiren işe yarıyor.” - Biliyorum, ama sadece yorgunum ve zaten tüm puanlarınla. Uzun zamandır benim sorunum değil, henüz ...
VolkerK 16:14

@VolkerK: düzenlememe bakın (cevabın ilk iki paragrafı). CI sunucunuz var mı? İş arkadaşlarınızla konuştuğunuzda, daha sık iş yapma isteksizliğini nasıl açıklarlar?
Arseni Mourzenko

1
@ VolkerK Bu cevap çok iyi açıklıyor. Teknik bir probleminiz yok. Sorun, insanların prosedürü takip etmeyi reddetmeleridir.
BЈовић

1
3. noktaya doğru: TortoiseSVN istemcisi, farklı parametrelere (zaman gibi) dayanarak giriş davranışını görselleştiren çeşitli diyagramlar oluşturabilir. Onları değerlendirmek aslında oldukça ilginç. Bunu SVN kullandığımız günlerde sık sık yaptım. stackoverflow.com/questions/412129/… :)
Aschratt

2
Giriş için teşekkür ederim, ama diğer rotaya geçtim ve yeni uyarı aldım ;-)
VolkerK

-3

Geçmişte sözleşme yaptığım bir organizasyon aynı sorunu çözmek istedi ve oldukça iyi bir sosyal çözüm buldu: geliştiricilerin kendi bilgisayarları yok. Geliştirme EKİBİ bilgisayarlara sahiptir, ancak herhangi bir kişiden herhangi bir günde herhangi bir geliştirme bilgisayarında çalışması istenebilir ve çalışması beklenebilir. Bu yüzden, check-in yapmak, dün yaptıklarınız üzerinde çalışmaya devam edebilmeniz için tek yoldur!

Yönetim sonra gitti ve saatlerce sonra bilgisayardaki değişiklikleri gizlice geri aldı, böylece kontrol edilmeyen herhangi bir şey kayboldu. Bu "benzetilmiş bilgisayar arızaları" devs gemiye binmeden önce sadece birkaç kez meydana gelmişti.

Elbette, kuralların “nedenini” ve “ne” yi açıklamak önemlidir. “Neden” açıklanmadıkça, kaynaklarını yalnızca USB sürücülerinde ya da bir şeylerde depolayabilirlerdi.


4
Bu insanlara davranmanın korkunç bir yoludur. Ayrılmadan önce doğru bir şey düşündüğünüzde ve makinede bulundurmak istediğinizde ne olur, ancak tamamlanmadı (sanki yapmaz), yani bunu yapmak istemezsiniz?
kullanıcı1118321

3
Ve bu bir kaynak israfıdır, çünkü normalde ihtiyaçlarınızı karşılayan bir kurulum ortamınız vardır. Uzun zaman önce aynı durum vardı ve 4 hafta sonra kendi dizüstü bilgisayarım oldu. Her gün aynı ayarları yapmaktan nefret ettim, sadece yapmam beklenen işi yapmayı.
mliebelt

1
Vay, bu birçok nedenden dolayı korkunç bir fikir. Yukarıdaki yorumlarda daha önce de belirtildiği gibi, (1) günden güne süreklilik olasılığını önlüyor ve (2) insanlara etrafta sadık kalarak özel ortamlar kurma yeteneğini reddediyor ...
Ben Lee

1
... Ama aynı zamanda (3) birisi kodları kontrol etmeyi unutursa veya yanlışlıkla bir nedenden ötürü yapmazsa çalışma saatlerini imha etme potansiyeline sahiptir ve (4) yönetimin kurallara uymadıklarına güvenmediğini gösterir. Bunun yerine, kuralları bir draconian şekilde uygulamak, potansiyel olarak onları biz-karşıtı bir ortam haline getirmek ve (5) kuralları sadece üretken olmaları için onları aşmaya teşvik etme potansiyeline sahiptir.
Ben Lee

Lütfen, bu fikri kimse uygulamıyor.
Ben Lee
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.