Projeler arasında küçük kod parçacıklarını paylaşmak için en iyi yöntemler

Her zaman DRY prensibini kesinlikle iş başında takip etmeye çalışırım; her zaman tembellikten kod tekrarladığımda, bu kodu iki yerde tutmam gerektiğinde sonra tekrar ısırır.

Ancak çoğu zaman , birbirine referans veremeyen iki projede tekrar kullanılması gereken küçük yöntemler (belki de 10 - 15 kod satırı) yazarım . Bu yöntem, ağ oluşturma / dizeler / MVVM vb. İle ilgili olabilir ve başlangıçta yer aldığı projeye özgü olmayan genel olarak faydalı bir yöntemdir.

Bu kodu tekrar kullanmanın standart yolu, yeniden kullanılabilir kod için bağımsız bir proje oluşturmak ve ihtiyaç duyduğunuzda bu projeye başvuru yapmak olacaktır. Bununla ilgili sorun, idealden daha az iki senaryodan birinde sona ermemizdir:

1. Her biri, tekrar kullanmamız gereken küçük sınıfları / yöntemleri barındıran onlarca / yüzlerce minik proje ile bitiyoruz. .DLLSadece küçük bir kod parçası için tamamen yeni bir ürün yaratmaya değer mi?
2. İlişkisiz yöntem ve sınıflardan oluşan büyüyen bir koleksiyona sahip tek bir proje ile son buluruz. Bu yaklaşım, çalıştığım bir şirketin yaptığı şeydi; base.commonYukarıda bahsettiğim şeyler için klasörleri olan bir projeleri vardı: networking, string manipulation, MVVM vb. Son derece kullanışlıdır, ancak ihtiyaç duymadığınız tüm alakasız kodla gereksiz yere yönlendirilmişlerdir.

Yani sorum şu:

Bir yazılım ekibi projeler arasında küçük kod parçalarını yeniden kullanma konusunda en iyi sonucu nasıl veriyor?

Özellikle, bu alanda politikaları olan veya bu ikilemi karşılaştığım gibi şahsen karşı karşıya kalmış bir şirkette çalışan biri varsa özellikle ilgileniyorum.

not: "Project", "Solution" ve "Reference" kelimelerini kullanmam, Visual Studio'daki .NET geliştirme geçmişinden geliyor. Ancak bu sorunun dil ve platformdan bağımsız olduğundan eminim.

Gerçekten yeniden kullanılabilir yöntemler / sınıflarsa, bunları az sayıda 'İsviçre Çakısı' kütüphanesine yazabilirsiniz. Bunu sık sık şirketimde yapıyoruz; onlara çerçeve kütüphaneleri diyoruz:

• Framework.Data - Veri tabanı sorguları ile çalışmak için yardımcı programlar.
• Framework.ESB - Kurumsal hizmet veriyolumuzla etkileşime girmenin standart yöntemleri
• Framework.Logging - Birleşik kayıt sistemi
• Framework.Services - Web servisleriyle etkileşime geçmek için yardımcı programlar
• Framework.Strings - Gelişmiş dizi işleme / bulanık dize arama vb.
• ...

Toplamda, bir düzine kadar kütüphane var. Kodu gerçekten uygun görebildiğiniz halde dağıtabilirsiniz, böylece yüzlerce numara ile bitmek zorunda kalmazsınız veya her şeyi devasa bir düzene sokmazsınız. Bu yaklaşıma uygun olduğunu düşünüyorum çünkü projelerimizin sadece bir kısmına ihtiyaç duyulacak Framework.Datave sadece bir kaçına ihtiyaç duyulacak Framework.Strings, böylece tüketiciler çerçevenin yalnızca kendi projeleriyle ilgili kısımlarını seçebiliyorlar.

Eğer gerçekten sadece parçacıklarsa ve kolayca yeniden kullanılabilen gerçek yöntemler / sınıflar değilse, onları IDE'ye (örneğin, Visual Studio Code Snippets ) kod parçacıkları olarak dağıtmayı deneyebilirsiniz . Geçmişte birlikte çalıştığım ekiplerin, standart kodlama uygulamalarımızı iç kodla da takip etmelerini kolaylaştıran ortak bir snippet kitaplığı vardı.

Pek çok nedenden dolayı kabul edilen cevaba katılmıyorum.

Tecrübelerime göre, kabul edilen cevap gibi "çeşitli" kütüphaneler gördüğümde , tekerleği yeniden icat etmek için bir bahane (ya da burada icat edilmedi (NIH) ) - Kendini Dont Etme (DRY) ' ni ihlal etmekten çok daha büyük bir günah .

