Utanç verici bir şekilde, birkaç yıl önce bir ekip ortamında böyle adlandırılmış bir "ortak" kütüphane tanıttım. Sadece birkaç ay içinde gevşek bir şekilde koordine edilen ekip ortamında neler olabileceğinin dinamiğini gerçekten anlamadım.
Onu tanıttığımda, bunu açıkça düşündüğümü ve ayrıca günlük olarak yararlı bulduğumuzu kabul ettiğimiz şeyler için minimalist bir kütüphane olması gerektiğini ve kütüphanenin başka hiçbir şeye bağlı olmaması gerektiğini belgelediğimi düşündüm. standart kütüphane, böylece yeni projelerde mümkün olduğunca kolay dağıtılabilir. O zamanki düşüncem, özel alanımızda günlük olarak yararlı bulduğumuz şeyler için standart kütüphaneye kendi küçük uzantımız olmasıydı.
Ve yeterince iyi başladı. Hepimiz common/math*günlük olarak kullandığımız rutin bir matematik kütüphanesi ( ) ile başladık , çünkü genellikle lineer cebir üzerinde ağır olan bilgisayar grafikleri üzerinde çalışıyorduk. Ve genellikle C kodu ile birlikte çalıştığımız için find_index, aksine,std::findC ++ 'da, C işlevlerimizin nasıl çalıştığını taklit eden bir yineleyici yerine bir dizide bulunan bir öğeye bir dizin döndürür - bu tür şeyler - biraz eklektik ama minimalist ve herkese tanıdık ve pratik kalacak kadar yaygın olarak kullanılır ve "yaygın" veya "standart" olan herhangi bir şey yapmaya çalışırken gördüğüm kadarıyla anlık aşinalık son derece önemli bir ölçüttür, çünkü gerçekten "ortak" ise, geniş bir sonucu olarak bu tanıdık niteliğe sahip olması gerekir. evlat edinme ve günlük kullanım.
Ancak zamanla, insanlar kişisel olarak kullandıkları şeyleri eklemeye başladığında kütüphanenin tasarım niyetleri, sadece başka birini kullanacağını düşündükleri şeyleri eklemeye başladı. Ve daha sonra birisi, yaygın GL ile ilgili rutinler için OpenGL'ye bağlı işlevler eklemeye başladı. Dahası Qt'yi kabul ettik ve insanlar Qt'ye bağlı kod eklemeye başladı, bu yüzden zaten ortak kütüphane iki harici kütüphaneye bağımlıydı. Bir noktada birisi, uygulamaya özgü gölgelendirici kitaplığımıza bağlı olan ortak gölgelendirici yordamları ekledi ve bu noktada Qt, OGL ve uygulamaya özgü gölgelendirici kitaplığımızı ve yazımızı getirmeden yeni bir projeye bile uygulayamadınız. projeniz için önemsiz olmayan bir komut dosyası. Böylece bu eklektik, birbirine bağımlı karmaşaya dönüştü.
Ama aynı zamanda, "ortak" olarak kabul edilen şeyin, "ortak" olanın çok sert bir çizgi kuralı belirlemezseniz, kolayca çok öznel bir fikre dönüşebileceğini bu kütüphaneye neyin girmesi ve neyin olmaması gerektiğini tartışarak buldum. Herkesin günlük olarak yararlı bulmaya eğilimi. Standartların herhangi bir şekilde gevşetilmesi ve herkesin günlük olarak yararlı bulduğu şeylerden, tek bir geliştiricinin başkalarına faydalı olma olasılığı olabilecek yararlı bir şeye çabucak ayrılır ve bu noktada kütüphane eklektik bir karmaşaya dönüşür .
Dahası, bu noktaya geldiğinizde, bazı geliştiriciler programlama dilini sevmemeleri için bir şeyler eklemeye başlayabilirler. For döngüsünün veya bir işlev çağrısının sözdizimini beğenmeyebilirler, bu noktada kütüphane, dilin sadece temel sözdizimiyle savaşan, gerçekte olmayan birkaç basit kod satırının yerini alan şeylerle dolmaya başlar. herhangi bir mantığı, sadece böyle bir stenoyu tanıtan geliştiriciye aşina olan tek bir egzotik kod satırına kopyalamak. Daha sonra böyle bir geliştirici, bu tür kestirme yollar kullanılarak uygulanan ortak kütüphaneye daha fazla işlevsellik eklemeye başlayabilir, ortak kütüphanenin önemli bölümleri, onu tanıtan geliştirici için güzel ve sezgisel görünebilen, ancak çirkin ve yabancı ve herkes için anlaşılması zor bu egzotik stenografi ile iç içe geçiyor. Ve bu noktada, gerçekten "ortak" bir şey yapma umudunun kaybolduğunu biliyorum, çünkü "ortak" ve "tanıdık" kutupsal fikirler.
Yani, en azından gevşek bir şekilde koordine edilmiş ekip ortamında, "yaygın olarak kullanılan şeyler" kadar geniş ve genel tutkuları olan bir kütüphaneye sahip her türlü solucan tenekesi var. Ve altta yatan problem, her şeyden önce gevşek koordinasyon olsa da, matematik rutinleri sağlamayı amaçlayan bir kütüphane ve başka bir şey gibi en azından birden fazla kütüphane, tek bir amaca hizmet etmeyi amaçladı, muhtemelen "ortak" bir kütüphane olarak tasarım saflığı ve bağımlılıkları. Bu nedenle geçmişe bakıldığında, çok daha açık tasarım niyetleri olan kütüphanelerin yanına düşmenin çok daha iyi olacağını düşünüyorum. Yıllar içinde, amaca yönelik olarak ve uygulanabilirlikte daralmanın kökten farklı fikirler olduğunu da buldum.
Ayrıca kuşkusuz en azından biraz pratik değilim ve bakım belki de estetik konusunda biraz fazla, ama bir kütüphanenin kalitesi (ve belki de "güzellik") fikrimi algılama eğilimim, en güçlü, benzer bir şekilde, bana dünyanın en iştah açıcı yiyeceklerini sunduysanız, ancak aynı tabağa, gerçekten kötü kokan bir çürüyen bir şey koyarsanız, tüm tabağı reddetme eğilimindeyim. Ve bu konuda benden hoşlanıyorsanız ve her türlü eklemeyi "ortak" olarak adlandırılan bir şey olarak davet eden bir şey yaparsanız, kendinizi bu analog plakaya yanda çürüyen bir şeyle bakarken bulabilirsiniz. Aynı şekilde, bir kütüphanenin düzenlenmeyecek şekilde düzenlenmesi ve adlandırılması ve belgelenmesi iyi olur '' t Zaman içinde gittikçe daha fazla ekleme davet edin. Ve bu, kişisel yaratımlarınız için bile geçerli olabilir, çünkü burada ve orada kesinlikle çürümüş şeyler yarattım ve en büyük tabağa eklenmezse çok daha az "lekelenir". Her şeyi küçük, çok tekil kütüphanelere ayırmak, sadece her şeyi birleştirmeye başlamanın çok daha az uygun olması nedeniyle, kodu daha iyi bir şekilde ayırma eğilimindedir.
Kod tekilleştirme yıllar içinde bana dövüldü ama bu sefer denemek gerekir gibi hissediyorum.
Senin durumunda ne önerebilir kod tekilleştirme kolay almaya başlamaktır. Ben kötü test, hata eğilimli kod veya bu tür bir şey büyük snippet'leri kopyalamak ve yapıştırmak veya gelecekte değişiklikler gerektiren iyi bir olasılık olan önemsiz olmayan kod büyük miktarda çoğaltmak için söylemiyorum.
Ama özellikle arzunuzun yaygın olarak uygulanabilir, son derece tekrar kullanılabilir ve belki de ideal olarak bugün on yıl kadar yararlı bulduğunuz bir şey yaratmak olduğunu düşündüğüm bir "ortak" kütüphane oluşturma zihniyetindeyseniz , bazen bu zor kaliteyi elde etmek için bazı çoğaltmalara ihtiyaç duyabilir veya isteyebilirsiniz. Çünkü çoğaltma aslında bir ayırma mekanizması işlevi görebilir. Bir video oynatıcıyı MP3 çalardan ayırmak istiyorsanız, en azından piller ve sabit sürücüler gibi bazı şeyleri çoğaltmanız gerekir. Bu şeyleri paylaşamazlar ya da bölünmez bir şekilde eşleştirilirler ve birbirlerinden bağımsız olarak kullanılamazlar ve istedikleri tek şey MP3 çalmaksa, insanlar artık cihazla ilgilenmeyebilir. Ancak bu iki cihazı birbirinden ayırdıktan bir süre sonra, MP3 çaların video oynatıcıdan farklı bir pil tasarımından veya daha küçük bir sabit diskten faydalanabileceğini görebilirsiniz; bu noktada artık hiçbir şey çoğaltmıyorsunuz; başlangıçta bu bağımsız cihazın iki ayrı, bağımsız cihaza bölünmesine izin vermek için çoğaltma olarak başlayan şey, daha sonra artık gereksiz olmayan tasarımlar ve uygulamalar ortaya çıkarabilir.
Bir kütüphane kullananların bakış açısından bir şeyleri düşünmeye değer. Gerçekten kullanmak ister misinkod çoğaltmasını en aza indiren bir kütüphane? Muhtemelen yapmayacaksınız çünkü bunu yapan biri doğal olarak diğer kütüphanelere bağlı olacaktır. Ve bu diğer kütüphaneler, kodlarını çoğaltmaktan kaçınmak için diğer kütüphanelere bağlı olabilir ve böylece, bir ses dosyasını yüklemek ve oynatmak gibi bazı temel işlevleri almak için 50 farklı kütüphaneyi içe aktarmanız / bağlamanız gerekebilir ve bu çok hantal hale gelir. . Bu arada böyle bir ses kütüphanesi, bağımsızlığını elde etmek için burada ve orada bazı şeyleri kasıtlı olarak çoğaltmayı seçerse, yeni projelerde kullanımı çok daha kolay hale gelir ve şansı, kazandığından neredeyse güncellenmesi gerekmemesidir. o bağımlı kütüphane dış ses kütüphanelerinin değişmesi sonucunda değişmelidir.
Bu nedenle, bir kütüphaneyi ayırmak ve bağımsız hale getirmek için kasıtlı olarak biraz (bilinçli olarak, asla tembellikten - aslında gayretten uzak) çoğaltmayı seçmeye değer çünkü bu bağımsızlık sayesinde daha geniş bir pratik uygulanabilirlik ve eşit kararlılık (daha afferent kaplinler yok). Sizi bir projeden diğerine ve yıllara kadar sürdürebilecek en yeniden kullanılabilir kütüphaneleri tasarlamak istiyorsanız, o zaman kapsamını en aza indirgemek üzerine, aslında burada biraz kopyalamayı düşünmenizi öneririm. Ve doğal olarak birim testleri yazın ve ne yaptığının gerçekten test edildiğinden ve güvenilir olduğundan emin olun. Bu sadece zaman ayırmak için gerçekten tek bir projenin ötesine geçen bir noktaya genellemek istediğiniz kütüphaneler içindir.