Dahili uygulamalar için neden dahili kütüphaneler geliştirilmeli?

Yalnızca dahili uygulamaları geliştirmek için kullanılacak iç kütüphaneleri neden geliştirmeniz gerektiğini anlamakta güçlük çekiyorum. Kuruluş dışından birinin yazdığı bir yazılımı kullanmak istersem bana başlık dosyalarını ve .a veya .so dosyalarını gönderebileceklerini ve projeme bağlayabileceğimi (aynı ortamda derlenmiş olduklarını varsayarak) takdir ediyorum. .

Ancak üstbilgiye ve uygulama dosyalarına erişebildiğimde ve bunları kaynak ağacıma dahil edip hepsini bir araya getirebildiğimde neden bir dahili kütüphane dahili bir uygulamaya bağlanacak şekilde geliştirilmeli?

Başka bir deyişle: bazı kaynak kodları yazılırsa, bunların bir ikili kitaplığa derlenip uygulamanızla bağlantılı mı yoksa sadece projenin kaynak dosyalarına dahil edilip düzenli olarak mı derleneceğine nasıl karar verirsiniz?

Her projeye 'dahil et' dediğimde, her dosyayı kopyalayıp şu anda geliştirilmekte olan projenin kaynak ağacına yapıştırmak istemiyorum. Yani, bir projenin dosyalarına her zamanki gibi dahil edilebilecek ortak kaynak kodu içeren bazı dizin / kütüphane (herhangi bir projeden ayrı) geliştirme demek, yani #include.

ps Birden fazla masaüstü uygulaması için burada c / c ++ geliştirme hakkında konuşuyorum.

Dahili kullanım için bile kitaplıklar ve paylaşılan kitaplıklar (.dll veya .so dosyalarında) oluşturmanın çeşitli nedenleri vardır :

1. Projeler arasında yeniden kullanım çok daha temiz
2. Sorumlulukların ayrılması - kodunuzun bir kısmı farklı geliştiriciler veya ekipler daha uygun olabilir
3. Belirli bir kodu bulmak zorunda kalmadan diğer ekiplerin yaptığı kitaplıklardaki iyileştirmelerden yararlanabilirsiniz
4. Daha hızlı derleme süreleri, kütüphane kararlıysa yeniden inşa edilmesine gerek yoktur.
5. Disk Alanı - projedeki yalnızca kütüphaneye ve başlıklara sahip olabilirsiniz
6. Paylaşılan kitaplıklar kullanıyorsanız, birkaç program kullanıyor olsa bile RAM'e yalnızca bir kopya yüklenmiş olarak bellek tasarrufu yapabilirsiniz
7. Genellikle kütüphanelerin daha iyi belgelenmesi ve test edilmesi ile sonuçlanırsınız
8. Temizleyici tasarımı ve kod - kütüphaneler içine yapılandırma şeyleri düşünme her kütüphanede işlevsellik ilgili gruplar neden olmalı ve sen jenerik kodunu ayırmak eğiliminde kütüphaneler içine , uygulama özelliğinden, app .
9. Kütüphanelerde özel algoritmalarınız varsa, kaynağa erişimi kısıtlayabilirsiniz, örneğin yüklenicilerin veya dışarıdan gelen ekiplerin kaynağa erişmesine izin vermemek.
10. Kütüphane kodu, başlangıçta bir parçası olarak yazılan Uygulamaya farklı bir lisans altına yerleştirilebilir, bazı şirketler Açık Kaynak kütüphanelerinde gurur duydukları bile bilinir - Açık Kaynak topluluğunda büyük kudoslar kazanırlar ve bazen önemli geliştirmeler katkıda bulunurlar geri.

Bazı şirketler, kütüphane oluşturan projelerin her yeniden kullanımda geri ödeme aldığı bir muhasebe uygulamasına bile sahiptir.

Daha büyük, önemsiz projeler için geçerli olabilecek diğer olası nedenler:

• Derleme süreleri: Binlerce dosya, binlerce sınıf, işlev vb.İle büyük monolitik C ++ projelerinin derlenmesi çok uzun zaman alabilir (birkaç kod satırını her değiştirdiğinizde yeniden derlemek istiyorsanız üretkenlik zarar verir). Statik olarak bağlanmış ve dinamik olarak bağlanmış kitaplıklar bağımsız olarak derlenir ve kaynakları değişmediyse yeniden derlenmeleri gerekmez.

• Farklı modüllerin veya alt sistemlerin mantıksal olarak ayrılması : Farklı işlev alanlarının ayrı modüllere yerleştirilmesi durumunda büyük sistemlerin yönetimi genellikle daha kolaydır ve geliştiriciler binlerce dosya / sınıf içeren muazzam klasörlerde / projelerde arama yapmakla karşılaşmazlar.

