Geliştiricilerin kendi iş istasyonlarında nasıl çalıştığıyla ilgili standartlar

Bir geliştirici proje ortasında birkaç gün boyunca hastalandığında zaman zaman ortaya çıkan durumlardan birine rastladık.

Kodunun en son sürümünü kullanıp kullanmadığı veya yerel makinesinde bakmamız gereken daha yeni bir şey olup olmadığı hakkında birkaç soru vardı ve beklememiz için bekleyen bir müşteriye teslim ettik. geri dönmek için.

Diğer geliştiricilerden biri, görünüşte aynı projelerin birçoğunu görünce ve bulmak için oturum açtı, zaman damgaları hangisinin "güncel" olduğunu netleştirmedi (projenin sürümlerinde bazı bitleri prototiplendiriyordu) onun "çekirdek" olanı).

Açıkçası bu boyundaki bir acıdır, ancak alternatif (her bir geliştiricinin en az çaba ile bir şeyleri alabilmesini sağlamak için her bir geliştiricinin kendi makinesinde nasıl çalıştığına dair katı standartlar gibi görünmektedir ) büyük olasılıkla geliştiricilerin kişisel iş akışları ve bireysel düzeyde verimsizliğe yol açar.

Check-in kodu standartlarından, hatta genel geliştirme standartlarından bahsetmiyorum, bir geliştiricinin yerel olarak nasıl çalıştığından bahsediyorum, genellikle (tamamen benim deneyimime göre) geliştiricilerin kendi kontrolü altında olduğu düşünülen bir alan.

Peki böyle durumları nasıl ele alırsınız? Bu olanlardan biri sadece ve başa çıkmak zorundasınız, geliştiriciler için ödediğiniz fiyatın onlara en uygun şekilde çalışmasına izin mi veriliyor?

Veya geliştiricilerden bu alandaki standartlara uymalarını mı istiyorsunuz - belirli dizinlerin kullanımı, standartları adlandırma, bir wiki ile ilgili notlar veya herhangi bir şey? Ve eğer öyleyse, standartlarınız neyi kapsıyor, ne kadar katı, onları nasıl koruyorsunuz?

Yoksa özlediğim başka bir çözüm var mı?

[Burada ne yaptığından bahsetmek için geliştiriciyle iletişime geçilemeyeceği fikrini varsayalım - hangi çalışma alanının bellekten basit ve kusursuz olmayacağını ve hatta bazen insanlar gerçekten İletişim kurulmaz ve tüm olasılıkları kapsayan bir çözüm istiyorum.]

Düzenleme: Birinin iş istasyonundan geçiyor (bu tam olarak neden olduğu hakkında ilginç - ve muhtemelen konu dışı - bir soru olsa da) kötü form olsun ve kesinlikle sınırsız erişim bakmıyorum. Kod dizinlerinin salt okunur bir paylaşımla oluşturulduğu bir standardın çizgileri üzerinde daha fazla düşünün - hiçbir şey değiştirilemez, başka hiçbir şey görülemez vb.

" Kaynak kontrolünde değilse, mevcut değildir. "

Bu, mesleğimizde dogmatik olduğum sınırda olduğum birkaç şeyden biri. Aşağıdaki sebeplerden dolayı:

1. İş istasyonu şirket malı olmasına rağmen, bununla yüzleşelim - bir programcının kendi iş istasyonunun kendi kalesi olduğuna dair yazılı olmayan bir kural var. Herkesin rutin olarak oturum açıp içinden geçebileceği bir işyeri kültüründen rahatsızım.
2. Herkesin kendi akışı vardır (sizin de söylediğiniz gibi). Tüm geliştiricileri kendi yerel çalışma alanlarını belirli bir şekilde düzenlemeye zorlamaya çalışmak, kendi özel çalışma yöntemlerine karşı çıkabilir ve akışlarını kırabilir ve daha az verimli hale getirebilir.
3. Kaynak kontrolünde olmayan şeyler yarı pişmiş koddur. Yayınlanmaya hazır tamamen pişirilmiş bir kodsa, kaynak kontrolünde olmalıdır. Hangi tekrar ana noktaya geliyor ....
4. "Kaynak kontrolünde değilse, mevcut değildir."

İnsanların iş istasyonlarındaki kodlara bakmak isteme konusunu hafifletmenin olası bir yolu, düzenli checkin kültürünü teşvik etmektir. Bir keresinde bir şirkette çalıştım - bunu yapmak için resmi bir yetki olmamasına rağmen - hafta sonu için her şeyin kontrol edilmesinin bir tür gurur noktası görüldü. Bakım ve serbest bırakma aday aşamalarında, CR öğeleri küçük, temiz görünür değişikliklere izin vermek için kasıtlı olarak çok ince taneli ve bunları takip etmek için düzenli kontroller yapmıştır.

Ayrıca, tatile gitmeden önce her şeyi kontrol olması zorunluydu .

