Gelecekte tek kişilik bir projeden ekip projesine geçiş. Şimdi hazırlık aşamasında ne yapmalıyım ve ne bekleyebilirim?

Ayrıntılı olarak, insanların hala tek kişilik bir proje (takım kaynak kontrolü, dokümantasyon, yapımlar vb.) projeye.

Bu senaryodan geçme konusunda herhangi bir deneyimi olan herkes, anlayışları takdir edilecektir.

Ne öğrendim. (Farklı bir düzen denedim. Yanılmışım. Bu, olayların alakalı hale geldiği sıra.)

1. Her şeyi kaynak kodu kontrolüne koyun. Herkesin erişebileceği bir şey kullanın ve hemen başlayın . İstisna yok. Gecikme yok. Bahane yok.

2. Kişisel "çalışan" veya "geliştirme" ortamınızdan tamamen ayrı bir KG / Test alanı oluşturun. En azından ayrı bir kullanıcı kimliği. İdeal olarak ayrı bir sanal makinede.
   Tamamen ayrı. Mevcut çalışma ortamınızla olası bir örtüşme yok.

3. Kendi çalışma ortamınızda birim testinin ötesinde test yapmayı durdurun. Kod ve birim testi "kendiniz yapın". Ayrı VM'de yaptığınız diğer tüm testler (entegrasyon, performans, ne olursa olsun). Asla kendin gibi test yap. Her zaman ayrı bir KG kullanıcısı olarak test edin. İdeal olarak ayrı bir sanal makinede.

   "Benim için çalışıyor," takım üyelerinize söylemeniz kötü bir şey. Çok kötü. Ne yaptýklarýný bulman gerek. Günde bir kaç kez.

4. Her şeyi yazmayı planlayın. Tüm belgelerin sürüm kontrolü deposundaki düz metin olması için düz metin biçimlendirme aracı (RST veya Markdown vb.) Kullanın. Bir araç HTML sayfaları (yani RST için Dokümanlar) veya PDF'ler veya en iyi görünenleri oluşturabilir. Tescilli belge biçimlerini (MS-Word gibi) kullanmayın. Bazı kaynak kodu kontrol sistemleriyle iyi oynatılamayabilirler.

5. Yazmanız gereken ilk şeyler şunlardır.

   • Bir çalışma geliştirme ortamı nasıl oluşturulur. Şüphe duyduğunuzda, bir Sanal makine oluşturun ve tüm işlemi o sanal makinede yapın. Adımların gerçekten işe yaradığından ve belgelerin açık olduğundan emin olun . Gerçek komut satırına yazılan gerçek satırlar netlik sağlar.

   • Birim sınama paketi nasıl çalıştırılır. Tekrar. Talimatların çalıştığından ve düşünmeyi gerektirmediğinden emin olun. "Bunu yazın:" "Onaylayın:" bir tür şey. Ekip üyelerinizin aptal olması değil. Hepsini yazmadıkça ne varsaydığınızı hatırlamıyorsunuz.

   • Tümleştirme sınama paketi nasıl çalıştırılır.

   Mimariyi veya tasarım ilkelerini tanımlamak için çok fazla zaman kaybetmeyin. Önce birini kurup çalıştırman gerekiyor. Daha sonra açıklayabilirsin.

6. Belgelenecek sonraki şeyler kullanıcı hikayeleridir. Ve bu hikayeleri destekleyen test senaryoları. Ve bu kullanıcı hikayelerini destekleyen test senaryoları için gerekli veri fikstürleri.

   Bunu paylaşacaksınız. Kaynak kodu kontrolü altına girer.

7. Sonunda, diğer 4 görünümü belgeleyebilirsiniz.

   • Mantıksal görünüm belgelenmesi için yararlı şeylerdir. Resimler burada kabul edilebilir. Bu hızla gelişmeye meyillidir, bu nedenle eski bilgileri yakalamak için zaman harcamayın. Ekip üyelerinizle işbirliği yapmanın bir yolunu bulun.

   • İşlem görünümü genellikle yararlıdır. Genel uygulamaya bağlı olarak bunun ne kadar önemli olduğuna bağlıdır.

   • Geliştirme görünümü - modüller, kütüphaneler, çerçeveler, vb. - genellikle gayri resmi olarak tanımlanır. Bir resim yardımcı olabilir, ancak birisinin bir belgeyi alıp başını veya kuyruklarını oluşturabileceği kadar kapsamlı hale getirmek oldukça zordur. Uzun süredir kurulmuş, çok halka açık projeler bile göz ardı edilen kütüphane belgelerine sahiptir. (Birçok Stack Overflow sorusuna yol açar.)

     Gayri resmi olarak kabul edilebilir olmanın yanı sıra, bu hızla değişme eğilimindedir.

   • Dağıtım bilgileri. Sunucular. IP adresleri. Veritabanı kimlik bilgileri. Bütün bunlar olmalıdır aşağı yazılır. Sonuçta.

