Michelin yıldızlı lüks bir restoranda şef olsaydınız sebze ve etleri rastgele doğrulanmamış kaynaklardan satın alır mıydınız? Neredeyse her ortalama projenin maliyeti yüzbinlerce, hatta milyonlarca dolar olarak ölçülür. Restoranlarla aynı yaklaşımın bizim sektörümüzün de olması gerektiğine inanıyorum. Örneğin UUID'ler oluşturmak için ek bir kitaplık kurmanıza gerek yoktur. Node.js ve tarayıcılar bunu kutudan çıktığı gibi : Kendinize hemen sormanız gereken ilk soru: Gerçekten yeni bir bağımlılığa ihtiyacınız var mı? Sorun, dil veya kurulu kütüphaneler gibi mevcut ortam kullanılarak çözülebilir mi? destekler crypto.randomUUID() Örneğin, yalnızca bir açılır menüye ihtiyacınız varsa Bootstrap gibi bir şey yüklemeye değer mi? Belki de kendinizi içeren, odaklanmış tek bir kitaplıkla sınırlamak daha iyidir? İkinci soru: Kütüphanenin tamamına mı ihtiyacınız var? Radix UI'dan stillendirilmemiş bir açılır bileşen Tamam aşkım. Aklımızda birkaç aday var. Peki doğru olanı nasıl seçeceğiz? Güzelce biçimlendirilmiş bir README? Tanınmış bir isim mi? Diğerlerine göre daha fazla çatal, yıldız ve indirme mi var? Ne yazık ki bu faktörler tek başına yeterli değil. Burada bir servis sağlayıcı seçiyoruz. Ortaya çıkan sorunların hızlı bir şekilde çözülmesini, işlevselliğin güncel kalmasını ve hepsinden önemlisi hizmetin güvenli ve güvenilir olmasını istiyoruz. Basit dış ölçümler her zaman kaliteyi veya uzun vadeli uygunluğu göstermez. Depo kataloğunda bulduklarımızı yüklemeden önce GitHub deposunu ziyaret edip içeriğini analiz etmek harika olurdu. Son birkaç yıldır kullandığım kriterlerin bir listesini hazırladım. Umarım en uygun kütüphaneleri seçmenize yardımcı olurlar. Bunları kapsamlı bir şekilde değerlendirmek ve bazı durumlarda aralarında seçim yaparken taviz vermek önemlidir. Aşağıda belirtilen kütüphaneleri eleştirmiyorum veya bunların kullanımını engellemeye çalışmıyorum. Bazı durumlarda, olgusal doğruluğu korurken kriter örneğine odaklanmak için kasıtlı olarak isimleri çıkardım. Yasal Uyarı: 1. Güvenlik Kullanımı ne kadar güvenli? Kulağa kurgu gibi gelebilir ama evet, bağımlılıklar tehlikeli olabilir. Örneğin, 500 bin indirme sayısına sahip bir kitaplığa ilginç bir özellik : IP adresiniz belirli bir aralığa giriyorsa bilgisayardaki tüm dosyaları ❤️ ile değiştirmeye çalışıyor. eklendi İlginç bir gerçek, bu bağımlılığın kullanılmış olmasıdır. Bu tür sorunları nasıl keşfedebiliriz? Sorunlar sayfasını kontrol edin veya kitaplığın adına göre Google'da arama yapmayı deneyin. Genellikle bu tür bilgiler hızla ortaya çıkar. vue-cli'de 2. Bakım Son yayın ne zamandı? Yayınlar ne sıklıkta gerçekleşiyor? Düzenli sürümler sorunların çözülmesini sağlar ve güncellemeler sürekli değişen teknolojileri destekler. Mobil geliştirme bağlamında düzenli sürümler aynı zamanda projenin başarıyla derlenmesini de sağlar. İşte Go dünyasından bir örnek: 18,2K yıldıza sahip bir kütüphanenin yazarları, bağımlılıklarını sürdürmeyi bırakıp kütüphaneyi arşivlediler. Bu, birkaç yıl içinde destek ve güncelleme eksikliğinin sorun haline geleceği anlamına geliyor. Şimdi GitHub'u kontrol etmeden benzer bir bağımlılık kurduğunuzu hayal edin. Bir nevi ürünlerin son kullanma tarihini kontrol etmek gibi bir şey. İşte sık sık yapılan iyi yayınlara bir örnek: 3. Açık/Kapalı Konular Açık konuların kapalı konulara oranı nedir? Yazarlar değişiklikleri kabul etmeye ne kadar istekli? Bir gün bir şeye katkıda bulunmanız gerekebilir. Örneğin, bu kütüphane oldukça popüler ve %98 oranında kapatılmış sayıya sahip. Sadece 18 tanesi açık. Kritik sorunlar ne kadar çabuk çözülüyor? Bir keresinde 31k yıldızlı bir ORM seçmiştim ama bir noktada bizi engelleyen bir sorunla karşılaştık. Geçici çözümler aramak ve sonunda başka bir çözüme geçmek zorunda kaldık. Maalesef üzerinden neredeyse 4 yıl geçmesine rağmen sorun hala çözülmedi. Bu tür sorunlar en çok yorum yapılanlara göre sıralanarak belirlenebilir. Katkı süreci yaratıcılar tarafından organize edildi mi? Açık ve tanımlanmış bir iş akışı mevcut mu? Mesela Next.js'in yaratıcıları, katkı süreçleriyle ilgili 40 dakikalık bir video bile kaydettiler. 4. Kod Kalitesi Evet çok fazla kod olabilir ama farklı kısımlarını incelemek her zaman mümkün. Proje nasıl organize ediliyor? Anlaşılabilir mi, iyi yapılandırılmış mı ve iyi uygulamalar geçerli mi? Kod ne kadar kötü yazılırsa, projenin gelecekte çökme olasılığı da o kadar yüksek olur. Benim için pek çok küçük aday bu aşamada elendi. 5. Test kapsamı Kütüphanede testler var mı? Test kapsamı nedir? Testler nasıl yazıldı? Bakımcılar birleştirme isteklerini incelese bile bir şeyin gözden kaçma ihtimali vardır. Kütüphaneye katkıda bulunan birçok farklı insan var. Normalde test kapsamı bilgileri havuzun üst kısmındaki rozetlerde görüntülenir. Ancak değilse projede her zaman testleri arayabiliriz. Örneğin, kütüphane ailesi mükemmel test kapsamına sahiptir ve çeşitli test türlerini içerir. formatjs 6. Kütüphane Boyutu Mobil uygulamalar genellikle büyük bağımlılık boyutlarına sahiptir ve uygulamanın tamamı 200 MB'tan fazla olabilir; bu da hücresel ağ indirmeleri sırasında sorunlara neden olabilir ve çok fazla depolama alanı tüketebilir. Bu, özellikle yavaş internet hızlarının yükleme sürelerini önemli ölçüde artırabildiği ön uç CSR uygulamaları için sorunludur. Web projeleri için paket boyutlarını belirlemek için harika bir araç var: . Elbette sunucu tarafı oluşturma ve ağaç sallama boyutu azaltabilir ancak bunun her zaman doğrulanması gerekir. https://bundlephobia.com Popüler bir örnek, tarih işleme kitaplıklarıdır. (2,9KB) tarafından sağlanan işlevsellik yeterli olabilir ve (72,1KB) veya (26,8KB) yükleme ihtiyacını ortadan kaldırabilir. dayjs moment.js date-fns 7. Bağımlılık Sayısı Yukarıda listelenen tüm noktalar, bir dereceye kadar projenin tüm bağımlılık ağacındaki bağımlılık sayısıyla çarpılır. Bağımlılık ağacının tamamını kontrol etmek için harika bir araç: https://npm.anvaka.com 8. Lisans Bunu hiç düşündün mü? Bende de yoktu. Örneğin MIT ve Apache 2.0 lisansları ticari projelerde kitaplıkların ücretsiz kullanımına izin verirken, bazı GPL v2 lisanslarının belirli gereksinimleri ve kısıtlamaları vardır. Projelerimizden birinde, tüm bağımlılık ağacımızın lisanslarını kontrol etmek için bir avukat tarafından hazırlanmış bir tablomuz vardı. Dolayısıyla, bir lisansta olağandışı bir şey görürseniz, denetim sırasında sorun yaşamamak için bir avukata danışmak daha iyidir. yardımcı programı kullanarak tüm lisansları mevcut npm bağımlılıklarından çıkarabiliriz. Not: Ben avukat değilim ve bu hukuki tavsiye değildi. Bir şeyin lisans nedeniyle uygun olmayabileceği nadir ve özel bir durumdur, ancak yine de mümkündür. Yasal Son! Makalemi okuduğun için teşekkür ederim! Buradaki kilit nokta, yüzeysel ve hızlı karar vermenin bazen en iyi seçeneğe yol açamayacağını gerçek dünyadan örneklerle göstermekti. Bu kriterleri göz önünde bulundurarak daha bilinçli bir karar verebileceksiniz. Lütfen yorumlarınızı veya önerilerinizi bırakmaktan çekinmeyin. Deneyimlerinizi de yorumlarda paylaşmaktan çekinmeyin. Beğenileriniz ve yorumlarınız bana yeni makaleler yazma konusunda ilham veriyor. Mutlu yemek pişirme :)