Bazen DRY'yi ihlal etmek makul bir uzlaşma olabilir, sıkı kaplin eklemekten daha iyidir. Yeniden kullanım, iyi nesne yönelimli tasarıma kıyasla ikincil bir sorundur. Biraz (küçük miktar demek , Üç Kural ), çoğaltmanın bir spagetti kod tabanından daha kolay anlaşılmasıdır.

Çok sayıda genel amaçlı kütüphanenin yaklaşımı kötü bir örnek teşkil etmektedir. İyi bir montaj ayrıntı derecesine yol açar ve çok fazla montaj kötüdür. Geçenlerde kurum içi 24 kütüphaneden 6 kütüphaneye düşürdüm. Derleme süresini birkaç dakikadan ~ 20 saniyeye çıkardı. Visual studio'nun yüklenmesi daha yavaş ve daha fazla montajla daha az duyarlı. Çok fazla kütüphaneye sahip olmak aynı zamanda kodun nerede yaşaması gerektiği konusunda kafa karışıklığına neden olur; daha az basit kuralları tercih edin.

Net Framework’deki sayfalar neden yeterince iyi değil? Çerçeve oldukça büyük; defalarca orada olan şeyleri yeniden uygulayan bir kod gördüm. Gerçekten, çerçevelerinizin .Net çerçevesindeki boşlukları doldurduğundan emin olun ve sadece estetik nedenlerden ötürü varolmadığınızdan emin olun (örneğin, ".Net çerçevesini sevmiyorum" ya da belki biraz erken optimizasyon )

Başka bir katmanı mimarinize tanıtmak önemli bir karmaşıklık maliyetine sahiptir. Katman neden var? Yanlış yeniden kullanım gördüm, demek istediğim, kodun kurum içi bir çerçevenin üzerine inşa edildiği anlamına geliyor. Standart kütüphanelerin üzerine doğrudan uygulamak çok daha etkili olurdu.

Standart teknolojilerin kullanılması (.Net çerçevesi ve popüler 3. parti / açık kaynak kütüphaneleri gibi), onu kendiniz kurmanın karşılaştırmalı teknolojik kazanımlarından daha ağır basan faydalara sahiptir. Bu teknolojileri bilen bir yetenek bulmak kolaydır ve mevcut geliştiricileriniz onu öğrenmeye daha çok yatırım yapar.

Önerilerim:

• Bu kodu paylaşmayın.
• Yapışkan bir amacı varsa yeni bir kütüphane oluşturun, topun tasarım desenini çamur kullanmayın .
• Mümkün olan yerlerde mevcut 3. parti kütüphaneleri yeniden kullanın.
• Kodun nerede yaşaması gerektiğine ilişkin daha basit kurallarla daha az montaj tercih edin.

Küçük kod parçaları için - bağımlılığı olmayan tek bir sınıf söyleyin - kodu yalnızca projelere kopyalayıp yapıştırma eğilimindeyiz. Bu bir DRY ihlali gibi geliyor ve zaman zaman olabileceğini kabul edeceğim. Ancak uzun vadede, birkaç nedenden ötürü bir tür devasa, çok başlı ortak projeye sahip olmaktan çok daha iyi oldu.

İlk olarak, özellikle de bir şeyler oluştururken ve hata ayıklarken kodu kullanışlı hale getirmek daha kolaydır.

İkincisi, kaçınılmaz olarak, bu proje için ortak koda biraz ufak tefek olmak isteyeceksiniz. Kaynağın yerel bir kopyasına sahipseniz, ince ayarını yapabilir ve bir gün arayabilirsiniz. Paylaşılan bir kitaplık varsa, o zaman bu kitaplığı ince ayarlayıp, diğer tüm uygulamaları bozmamaya veya sürüm oluşturma kabusu yaratmamaya dikkat ediyor olabilirsiniz.

Dolayısıyla, kendi ad alanı için yeterince becerikli değilse, onu projedeki uygun parçalara itme ve onu bir gün arama eğilimindedir.

Tanımladığınız ikinci çözüm o kadar da kötü değil. .NET'te ayrıca, yalnızca bir sınıfını kullanıyor olsanız bile, GAC'den bir derleme başvurursunuz. 'Alakasız kodu sürüklemek', düşündüğünüz gibi bir sorun değildir. Bu durumda, en azından farklı ad alanlarında temiz bir şekilde organize edilmiş ilgili yöntem ve sınıfları tutmak hayati önem taşır. Ek olarak, bu çözümün karmaşa yaratmasını önlemek için API tasarımı için iyi uygulamalar uygulanmalıdır.