Araçlar ve metodoloji

Başarılı bir şekilde işbirliği yapmak ve üretken olmak için neler gerekir?

• Projenizin parçalarını / bileşenlerini tanımlayın : Farklı parçalar (veritabanı, veri erişim katmanı, web sitesi, hizmet, API, test projeleri, komut dosyaları oluşturma ...) ve ortamlar (geliştirme, aşamalandırma, üretim) arasında net bir şekilde ayrım yapma ve adlandırma sözlü ve yazılı iletişiminiz üzerinde sürekli bir etkisi vardır (belgeler, proje adları, ...)
• Bir kaynak kodu yönetim sistemi kullanın (henüz yapmadıysanız). Dallanmayı projeniz ve kurulumunuzla nasıl kullanacağınızı düşünün.
• Yapılarınızı otomatikleştirin - kaynak deponuzdan bir ortam oluşturmayı mümkün olduğunca kolay hale getirin.
• Test projeleri , en azından daha karmaşık projeler için büyük projelerde bir zorunluluktur.
• Projenizin kullanılmaya hazır olduğu hazırlama ortamlarını kullanın . Ayrıca, otomatik bir hazırlama ayarı için örnek veriler oluşturun ve koruyun.
• Geliştirmeyi önceliklendirmeye ve planlamaya yardımcı olabilecek bir hata izleme sistemi kullanın ve ayrıca geçmiş hatalar ve bunların nasıl çözüldükleri için bir bellek görevi görür.
• Projenizin her bir parçasını diğerlerinden daha fazla belgeleyin . Ben şahsen: Genel Bakış - Mimari - Bağımlılıklar - Yapılandırma - Sık karşılaşılan sorunlar ( buradan ). Bazen daha azı daha fazladır - belgelerinizin eski olmasına izin vermemek için kısa ve öz olmanız ve belgelerin günlük etkinliğinizin bir parçası haline gelmesi daha iyidir.

Yönetim / ekip çalışması

... ya da kişiler arası düzeyde herhangi bir şey

• Diğer geliştiriciden beklentilerinizi tanımlayın . Makul olun, hiç kimse seninle aynı katılımı ve tutkuyu getirmeyecektir - en azından en baştan değil. Ne beklediğinizi, ne beklemediğinizi söyleyin, kendinizin ve diğerinin sorumluluklarını tanımlayın. Herkes bir mühendis, mimar, geliştirici, dba ve sysadmin değildir, ancak aradığınız şey buysa, doğru kişiyi seçin yoksa hayal kırıklığına uğrayacaksınız.
• İlk başta , kesin görevleri tanımlamak ve inceleme ve sonuçlarını tartışır. Yavaş yavaş, giderek daha az mikro yönetime başlayın. Fikir güven oluşturmak ve sorumluluğu arttırmaktır.
• Projenizi planlayın, projeniz ve gelecek yıl için ekibiniz için hedefler belirleyin. Bunu yazın ve daha sonra kontrol edin, bu perspektif verecektir . Bu hedefler ya da (onlar amaçlarıdır sürece başkalarına tebliğ olabilir veya olmayabilir sen , diğerlerini elde etmek gerekir), sadece kendi kontrol listesi olabilir.
• Yeni geliştiricinizin ilk ayını (veya iki / üç ayını) hazırlamak ve planlamak için bir gün ayırın . İyi hazırlanmış insanlarla çalışırken son derece motive edici buluyorum. Hiç kimse zamanının boşa gittiği izlenimini edinmemelidir.
• Bırakın . Bu senin bebeğin, başka biri de olmalı. En azından projenin bazı kısımlarında diğerinin sizden daha iyi bir uzman olmasına izin verin. Bu aslında başarılı olduğunuz anlamına gelir.
• Dinle - eğer onu işe aldıysan, söyleyecek bir şeyi var. Öğrenmeye hazır olun.
• Bilginizi ve deneyiminizi paylaşmaya hazır olun (ve bu nedenle zaman - sabırlı olun).
• Hatalar yapılacak, bunların nasıl ele alınacağı ve herkesin neyle ilgili önemli olduğunu öğrendikleri şey.
• Öğrenmek ve denemek için zaman tanıyın

