Ekibinizin hangi sınıfları ve işlevleri yazdığını nasıl takip edersiniz?


43

Kod üzerinde çalışırken, takım arkadaşlarımın yaptığı zorlukların birçoğuyla yüzleşiyorum ve bazı yararlı fonksiyonlar ve sınıflar yazdım ve onlar da öyle. Eğer iyi bir iletişim varsa, birilerinin bir araya getirdiği harika şeyleri duyacağım ve altı ay sonra ihtiyacım olduğunda onu hatırlayabilir ve bu fonksiyonu çağırarak zaman kazanabilirim. Eğer hatırlamıyorsam ya da hiç bilmiyorsam, muhtemelen tekerleği yeniden icat edeceğim.

Bu tür şeyleri belgelemek için özel bir uygulama var mı? Bulmalarını nasıl kolaylaştırıyorsun?

Ekibinizde böyle bir dokümantasyon yoksa, tekerleğinizin mevcut olup olmadığını nasıl anlarsınız?

DÜZENLE:

Şimdiye kadarki cevaplardan biri dışındaki herkes ideal bir durumla ilgileniyor, bu yüzden şu çözümleri özetleyeyim: dokümantasyon ve iletişim; Wiki'ler, stand-up toplantıları, vb. Bunların hepsi harika şeylerdir, ancak programcıları dokümantasyonu yazmak ve toplantılara katılmak ve not almak ve her şeyi hatırlamak için zamana (ve becerilere) sahip olan programa güvenirler.

Bugüne kadarki en popüler cevap (Caleb), belgelendirme ve toplantı yapamayan bir programcının kullanabileceği ve yalnızca bir şeyi yapan tek cevaptır: programlama. Programlama, bir programcının yaptığı şeydir ve evet, büyük bir programcı dokümantasyon, birim testleri vb. Yazabilir, ancak bununla yüzleşelim - çoğumuz dokümantasyonu programlamayı tercih ediyoruz. Çözümü, programcının yeniden kullanılabilir kodu tanıdığı ve kendi sınıfına veya deposuna veya her neyse onu çıkardığı ve izole olduğu gerçeğine göre, onu bulabilir hale gelir ve kullanımı için öğrenme eğrisini kolaylaştırır ... ve bu programlama ile başarıldı.

Bir şekilde şöyle görüyorum: Sadece üç işlev yazdım ve bana göre başkası bunları bilmeli. Onları belgeleyebiliyor, yazabiliyorum, bir toplantıya duyuruyorum, vs. - yapabiliyorum, ama bu benim gücüm değil - veya ... Onları bir sınıfa çıkarabilir, iyi adlandırabilir, fonksiyonlarını yerine getirebilirim. bir kara kutu ve diğer sınıf dosyalarının gittiği yere yapıştırın. O zaman kısa bir e-postayı duyurmak kolaydır. Diğer geliştiriciler kodu tarayabilir ve kodu tam olarak anlamadıkları izole edilmiş bir fonksiyondan daha iyi anlayabilirler - bu bağlam kaldırılır.

Bunu sevdim, çünkü iyi adlandırılmış bir sınıf dosya dizisine sahip olmak, iyi adlandırılmış yöntemlerle, iyi bir programlama ile yapılan iyi bir çözümdür. Toplantı gerektirmez ve detaylı dokümantasyona olan ihtiyacı yumuşatır.

İzole edilmiş ve zamanın bastırılmış geliştiricileri için ... bu konuda başka fikir var mı?


5
Daha büyük bir ölçekte sormak için soruyu genişletirim, belki de 100'den fazla çalışanı olan bir şirkette aynısını nasıl yaparsınız. Daha önce yapılan çalışmaların tekrarlanmasını önlemek için hangi en iyi yöntemler yapılabilir?
Asaf

1
@Sağla - Doğru cevabın popülasyonun büyüklüğüne bağlı olacağından şüpheleniyorum - 5 kişilik bir dükkanda çalışanlar 50 için işe yaramaz ve 50'de çalışanlar için 500 çalışanlar yok.
Dan Pichelman,

3
Bu harika bir soru!
Rocklan

