Kodun yeniden kullanımı ve dokümantasyonu nasıl teşvik edilir? [kapalı]

Yaklaşık 10'dan fazla geliştiriciden oluşan bir ekip olarak, kodun yeniden kullanılmasını teşvik etmek istiyorum. Çok fazla kod yazdık - birçoğu son birkaç yıldır tekrar ediyor. Sorun şu ki, bu kodların birçoğu diğer bazı kodların kopyası veya küçük bir varyasyonu.

Gelecekteki projeler için yeniden kullanılabilmeleri için bileşenlere nasıl kod yapılacağı ile ilgili harekete (tartışma) başladım, ancak sorun, yeni geliştiricilerin veya bileşenlerden habersiz olan diğer geliştiricilerin sadece ilerleyeceğinden ve kendi şeylerini yaz.

Geliştiricilere mevcut kodu çoğaltmak ve üzerinde ince ayar yapmak ya da sadece kendi kodlarını yazmak yerine bileşenleri yeniden kullanmalarını / belgeleri iyileştirme / temel bileşene katkıda bulunmalarını hatırlatmak için yine de var mı?

Bileşenleri herkesin kullanması için kolayca keşfedilebilir, kolayca kullanılabilir hale nasıl getirebilirim?

Her geliştiricinin yeniden kullanılabilir bileşenlerin faydalarını bildiğini ve kullanmak istediğini düşünüyorum, sadece onları nasıl keşfedilebilir hale getireceğimizi bilmiyoruz. Ayrıca, geliştiriciler kod yazarken, yeniden kullanılabilir kod yazmaları gerektiğini ancak bunu yapmak için motivasyon eksikliği olduğunu biliyorlar.

Belgelere ihtiyacınız var, doğru olanı. Bulmak ve gezinmek kolay olmalıdır. Ayrıca disipline de ihtiyacınız var. Yeniden kullanılabilir kod kitaplıklarınızda zaten bir çözüm varsa, ancak geliştirici kendi çözümünü kullanmayı tercih eder (herhangi bir sebep olmadan), çözümünü geri almalı ve mevcut çözümü kullanmasını söylemelisiniz.

Euphoric'in soruya yaptığı yorumu da kabul ediyorum. Farklı projeler arasında herhangi bir şeyi yeniden kullanmak genellikle imkansızdır (genellikle tüm CRUD işlemleri aynı görünür, ancak genellikle bunları tekrar kullanamazsınız).

Daha önce bahsedilen faktörlerin yanı sıra "dokümantasyon", "bulunması ve gezinmesi kolay", "disiplin" ve "kod görünümü"

yeniden kullanılabilir kod

• kullanımı kolay (= örneklere ihtiyaç vardır, yani birim testleri)
• diğer modüllere çok fazla bağımlılık olmadan ve
• bu kütüphane kullanmak için benim aplikasyon güncellemek zorunda donot istikrarlı bir API olması gerekir .

Son iki öğe olmadan istemediğimiz "kopyala ve geçmişten kalıtım" ı kullanmak çok daha kolaydır.

Onları kodları yeniden kullanmanın en iyi yolu motivasyon. Yeniden kullanılabilir bileşenleri Euphoric'in önerdiği gibi ekstra projelere koyarsanız, buna çok çaba gösterin. Çalıştığım yerde, yapılandırılabilir yürütme planlarında önceden tanımlanmış bir dizi arabirim çalıştıran ve birkaç hizmet (örneğin DB_interaction, FTP-Service, ... için farklı sınıflar) sağlayan bir proje yaptık. Proje büyük bir başarı, çünkü geliştiricilerimiz aslında mikro çerçeveyi kullanmak istiyor , çünkü benzer projeler için kazan plakası yazmak için onlara çok zaman kazandırıyor. Aynı şey Listeler, Dizeler, vb. İçin Yardımcı Programlar kitaplıkları içindir, ancak bu durumda var olanı bir kez kullanmak istersiniz. (neden ağzı yeniden icat ettiniz?)

Sonuç: Geliştiricilerinizin iyi test edilmiş tekrar kullanılabilir bileşenlerin faydalarını deneyimlemelerine izin verin. Ama aynı zamanda Andrzej Bobak'ın cevabına da katılıyorum: Birçok şey yeniden kullanılamaz, çünkü benzerler, ama aynı değiller.

