Takım arkadaşlarımı bazı temel kuralları takip etmeye nasıl ikna edeceğim?

Takım arkadaşlarımla bir sorunum var. Uzun lafın kısası: Bir yarışma için bir projede çalışan üç öğrenciyiz. Proje 2 ayrı uygulamadan oluşuyor: biri Windows (geliştirdiğim) ve diğeri Android için (meslektaşlarım geliştirmekten sorumlu). Kod tabanlarımız hiçbir zaman kesişmeyecek, uygulamalar üçüncü taraf araçlarıyla iletişim kuracak.

Sorun şu şekilde: Geçtiğimiz yıl büyük bir şirkette staj yaptığım ve kodumuza ilişkin bazı kodlama standartlarını uygulamaya koymaya çalıştığım takımlarda çalışma tecrübem var. Ayrıca, kod yazmak / fikir yazmak, belge protokolleri vb. İçin kullanabileceğimiz bir git depo / wiki / işbirliği yazılımı hazırladım, ancak bu araçları kullanan tek kişi benim gibi görünüyor.

Onlara kalite kodu yazmanın ve her adımı belgelemenin uzun vadede bize fayda sağlayacağını söylemeye çalıştım, ancak bunun avantajını görmüyorlar. Ayrıca bazı entegrasyon testleri eklemeyi düşünüyordum ama görebildiğim kadarıyla, yaşamlarını kolaylaştırmak için mevcut araçları kullanmadıkları sürece, onları entegrasyon testlerinin kullanışlılığına ikna edebileceğimi sanmıyorum.

Eş kodunun çoğu bilgisayarlarında bulunur, ortak bir kod tabanını paylaşmazlar ve bulduğum gibi, usb stick aracılığıyla kod toplayıp paylaşarak parçalarını birleştirdiler.

Sorum şu: bu konuda çok sert miyim? Bazı saçma kuralları zorluyor muyum? Bunun küçük bir proje olduğunu, gereksinimlerin çok net olduğunu unutmayın (uygulamaların ne yapması gerektiğini belirten belgeler oluşturdum), üç kalifiye geliştirici bunu 3-4 gün içinde yapabilirdi, bu yüzden yazma kalitesinin ek karmaşıklığını görmeyebilirler. Geçerli yöntemleri yalnızca çalıştığı sürece kod.

Onlara git ve benzeri kodları kullanarak, kod kodlama avantajını gösterebileceğim bir yol var mı?

Sorum şu: bu konuda çok sert miyim?

Bir atı suya götürebilirsin ama onun içmesini sağlayamazsın.

Çok sert olup olmadığınızı söylemek zor ama takım arkadaşlarınızın beklediğiniz tüm altyapıları benimsemelerini beklemek gerçekçi olmayabilir. Ve gerçekten, eğer ekip birlikte iyi çalışıyorsa, üç kişi arasında iletişim kurmak için bir wiki kullanmak muhtemelen fazladan bir engeldir.

Beklentilerinizi yeniden ölçeklendirin ve bilmediğiniz araçları kullanmaya başlamalarını gerektirmeden bazı hedeflerinize ulaşmanın yollarını arayın. Git'i nasıl kullanacaklarını bilmiyorlarsa, muhtemelen her halükarda bundan fazla faydalanamayacaklardır. Ancak, bir sabit sürücü arızası veya başka bir felaket durumunda tüm kodların yedeklendiğinden emin olmak istersiniz; bu nedenle, proje klasörlerini düzenli aralıklarla bir Google Drive'a, Dropbox'a veya benzer bir çevrimiçi dosya paylaşım hizmetine kopyalamasını isteyin. Aynısını yaptığınızdan emin olun.

Benim düşüncem, eğer bu tür şeyleri küçük projelerde yapmayı öğrenirseniz, büyük projeler geldiğinde hazırlıklı olursunuz.