4
Conway Yasası : "sistemleri tasarlayan kuruluşlar ... bu kuruluşların iletişim yapılarının kopyaları olan tasarımları üretmekle sınırlıdır".
Mark Rushakoff,

2
@nathanhayfield: 1 dev, bir dereceye kadar 2 dereceye kadar çalışabilecek bir çözüm, ancak 20 veya 100 değil. Ve tek başıma çalıştığımda bile yardımcı fonksiyonları tematik olarak ayırmayı tercih ediyorum.
Doc Brown,

Yanıtlar:


29

Kütüphaneler. Çerçeveler. Sürüm kontrolü

Yeniden kullanılabilir kodunuz varsa, istediğiniz en son şey farklı ekip üyelerinin kaynak kodu projelerine kopyalamalarıdır. Bunu yaparlarsa, şans biraz burada değişecek ve orada biraz ince olacak ve yakında hepsinin aynı adı taşıyan ancak her birinin biraz farklı çalıştığı düzinelerce işlev veya yöntem var. Veya, belki de daha muhtemel olarak, orijinal yazar, hataları düzeltmek, daha verimli hale getirmek veya özellikler eklemek için kodu düzeltmeye devam edecektir, ancak kopyalanan kod asla güncellenmeyecektir. Bunun için teknik isim büyük bir hilkat garibesi .

Doğru çözüm, yeniden kullanılabilir malzemeleri ilk olarak hangi projede kurduğunuzdan çıkarmak ve kendi sürüm kontrol havuzunda bir kütüphane veya çerçeveye koymaktır. Bu, bulmayı kolaylaştırır, ancak kullanan diğer tüm projeler için dikkate alınmadan değişiklik yapma konusunda cesareti kırır. Birkaç farklı kütüphaneye sahip olmayı düşünebilirsiniz: bir tanesi, artık değişmesi muhtemel olmayan iyi denenmiş bir kod için, bir tanesi sabit gibi görünen, ancak iyi bir şekilde test edilmemiş ve gözden geçirilmiş, bir tane de eklemeler için.


5
Ayrıca, tekrar kullanılabilir kütüphane için çok kapsamlı bir regresyon testi yaptırmanızı tavsiye ederim. Değişim zararsız görünse bile, biri bu davranışa bağlı olabilir.
Bobson,

2
Teknik terimin BBOM olduğunu sanıyordum .
zzzzBov

2
Cevabınız ilk bakışta mantıklı geliyor ve smallr ila orta büyüklükte bir ölçekte, “kopyalamıyor” direktifinin karanlık tarafını da gördüm. Farklı ürünler için, farklı lisans koşullarına, farklı yaşam döngülerine ve farklı bakım sözleşmelerine sahip farklı takımlarınız varsa, istediğiniz en son şey , farklı ürünleri, bu bakım gereksinimlerini karşılamayan, evde üretilen bir kod parçacıkları kitaplığına bağlamaktır. . Senaryo ihtiyacı için bu tür Kütüphaneler çok yüksek kalitede olması ve bazen bir takım için onun daha effient kodu ve .. kopyalamak
Doktor Brown

3
@Caleb: Sakin ol, gönderimi tamamen oku. Demek istediğim şu: kodun başka bir yerden kopyalanması, ayarlanması ve bir takım kütüphanesine dahil edilmesi sizi mutlaka “geleceğe giden yol” haline getirmez. Örtüşen işlevselliğe sahip iki lib'iniz ve her birinin lib'lerini korumaktan sorumlu iki ekibiniz varsa, durum o kadar da kötü değildir. Bir takım, çünkü zaten mükemmel değil olabilir de, diğeri yapar bazı işler yapmak, ancak bazen bu takımlar bağımsız beeing tutmak avantaj çift işi ağır basar.
Doktor Brown,

1
@DocBrown Kod kopyalamanın gerekli olduğu durumlar vardır , ancak kodun ilk olarak paylaşılmasından dolayı yapmak zorunda olduğunuz bir şey değil, bilinçli bir karar olmalıdır.
Caleb,

13

Bunun için bir yaklaşım, bu amaç için bir Wiki oluşturmak ve hangi yeniden kullanılabilir bileşenlere, bir problemi nasıl çözdüğünüze vb. İlişkin bazı üst düzey dokümanlar yazmaktır.

