Ne kadar NPM çok NPM

Öncelikle şunu söylerek başlamak istiyorum, bu “ideal kodlama” gurularının çizdiği keskin çizgileden kaçınmaya özenerek bu yazıyı yazıyorum. Söylediğim şeyleri birer kuralmışçasına algılama. Şu doğru, bu yanlış gibi bir sonuçtan çok, paket kullanımı konusunda kendi perspektifimi paylaşıyorum.

NPM Paketleri

Seviyoruz kardeşim bu olayı;

npm i ne-vereyim-abime

basıyorsun enterı, geliyor fellah fellah kod. Temiz… 1-3-10-20 paket sonra ise işler bir tık karmaşıklaşmaya başlıyor. İşte bu sebep-sonuç ilişkisine biraz daha yakından bakalım

Paket kullanmak kötü mü

Kısa cevap,net. Hayır. Elbette kötü değil. Hatta doğru kullanıldığında kod kalitemizi oldukça arttıran bir yöntem.

Örneğin fullstack bir web geliştiriyoruz ve bir oauth sistemine ihtiyacımız var. Google ya da facebook gibi bir servis ile sitemize giriş yapmak istiyoruz. Freelancerız ve zamanımız sıfırla,

• Oauth requestlerini yaz,
• Statemanager crypted kodu üret
• Dönüşleri değerlendir
• Session yaz, cookie yarat
• Timeoutları yönet

E iş yani bunlar. Üstelik authorization ve authtantication gibi önemli iki konuda bir çok bug çıkma ihtimali var. Bunların debug süreçleri var…

Bunun yerine, çalıştığın platformda bir çok geliştirici tarafından aktif olarak bakımı yapılan bir kütüphane kullanman senin açından çok daha avantajlı.

Bir çok senior developerın geliştirdiği, robust kod yapısına bir kaç ayar ile ulaşıp, projende kullanabiliyorsun. Yönetimi, bakımı ve debug süreci inanılmaz derecede kısalıyor.

Bu seneryoyu %100 onaylıyorum. Örneğin next-auth, passport gibi kütüphaneler bu işler için harikulade.

Ayın karanlık yüzü

Biraz da işlerin nerede kötüye gittiğini konuşalım. Paketlerin, karşılaştığımız sorunları çözme yeteneğimizi ve hızımızı arttırdığı bir ortamda, ister istemez ilk içgüdümüz bu konsepti günlük yazılım alışkanlıklarımıza katmak oluyor.

Bir süre sonra bakıyoruz ki, bir isEven paketinin haftalık yüklenme sayısı 160.000. Yani her hafta, 160k defa, bir sayı çift mi değil mi diye kontrol eden paket projelere dahil ediliyor.

Bir sayının ikiye bölümünden kalan sıfır mı değil mi diye kontrol etmek yerine isEven npm paketi kullanan geliştiriciler görüyoruz.

Yargı mı dağıtıyorum? Ne var efendim ha fonksiyonla, ha paket ile kontrol etmiş diyor musun yoksa? Deme. Bütün bu paket bütünün, gün döner hesap döner kıvamın da bir de sonu var. Yoksa npm i yazan barnağına kurban developerımın.

Paket yığını yönetimi

Çatır çutur ekledik paketleri, ortaya bir şey çıktı, çalışıyor. Teslim ettik projeyi, müşteri de onayladı. Mis!

Performans Herşey çalışıyor da, müşteri laf arasında “hosting mi yavaş bizim” gibi bir şey sormaya başladı. Bir kontrol yaptın network izleyerek, toplam js bundle boyutu dayanmış mb’a… Kekremsi bir cold start hızı…

Sürüm yönetimi Bir update lazım, frameworkün yeni sürümüne geçilecek, ama isEven paketinin yöneticileri böyle blog yazılarına kırılıp, geliştirmeyi bırakmışlar. Bu paket son framework sürümü ile uyumlu değil.. Hayda… Bunun gibi 8 10 paket de uyumsuz. Eee yeni sürüme geçmiyor muyuz? Geçeceksek 100 dosyada yeni paketler kullanılmalı…

Bug yönetimi Alakasız bir yerde güvenlik açığı var. Giriyorsun ilgili uç noktanın sunulduğu router fonksiyonuna, paket yapıyor işlemi. Bu senin değil, çözüm senin değil ama müşteri senin.

Yani özetle demek istiyorum ki;

Büyük güç, büyük sorumluluk getiriyor. Paketler gerekli yerlerde kullanıldığında kaliteyi arttırırken, fazla kullanımı ise bir projenin sürdürülebilirliğini ciddi ölçüde zorlaştırıyor.

Eğer amacın vur kaç bir yazılımcı olmak değilse, yaptığın proje uzun ömürlü, sürekli geliştirilen bir taneyse, gözün package.json dosyasında olsun derim.