TL; DR versiyonu : İnsanların iş istasyonlarından geçmek kötü bir form. İstediğimizi bulmak için insanların iş istasyonlarından geçmeyi kolaylaştıracak bir kültür geliştirmeye çalışmak yerine, mantıklı bir kaynak kontrolü kullanımı ve düzenli kontroller kültürünü teşvik etmek daha iyi bir uygulamadır. Muhtemelen hiper düzenli kontroller ve projelerin kritik aşamalarında ince taneli görevler.

Geliştiricilerinizin iş istasyonlarını nasıl organize ettiklerine ilişkin bir standart uygulamak yerine, her günün sonunda tüm işlerin kontrol edildiği bir standart uygulayın . Check-in'ler hala tamamlanmamışsa şubelere olabilir.

Bu şekilde kimsenin başka bir geliştiricinin iş istasyonuna erişmesine gerek kalmaz.

Bu politikanın bir miktar muhalefetle karşılanacağını hayal ediyorum, ancak iş istasyonlarının organizasyonu ile ilgili kuralları uygularsanız ne beklediğime kıyasla hiçbir şey.

Birinin makinemde oturum açacağı ve eşyalarıma göz atacağı fikri hakkında tedirgin olduğum gerçeğini size söyleyeceğim. Verilmiş, bu şirket ekipman ve mülkiyet, ama sadece yapmak kötü bir şey.

Son kez bir hafta sonu için ayrıldığımda çocuklar sunucuları veritabanı ve kaynak kontrolü ile yeniden yapılandırdılar ve bir nedenden dolayı makinemde oturum açıp sistemi yeni ayar için yeniden yapılandırmanın gerekli olduğunu hissettiler.

Ne yaptıkları hakkında hiçbir fikirleri yoktu ve son iki aydır üzerinde çalıştığım bir prototipi sildiler.

Doğru iletişimin yerinde olsaydı olmazdı. Siz de buna ihtiyacınız var. Bu geliştiriciye gidin ve şeylerin durumunu öğrenin. Daha da iyisi, insanlardan izin almadan önce bir rapor isteyin, böylece herhangi bir şeye ihtiyacınız olup olmadığına dair bilinçli bir karar alırsınız.

Ama insanların iş istasyonlarıyla uğraşmayın.

PS Bir dizin yapısı için bir konvansiyonumuz var ama ana varoluş nedeni tarih / konfigürasyonun bir karışımı - başka bir yere koyun ve derlenmeyecek.

Birkaç ay önce oldukça büyük bir proje üzerinde çalışıyordum ve hastaneye kaldırıldığımı öğrendiğim için aniden işten ayrılmak zorunda kaldım. Proje için en son kodumu kontrol etmek için zamanım yoktu.

Neyse ki, /var/www/ourdomain.comüretimi taklit etmek için kodun saklanması burada ("gerekli olmasa da") . Böyle mantıklı ve takip edilmesi kolay bir kuralla, bir iş arkadaşımın makineme giriş yapması ve son değişiklikleri alması kolaydı.

Bazı sözleşmelerin iyi olduğunu düşünüyorum. Gerçi Bobby ile aynı fikirdeyim

"Kaynak kontrolünde değilse, mevcut değildir."

Ayrıca, herhangi bir programcının çalışma alanına yararlı bir ek, tüm kaynak ve geliştirme projelerini depolamak için önden yerleştirilmiş çalışırken değiştirilebilir bir SATA sürücüsü olabilir. Bu şekilde, böyle bir sorun ortaya çıkarsa, bir çalışan, geliştiricilerin iş istasyonuna giriş yapmaya gerek kalmadan projede yeni kaynak değişikliklerini kolayca alabilir.

Sorunuzun ilk kısmı, ekibinizdeki iletişim sorunlarını açıkça tanımlar. Eğer denediniz günlük Standups ?

Standartların çok katı olmaları durumunda verimsizliğe yol açacağını söylediğinizde size katılıyorum. Standartlar ekip tarafından tanımlanmalıdır herkesin dahil olduğu .

Sizin durumunuzda, ilgili geliştiricinin işe geri dönmesinden birkaç gün sonra beklerdim. Ardından bu standartlar hakkında konuşmak için bir toplantı düzenleyin.

Herhangi bir psikolojik blok ve dirençten kaçınmak için, gördüğünüz kişileri veya belirli şeyleri adlandırmayın. Genel tutun, buradaki amaç, çalışma şeklini geliştirmesi gerektiğini düşündüğünüz geliştirici de dahil olmak üzere herkesten girdi elde etmektir. Adam da organizasyonunuzu bir karmaşa olarak düşünebilir.

Toplantı sırasında sorunu gösterin ve ekibin durumu nasıl iyileştirebileceğini net bir şekilde sorun .

(Bütün) ekip ne yapacağına karar verir.

Bu kullanıcı muhtemelen uygun araçların eksikliğinden muzdaripti. Özellikle, dağıtılmış bir sürüm kontrol sisteminin kullanımı, onun için farklı eyaletlerde farklı kod dizinlerine sahip olma ihtiyacını ortadan kaldıracaktır. Tüm bunları dallarda tutabilirdi ve çok daha mutlu olabilirdi.

