Hazır Kütüphane mi, Kendimiz mi Yazalım? Bağımlılık Seçmenin Ölçütleri

Bu tartışma çoğu zaman ideolojik bir yere kayar: bir taraf 'tekerleği yeniden icat etme' der, diğer taraf 'bağımlılıklar seni esir alır' der. İkisi de doğrudur ve ikisi de yanlış soruyu cevaplar. Doğru soru şudur: bu parça bizim ürünümüzün kimliğine ne kadar yakın ve bir gün değişmek zorunda kalırsak bedeli ne olur? Cevap her parça için farklıdır; bu yüzden tek bir kural değil, bir ölçüt seti gerekir.

Bizim pratiğimiz karışık ve bilinçli olarak öyle. Veritabanı, sunucu çatısı, arayüz çatısı, sürükle-bırak kiti ve çok dillilik altyapısı gibi geniş yüzeyli, olgun ve endüstri standardı parçaları hazır kullanıyoruz. Buna karşılık zengin metin editörünü, grafikleri, tablo bileşenini ve ziyaret ölçümünü kendimiz yazdık. Aradaki fark 'zor-kolay' değil; her birinin ürüne yakınlığı ve değişim maliyeti farklı.

Bir parçanın yüzeyi ne kadar genişse, kendiniz yazma fikri o kadar kötüdür. Veritabanı motoru, işletim sistemi, tarayıcı çatısı — bunlar on yıllara yayılmış, binlerce sınır durumu görmüş yazılımlardır. Bunları yeniden yazmaya kalkışmak, ürününüzü değil kendi altyapınızı geliştirmekle geçen bir yıl demektir. Bizim seçtiğimiz taraf net: çekirdek altyapı hazır kullanılır ve bu konuda tartışma açmayız.

Yüzeyi dar olan parçalarda ise denklem tersine döner. Örneğin bir tablo bileşeni: ihtiyacınız sıralama, sayfalama, sunucu taraflı filtre ve satır aksiyonlarıdır. Hazır bir bileşen bunları verir ama beraberinde tema sistemini, kendi olay modelini ve sizin hiç kullanmayacağınız otuz özelliği de getirir. Kendi yazdığınız dar bileşen, ürününüzün geri kalanıyla aynı dili konuşur ve güncelleme günlerinde kimseyi uğraştırmaz.

Bir parça, kullanıcının ürününüzü hatırlarken aklında kalan şeye ne kadar yakınsa, onu kendiniz yazmanız o kadar mantıklıdır. İçerik yönetimi yapan bir üründe metin editörü tam olarak böyledir: kullanıcı ürünle vaktinin çoğunu orada geçirir. Editörün davranışı, yapıştırılan metni nasıl temizlediği, başlıkları nasıl ele aldığı — bunlar 'detay' değil, ürünün kendisidir.

Biz editörü tarayıcının kendi düzenlenebilir alanı üzerine, dışarıdan hiçbir bileşen almadan yazdık. Kolay olduğu için değil; tam tersine, birkaç haftalık ek emek istedi. Ama karşılığında yapıştırma davranışını, izin verilen etiket kümesini, resim yerleşimini ve temayı tamamen kontrol ediyoruz. Aynı editör iki ayrı ürünümüzde çalışıyor ve ikisinde de dışarıdan gelen bir sürüm yükseltmesiyle bozulma riski yok.

Aynı mantık grafikler için de geçerli oldu. Rapor ekranlarındaki grafikleri hazır bir çizim kütüphanesiyle değil, doğrudan vektör çizimle ürettik. Sebep basitti: ihtiyacımız üç grafik tipiydi ve hepsinin temamızın renk değişkenlerine uyması, koyu-açık temada doğru davranması gerekiyordu. Hazır kütüphaneyi temaya uydurmak için harcanacak emek, üç grafiği yazmaktan azdı diyemeyiz.

Bir bağımlılığın bugünkü lisansı, yarınki lisansı değildir. Uzun yıllar ücretsiz kullanılan bir bileşenin ticari modele geçtiği, kritik bir paketin bakımının bırakıldığı ya da yeni sürümün ücretli hâle geldiği durumlar nadir değil. Bu, kötü niyet meselesi de değil — bakımı bir insan yapıyor ve o insanın ekonomik gerçekleri var. Ama sizin ürününüz açısından sonuç aynı: plan dışı bir karar.