Bu insanlar, çünkü zor olacak gibi o yapıyor gibi basit bileşenleri için yeni kod yazmak ve onlar kendi yolunu. Mevcut bir çözümden yararlanmak ve onu genişletmek, yeni gereksinimlerle tamamen yeni bir uygulama yazmaktan daha zordur. Belirtildiği gibi yapmanız gereken, yeni bir bileşen yerine mevcut bileşenlerin kullanılması / genişletilmesi gereken durumların belirlenmesine yardımcı olmak için ekip arasında bir kod inceleme süreci başlatmaktır.

Ayrıca, insanların başvurabilmeleri ve ihtiyaç duyduklarını kolayca bulabilmeleri için çok iyi ve kapsamlı bir dokümantasyona sahip olmanız gerekir. Belgeler eksik veya gerçek şeyle senkronize değilse, insanlar bu belgeyi aramak veya geliştirmek için motive olmayacaktır.

Ekip liderliğinde, insanları kendi bileşenlerini oluşturmadan önce benzer bir bileşen olup olmadığını kendilerine sormaya ve onları arayabilmeleri için belgelere yönlendirmeye teşvik etmelisiniz. Birisi mevcut bir bileşeni kaçırırsa kod inceleme sürecinin yakalayacağından emin olabilirsiniz, ancak kendi uygulamalarına zaten 10 saatlik geliştirme koyarlarsa ne olur? Takımda iyi araştırma davranışları uygulayarak bu durumlardan kaçınmanız gerekir.

Bu sorunla şu anda üzerinde çalıştığım büyük bir projede karşılaştık. Son birkaç aydır geliştiricilerin rotasyonu oldu, aynı zamanda oldukça büyük bir kod tabanı ve en başından beri projede olanlar bile her santimini bilmiyor.

Kod genellikle iyi yazılmış ve tek sorumluluklarla küçük parçalara bölünmüş ve dokümantasyon orada olsa da, yapılan bir şeyi kaçırmak oldukça kolaydır. Tutarlı adlandırma kuralları çok yardımcı olur, çünkü herhangi bir IDE'de bir şey aramak kolaydır. Belgeler kapsamlı olabilir ancak daha uzun büyüdükçe okumak biraz acı verici olur.

Benim görüşüme göre durumu büyük ölçüde iyileştirdiğimiz bir şey, Yıldırım görüşmeleri dediğimiz bir şeyin başlamasıydı . Birisi takıma bilinmesi gerektiğine inandığı bir kod parçası yazdığında, kısa (genellikle 5-15 dakika) bir sunum düzenlenir. Bunu haftada bir kez yapmaya çalışıyoruz. Konular, yeni özellikler ve yakın zamanda ortaya çıkan karmaşık problemleri ele alma yöntemlerinden, test / kodlama yaklaşımları, yeniden kullanılabilir bileşen, uygulamanın temelleri ve yeniden düzenleme işlemlerine kadar değişme eğilimindedir.

Şirket genelinde benzer görüşmelerde bazı konulardan bahsedilmektedir. Bilgi paylaşımını teşvik etmenin oldukça etkili bir yolunu bulduk. Kısa bir sunumu görmek ve hatırlamak ve ek dokümanları nerede arayacağınızı veya kimin yardım alacağını bilmek çok uzun ve nadiren yapılan eğitim oturumlarına katılmaktan ya da sadece orada oturmak, belgelerin kapsamını okumaktan çok daha kolaydır.

Şirket çapında görüşmeler ilk sırada gerçekleşti. Bu yaklaşımı projeye özgü bilgi paylaşımı için benimsedik ve bence oldukça iyi çalışıyor.

Çift programlama aynı zamanda bilgi dolaşımını çok daha hızlı hale getirir.

Bunun aslında iki soru olduğunu düşünüyorum - her ikisine de cevap vermeye çalışacağım.