Bu projeyle iyi gelişim uygulamalarını takip ederlerse, gelecekteki işverenlere göstermek için kodları olacak ve onları çalışanlar olarak değerli kılacak deneyime sahip olacaklar.

Onları ikna etmek için daha fazla materyal istiyorsanız, Pragmatik Programcısına veya Code Complete'e başvuracağım .

Öte yandan, onları biraz gevşetmeyi düşünün. Proje, yarışmadan hemen sonra kazanılan bir kavram kanıtıysa, sadece istedikleri gibi yapmalarına izin vermelisiniz. İyi uygulamaların zihinsel yükü olmadan kodu sadece ilk etapta yazmakta zorlanıyor olabilirler.

Korkarım tanımladığınız kurallar hiç de temel değil.

En kolay görev IMO, takım arkadaşlarınızı bazı kodlama standartlarını kullanmaya ikna ediyor. Ve bunu başarmanın basit bir yolu, bir kez iyi biçimlendirilmiş ve daha sonra kötü biçimlenen aynı kod pasajını göstermelerini, kodu okumalarını, ne yaptığını anlamalarını ve kendilerini yargılamalarına izin vermelerini istemek.

Git deposunu kullanmaya gelince, bu acemiler için bir acı olabilir. Bir Android projesinde 3 kişilik bir ekipte çalışırken, ilk önce sürüm kontrol sistemimizle ilgili çok sorun yaşadık. Bu yüzden takım arkadaşlarınızın da sorun yaşamasını bekliyorum.

Deneyimli geliştiricinin projeyi bitirmesinin 3-4 gün alacağını söylemiştiniz (ekibinizin 2-3 kez daha uzun süreceğini tahmin ediyorum). Bu çok kısa bir zaman dilimidir, bu nedenle yeni araçlar kullanmanın uzun vadede yardımcı olacağı argümanı işe yaramayacaktır.

Yapabilecekleriniz, bu araçların nasıl kullanıldığını göstermek için kısa ve basit gösteriler yapmaktır. En temel işlevleri ilk önce ele alın, yanlarına oturun ve araçları kullanmalarına yardımcı olun. Git'i yapılandırma, wiki sayfa yapısını oluşturma vb. Gibi tüm görevleri yapmaya hazır olun.

Düzenleme : Yoruma cevap olarak, net görevler, tahminler ve son tarihler oluşturmak ve harcanan zamanı takip etmek, git veya benzeri araçları kullanmaktan daha önemli. Uygulama üzerinde daha sonra çalışmayı planlıyorsanız, ne yapıldığını ve her özelliğin ne kadar sürdüğünü takip etmek çok önemlidir. Bu yüzden görev yönetiminden başlamanızı ve ardından kullanmak istediğiniz araçlara ilerlemenizi öneririm.

Aslında Joel Spolsky'nin kendi düşüncelerini beğendim, çünkü sen sadece homurdandığında işlerin yapılması . Özetlemek:

1. Sadece yap - Makefiles yaz, günlük inşa sunucusu oluştur vb.
2. Kimse kaynak kontrolü veya hata veritabanları kullanmıyor mu? Onları kendin kullanmaya başla. Birisi işinize karşı bir hata bildirirse, onlardan kibarca size hataları bildirmek için hata veritabanını kullanmalarını isteyin; Aksi takdirde, onları doğrudan kafanızda tutamaz ve düzeltemezsiniz. Önemsiz olmayan herhangi bir projede, yalnızca kaynak kontrolü ile çözülebilen bir durum olacaktır: kod için kaynak kontrolünü kendiniz kullanın ve böyle bir durumun meydana geldiği günü kurtarmak için kahramanca dokunun. Bu birkaç kez gerçekleştiğinde ikna olurlar
3. Mükemmeliyet Cebi Yaratın - Kendiniz için doğru şeyleri yapın: belirleme, zamanlama vb. mesajına inanan yeni ekip üyeleri
4. Değerli Olun - Takımdaki etkinizi arttırmada büyük bir katkı olduğunuzu gösterin. Aksi takdirde, sonuçları ve süreçleri değerlendiren değerlere değer veren bir kişi olarak tanınma riskiniz vardır.