Kitap referansları

Aslında okuduğum bazı yaygın kitapları listeleyeceğim ve okumaya değer olduğunu düşünüyorum, daha ayrıntılı bir açıklama için veya daha fazla kitap için SO'nun tam olarak bunun için sorduğu bazı soruları kontrol etmek isteyebilirsiniz. şu ya da bu soru.

Bu kitaplar ekipler, organizasyonlar ve programlama projeleri için gerçekten okumaya değer:

• Peopleware
• Efsanevi Adam Ayı
• Yazılım Sanatının Tahmini, Siyah Sanatın Keşfi

Bunların hiçbiri X metodolojisinin nasıl uygulanacağına dair pratik rehber değildir (Yazılım tahmini hariç, bu kitaplar uygun bir tahmin süreci seçmenize yardımcı olur). Tabii ki, Code Complete gibi kendini programlamaya daha çok odaklanan kitaplar da çok zenginleştirici.

Deneyimden konuşacağım, ancak herkesin farklı olduğunu unutmayın. Bunlar evrensel değil.

Bir şey kişisel olarak gitmesine izin vermektir. Bu proje 18 ay boyunca yaşadığınız ve yaşadığınız bir şeydir - doğal olarak her değişikliğin sizin yaptığınız gibi olmasını istersiniz. Bir meslektaşınıza hata yapması, öğrenmesi için bir tampon verin. Yararlı olmaları için bir oda oluşturun. Ve bunun hemen gerçekleşmeyebileceğini unutmayın. Ayrıca, kodun iyileştirme veya oluşturmada başarılı olduklarını hissedebilecekleri, kısa bir sürede başarı gibi hissettikleri bir şey varsa harika olurdu. Sabır ve hoşgörü burada iyi bir ödeme oranına sahiptir. Mikro yönetimi yönetmeye çalışmayın ve eleştirmek istiyorsanız, "yanılıyorsunuz" demek için bir değere sahip olduğunuzdan emin olun, bunu kanıtlayabilirsiniz, "dini" bir mücadele değildir.

Bir diğer önemli konu da sizin için doğru kişiyi bulmaktır. İdeal olarak kendinizden daha akıllı birini bulmak daha iyidir. Öznel ve görecelidir, ancak bir kişinin sahip olmadığınız bazı bilgi ve becerilere sahip olduğunu düşünüyorsanız, en iyisidir. Karşılıklı olarak ödüllendirici bir işbirliği olacak.

Gidebileceği iki yol var - meslektaşınız bir sürtünme olacak ve sonunda yaptıklarını yeniden yapacaksınız ya da ikinizin becerileri sadece toplanmakla kalmayacak şekilde çoğalacak ve birlikte çalışmayı gerçekten takdir edeceksiniz.

"Temiz, hızlı, yeniden kullanılabilir kod" konusunda - Bir röportaj öneriyorum, küçük bir mikro çekirdek / servis yöneticisi ve / veya iş yürütücü yazmayı rica ediyorum. Takılabilir bileşenlerin nasıl belirtildiğini ve yapılandırıldığını görün. Bitirilmesi gerekmiyor, önemli bir düşünce. Ve ayrıca hızlı bir şekilde bunu nasıl yapacağını iyi bilen insanları öğreneceksiniz iyi para ;-) İyi şanslar!

Benim almam: Dahili projenizin mimarisini, farkında olmayan biri için belgelemekle başlayın. Hangi varsayımların mevcut olduğunu ve ortak uygulamalardan ne zaman / nerede ayrıldığınızı ve nedenini açıklamaya çalışın.

Yapı otomasyonu: Harika fikir, bir geliştirici makinesi için yapılandırma otomasyonu ekleyebilir miyim. Daha kolay inşa etmek en kolayıdır (daha fazla / daha hızlı test dağıtımı).

