Size kişisel tecrübelerimin desteklediği bazı ipuçları vermeye çalışacağım.
Takım arkadaşlarımdan biri, deneyimli olmasına rağmen, SVN'yi gerçekten anlamıyor. Doğal olarak, zihinsel haritasında SVN okyanuslarını betimleyen boş alanlar onun oldukça garip kullanım biçimlerini benimsemesine neden oluyor.
Örneğin, "geliştirici başına günde 1 SVN işleme kararlılığı" politikası ilan etti çünkü aksi halde "sunucu yakında disk alanı tükenecekti". SVN’nin taahhütlerinin tam kopya olmadığını, delta olduğunu açıkladığımda, şüpheyle cevap verdi ve bugün bile ne anlama geldiğini anlayabildiğinden emin değilim.
Disk alanı bir sorun olsa bile, bir kerede çok fazla dosya işleyebilirdiniz, bu yüzden önerdiği şeyin yanlış bir çözüm olduğunu düşünüyorum. Ayrıca, büyük ikili dosyaları kontrol ederek çok fazla alan israf etmek mümkündür, çünkü SVN ikili dosyalar için deltaları saklamaz. Günde bir check-in yapmak da kötüdür çünkü sizi bir araya gelmeyen değişiklikler yapmaya zorlar; örneğin, günde birden fazla hata düzeltmeniz durumunda.
Şirketimizde benimsediğimiz çözüm, ikili dosyalar içeren tüm taahhütleri reddeden bir filtre olmasıdır. Giriş yorumunda özel bir anahtar kelime kullanarak taahhüdü zorlayabiliriz (SVN'ye ne yaptığımızı bildiğimizi göstermeliyiz). Bir veya iki yılda bir proje yöneticisi eski şubeleri arşivler ve bunları depodan kaldırır. Bu stratejiyle bildiğim uzay sorunlarımız yok (havuzumuz birkaç farklı projeyi destekliyor ve 100000'den fazla revizyona sahip).
Özetle, ona disk alanının önemli bir sorun olduğu konusunda hemfikir olduğunuzu söyleyebilirsiniz, ancak diğer taraftan, işaret edin
- monolitik günlük check-in yerine özellik ile ilgili check-in'lerin önemi;
- Günde bir büyük ikili dosyayı kontrol ederek, birinin yine de diski doldurabileceği gerçeği.
Ardından, disk alanı kullanımını kontrol altında tutma stratejilerini (örneğin ikili dosya filtreleri, düzenli yedekleme ve eski kullanılmayan dalların temizlenmesi gibi) tartışmak için bir toplantıya (muhtemelen diğer geliştiricilere veya sistem yöneticilerine de sahip olabilirsiniz) önerebilirsiniz.
Ayrıca Eclipse .project yapılandırmasının SVN'ye dahil edilip edilmeyeceği konusunda da ateşli bir tartışma yaptık. Takım arkadaşım, çok sayıda anlamsız çatışmaya neden olmasına rağmen, ısrar etmemiz konusunda ısrar etti. Bireysel geliştirici yapılandırma dosyalarını SVN'de tutmamaya karşıydım. Sonunda, takım arkadaşımın “kaynak havuzuna işlenen kodun” sadece yapıldığından emin olmak için her kaynak ağacın tamamını yeniden kontrol etme uygulaması olduğu ortaya çıktı. Proje konfigürasyonunu SVN'de tutmakta bu kadar kararlı olmasının sebebi buydu - bu yüzden projeyi yeniden almak kolay olurdu. Teslim etmenin çalışma kopyasını tekrar kontrol etmeyi gereksiz kılan uzak bayt baytla senkronize ettiğimi açıkladığımda, ekip arkadaşım tekrar şüpheyle cevap verdi ve sonunda tüm konuyu önemsiz olarak salladı.
Bence ekibimiz, yalnızca SCM ile paylaşılması gerekmeyen geliştiriciye özgü ayarları içeren proje yapılandırma dosyalarındaki SVN çakışmalarını çözerek zaman harcıyor. Tüm bu karışıklık, çünkü birileri süreci yanlış varsayımlara göre uyarladı.
Bir yapı sunucusu kullanıyor musunuz? Projenin tamamını kontrol eden ve her gece derleyen bir derleme sunucumuz var. Ertesi sabah, test ediciler ürünün teste hazır bir kurulumcısına sahiptir (eğer usta yapı doğru çalıştıysa) ve biz (geliştiriciler) tüm uyarıları içeren bir derleme raporuna sahibiz (ve varsa, varsa). Tabii ki, her geliştirici sonra projenin geri kalanı ile birlikte onları kontrol edebilirsiniz. Derleme sunucusu için standart konfigürasyon dosyalarını kurmak ve onları kontrol etmek gerekir, ancak kontrol etmek için izin verilmez herhangi yerel değişiklikler.
Bu senaryoda, tüm projeyi kontrol edebilme ve istediği zaman inşa edebilme ihtiyacını ele alıyorsunuz. Ayrıca, kontrol edilmemesi gereken değişiklikleri birleştirmek için zaman harcamaktan da kaçınırsınız, çünkü bunlar ürünün bir parçası değildir: ürün ana yapıdır ve temiz tutulması gerekir. Birisi ana yapıyı kırarsa (örn. Kendi .project dosyasında denetleme) değişiklikleri geri alabilir veya bu geliştiriciyi sorunu çözmeye zorlayabilirsiniz.
Belki konuyu tekrar gündeme getirirse, yine bir toplantı yapmayı önerebilir (muhtemelen diğer geliştiricilerle) ve birlikte ortak bir strateji bulabilirsiniz.
SVN'nin temellerini daha iyi anlaması için kendini kıdemli olarak gören bir takım arkadaşını nasıl ikna edebilirim?
Bence en iyi strateji, çatışmayı kişisel bir düzeye çıkarmaktan ve eldeki sorunları ve olası çözümleri tartışmaktan kaçınmak olacağını düşünüyorum. Kişisel bir yüzleşme arayışı içinde olduğu izlenimini yaşıyorsanız, bazı öneriler (yine kişisel deneyimlerden):
- Takım dinamikleri nasıl? Diğer meslektaşlarınız bu takım arkadaşı ile benzer bir deneyime sahip mi? Bir ekibin belirli davranışlardan vazgeçmesi (küçük şakalar veya gözlemler) bir üyeye üyelerine verebileceği ve yapıcı yüzleşmeyi teşvik etmesi (bir toplantı önermesi veya bir kahve molası sırasında gayri resmi bir konu açması) konusunda çok sayıda küçük, çok açık olmayan ipuçları vardır. ). Bazen iyi bir ekip, rahatsız edici bir öğeyi hızla izole edebilir ve işleri normale döndürür.
- Personel yönetiminiz ne kadar iyi? Şirketimizde bir ihtilaf vakası vardı ve durumu düzeltmek için personel başkanı müdahale etmek zorunda kaldı. Güzel değildi, ama bazen çalışma ortamı o kadar kötüleşiyor ki kendi başına iyileşmeyecek. Umarım bu sizin durumunuz değildir (henüz o kadar etkilendim olduğu izlenimine sahip değilim), ancak iyi bir personel idaresine sahip olup olmadığınızı veya çatışmaları kendi başınıza çözmek zorunda olup olmadığınızı bilmek her zaman iyidir.
Bunu neden yazıyorum? “SVN temellerini daha iyi anlaması için kendini kıdemli olarak gören bir takım arkadaşını ikna etmek istediğini” söylüyorsunuz. Bana göre çatışma çok kişiselleşiyor gibi geliyor. Bazı psikologlar, iletişimimizin% 70'inin duygusal düzeyde olduğunu, eğer bu seviye işe yaramazsa, insanlar gerçekler hakkında konuşmayı bıraktığını, çünkü duygularla uğraşmak için çok meşgul olduklarını savunuyorlar.
Böylece, puanlarınızı açıklamanın yanı sıra, iletişimi geliştirmek için bir şeyler yapmayı da deneyebilirsiniz. Bir kahve içmek ya da öğle yemeği molası vermek, işle ilgili olmayan bir konu hakkında kısa bir konuşma yapmak, iletişimi geliştirebilir ve meslektaşınızın dikkatini onun anlamasını istediğiniz önemli gerçeklere geri getirebilir . Bu tür bir iletişimi kabul ederse, belki de şu ana kadar sahip olduğunuz çatışmalar, birbirinizi iyi tanımadığınız ve bazı yanlış anlaşılmaların olduğu gerçeğiyle ilişkiliydi, ancak muhtemelen yapıcı bir işbirliği kurmaya açık. Reddederse, tarafında daha derin bir düşmanlık olabilir.
Bu durumda, rolleriniz netleşene kadar beklemelisiniz. Takım arkadaşınız resmi olarak sizinkinden daha yüksek bir seviyeye sahip değilse, işleri iyileştirme girişimlerinizde tahriş etme noktası yoktur. Zamanla, daha iyi bildiğini göstermeye çalışırsa sürekli kabul etmek veya aptallık etmek zorunda kalacak. O takdirde var daha yüksek bir rütbe, onu bu tartışma altında olmadığını anlatmak için bir yol bulmak gerekir: Gözlemleriniz verimliliği iyileştirme amaçlı olduğunu ve tutumunu da bozmayı, bu% 100 net olmalıdır. Roller netleştiğinde, yine de yapıcı öneri veya eleştiriyi kabul edemiyorsa, gerçekten özgüven ya da onun gibi bir şeyle ilgili bir problemi olması gerekir.
Eğer yukarıdaki tüm stratejiler başarısız olursa ve (çok) sinirli hissetmeye devam ederseniz, korkarım ki yapılacak tek şey şeylerinizi toplayıp daha iyi bir yer aramak olacaktır. Bu deneyimi üç yıl önce yaptım ve şu anda çok memnun olduğum çok daha iyi bir şirket buldum. Belki bu sizin durumunuz değildir (umarım elbette değil) ama bu noktayı da anlamaya çalışın.
Sadece 2 sentim.