Eğer çok küçük kod parçaları gelirse, aşağıdaki yaklaşımı ortak bir projeye eklemek için iyi bir destek olduğunu düşünüyorum: Farklı çözümlerle çoğaltılmalarını sağlayın. Onlarla en iyi uygulamalar gibi davranın: onları belgeleyin ve takıma iletin.

Sadece bu tarz bir meselenin gündeme geldiği “işletme” ortamlarında çalıştım ve her seferinde benimsenen ikinci seçenek oldu. Çoğunlukla işe yaradı çünkü uygulama ayak izinde herhangi bir kısıtlama olmadı.

Ancak, geçen haftayı kendi Nuget sunucusunu işleten bir start-up ile geçirdikten sonra bunu uygun bir alternatif olarak sunma eğilimindeyim. Elbette ortaya çıkmayı umduğum konular keşif kabiliyeti etrafında olacak.

Projeler uygun bir şekilde granüler ise ve ad alanları mantıklıysa, bunun yer yer popüler bir yaklaşım olduğunu görebiliyorum.

Son zamanlarda bunu düşündüm ve başıma gelenler, şu ana kadar belirtildiği gibi geniş bir ortak yöntem kütüphanesiydi, ama bir bükülme ile. Kütüphane projesi, derleme zamanında BusyBox projesine benzer parçaları içerecek şekilde yapılandırmanıza izin verir . Bu yaklaşımla mutfak lavabosu tarzında bir kütüphane deposuna sahip olabilirsiniz, ancak sadece derlerken ihtiyacınız olan araçları elde edin.

GitHub, kod parçacıklarını kaydetmek için oldukça kullanışlı bir araca sahiptir. Https://gist.github.com/

Snippet'lerinizi gizli tutabileceğiniz veya snippet'leri diğer insanlarla paylaşmak için kullanabileceğiniz git depoları olarak depolar.

Ekibin / projenin / şirketin büyüklüğüne bağlı olarak bu, bir şekilde ortamınıza zaten yerleştirilmediği sürece etkili bir şekilde yapılması zor olacak ve (eğer uygularsanız) bulacağınız her çözüm bir miktar paraya mal olacak. (Sizi daha fazla güvende tutabilir, ancak kolayca ölçemeyeceksiniz.) Fiyatına değip değmeyeceğini kontrol etmeniz gerekecek. Yeniden kullanılabilir çözümlerin soyut olma eğiliminde olduğunu ve çoğu zaman birçok duruma uyacak, ancak optimal olamayacaklarını unutmayın.

Her durumda, bunu birden fazla kişinin ürettiği kod için yapmak istiyorsanız, ilk önce herkesin ve işbirliğinin farkındalığına ihtiyacınız olacak. Buna geliştiriciler ve yöneticiler de dahildir.

O zaman bunu yapmak istediğiniz kapsamı bildiğinizden emin olmanız gerekir. Takım? Proje? Bölüm? Şirket? Cevabınıza bağlı olarak, bu tür çözümlere koyacağınız kod türü, görevleri nasıl belirleyeceğiniz titizlikle değişecektir. Buna bir kez karar verdikten sonra (tercihen fikir için bir coşku ile - siz?) Oturmalı ve buna bir yapı koymaya başlamalıdır.

Sadece bu tür işleri yapmak hile yapmak için yeterli olmayacak. Onları kullanışlı kılmak için, onları (kullanıcılara ve katkıda bulunanlara) tanıtmanız ve başka herhangi bir yazılım gibi sürdürmeniz gerekir; bu, genellikle birisini uzun süre sorumlu tutacağınız anlamına gelir. Aynı zamanda güvenilir belgelere de ihtiyacınız olacak, bu da daha sonra da bakıma ihtiyaç duyacak. Bazı şans ve işbirliğiyle, bazı en iyi uygulamalarla sonuçlanabilir, ancak ilgili ekiplerin büyüklüğüne ve sayısına bağlı olarak kendi projesine kolayca dönüşebilir. Ve bunun için hala yönetim desteğine ihtiyacınız olacak.

çok sorunla karşılaştım ve tercih ettiğim çözüm kodu github / pubic web etkin bir depoda yayınlamak. birçok sorunu çözer -