Bizde bu, bir nesne eşleme kütüphanesinde yaşandı: ticari sürüme geçtiği için, ürünlerimizden birinde 'lisans al, eski sürümde kal ya da kendi küçük çözümümüzü yaz' kararı gündeme geldi. Üç seçeneğin hiçbiri felaket değil; ama üçü de plan dışı zaman demek. Bu deneyimden sonra ölçütümüze bir soru ekledik: bu bileşen yarın ücretli olsa, bizim için maliyeti ne olur?

Bu sorunun pratik faydası, bağımlılığı reddetmek değil, sınırlamaktır. Bir bileşeni kodun her yerine serpiştirmek yerine tek bir sarmalayıcının arkasına koyarsanız, değiştirmek bir günlük iş olur. Sarmalamadan doğrudan kullanırsanız, aynı değişiklik bir aya yayılır. Biz kritik bağımlılıkları hep bir arayüzün arkasına koyuyoruz — kaynak değişirse yalnız o katman değişsin diye.

Bağımlılıkların gerçek maliyeti kurulum günü değil, güncelleme günüdür. Onlarca paket kullanan bir projede her sürüm yükseltmesi bir uyum çalışması doğurur; bazen bir paket, başka bir paketin eski sürümünü zorunlu tutar ve ortada çözülemeyen bir düğüm kalır. Bu düğüm çoğu zaman görünmez bir sınır çizer: 'çatıyı yükseltemiyoruz çünkü şu paket henüz uyumlu değil'.

Kendi yazdığınız bir bileşen bu düğümün parçası olmaz. Arayüz çatısı yükseldiğinde kendi editörünüzü ya da grafiğinizi siz uyarlarsınız; kimseyi beklemezsiniz. Bunun bedelini de dürüstçe söyleyelim: uyarlama işi size kalır. Yani yük kaybolmuyor, yeri değişiyor — dışarıdan gelen belirsiz bir bekleyiş yerine, planlayabildiğiniz bir iş kalemine dönüşüyor.

Kendi bileşeninizi yazarken görünen iş, ekranda çalışan hâlini üretmektir; görünmeyen iş, hazır kütüphanenin yıllar içinde biriktirdiği sınır durumlarıdır. Bir metin editöründe bunlar şöyle sıralanır: farklı tarayıcıların yapıştırma davranışı, geri alma yığını, klavye kısayolları, ekran okuyucu uyumu, sağdan sola yazılan diller, mobil klavye. Hepsini ilk sürümde çözemezsiniz ve çözmemeniz de gerekmez — ama listeyi bilmeniz gerekir.

Erişilebilirlik bu listenin en sık atlanan maddesi. Hazır bir bileşen genellikle klavye ile gezinmeyi, odak yönetimini ve ekran okuyucu etiketlerini içinde getirir; kendi yazdığınız bileşende bunları siz düşünmek zorundasınız. Kurumsal ve kamu projelerinde bu bir tercih değil, çoğu zaman şart. Bileşeni yazma kararını verirken erişilebilirlik işini de maliyete dahil edin.

Bizim yöntemimiz, kapsamı bilinçli daraltmak oldu: editörümüz her şeyi yapmaz, içerik yazımı için gereken sınırlı etiket kümesini iyi yapar. Grafiklerimiz her grafik tipini çizmez, ihtiyacımız olan üçünü doğru çizer. Kendi bileşeninizi yazarken kazanan strateji, hazır kütüphaneyi taklit etmek değil, ihtiyacınızın tam sınırında durmaktır.

Hazır bileşenin en değerli tarafı kodu değil, etrafındaki bilgidir: soru-cevap arşivleri, örnekler, hata kayıtları, sizinle aynı sorunu yaşamış yüzlerce kişi. Kendi bileşeninizi yazdığınızda bu ağın tamamından vazgeçersiniz; karşılaştığınız bir sorunu arama motoruna yazdığınızda kimse cevap vermez, çünkü o kod yalnız sizde var.