Ancak asıl nokta, hayır, kendi iş istasyonumu nasıl düzenlediğim konusunda benim üzerime standartlar uygulanmasını istemiyorum. Şu anda (olsa bile IMO için en iyi araç değil, kullandığı ve iyi bildiklerini, çünkü patronum GERÇEKTEN Eclipse hepimizi isteyen bir IDE benim bölüm standartlaşarak hakkında geri itiyorum benim iş).

Geliştiricilerin kendilerini rahat ettiren her şeyi yapmasına izin verin. Rahat bir geliştirici, rahatsız edici olandan daha üretkendir. Ve eğer birisi üretken DEĞİLSE ve araçlarla yerel olarak uğraştığından şüpheleniyorsanız, yeni kurallar yapmak için iyi bir zaman değil, eğitim için bir fırsattır.

Eski iş yerimde, hata takibimizdeki her görevin kaynak kontrolünde kendi şubesine sahip olduğu bir sistemimiz vardı. Çoğu zaman, bir hata / görevin bir geliştirici tarafından ezildiği anlaşıldı, böylece kırık kodun kaynak kontrolüne kontrol edilmesine izin verildi.

Kod, geliştirme dalında kararlı olduğu bir duruma geldiğinde, entegre edeceğiniz daldan kodu sürükleyerek bir rebase yapıldı. Bu birleştirmeyi test ettikten sonra, kodu entegrasyon şubesine teslim etme vakası olacaktır - şubenizde birleştirme işlemini zaten yaptığınız için birleştirme gerektirmez.

Bu şekilde, geliştiricilerin sorununu bozulan kodu işlemekten endişe ederek kurtarırsınız - ve geceleri ofisten ayrılmadan önce kodu kontrol etmek için süper kabul edilebilir hale getirmek için sosyal politikayı uygulamaya başlayabilirsiniz - güzel ve güvenli.

Gelen bu belirli bir durum çağrısı evde kişi, onun hasta olduğunu şüphe olmadığını çok açık hale ama başka birisi var işine devam ve en son malzeme ve ne durumda nerede sormak gerekir.

O zaman buradan ne yapacağınızı düşünmelisiniz. Sorun insanların çok nadiren check-in yapması ise, insanların birbirlerini rahatsız etmeden dallarda çalışmasına izin veren dağıtılmış bir kaynak kontrol sistemi kullanmayı düşünün.

Sorun, makinelerinde birden fazla çalışma alanına sahip geliştiricilerin hoşlanmamasıdır, o zaman üstesinden gelin. Çalışma tarzı bireyseldir ve kaynak deposu kuralları ile iyi çalıştıkları sürece temelde sistemlerinden uzak durmalısınız. Şahsen, farklı projeler için yeni bir kopyayı çok sık kontrol ediyorum ve arada bir temizliyoruz.

Sorun geliştiricinizin ne yaptığını bilmiyorsanız, sorun teknik değil politiktir ve yönetim tarzınızı değiştirmeniz gerekir. Geliştiricilerin, mikro yönetimi çok nadiren seven ve yetki verdiğiniz personel olduğunu unutmayın . Aksi takdirde en yetenekli kişileri uzaklaştıracaksınız.

Bu nedenle, ortak kaynak deposuyla çalışmanın daha iyi bir yolunu teşvik etmenizi öneririm - insanların şubelerde çalışmasının iyi olduğunu ve yerel kopyalarını ana depoya günlük olarak senkronize ettikleri sürece (genellikle her zaman bir dalda geliştirme çalışmaları yapacak, bu başkalarını etkilemeyecektir).

Peki böyle durumları nasıl ele alırsınız?

Bu sorunu, kişisel kararsız dalları destekleyen bir kaynak kontrol sistemi ile ve sık taahhütleri koruyarak çözebilirsiniz. Bir problemin tamamı çözüldüğünde bir taahhüt gelmek zorunda değildir. Kaynak kontrolünden her faydalandığınızda gelmelidir. Günün sonu, değişikliklerin nerede yapıldığını görebilmeniz, yedekleyebilmeniz ve gelecekteki kendinize veya başkalarına açıklayabilmeniz için bir taahhüdün gerçekleşmesi gereken birçok noktadan biridir.

Veya geliştiricilerden bu alandaki standartlara uymalarını mı istiyorsunuz - belirli dizinlerin kullanımı, standartları adlandırma, bir wiki ile ilgili notlar veya herhangi bir şey?

Kurallara işaret eden ancak bir standardı belirtmeyen muazzam bir ortam yapılandırma belgesine sahibiz. Standartlar üretim kodu ve ortamları içindir. Bununla birlikte, geliştirme araçlarımızın çoğu sözleşmeleri destekleyecek şekilde düzenlenmiştir ve çoğu geliştirici trendi yakalamak için çaba harcamamaktadır.