1. kolay erişim ve paylaşılması kolay. cvs / svn / enterprise-repos, projeyi birden fazla IDE çalışma alanına dönüştürmek ve bazen çalışma alanlarını veya bilgisayarları yalnızca küçük bir kod snippet'ine başvurmak üzere değiştirmek zorunda kalmak anlamına gelir.
2. Bu kod snippet'lerinin özel / sınıflandırılmış kod parçaları olmadığını ve kamuya açık bilgilerin varyasyonları olduğunu farz edersek, bunları github gibi halka açık bir depoda yayınlamak, başkalarının buna bakacağı ve hatta katkıda bulunabileceği anlamına gelir.
3. kamuya açık alanda adınız altında bir şey yayınlamak, itibar baskısı yaratır. bir programcı olarak yeteneklerinizi yansıttığından, şeyleri iki kez kontrol edip güncelleyeceksiniz.
4. güncellemeler. Kod parçasını bir depoda saklamakla ilgili şey, eğer bir parçacık uzun süre kullanılmamışsa bayatlayabilir (eski moda apis / lib'ler içerir). example - bir dosyayı okumak için java kodu pasajı. 2009'da bunu yapmanın en iyi yolunu bulmuş olabilirsiniz, ancak 2014'te her şeyi değiştiren yeni bir dosya api ortaya çıkıyor. snippet'iniz? hala 2009 yılında sıkışıp kalmış. Bir kamuoyu deposunda, işler sizin tarafınızdan (mermi 3'ten dolayı), takım arkadaşlarınız veya genel programcı popülasyonunun bazı üyeleri tarafından güncellenecek ve bu süreçte, bir şeyi düzeltmek için öneriler alabilirsiniz. uzun zamandır yanlış yapıyor olabilirsiniz.

Tavsiye edebileceğim bir şey - snippet'lerinizi nerede sakladığınızın önemi yok, kullanmadan önce her zaman google şeyler. işler her zaman değişir. Kaydedilen snippet'ler zaman kazandırır ancak aynı zamanda rahatlık sağlar .

Bütün bu küçük metotları testlerle birlikte sakladığımız ayrı bir projemiz var.

Bir proje bazı yardımcı programlara ihtiyaç duyduğunda, kaynak dosyaya yalnızca "link as add" ile gerekli yöntemi ekler.

Bu, eklenmiş çalışma zamanı bağımlılığı olmadığı anlamına gelir (dahil edilen dosyaya gerek duymadıkça).

Sistem iyi çalıştı ancak diğerleri gibi, faydası hakkında disipline ihtiyacı var. Yüksek test kapsamı gerektiren bizim için iyi çalıştı ve testler aynı zamanda iyi kullanım belgeleridir. Keşif hala bizim için çözülmemiş bir konudur.

Kamu hizmeti projesi ile ilgili bir karmaşıklık, maddeler üzerinde görünürlük seviyesine karar vermektir. Temel bir kural, yöntemlerin iç ve kamuya açık veri yapıları olması gerektiğidir.

Şirketim intranet yerel web servisleri kullanıyor. Yaygın dahili web servisleri olarak ayarlanmış birkaç web servisimiz var ve başka bir projenin servislerden birine erişmesi gerektiğinde, tanımlanmış bir arayüze sahip bir http isteği gönderiyor. Aynı sunucu grubundaki intranette olduğundan, bu istekler çok hızlı.

Açıkçası bu sadece internet uygulamaları ile çalışır (ve aynı yerel ağdayken sadece milisaniyede çalışır), ancak gerçekten çok hoş bir avantaja sahiptir.

Son zamanlarda bu hizmeti ile geldi: Snip2Code ( http://www.snip2code.com ).

Sadece snippet'lerinizi (tamamen kütüphaneleri değil) ekibinizle paylaşmanın ilginç bir yolu. Diğer projelerde referans alınması gereken ortak kütüphaneler oluşturmak her zamanki noktayı kırar ve bence bu değerli bir vizyondur.

Dahası, ortak bir kütüphanenin kullanımı basitçe uygulanmayan birçok senaryo var: örneğin, Singleton, Strategy veya Observer gibi bazı Tasarım Modellerini göz önüne alalım. Bu tür kalıpları desteklemek için kütüphaneler oluşturabilirsiniz, ancak yine de% 100 kapsama alanı yoktur.

Asıl ihtiyaç, ekip içinde ortak uygulamaları paylaşacak bir araca sahip olmaktır. Github'ın özlemlerini kullanmaya çalıştım, ama onların araştırılmasıyla (gerçekten fakir) şaşırıp kaldım ve onları sadece takımım arasında paylaşamıyorum ve diğerleriyle değil ...

(Feragatname: Snip2Code'un kurucusuyum ve bir süre önce aynı kurucunuzla - ortak kurucularımla birlikte oldum: bu yüzden bu projeyi başlatmaya karar verdik!)