• Geliştiriciler / ekipler arasındaki sınırlar : Aynı anda ayrı yeni işlevsellik oluşturan geliştiriciler, her geliştiricinin farklı modüllerde çalışmasını sağlamak için birleştirme çakışmaları olasılığını azaltabilir.

• Canlı bir ortama bırakılmaması gereken kod : Örneğin, canlı sistem bileşeninin (donanım, API'ler, uzak sistemler, veritabanları vb.) Yerine geliştirici sınaması için kullanılan birim sınama kitaplıkları veya 'sahte' kitaplıklar.

• Derleyici bayrakları : Kendinizi, garip bir derleyici bayrağı bekleyen bazı 3. taraf API'sı ile entegrasyon konusunda çok talihsiz bir konumda bulursanız, kütüphane, 3. taraf API ile uygulamanın geri kalanı arasında oturan bir "dekontaminasyon katmanı" olabilir.

• İsteğe bağlı özellikler / Optimizasyon : Büyük sistemlerde, bir uygulama dinamik olarak bağlı belirli modülleri uygulamanın temel işlevselliği için kritik değilse çalışma zamanında belleğe yüklemeden önce bekleyebilir.

Genel olarak, birçok iç proje genellikle ayrı kütüphanelere bölünmekten fayda sağlamayan küçük mikro uygulamalardır. Yalnız bir geliştirici olarak küçük bir proje üzerinde çalışıyorsanız, kodunuzu kütüphanelere bölme konusunda endişelenmenize gerek olmayabilir (henüz ...). YAGNI prensibini unutmayın .

Orijinal sorunuz diğer yanıtların çoğu için burada yanlış anlaşılmaya neden olmuş olabilir. Mevcut kodu projeler arasında kopyalamak değil , aynı kaynak dosyalarını farklı projelerden referans olarak dahil etmek istediğiniz için, "yinelenen kod" bağımsız değişkenleri ve sunulan diğer birçok bağımsız değişken anlamsız hale gelir.

Bunun bazen (- her zaman değil -) mantıklı bir teknik olduğuna dikkat edin . Aslında, projeler arasında yeniden kullanmak istediğiniz tüm kaynak dosyalarını tek bir içerme klasörüne koyduğunuzda, zaten bir libary de oluşturdunuz - ikili bir lib değil bir kaynak kodu kütüphanesi. Özellikle C ++ 'da, şablonlarla genel kütüphaneler oluştururken, sadece basit bir içerme gerektiren ve ayrı bir bağlantı hazırlığı gerektirmeyen sadece başlık kütüphanelerine sahip olmak olağandışı değildir.

Yani asıl soru - kaynak kod kütüphaneleri ne zaman inşa edilmeli, ya da önceden derlenmiş ikili kütüphaneleri ne zaman tercih etmeliyim? Bu sitedeki bu eski cevapta, sadece başlık libs'lerinin bazı artılarını ve eksilerini tartıştım, belki size yardımcı olabilir. Kaynak kodu kütüphanelerinin ana avantajı, bunları kullanan uygulama ile aynı çalışma zamanı ve / veya uyumlu derleyici / bağlayıcı bayrakları ile derlenmeleri gerekmemesidir. Dezavantajları, ek derleme süreleri ve kaynak koduna erişim sağlama gereksinimidir (bu, aklınızdaki "dahili" projeler için bir sorun değildir).

Kod kopyalamamanız gerektiğini yazarken diğer yorumcularla aynı fikirdeyim. Senin durumunda, ancak siz (veya birlikte çalıştığınız kişi) kodu kütüphaneleri oluşturmak gibi görünüyor değil başka yerde çoğaltılamaz.

Bu durumda, erken genellemeye karşı uyarıyorum . Kişinin bir kod parçasının yeniden kullanılabilir olacağını hissettiği zamanlar vardır . Bununla birlikte, ikinci kullanım durumunun bu kodu nasıl kullanacağına dair ayrıntılı bilgileri bilmeden, ek durumlarda gerçekten yararlı olmayacak "yeniden kullanılabilirlik" özellikleri için ekstra zaman harcamak veya yanlış kanıtlayan varsayımlar yapmak çok kolaydır. İkinci dava.

Bir kullanım vakası için bir "kütüphane" yazmak, herhangi bir kazanç olmadan çok pahalı bir egzersize dönüşebilir --- Bunu birkaç kez ısırdım.

Örnek maliyetler:

1. "Genel" kullanım durumlarını değerlendirmek için harcanan zaman / enerji
2. "Kütüphaneyi" "müşterinize" (kendi kodunuza) dağıtılabilir hale getirmek için harcanan zaman
3. Bir sonraki kullanım örneğiyle tam olarak eşleşmese bile "kütüphane" yi kullanmak için gelecekteki baskı

Genel kuralım: Kodun gerekli olduğu en az 2 ayrı yerim olmadıkça kodu kitaplığa dönüştürmeyin.

üstbilgiye ve uygulama dosyalarına erişebildiğimde ve bunları kaynak ağacıma ekleyip hepsini bir araya getirebileceğimde neden bir dahili kütüphane dahili bir uygulamaya bağlanacak şekilde geliştirilmeli?

Çünkü "sadece kaynak ağacıma eklerseniz" kodu çoğaltırsınız .

Buradaki sorun, kodu kopyaladığınız proje tarafından yapılan herhangi bir iyileştirmeden (kritik hata düzeltmeleri dahil) ve sizin yaptığınız iyileştirmelerden yararlanamayacağınızdır.

Bu sorunu, kodun en yeni sürümünü düzenli olarak kaynak ağacınıza kopyalayarak, belki de git'de bir alt modül veya benzeri bir şey kullanarak otomatik olarak kopyalayarak çözebileceğinizi düşünebilirsiniz. Ancak, uyumsuz API değişiklikleri nedeniyle derleme sürenizi sürekli olarak alırsınız. Diğer yandan bir kütüphane, geliştiricilerinin müşterileriyle koordinasyon olmadan değiştirilemeyeceğini bildikleri "resmi" bir ortak API'ya sahiptir.

Son olarak, teknik nedenler olabilir - kodun bir kısmını bir kütüphane olarak tutmak gerekli olabilir;

Çözümünüzün daha uzun vadede sahip olduğu maliyetler üzerinde durmak istiyorum.

Açıkçası, bir projeye kütüphane eklenmesi bazı yükleri vardır, her şeyden önce ilkse: iş akışları değiştirilmelidir, bazen altyapı bile ve bazı ekip üyeleri onu sevmeyebilir (ilk başta). Daha az maliyetler getirdiği için yüzden çözümün avantajları ortada şimdi .

Ancak, projeniz büyüdükçe "sözde kütüphane" maliyeti de olacaktır. ABir uygulama ve birim test cihazı tarafından kullanılan bir "sözde kitaplığınız" olduğunu varsayın . Her cpp Aeklediğinizde, bunu her iki projeye de eklemeniz gerekir, aksi takdirde bağlantı oluşturmazlar.

"Sözde kitaplığınız" başka bir "sözde kitaplık" tarafından kullanılıyorsa ne olur B? Daha fazla projeye yeni cpp'nizi eklemelisiniz. Ve Bbaşka bir kütüphane kullanmak için geçiş yaparsanız ? Sadece Abağlı olarak tüm projelerde cpps silmek zorunda kalacak B.

Gerçek bir kütüphane kullanılacaksa bunların hepsi ücretsiz olacaktır. Yani soru şu ki, gerçek bir kütüphaneye taşınmayı haklı çıkarmak için kaç cpp'ye ihtiyaç var?

Ancak bekleyin, daha da fazla teminat var: Bir geliştirici, yeni cpp'ye ihtiyaç duyan tüm projeleri avlamaktan bu aptalca işi sevmiyor ve kodunu / sınıflarını zaten mevcut olan dosyalara bir yere ekleyecek, ki bu iyi bir şey değil. uzun koşu.

Bu nedenle, "sözde kitaplığı" kullanmak, yekpare bir projeyi kırmak için ilk adım olabilir, ancak avantajlarını kullanabilmek için gerçek bir kitaplık yapmak için çok uzun süre beklememelisiniz.

Ancak üstbilgiye ve uygulama dosyalarına erişebildiğimde ve bunları kaynak ağacıma dahil edip hepsini bir araya getirebildiğimde neden bir dahili kütüphane dahili bir uygulamaya bağlanacak şekilde geliştirilmeli?

Kitaplık yalnızca bir uygulama tarafından kullanılıyorsa, muhtemelen ayrı bir kitaplık olarak ihtiyacınız yoktur .

Kütüphane 3500 uygulamalar tarafından kullanılırsa o zaman mutlaka yapmak ayrı bir kitaplık olarak buna ihtiyacım var.

Kütüphanede bir hata varsa ve düzeltmeniz gerekiyorsa ne olur? Veya bazı yasal veya düzenleyici değişim söz konusu araçlarla birlikte geliyor olması yolu kütüphane çalışmaları değiştirilir?

Ayrı bir kütüphanedeyse, kütüphaneyi (potansiyel olarak) düzeltebilir, yeniden test edebilir ve yeniden dağıtabilirsiniz ve her uygulama düzeltmeden yararlanır.

Her uygulama için yalnızca "yerel" olan kaynak kodundaysa, her uygulamayı ayrı ayrı değiştirmeniz, yeniden oluşturmanız, yeniden test etmeniz ve yeniden dağıtmanız gerekir . Bu çok daha büyük (yani daha pahalı) bir egzersiz.