Zor olan kısım, ekibinizde her birinin sürekli olarak bu Wiki'yi sürdürmesini sağlamaktır. Ancak başka herhangi bir belge de aynı sorundan muzdariptir.

Kodunuzun bazıları, yeniden kullanılabilir bir kitaplığa koymak için yeterince iyi olabilir. Bu, daha sonra kodu tekrar bulmayı da kolaylaştırır.


5
Bir wiki kodu yaymanın doğru yolu değildir. Kod hakkında iletişim kurmak için harika bir yol , ancak (cevabımı görün) insanların bir wiki parçasından daha büyük bir şey kopyalamasını ve projelerine yapıştırmasını istemiyorsunuz.
Caleb

@Caleb iletişim zor kısmıdır
jk.

jk - C
JeffO

3
@Caleb: OP'nin sorunu, kodu yaymakla ilgili değildi, soru daha sonra iletişim kurmak ve bulmaktı.
Doktor Brown,

@DocBrown Yine, wikiler iletişim kurmak için mükemmeldir ve muhtemelen GitHub gibi araçların yerleşik bir yapıya sahip olmasının nedeni de budur. Bu bir wiki olabilir , ancak insanların gerçekten kullanacakları koddan bahsediyorsak (bir çözümü gösteren bir parça parçacığa karşı) , bir tür kütüphane olmalı, üretilebilir, test edilebilir ve Er ya da geç güncellenmesi gereken yerlerin sayısı çarpılmadan birleştirilebilir.
Caleb,

7

700 çalışanı olan bir şirkette, 2 ila 20 kişi arasında değişen ekipler arasında olmak benim deneyimim.

Takım düzeyinde

Her gün yaklaşık 15-20 dakika "standup toplantıları" yapıyoruz. "Bu işlevi dün yaptım, çok zorluyor" gibi genel bilgileri hızla paylaşabiliriz.

Ayrıca proje başına bir wiki'miz var. Bu, yerleşik özel sınıflar / fonksiyonlar dahil olmak üzere, projede neler yapıldığı hakkında bilgileri (teknik) paylaşabiliriz.

Ajans düzeyinde

Ajans düzeyinde 4 aracımız var:

  • Başka bir wiki. Donanım ve diğer konular hakkında bize bilgi vermek için esas olarak orada bulunuyor, ancak bazen şirket düzeyinde koymadan önce incelenecek teknik bilgileri paylaşmak için kullanıyoruz.
  • Haftalık toplantılar Çoğunlukla her takımın / projenin ilerlemesini biliyorlar, ancak çoğunlukla teknoloji meraklıları olduğumuz için harika şeyler üretebiliriz.
  • Mail listesi. Ajanstaki herkesle bir mailimiz var. Çok güzel şeyler / eğlenceli şeyler / faydalı şeyler oradan geçer.
  • VCS deposu. Her ajansın küçük projelerin bulunduğu kişisel depoları vardır, çoğunlukla farklı projelerde kullandığımız modüller.

Şirket düzeyinde

Şirket düzeyinde, daha organize.

"Ajans seviyesi" wiki aslında şirketin wiki'sinin bir parçası.

Ve wiki daha sonra teknolojilere göre ayrılır. Böylece, herkes onu iyileştirebilir, araştırabilir ve temel olarak wiki'ye bir hayat verebilir.

Ayrıca abone olabileceğimiz posta listeleri de var. Ajanstaki herkes abone olabilir ve çoğu insan en az bir ya da iki teknolojiyi takip eder, aslında çoğu insan 5-10'unu takip eder.

Ve VCS elbette en iyi kod paylaşım sistemidir.

Sonuç

Özetle, kesin bir kesin çözüm yok. Bilgi paylaşımı her zaman büyük bir sorun olmuştur ve muhtemelen kalacaktır. Bilgi tabanı oluşturmak için birçok çözüm vardır ve biri muhtemelen faturanıza uyabilir. Ancak, mevcut çözümler her zaman çok akıllı olmadığından bazı insanlar daha iyi bir KB almaya çalışıyor.


