Umarım size biraz yardımcı olabilirim ya da en azından sizi doğru yönde gösterebilirim!
Yine de bir feragatname olarak, bu çok büyük bir konu - ve gerçekten derin bir anlayış elde etmek için " atılan " olduğunu düşündüğüm bir konu . Bununla birlikte, iki ana konuyu hızlı bir şekilde gözden geçireceğim:
- Kod ve kaynak kontrolü
- İletişim ve bazı ipuçları.
Özellikle OOP projelerine gelince - Dürüst olmak gerekirse OOP'a özgü başka yerde bulunmayan çok fazla sorun göremiyorum.
Aslında, OOP tarzı programlamanın takım gelişimi için inanılmaz derecede uygun olduğunu düşünüyorum. Sadece bilmek gerekir: OOP Bir anahtar ahlâki ben etkileşim ile her nesneyle ilgili tüm ayrıntıları bilmiyor gerektiğidir olabilir , ve ben bunu yapmak için nasıl alabilirim.
OOP'un sağlayabileceği soyutlamalar bir takımda harika.
Kaynak kontrolü
Projenin depolanması için merkezi bir yer olması ve birden fazla geliştiricinin herhangi bir zamanda kod tabanına erişmesini sağlayan bir yer olması gerekir. Git (veya SVN) gibi sistemler burada devreye giriyor.
Daha önce hiç SVN kullanmadığım için sadece Git hakkında konuşabiliyorum - ancak benzer ama farklı terminolojiye sahipler.
Git'i kullanarak belirli bir proje için tüm kaynak kodunu içeren bir havuz oluşturabilir ve ardından ekibimin depoya erişmesine izin verebilirim. Daha sonra yapılan her özellik veya hata düzeltmesi için, bireysel geliştiriciler kendi "dallarını" oluşturabilir, bu da paralel kanallarda gelişimin olabileceği anlamına gelir.
Bir özellik veya düzeltme tamamlandıktan sonra , ana projenin kod tabanına " birleştirilebilir ". Daha sonra herhangi bir " çakışma " Git tarafından algılanabilir ve sorumlu geliştirici tarafından kaynak düzeyinde çözülebilir.
Git'i daha önce kullanmış olup olmadığınızdan emin değilim, ancak ilk başta oldukça karmaşık görünebilir - ancak son popülerliği sayesinde (kısmen Github'a göre ) orada çok sayıda öğretici ve kaynak var.
Daha önce kullanmadıysanız, GitHub'a kaydolmanızı ve bu şekilde hissetmenizi öneririm! (Alternatif olarak, Bitbucket benzer bir alternatiftir, ancak ücretsiz olarak özel depolara sahip olmanızı sağlar.)
Git Flow , ekipler için inanılmaz derecede yararlı olan mükemmel bir Git tabanlı iş akışıdır. Genel olarak Git gibi, bir süre onunla çalıştığınızda onsuz bir takımda çalışmayı hayal etmek zorlaşır!
Haberleşme
Tüm teknik engelleri aştığınızda, çoğu projeyi (teknik ya da değil) rahatsız eden temel konuya inersiniz - bu iletişimdir.
Tüm ekibin kimin ne yaptığını, ne zaman yaptığını ve neyi etkilediğinin farkında olması gerekir.
Sorumluluğun açıkça tanımlanması gerekiyor
Bu açıktır, ancak çoğu proje, herhangi bir özellik isteğinin veya hatanın günlüğe kaydedildiği ve daha sonra belirli bir personel üyesine atandığı bir çeşit bilet sistemi kullanacaktır. ( JIRA , Unfuddle vb.) Genellikle bunlar, kaynak kontrol sisteminde yerleşik olarak bulunur ve bu da hayatı biraz kolaylaştırır. (BitBucket ve GitHub, birlikte barındırılan Git depoları için sorun izleme sağlar.)
Bu, geliştiricilerin yanlışlıkla aynı sorunlar üzerinde çalışmasını durdurur veya en azından önlemeye yardımcı olur.
Bu tam bir düzeltme değil; geliştiricilerin diğer geliştiricilerin sorumlulukları hakkında bilgi sahibi olmalarını sağlamanız gerekir. Geçmişte, belirli bir hatayı düzeltmek için karşılaştığım diğer sorunları düzelttiğimi biliyorum, sadece mantıklı olduğu için. (" Eh, ben zaten buradayım. Bu bir refactor ile yapabilirdi ve belki de başka sorunları kontrol edebilirim. ") Sonra diğer geliştiricilerden özür dilemek zorunda kaldım. sabit - zamanımızın boşa harcıyor.
Genel olarak, bu sorunlar ...
Düzenli buluşmalar
Bazı proje yönetimi / geliştirme yöntemleri belirli iletişim yöntemlerini veya toplantı aralıklarını belirler. Genel olarak, gördüğüm en verimli sistemler, bir takımdaki herkesin yaptıklarını hızlı bir şekilde gözden geçireceği sabah stand-up toplantıları olmuştur - bunu sadece geliştirme ekibi üyeleriyle sınırlarsanız ve ne hakkında net yönergeler varsa iletişim kurmak için bunlar inanılmaz derecede etkili olabilir. Her zaman bağlı kalmaya çalıştım:
X üzerinde çalışıyorum,
Y'ye ulaşmak / düzeltmek için,
Bu Z'yi değiştirmeyi / değiştirmeyi içerir.
Diğer ekip üyeleri hemen " Fergus'ın geçen gün kaydedilen hatayı düzeltmeye çalışıyor, ancak bu, bakmam gereken bazı kodlar üzerinde çalıştığı anlamına geliyor - Herhangi bir değişiklik yapmadan önce onunla kontrol edeceğim. ".
Mimari toplantılar
Kısa bir süre önce , daha büyük / mimari konuların tartışılacağı iki haftada bir " teknik sohbet " yapan harika bir ekiple çalıştım . Ekibin her üyesi, projenin karşılaştığı daha büyük sorunları anlamak için zamana sahipti ve olası düzeltmeleri tartışabiliyordu.
Şahsen bunu çok sevdim, projeye yeni katıldığım için çok katkıda bulunmadım - ama tartışmaları dinleyebilmem bana çok fazla fikir verdi ; çok geçmeden projeyi ve bireysel düşünme stillerini anlayabiliyordum.
İletişim, herhangi bir takımı aşağı çekebilecek tek konudur . Teknik ya da değil, eğer insanlar daha büyük resmin farkında değilse, başarısız olma şansları daha yüksektir.
Diğer sorunlar
Bir ekipte çalışırken herkesin aynı yapılandırmaya veya stile sahip olmasını sağlamak iyidir. Ne demek istiyorum?
Yapılandırma
Bir Java projesi üzerinde çalışıyorsanız - belki de (en azından geliştirme ortamları için, kesinlikle test etmek için değil) sağlamak JVM sürümleri ekip arasında yaygındır, iyi bir fikir olabilir mi? Sonra IDE'ler. Tüm ekip Eclipse veya NetBeans veya seçtiğiniz IDE'nizi kullanıyorsa büyük ölçüde yardımcı olur .
Bir web projesinde, tüm geliştiricilerin belirli bir yığına ihtiyacı olabilir; belirli Apache veya PHP sürümleri ile.
Bunun gibi faktörleri düşünmek, ekibin aklımda biraz daha hızlı "jelleşmesine" izin verir.
stil
Sekmeler ve boşluklar mı? CamelCase veya spacing_with_underscores? Bu sorular, yalnız çalışırken olabildiğince küçük, daha büyük bir ekiple çalışırken, ortak bir tarza doğru çabalamak istersiniz.
Aslında, belirli bir kod bölümünü kimin yazdığını gerçekten söyleyememelisiniz - sadece bunun ait olduğunu bilmelisiniz .
Bu nedenle, birçok açık kaynak projesi açıkça kaynak kodu biçimi yönergeleri / stil kılavuzları yayınlamaktadır - bunların neler içerdiği hakkında bir fikir edinmek için kendi açık kaynak projeleri için Google StyleGuides'e göz atın .
Görevler ve Birim Testleri
Bu sadece takımlarla sınırlı değil, özellikle bir nedenden dolayı buna hızlıca değineceğim: takım hayatını çok daha kolay hale getiriyor.
Çok sayıda bağımlılığa sahip karmaşık bir iş akışınız veya uzun bir oluşturma süreciniz varsa - genellikle bir görev çalıştırıcısı kullanarak bunu otomatikleştirmek yararlıdır. Web projeleri için GruntJS harika, Java'dan gelmesine rağmen Apache Ant'in oldukça benzer olabileceğini düşünüyorum.
Bir birey olarak , sitemi FTP sunucuma dağıtmadan önce oluşturmak için GruntJS kullanıyorum - bir Grunt komutu, CSS / Sass'ımın derlenmesi ve küçültülmesi , varlıklarımın sıkıştırılması ve daha sonra dosyalarımın yüklenmesi için ihtiyacım olan tek şey.
Yine de bir ekip üyesi olarak, herhangi bir testi kırmadığımı ve projenin diğer bölümleri hakkında tam olarak farkında olamadığım hataları kontrol etmediğimi kontrol etmek için GruntJS'yi kullanabilirim. Bu elbette, bireysel bir geliştirici olarak bana sağladığı faydalara ek olarak.
Fantezi kaynak kontrol paketimi (Git) kullanarak bir projeyi klonlayabilmem için de kullanabilirim ve tüm bağımlılıklarımı yüklemek için bir komut çalıştırabilirim. Yeni bir geliştiriciyi, gelişmeye başlayabilecekleri konuma almak için harcanan zaman oldukça büyük olabilir - bilinmedik bir kod tabanına alışmak için gereken süreyi göz önünde bulundurmadan.
belgeleme
Gördüğüm en iyi projelerin geliştiricilere yönelik belgeleri vardı (ve genellikle oldukça aşırı). Bu tür belgeler aşağıdaki gibi şeyleri açıklayabilir:
1. geliştirme ortamı:
"Şu anda LAMP yığını çalıştıran bir sunucuya konuşlandırıyoruz , çünkü bu tür geliştiricilerin özetlenen sürümleri hedeflemesi gerekiyor."
2. İş akışı
"Tüm özellikler bir 'özellik / *' dalında geliştirilmeli ve piyasaya sürülmeye hazır olarak değerlendirilmeden önce" test "dalıyla birleştirilmelidir."
3. Takımdaki sorumluluklar:
"Veritabanı sorunları için Steve ile konuşun. Platform sorunları için David ile konuşun."
4. Gelecek için bir " boru hattı "
"Yeni kod geliştirirken, Haziran 2014'ten itibaren x - eski kodunu uygulamak istediğimizi, bunun gerçekleşmeden önce gözden geçirilmesi gerekebileceğini unutmayın."
Örnekler
İster kendi iş akışına sahip (genellikle yoğun bir şekilde belgelenmiş) yerleşik bir çalışma ister GitHub'daki birçok örnekten biri olsun, nasıl çalıştığına dair bir fikir edinmek için açık kaynaklı bir projenin iş akışına bakmaya değer olabilir.
Son bir uyarı kelimesi
Kendinizi tüm bunları doğru yapmayı başaran bir ekipte bulursanız .. başka bir yerde olmaktan nefret edeceksiniz ..! Benden al, iyi bir takım yaşadıktan sonra aniden başka yerlerdeki sorunlar seni gerçekten aşağı çekebilir. (Bu başka bir yazı için bir hikaye!)