Belgeleme, Wiki, sürüm yazılımı, metodolojiler vb. Zamanla öğrenilen deneyimler ve derslerdir; birkaç projenin ve muhtemelen birkaç ekibin çalışması. Ve genellikle zaten çalışanlar veya endüstrilerini ciddiye alanlara yapışır. Onlar öğrenci, bu yüzden çıkarları gelecekte ne olacağı konusunda sınırlı. :)

Ancak sorunuzu cevaplamak için:

Onlarla bir takımdaysanız, önemli olduğunu düşündüğünüz şeyleri çıkarlarına fayda sağlayacak şekilde uygulamanız gerekir. Örnek olarak: USB paylaştığında kodlarının kırılmasından şikayet etmeli mi? O zaman belki onlara SVN'yi (git yerine) versiyonlama aracı olarak kullanmanın basit (karmaşık olmayan) bir yolunu verin.

Arnaud'un yorumuna da katılıyorum.

Onlarla çalışırken tüm bu araçların yararını gördünüz ve onlarda değer gördüğünüz ve kullanımlarını neden anladınız. Takım arkadaşlarınız halihazırda işleri nasıl yaptıkları konusunda bir katma değer görmüyorsa, o zaman bunu uygulamazlar. Ve üzücü olan şey, bu, herhangi bir deneyimi olan insanlardan oluşan ekipleri bile sayar.

Yaklaşımın sorunları var:

1. Yaklaşımınız simetrik değil. Diğer takım üyelerinizin değişmesi gerekiyor, ancak iyi uygulamalarını öğrenmiyorsunuz. Böyle bir durumda kuralları uygulamak zordur. Daha iyi bir yaklaşım, ekibin tüm üyelerinden iyi kurallar ve uygulamalar toplamak olacaktır ve ardından herkes sonuçta ortaya çıkan dokümanı okur.

2. Öğrenme zor. Diğer insanların kuralları sadece mantıklı değil çünkü bu kurallar programcılarınızın beklediği mantıksal yapıya sahip değil. Mantıklı olmayan kuralları uygulamak, yararlı bir faaliyet değildir.

3. Herkes farklı şeyler öğrendi. Farklı geçmişlerden gelen programcıların farklı şeyler öğrenmesi doğaldır. Güçlü yanları farklıdır ve kod yazma stilleri farklıdır. Kullandıkları araçlar farklı. Bir kurallar / araçlar / stiller dizisinin yürürlüğe konması kabus olacak çünkü kısıtlamalar bu geliştiricilerin yıllarca öğrendiği gücü kaybetmektedir.
4. Değişim zaman alır. Uyguladığınız kuralları icat eden kişi kuralları takip ederken oldukça kolay zaman alırken, diğer herkes acı çekiyor ve yeni kuralları öğrenmek için zaman harcıyor. Bu, takımdaki herkesin kuralları değiştirebilmesinin nedeni budur.
5. Takımın tamamı için araç / kodlama kuralları veya stilleri seçmek zor bir iştir . Neyin işe yarayıp yaramadığını test ederek sadece zaman içinde yavaşça yapılabilir. Bir ekibin 50 kuralı takip etmeye 2 hafta vermesi işe yaramaz.

Bu problemi üniversitede buldum. Birçok insan, farklı (ve belki de daha profesyonel bir yaklaşım) çalışma şekli öğrenmeye istekli değildir.

Ancak, sisteminiz var ve sistemi nasıl kullanacağımı açıklarım, o zaman birçok kişi denemeye isteklidir. Ayrıca depoların çok kullanılan araçlar altında olduğunu ve insanların genellikle yalnızca dropbox gibi bir şey kullanacağını düşünüyorum.