Sonucun "wiki, wiki, wiki, wiki, wiki" den başka bir şey söylememesi gerektiğini düşünüyorum, ancak ciddi bir notta, iyi bir cevapta, bir iç wiki, daha üst düzeydeki ayrıntıları veya kullanım yaşını ayrıntılandırmak için iyi olabilir. aranabilir olmak iyi bir zaman tasarrufu.
RhysW

6

Her şey iletişimden kaynaklanıyor.

Wiki'ler harika ve kesinlikle bir tane kurup kullanmalısınız. İyi bir iç programcı intraneti, eğer insanlar onu okuyup güncellerse iyidir, bu yüzden aslında orada bir insan probleminden bahsediyorsunuz. Herkesin bir araya geldiği ve neler olduğuna dair genel bir bakış sağlayan haftalık "ekip güncellemesi" toplantıları önerebilirsiniz. Teknoloji liderleri (en azından!) Bir araya gelmeli ve her takımın ne yaptığı hakkında sohbet etmelidir. "Kahverengi Çanta" gayrı resmi oturumlar harikadır, öğle yemeğinde onları planlayın ve insanlarla konuşun.

Ayrıca, bir kod paylaşma, paketleme, sürümleme ve dağıtma yöntemine de ihtiyacınız vardır. Gerçekten iyi yönetilen bir kaynak kod deponuz varsa, "ortak" ve proje klasörlerinde iyi düzenlenmişse işler daha kolay olacaktır.

Eğer böyle bir şey yapılmadıysa, patronunuzla bir araya gelin, şirkete nasıl fayda sağlayacağını açıklayın ve ileriye dönük bir yol önerin :)


1
Cevabınızda "ortak" kavramı biraz daha ilerletirim.
JeffO,

4

Kod inceleme oturumları yardımcı olabilir. Ekibiniz neyin geliştirildiğini tartışmak için düzenli olarak toplanırsa, o zaman bir çözüm bulan kişi diğerlerine nasıl kullanılacağını gösterebilir. Birisi, üzerinde durdukları bir noktaya değerse, diğer ekip üyeleri mevcut bileşenlerin yeniden kullanımını artıran bir yaklaşım önerebilir.


1
Öyleyse, 4 yıl ve 600 sonra bir işlev yapmış olduğunu hatırlamak istediğinizde işler mi? OP'nin sorununun bir kısmı yaratılmış olan her şeyi hatırlamaya çalışıyordu, bu başlangıçta iyi olabilir, belki de bir ya da iki ay boyunca beklemeyecek
RhysW

2

Böyle bir şeyle başa çıkmanın en iyi yolu, bazı basit kuralları olan bir depo yapısına sahip olmaktır; böylece bir programcı olarak, bir işlev varsa doXYZ, kabaca o işlevi aramam gereken bir yer olduğunu biliyorum. Ad alanları, dizinler, modüller, eklentiler, paketler, ne kullanıyorsanız kullanın, kodunuz modüler olmalıdır, böylece aynı şeyi yapan veya aynı veri kaynaklarına erişen işlevler çoğunlukla aynı noktada olur.


0

İdeal olarak, yazarın her kontrolde kod incelemesi yapması dışında en az bir kişi daha olması gerekir. Kod gözden geçirme işlemi, kontrol edilmekte olan birçok yinelenen yöntemin sorununu hafifletmeye yardımcı olabilir.

TL; DR: Her check-in için kod incelemeleri.


2
Anlamadım. Test edilmiş ve çalışan bir kodu atmak mı istiyorsunuz, çünkü kod incelemesinde yinelenmiş gibi görünüyor? Soru, kopya kodun ilk etapta nasıl yazılmaması gerektiğiydi. @ Daenyth'in cevabı gibi bir oturum daha iyi görünüyor.
adrianm '

Bir gözden geçiren, işlevselliği kopyalayan bir kod eklediğimi söyleseydi ve baktıklarını doğru bulduğumu söylerse, evet, dupe kodunu hurdaya çıkardım. (Uygulamamın daha iyi olup olmadığını da kontrol edebilirim ve eğer öyleyse, yeni bir uygulama eklemek yerine diğer uygulamayı da değiştirip değiştiremeyeceğime bakın.)
Carolyn
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.