Bu riski azaltmanın yolu, kendi bileşenlerinizi belgelemeyi ciddiye almaktır. İçeride yazılmış bir bileşenin nasıl kullanıldığı, hangi kararların neden alındığı ve nerede sınırının olduğu yazılı değilse, ekipten bir kişi ayrıldığında o bileşen dokunulmaz bölgeye dönüşür. Kendi kodunuz, dış bir kütüphaneden daha çok belge ister — daha az değil.

Sürükle-bırak kitini hazır aldık. Sebep: yüzey geniş (dokunma olayları, kaydırma, erişilebilirlik, tarayıcı farkları), kimliğe uzak (kullanıcı 'ne güzel sürükleniyor' der ama bunu bizim kodumuza atfetmez) ve olgun bir seçenek mevcut. Aynı işi kendimiz yazsaydık haftalar harcar, karşılığında hiçbir ayırt edici şey kazanmazdık.

Tablo bileşenini kendimiz yazdık. Sebep: yüzey dar (sıralama, sayfalama, sunucu filtresi, satır aksiyonu), kimliğe yakın (ekranların çoğu tablo) ve tema uyumu şart. Hazır bir tabloyu kendi tema değişkenlerimize oturtmak, tabloyu yazmakla kıyaslanabilir bir iş çıkarıyordu; üstelik her sürüm yükseltmesinde yeniden.

Çok dillilik altyapısını hazır aldık ama içerik çevirisini kendi modelimize bağladık. Bu, sık kullandığımız üçüncü yol: altyapı hazır, ürüne özgü kısım bizim. Bir bağımlılığı ya tamamen alıp ya tamamen reddetmek zorunda değilsiniz; çoğu doğru karar, sınırın nereden geçtiğini belirlemekle ilgili.

Bağımlılık almak kadar çıkarmak da bir karardır ve genellikle çok geç verilir. Çıkarma sinyalleri şunlardır: bileşen yüzünden çatıyı yükseltemiyorsanız, kullandığınız yüzey toplam yüzeyin küçük bir kısmıysa, her sürümde uyum işi çıkıyorsa ya da lisans/bakım tarafında belirsizlik varsa. Bu dördünden ikisi aynı anda doğruysa çıkarmayı konuşmanın zamanı gelmiştir.

Çıkarma işini kolaylaştıran şey, en başta konulan sarmalayıcıdır. Kütüphane doğrudan yüzlerce dosyadan çağrılıyorsa çıkarma bir refactor projesine dönüşür; tek bir katmanın arkasındaysa yerine kendi kodunuzu koymak günler sürer. Bu yüzden 'belki bir gün değiştiririz' düşüncesi, bağımlılığı aldığınız gün mimariye yazılmalıdır.

Kullanıcı verisine dokunan bileşenlerde ölçüt tamamen değişir: burada kolaylık değil sorumluluk konuşulur. Ziyaret ölçümünü hazır bir dış servisle yapmak beş dakikalık iştir; ama o an ziyaretçinizin verisini üçüncü bir tarafa göndermeye başlarsınız ve bunun hukuki karşılığı size aittir. Biz bu yüzden ölçümü kendimiz yazdık: kişiyi tanımlayan hiçbir veri toplamıyor ve hiçbir yere göndermiyoruz.

Aynı düşünce kimlik doğrulamada da geçerli. Yaygın çözümler yerine sunucu tarafında yaşayan, iptal edilebilir bir oturum jetonu kullanıyoruz. Sebep moda değil ihtiyaç: kurumsal bir üründe 'bu kişinin erişimini şimdi kapat' talebi teorik değil, sık gelen bir taleptir ve istemcide taşınan, süresi dolana kadar iptal edilemeyen bir jeton bunu karşılayamaz.

Bir paketi projenize aldığınızda yalnız o paketi almazsınız; onun bağımlılıklarını, onların bağımlılıklarını ve o zincirdeki herkesin bakım kalitesini de alırsınız. Modern bir arayüz projesinde doğrudan eklediğiniz on paket, arka planda yüzlerce pakete dönüşebilir. Bu zincirin herhangi bir halkasında oluşan bir güvenlik açığı sizin projenizin açığıdır ve çoğu zaman haberiniz bile olmaz.

