Bağımlılık mı ekleyeyim, kendim mi yazayım?

Bu tartışma genelde iki uçta yapılıyor: "hazır varken niye yazalım" ve "her paket bir güvenlik açığı". İkisi de bir kısıtı yok sayıyor.

Kararı netleştiren altı soru şunlar.

1. Bu problem gerçekten benim problemim mi?

Tarih/saat işlemleri, para hesabı, karakter kodlaması, kriptografi, PDF üretimi — bunların hepsi görünenden çok daha derin problemler. Kendi kriptografi kodunuzu yazmayın; bu tartışmaya bile açık değil.

Buna karşılık "bir diziyi grupla", "nesneyi düzleştir", "metni kısalt" gibi işler, kendi projenizin problemi. Bunlar için paket eklemek, on satırlık kodu bir tedarik zinciri riskine dönüştürüyor.

Ayırt edici soru: Bu problemin yanlış çözülmesi sessizce mi yanlış sonuç üretir? Evetse paket kullanın — çünkü sessiz hatalar kendi kodunuzda yıllarca durur.

2. Yüzeyin ne kadarını kullanacağım?

Bir kütüphanenin %5'ini kullanıyorsanız, %95'inin bakım ve güvenlik yükünü boşuna taşıyorsunuz. Tek bir fonksiyon için 300 kB'lık bir paket eklemek yaygın ve kolay fark edilmeyen bir maliyet.

Pratik ölçü: paketin dokümantasyonunda kaç başlık var ve siz kaçını okuyacaksınız?

3. Kaç bağımlılığı var?

npm ls --all çıktısı, kararın en somut girdisi. Tek bir paket eklerken 40 alt bağımlılık geliyorsa, güvendiğiniz taraf sayısı 40'a çıkıyor. Bu, karşılığında yeterince değer alıyorsanız kabul edilebilir bir maliyet — ama bilinçli olmalı.

4. Bakımı sürüyor mu?

Bakılacak sinyaller:

• Son yayın tarihi (ama tek başına yanıltıcı: olgun kütüphaneler nadiren güncellenir)
• Açık sorunlara verilen yanıt hızı
• Tek bir kişiye mi bağlı, kurum ya da ekip arkasında mı
• Sürüm geçmişinde kırıcı değişiklik sıklığı

"Son commit iki yıl önce" küçük ve tamamlanmış bir kütüphane için sorun değil; büyük ve karmaşık bir kütüphane için ciddi bir uyarıdır.

5. Çıkış maliyeti ne?

En sık atlanan soru. Bu paketi iki yıl sonra değiştirmem gerekirse ne olur?

Kütüphaneyi kod tabanının her yerine yayarsanız çıkış maliyeti sonsuza yaklaşır. Bir arayüz katmanının arkasına koyarsanız (tek bir modül, kendi tipinizle) çıkış maliyeti bir günlük işe iner.

Bu, özellikle dış servis istemcileri için geçerli: ödeme, e-posta, depolama, kimlik doğrulama. Bunları asla doğrudan çağırmayın; kendi ince sarmalayıcınızın ardına koyun.

6. Ekip bunu okuyabiliyor mu?

Elle yazılan çözümün gizli maliyeti, o kodu bir yıl sonra kimsenin anlamaması. 40 satırlık zarif ama yoğun bir yardımcı fonksiyon, ekipteki herkesin okuyamayacağı bir şeyse, bakım açısından bir bağımlılıktan farksızdır — üstelik dokümantasyonu yoktur.

Basit bir karar tablosu

Durum	Eğilim
Kriptografi, tarih/saat, para, kodlama	Kütüphane kullan
10-50 satırlık yardımcı fonksiyon	Kendin yaz
Dış servis istemcisi	Kütüphane kullan, ama sarmala
Alan mantığın (domain)	Kendin yaz — bu senin ürünün
UI bileşen kümesi	Kütüphane kullan, ama tek noktadan geçir
Tek bir fonksiyon için büyük paket	Fonksiyonu kopyala, lisansı kontrol et

Son not: kopyalamak da bir seçenek

Küçük ve izin verici lisanslı (MIT, ISC) bir kütüphaneden ihtiyacınız olan 30 satırı, lisans notuyla birlikte projenize kopyalamak meşru bir çözüm. Ekosistemde hafife alınıyor ama pek çok durumda en doğru karar: bağımlılık yok, bakım sizde, davranış sabit.

Kural şu: kopyaladığınız kodu artık siz yazmışsınız gibi davranın. Testini yazın, adını değiştirin, anlamadığınız kısmı silin.