1) Bir kod tabanındaki yinelenen kodu nasıl azaltabiliriz.
Kendimize bunu yapmanın faydasını hatırlatmaya yardımcı olur: yinelenen iş mantığı nedeniyle daha az hataya neden olur ve daha az kodun korunması gerekir. Bunun gerçekleşmesini azaltmanın en iyi yolu, diğer cevaplarda belirtildiği gibi iletişimdir. Kod gözden geçirme sorumluluklarını eşit bir şekilde yaymak için kod gözden geçirme sorumluluklarını eşit olarak paylaşmanız gereken ekstra uyarı ile kod önerilerini kullanma önerisini şiddetle kabul ediyorum. Ayrıca, günlük stand-up'lar kullanmalısınız, böylece geliştiriciler, birisi yararlı kod içeren bir sorunu çözmeye çalıştığında sık sık tanıyacaktır. Bilgi paylaşımını artırdığı ve programcıların disiplinli kalmasına yardımcı olduğu için kod eşleştirmeyi de göz önünde bulundurmalısınız.

Ayrıca, geliştiricilerinizi mümkün olduğunca birbirine yakın, tercihen aynı odada tutmanızı da öneririm. Çok sayıda paylaşılan yazı tahtası ve alan. Sonra onları birlikte yemek için gönderin. Geliştiricileriniz ne kadar "bağ" kurarsa, birbirleriyle o kadar iyi iletişim kurarlar.

Bir wiki veya benzeri bir belge kodu kullanma önerisini kabul etmiyorum. Disiplinli geliştiriciler ne kadar uğraşmaya çalışırlarsa olsunlar dokümantasyon orijinal koddan sapacaktır. Daha etkili bir yaklaşım, spesifikasyonun örnek stil testleri ile kullanılması olacaktır. Bunlar, kodu, nasıl kullanılması gerektiğini netleştirecek şekilde belgelendirir ve birisi örnekleri değiştirmeden kodu değiştirirse testleriniz başarısız olur.

Zaten çok sayıda yinelenen kod içeren büyük bir kod tabanınız var, bu yüzden muhtemelen bunu yeniden düzenlemeye çalışmalısınız. Kesilmeyen ve yapıştırılmayan yinelenen kodları bulmak zor olabilir. Bunu yapmak yerine, değişiklik geçmişinizi analiz etmenizi öneririm. Aynı anda sıklıkla değişen dosyaları arayın. Bu, gerçek yinelenen kodu göstermiyorsa ve yine de temizlemeye değerse, kapsülleme ile ilgili sorunları gösterecektir. Hata düzeltme geçmişinizi kod değişikliklerinize karşı da analiz edebiliyorsanız, düzeltmelerin sıklıkla gerekli olduğu belirli sıcak noktaları bulabilirsiniz. Bu sıcak noktaları analiz edin ve muhtemelen birçoğunun, bir geliştiricinin iki kez değiştiğini fark etmeden sadece bir yerde değiştirdiği yinelenen iş mantığından kaynaklandığını göreceksiniz.

2) Daha sonra başka projelerde kullanılabilecek paylaşılan widget'lar, bileşenler, kütüphaneler vb. Yapmaya nasıl yaklaşmalıyız ?
Bu durumda, iş mantığını sarmaya çalışmamalı, yararlı çerçeve kodunu paylaşmalısınız. Bu, paylaşılan bir dizi bileşen oluşturma ve bakımının maliyeti oldukça büyük olabileceğinden ve hangi durumlarda yapmaya değer olduğunu tahmin etmek zor olabileceğinden, bu zor bir denge olabilir. Burada önereceğim yaklaşım üç grev kuralıdır. Benzer bir kod parçasını iki kez yazma konusunda endişelenmeyin, ancak üçüncü kez yapmanız gerektiğinde bunu paylaşılan bir bileşene yeniden düzenleyin. Bu noktada, yararlı olacağından emin olabilirsiniz ve bileşen için daha geniş gereksinimler hakkında iyi bir fikriniz vardır. Açıkçası, geliştiriciler arasındaki iletişim burada çok önemlidir.

Paylaşılan bileşenlerinizin çoğunu mümkün olduğunca açık kaynak yapmayı düşünün. İş mantığı değil, bu yüzden rakiplerinize çok fazla avantaj sağlamayacak, ancak ücretsiz olarak ekstra yorumcular ve koruyucular elde edeceğiniz anlamına geliyor.

