Bir meslektaşınıza kod nasıl tanıtılır

Ekibinizin yeni bir üyesine oldukça karmaşık ve birçok "gotchas" ile karışık olabilecek kod tabanını tanıtmaya nasıl başlıyorsunuz?

En kolay yolun, genel mimariyi diyagramlarla ortaya koymak ve yeni kişiye, koda daha alışık olduğu için iyi tanımlanmış (ve iyi kapsamlandırılmış) görevleri vermek için birkaç hafta (veya ay) sürmek olduğunu düşünüyorum.

Bununla birlikte, bir danışman (ve genç çalışan olarak), zaman kısıtlamaları veya takım rolü atamaları nedeniyle her zaman sahip olamam. (Ben bu özel projede herhangi bir kimse iki kat daha uzun süredir, bu yüzden "junior" hiçbir şekilde "kod / proje hakkında daha az şey bilemez.")

Projeye ve koda yeni bir üye tanıtmak için şimdi birkaç kez görevlendirildim ve ne yazık ki her bulduğumda, öncekinden çok daha iyi değilim. Diyagramları ve resimleri seviyorum, ancak çoğu zaman bir sistemdeki karmaşıklığı yeterince açıklamadıklarını hissediyorum. (Peki ya küçük olanların "yakaladıkları"?)

Proje, müşteriye dağıtacağımız bir noktaya geliyor ve işleri daha zor hale getirmek için, bilgi transferi yapacağım kişi aslında üniversiteden çıktı. (Üst düzey geliştiricilerle bilgi aktarımı yaparken daha iyi olduğumdan değil.)

Ayda bir kez bir kullanıcı grubuna ve ortaya çıkan diğer fırsatlara katılıyorum, bu yüzden yeni konulara tanıtılmak için kullanılmıyorum, ancak etkili bilgi paylaşımını acımasızca yetersiz olarak çoğaltma yeteneğimi hissediyorum.

Herhangi bir tavsiye büyük mutluluk duyacağız. Çoğunlukla takip edebileceğim bir rehber arıyorum. Örneğin: Nereden başlıyorsunuz? Nasıl ilerliyorsunuz? Bütün gün almadan dinleyicinin bilmediği teknolojileri veya kalıpları nasıl kapsıyorsunuz? İş mantığına ve kod yapısına nerede bağlanıyorsunuz?

Teşekkür ederim!

(Her zaman olduğu gibi, lütfen soruyu uygun gördüğünüz gibi düzenlemekten çekinmeyin.)

Birinci adım elbette koddan "gotchas" kaldırmaktır. Açık, özlü, tutarlı kod girmek, çalışmak ve hata ayıklamak daha kolaydır.

Nereden başlıyorsunuz?

Yeni gelenlere kod tabanına nasıl girmek istediklerini soruyorum. Herkes farklı öğrenir. Bazı insanlar üzerinde çalışmak için çok az görev yapmaktan hoşlanır. Bazıları mevcut kodda hata ayıklamayı sever. Bazıları kodun ne yaptığını anlamak için çalıştığını görmek ister. Bazıları giriş noktasında başlamak ve sadece dolaşmak istiyor. Bazıları visio diyagramları ister ... Hiçbir set deseni herkes için en iyi sonucu vermez.

Bütün gün almadan dinleyicinin bilmediği teknolojileri veya kalıpları nasıl kapsıyorsunuz?

Onlardan kaçınırım. Yeni gelenler sorana kadar kara kutular olsunlar. Daha sonra, kendi zamanlarında daha fazla bilgi edinebilecekleri veya daha sonra genel şeylerin ne zaman daha iyi bilindiklerini sorabilecekleri ipucu ile yeterli bilgi sağlayın.

İş mantığına ve kod yapısına nerede bağlanıyorsunuz?

Yapmamaya çalışıyorum. Yeni gelenlerin kendi başlarına öğrenmeleri neredeyse her zaman daha iyidir, böylece düşüncelerine daha doğal bir yapıda düşünürler.