Bu, bağımlılıktan kaçınmak için değil, bilinçli seçmek için bir sebep. Pratik önlemler basittir: doğrudan bağımlılık sayısını düşük tutmak, sürümleri sabitlemek, düzenli aralıklarla güvenlik taraması çalıştırmak ve bakımı bırakılmış paketleri erken fark edip değiştirmek. Bir paketin son güncellenme tarihine bakmak, onu almadan önce yapılacak en ucuz kontroldür.

Kendi yazdığınız kod bu zincirin dışında kalır ama otomatik olarak güvenli olmaz — yalnız sorumluluk tamamen size geçer. Fark şu: dış bir pakette açık çıktığında düzeltmeyi bekler, kendi kodunuzda çıktığında düzeltirsiniz. Hangisinin daha hızlı olduğu, ekibinizin kapasitesine bağlı; ikisinin de bir cevabı olmalı.

Kendi bileşenini yazma kararı, ekibin sürdürebileceği bir yük olmalıdır. Üç kişilik bir ekipte kendi editörünü, kendi tablo bileşenini ve kendi grafiğini yazmak; bunların bakımını da aynı üç kişiye yıkmak demektir. Bu bazen doğru karardır — bizde öyle oldu — ama ancak o bileşenler ürünün kimliğindeyse ve dar tutulduysa doğrudur.

Ölçüt olarak şunu kullanıyoruz: bir bileşeni yazmayı, onu önümüzdeki üç yıl boyunca güncellemeyi göze alabiliyorsak yazarız. Göze alamıyorsak hazırını alırız — kararı 'şu an daha eğlenceli' diye vermeyiz. Kendi kodunu yazıp iki yıl sonra ona bakamayan bir ekip, en başta bağımlılık alan ekipten daha kötü durumdadır: hem eski hem de kimsenin bilmediği bir kod taşır.

Bir bağımlılığı almadan önce sorduğumuz dört soru şu: Bir, bu parçanın yüzeyi ne kadar geniş — bir hafta içinde yazabileceğimiz bir şey mi, on yıllık birikim mi? İki, ürünün kimliğine ne kadar yakın — kullanıcı bu parçayı 'sizin ürününüz' olarak mı hatırlayacak? Üç, yarın lisansı ya da bakımı değişse maliyeti ne olur? Dört, çatı yükseldiğinde bizi bekletir mi?

Bu dört sorunun cevabı çoğu zaman net bir yön verir. Geniş yüzeyli, kimliğe uzak, olgun ve iyi bakılan bir parça: alın, kullanın, sarmalayın. Dar yüzeyli, kimliğe yakın, tema ve davranış uyumu isteyen bir parça: yazın. Ortada kalanlar için ise geçici karar verin ve arayüzün arkasına koyun — kararı ertelemenin en ucuz yolu, geri dönülebilir hâle getirmektir.

Son olarak bir uyarı: 'kendimiz yazalım' kararı, o parçanın bakım sorumluluğunu da üstlenmek demektir. Yazdığınız editörün gelecek yıl da güncellenmesi, tarayıcı değişikliklerine uyarlanması ve hata düzeltmelerini alması gerekir. Bunu yapmayacaksanız hazırını kullanmak daha dürüst bir karardır. Kendi kodunu yazıp bakmamak, bağımlılık almaktan daha kötüdür.

Bağımlılık seçmek, mühendislik zevkiyle değil sahiplik ölçütleriyle yapılacak bir iştir. Geniş yüzeyli altyapıyı hazır alın; ürününüzün kimliğini taşıyan, dar ve tema duyarlı parçaları kendiniz yazın; verinize dokunan her şeyi kendi kontrolünüzde tutun; ve aldığınız her bağımlılığı bir arayüzün arkasına koyun ki bir gün değiştirmek bir günlük iş olsun.

Bizim ürünlerimizde bu ölçütler yayında karşılığını buluyor: kütüphanesiz bir editör, kütüphanesiz grafikler ve kendi ölçümümüz var; ama veritabanı, sunucu ve arayüz çatısı hazır. Tartışmayı 'hangisi doğru' diye değil, 'bu parça için hangisi doğru' diye kurmak, hem zaman hem sinir kazandırıyor.