IMMO anahtarı değil belgeleri veya araçları, anahtar İLETİŞİM. 10+ geliştirici pek çok insan değil, bu iletişimi geliştiren bazı şeyler:

• çift ​​programlama: iki kişiyle, ikisinden birinin problemin projenin başka bir bölümünde zaten çözüldüğünü ve tekrar kullanacağını bildikleri daha fazla değişiklik var.

• Kolektif kod sahipliği: Tüm insanlar sistemlerin farklı bölümleriyle çalışır, bu şekilde projenin başka bir bölümünde zaten yapılmış bir şeyin olduğunu bilmesi çok daha kolaydır, benim için bu bir ekipte temel uygulamadır.

• Yatay projelerin çalışmasına zaman verin: örneğin, ayda bir veya iki cuma, ve bu zamandaki geliştiriciler şirket projenize uygulanabilirliği olan kendi projelerinde çalışabilirler. Bu şekilde geliştiriciler yeniden kullanılabilir kitaplıklar ve bileşenler yazabilir, bazen kodu zaten vardır, ancak bazı temizlik ve belgelere ihtiyaç duyarlar.

• Görüşmeler ve atölye çalışmaları yapın: Geliştiriciler için görüşme ve atölyeler için zaman ayırın, geliştiriciler kütüphaneleri hakkında konuşabilir veya belki refactor atölyeleri yapabilir ve çoğaltılan kodları alıp tekrar kullanılabilir bir bileşen oluşturarak çoğaltmayı kaldırabilirsiniz.

Belgeler muhtemelen gerekli ama ihtiyacınız olan gerçek şeyin sadece küçük bir kısmı: ekibinizdeki iletişimi geliştirin.

Kodunuzu dizine eklemek için Lucene (veya kaynak koduna daha özel bir şey) gibi yerel bir arama motoru kullanmaya ne dersiniz? Birisi yeni bir sınıf veya yeni bir işlev yazmaya başladığında (örneğin) kendi kodunu yazmadan önce birkaç arama yapmayı denemelidir (iç politika olarak). Bu şekilde çok fazla iletişimden kaçınabilirsiniz ve iyi yorumlara, yöntemlere ve sınıf adlarına güvenebilirsiniz. Kendimi internette bulunan açık kaynaklı arama motorları ile yapıyorum: Bir yöntemin veya bir sınıfın adının ne olduğunu veya ne olduğunu kimin yazdığını bilmiyorum, ancak birkaç arama veya eşanlamlı ile her zaman ihtiyacım olanı buluyorum.

Geliştiricilerinizin sorunsuz bir şekilde yapmasına yardımcı olan bir araca ihtiyacınız var. Geliştiricileriniz, kod snippet'lerini (yalnızca kodu yazma açısından değil, aynı zamanda kalite güvencesi, entegrasyon vb. İçin) yeniden kullanarak ne kadar zaman kazanabileceklerini keşfederse, kullanımı kolay ve doğrudan geliştirme ortamına entegre, onlar böyle bir aracı benimsemeye PRAY olacak!

Kodların yeniden kullanımı için kütüphanelerin gerçekleştirilmesinin büyük bir avantaj sağlamayacağına dikkat edin (çok güçlü ve büyük olma eğilimindedirler ...); Bunun yerine, basit snippet'lere, yani belirli bir görevi etkili bir şekilde çözen birkaç kod satırına odaklanmak istiyorum.

Bu şekilde, doğrudan programcılar tarafından kullanılabilecek gerçek örnekler vererek kılavuzların ve en iyi uygulamaların kullanımını zorlayabilirsiniz.

Snippet yönetimi için birkaç araç vardır, bunu tavsiye ederim: http://www.snip2code.com .

(Feragatname: Snip2Code'un kurucusuyum ve bir süre önce aynı kurucularla birlikte - aynı kurucularımdaydım: Bu yüzden, tüm bu projeleri topladığım yukarıda belirtilen, yani snippet'leri bir ekip arasında paylaşma, Visual Studio, Eclipse, IntelliJ, Notepad ++ vb. gibi IDE'lerde entegrasyon)