Hatırlanması gereken bir şey, talimatı kısa tutmaktır. İnsanlar oldukça hızlı bir şekilde kontrol etme eğilimindedir, bu yüzden o noktada daha fazla talimat sadece 'yapışmaz'. Onlara 15-60 dakika boyunca bir şeyler gösterin (farklı insanların farklı dikkat süreleri vardır), daha sonra işlemek için 5-30 dakika ara verin.

Deneyimlerime göre, bir mimari diyagramın verdiği genel bakış ve aslında kodla çalışmanın cesur detayları arasındaki boşluğu kapatmanın iyi bir yolu, sistemin bir detayını yapmaktır, yani bir istek geldiğinde ne olur (sunucu kodu için) ) veya kullanıcı bir giriş yapar (istemci kodu için), daha sonra ilgili tüm kod katmanlarını adım adım açıklar.

Başka bir yol, kaynak kodun "rehberli bir turudur", yani paketler / ad alanları / modüller / dizinlerden geçerek her birindeki kodun genel olarak ne yaptığını açıklamaktır. Tabii ki bu, kodun mantıklı bir şekilde ortaya konmasını gerektirir.

Onlara kod tabanını öğretmiyorsunuz, onlara işinizi öğretiyorsunuz . Neye ihtiyaç duyabileceklerini düşünmeye çalışmayın, işinizi yaparken gerçekten bilmeniz gerekenlere bakın.

Hata izleyici geçmişinin son birkaç ayını çekin, kullanıcı hikayelerini, durum raporlarını ve kaynak kontrol taahhütlerini izleyin. En çok hangi dosyalara dokundun? Hangi kod en sorunlu? Hangi görevler seni en uzun sürdü? Muhtemelen, son birkaç aydır dokunmadıysanız, sandığınız kadar önemli değil.

Masanızdaki çıktı yığınına bakın. Son tarayıcı geçmişinizi kontrol edin. Sık kullandığınız kaydedilmiş e-postaları, kullandığınız kişileri, indirdiğiniz belgeleri arayın. Başkalarına aktardığım en faydalı referanslardan bazıları, sistemi ilk kez öğrenirken veya tasarlarken kendim için sakladığım notlar. Ne referans materyal için en yararlı olan sana ?

Sonra bilinen birikmiş işinizi yukarı çekin. Bu görevleri tamamlamak için hangi şeyleri araştırmanız gerekir? Hangi kod alanlarının sorunu büyük olasılıkla içeriyor? Bu bilgileri kendiniz için not alıyormuş gibi iletin.

Günlük çalışmalarınızdaki grafiklere veya diyagramlara atıfta bulunuyorsanız, bunları ekleyin. Hiç yapmadıysanız, muhtemelen halefiniz / meslektaşınız için bu kadar yararlı olmayacaktır.

Öğretirken en zor görevlerden biri kendinizi ayakkabılarına sokmaya çalışmaktır. Bu durumda, onların yerinde . En iyi şekilde yararlanın.

Destek çalışması en iyisidir, kolay bir böcek alın ve bulunacağı alanlarda yürüyün. kodun birbirine nasıl uyduğunu çabucak öğrenecekler. Doğal olarak, bu hata ve kod tabanı hakkında sorular sormaya gelecekler, ancak oraya ulaşacaklar (ve bir hata düzeltilecek). Çoğu zaman örneklerle bir şeyleri anlamak çok daha kolaydır, benzer şekilde, bir hata ayıklayıcıda içinden geçerek bir kod tabanı üzerinde çalışmak daha kolaydır.

Kod değişikliklerinden emin değilseniz (ya da kod koduna aşina olana kadar genellikle kod düzeltmelerimden emin değilim) sonra check-in işleminden önce inceleyebilirsiniz.

Tabii ki, mevcut geniş genel bakış ve blok diyagram fikirleriniz ilk adımlardır.