Başka bir fikir (bana bir kez çok yardımcı oldu): Yeni geliştiriciden, kod tabanınızın farklı alanlarında bazı temiz küçük ölçekli görevler yapmasını isteyin, böylece düzen araçlarına vb. Alışacak. daha sonra karışıklık yaratabilecek belirsiz alanlar (örnek: bir yerde bir kabuk betiğinin iki satırı için emmm python kullandıysanız ve projeniz java tabanlıysa, bu iki satırın java'da yeniden yazılmasını isteyin, böylece 3 numaralı geliştirici çalışmak için daha az bilmek)

Ben ediyorum böylece deneyimsiz bir kişi tarafından berbat edilebilir iş gücüne gerek her şeyi otomatik hale odaklanmak . Yukarıdaki kısa yorumunuza dayanarak aşağıdakileri içerir:

• sürüm kontrolünü yükleyin ve manuel yedeklemeleri otomatik olanlarla değiştirin,
• otomatik dağıtımı olabildiğince ayarlayın (en azından, FTP yoluyla dağıtmak için elle yapmak yerine bir komut dosyası yazın.

Bunları yapamazsanız, ya bu görevleri sonsuza dek yapmak için zincirleneceksiniz veya yeni adam (lar) kaçınılmaz olarak er ya da geç bir şeyi berbat edecektir.

Diğer önemli görev @ dimitris'in belirttiği gibi belgelerdir. @S. Lott bu konuda çok daha fazla ayrıntı ekledi, bu yüzden tekrarlamak yerine ona +1 +1

Kısmen kişisel deneyime dayanan bazı düşünceler şunlardır:

• Projenizi belgeleyin . Tasarım özellikleri, diyagramlar, kılavuzlar ve yorumlar yeni çalışanın hız kazanmasına yardımcı olacaktır. Karmaşık bir sistemi sadece sözlü olarak açıklamak yavaş ve sinir bozucu olabilir. Tek kişilik projelerde dokümantasyon sıklıkla ihmal edilir. Sizinkinin bir istisna olduğundan emin olun.

• İlk olarak, yeni çalışana kodu yavaş yavaş tanımak için bazı "uygulama katmanı" işleri veya hata düzeltmeleri verirken, API / çekirdek düzey koduna kendiniz konsantre olun . Genel olarak, daha kolay , ancak anlamlı ve böylece ödüllendirici görevlerle başlayın .

• İletişim önemlidir. Yeni çalışanın sorularına, yorumlarına ve fikirlerine yanıt verin. Bir fikrin neden iyi olmadığını düşündüğünüzü açıklayın. Yeni bir göz çifti, iyileşme için odayı şaşırtıcı derecede iyi bir şekilde tespit edebilir. Yeni çalışanınız iyi biriyse, kodunuzu akran inceleyebilir ve sonunda mimari kararlara katılabilir. Tartışın, fikirleri birbirinizden alın. Bu, projenizde bir iş arkadaşınızın olmasının en büyük avantajlarından biridir.

• Yeni ekip üyenizin ne tür görevler üstlendiğini öğrendikten sonra sorumlulukları net bir şekilde tanımlayın . Her şeyi pürüzsüz tutmak için dokümantasyon uygulamaları ve kodlama kuralları oluşturun.

• Bir revizyon kontrol sistemi kullanın . Mantıksal kaynak dosyası düzenini koruyun ve disiplin oluşturun .

Röportaj gelince - adayın strese dayanıklı yeteneğini denemek istemiyorsanız, yapay kodlama testleri veya hile sorularının büyük bir hayranı değilim. Böyle bir durumda en akıllı problem çözücüleri bile kilitleyebilir. Aradığınız özellikler, diğerlerinin yanı sıra: dürüstlük , profesyonel yetenek , teknolojik bilgi / içgörü , coşku ve karşılıklı uyumluluk . Çalışma ortamı çok şey ifade edebilir; hoşunuza gitmeyen bir takım arkadaşı seçmek tavsiye edilmez. Sorularınızı doğru yerleştirin ve adayınızın iyi bir resmini elde etmek için gayri resmi tartışmalar yapın. İyi şanslar!

teknoloji

Geliştirici olarak bir başkasını getiriyorsanız, başlamadan önce çalıştırıp çalıştırmanızı tavsiye ettiğim üç temel şey vardır.

1. Kaynak kontrolü
2. Sorun takibi
3. Sürekli entegrasyon

Bu üç şey düzgün çalışıyorsa ve yeni bir ekip üyesi getirdiğinizde ortaya çıkan ortak sorunun yaklaşık% 75'ini ortadan kaldıracaksınız. Bu teknoloji parçalarının amacı, sadece kafanızda olanların çoğunu almak ve ekip üyenizle etkileşime girebileceği yerlerden çıkarmaktır.

Kaynak kontrolü, ikinizin de aynı şey üzerinde çalışmanızı sağlar. Sorun izleme, ne yapılması gerektiğini takip etmenize yardımcı olur ve ne üzerinde çalıştıklarını ve neleri başardıklarını bilmenizi kolaylaştırır. Sürekli entegrasyon ve test, tekrarlanabilir bir oluşturma işleminizin olduğundan ve yeni iyileştirmelerin kodun diğer bölümlerini bozmadığından emin olmanıza yardımcı olacaktır.

Pragmatik Programcı'nın bu konuda oldukça iyi kitapları var. İşte birkaç tavsiye ederim. Hangi programlama dilini kullandığınıza veya hangi sürüm kontrolünü kullanmak istediğinize bağlı olarak başka benzer başlıkları vardır:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / başlıkları / otomatik / pragmatik-proje-otomasyon

Kişiye özel

Çoğu zaman karşılaşacağınız zorluklar, şeylerin teknik tarafında daha az, yanlara gitmeyi öğrenmede daha fazladır. Başka birine projenin yönleri üzerinde kontrol vermek zor olabilir - özellikle de tüm bunları kendiniz yapmaya ve her bir kararı vermeye alışkınsanız. Yeni kişinin başlangıçta makul bir özgürlükle çalışmasını sağlayabileceğiniz bir alan bulabilirseniz kendinize biraz keder kaydedersiniz, böylece bir güven temeli geliştirebilirsiniz. İyi bir kişiyi işe alırsanız, muhtemelen öğreneceğiniz en önemli şey, tüm bireysel kararları verdiğinizle aynı olmasa bile, diğer kişiye iyi iş yapmak için nasıl güveneceğinizdir.

Yeni işe alımınıza, sorunları erken yaşta yakalayabilmeniz için önlemleri yerinde tutarken, kendileri için uygun şekilde çözme özgürlüğü vermek istiyorsunuz.

Bu noktalar bence çok önemlidir:

1. Kodunuzun önemli kısımlarını okuyun ve kolay anlaşılır olduklarından emin olun. Yorumları veya sezgisel işlevi ve değişken adlarını kullanın.
2. Yeni kişinin kod göndermesini kolaylaştırın.
3. Önemsiz değilse, yeni geliştirici için geliştirme ortamının nasıl kurulacağı konusunda gerekli tüm adımları açıklayan bir README dosyası oluşturun. Alternatif olarak, bu ortamın oluşturulmasına da yakından yardımcı olabilirsiniz.
4. Bu yeni proje üzerinde çalışırken yeni geliştiriciye çok net tanımlanmış görevler verin. Bence bu görevler yeni fakat basit bir işlevsellik içermelidir. Yeni geliştiricilerin ilk önce kodlama stilinize ve bu alışkanlıklara, kötü olsalar bile alışması gerektiğinden, temizleme görevleri bence pek mantıklı değil. Temizlik ve hatta yeniden düzenleme, kodu bilen kişiler tarafından yapılması gereken işlerdir.
5. Kod gönderme işleminin ne olduğunu netleştirin. (Örneğin sadece derleyen şeyler gönderin.) Ama çok katı olmayın, bu başlangıçta sinir bozucu olabilir.
6. Kodlama kurallarına sahip bir belge hazır bulundurun. Sözleşmeleri kodlayan diğerlerinin ne olduğunu tahmin etmek gerçekten sinir bozucu olabilir.
7. Uygulama karmaşıksa, mimariyi açıklayan bazı belgelere hazır olun. Ya da akış şemalarını veya benzer bir şeyi kullanarak mimariyi yeni kişiye açıklayın. Yeni geliştiricinin projenizi tersine mühendislik için çok fazla zaman harcamak istemezsiniz.
8. Yeni geliştiricinin dağıtımları kendisi yapması gerekiyorsa, dağıtmak için gerekli tüm adımları açıklayan düzenli bir kontrol listesi hazır bulundurun.

Ve son fakat en az değil: bir sürüm kontrol sistemi edinin. Subversion gayet iyi. Ancak, kullanıcıya özgü olan ve bu nedenle sürekli değişen bu Eclipse dosyalarını (veya her neyse) eklemediğinizden emin olun. Sizi saatlerce boşa harcarlar. Stackoverflow ile ilgili sorun yaşıyorsanız sormaktan çekinmeyin.