Web sitenizdeki teknik borç: görünmez faiz

Kredi kartı borcunu herkes bilir: bugün harcarsınız, sonra faiziyle ödersiniz. Teknik borç da aynı mantıkla çalışır — ama ekstre gelmez. Web sitenizde bugün alınan her kestirme karar, ileride ödenecek bir faiz üretir. Ve bu faiz görünmez olduğu için, çoğu site sahibi borcun farkına ancak ödeme günü geldiğinde varır: yeni bir özellik "iki günlük iş" yerine iki hafta sürdüğünde, ya da basit bir güncelleme siteyi çökerttiğinde.

Bu yazı teknik borcun ne olduğunu, web sitenizde nerelerde biriktiğini ve ne zaman ödenmesi gerektiğini anlatıyor. Bir şeyi baştan söyleyelim: teknik borç her zaman kötü değildir. Bazen bilerek borçlanmak doğru karardır. Sorun borcun kendisi değil, yönetilmeyen borçtur.

Teknik borç tam olarak nedir?

Terimi 1992'de Ward Cunningham ortaya attı ve benzetme bilinçliydi: yazılımda hızlı ama kirli bir çözüm, kredi çekmek gibidir. İşinizi bugün görür; ama her geçen gün, o kirli çözümün üstüne eklenen her satır kod, faiz olarak birikir.

Web sitesi bağlamında teknik borç genellikle şöyle görünür:

• Kestirme kod. "Şimdilik böyle yapalım, sonra düzeltiriz" denilen ama hiç düzeltilmeyen kısımlar.
• Güncellenmemiş bağımlılıklar. Üç yıl önceki bir framework sürümü, güncellenmeyen eklentiler, artık desteklenmeyen kütüphaneler.
• Belgelenmemiş kararlar. Siteyi yapan kişi gitmiş, neden öyle yapıldığını kimse bilmiyor.
• Kopyala-yapıştır mimari. Aynı kod parçasının beş farklı yerde beş farklı sürümü.
• Test yokluğu. Her değişiklikte "umarım bir şey bozulmamıştır" duası.

Dikkat ederseniz bunların hiçbiri ziyaretçiye görünmez. Site dışarıdan gayet normal çalışır. Borç, kaportanın altındadır.

Görünmez faiz nasıl işler?

Faiz kendini üç yerde gösterir.

1. Her değişiklik yavaşlar

Sağlıklı bir sitede "iletişim formuna bir alan ekleyin" bir saatlik iştir. Borçlu bir sitede aynı iş şöyle ilerler: form kodu üç yerde tekrarlanmış, hangisinin gerçekte çalıştığı belirsiz; alanı ekleyince e-posta bildirimi bozuluyor çünkü form ile bildirim birbirine kablo bağı ile tutturulmuş; test ortamı olmadığı için deneme canlı sitede yapılıyor. Bir saatlik iş üç güne çıkar.

Faizin ilk hali budur: aynı işin giderek daha pahalıya mal olması. Ajans veya geliştirici değiştirdiğinizde bu daha da belirginleşir — yeni gelen kişi önce borcun envanterini çıkarmak zorundadır ve bu süreyi siz ödersiniz.

2. Risk sessizce büyür

Güncellenmeyen her bağımlılık, bilinen güvenlik açıklarının birikmesi demektir. WordPress ekosisteminde bunun örnekleri her yıl yaşanıyor: saldırıların önemli bir kısmı çekirdekten değil, güncellenmemiş eklenti ve temalardan geliyor. Ama bu WordPress'e özgü bir sorun değil — modern bir React projesinde de iki yıl npm update çalıştırılmamışsa aynı borç birikir.

Buradaki tuzak şu: güncelleme ertelendikçe güncellemenin kendisi riskli hale gelir. Sürüm 2'den 3'e geçmek küçük bir iştir; 2'den 6'ya atlamak ise çoğu zaman yeniden yazmaya yaklaşır. Borç, ödemeyi geciktirdikçe anaparayı büyütür.

3. İyi insanlar kaçar

Daha az konuşulan bir maliyet: borçlu bir kod tabanında kimse çalışmak istemez. Freelancer'lar "bu siteye dokunmam" der, ajanslar fahiş fiyat verir — çünkü fiyatın içinde borcun keşif maliyeti vardır. Sonunda siteyi yalnızca onu yazan kişi değiştirebilir hale gelir; o kişi ayrıldığında ise site fiilen dondurulmuş olur.

Teknik borç her zaman kötü müdür?

Hayır — ve bu, konunun en çok atlanan kısmı.

Yeni bir ürün fikrini test ediyorsanız, dört haftada çıkan "borçlu" bir MVP, dört ayda çıkan kusursuz mimariden daha değerlidir. Çünkü asıl riskiniz teknik değil, ticaridir: belki o ürünü kimse istemiyor. Bilerek, sınırları çizilmiş borç almak — "şu modülü şimdilik basit tutuyoruz, ürün tutarsa yeniden yazacağız" — profesyonel bir karardır.

Kötü olan, farkında olunmayan borçtur. Kimsenin kaydını tutmadığı, "sonra düzeltiriz"in hiç gelmediği, faizi sessizce işleyen borç. Aradaki fark, kredi çekmek ile kredi kartı ekstresini hiç açmamak arasındaki farktır.

Bir istisna daha: ömrü belli siteler. Üç ay yaşayacak bir kampanya sayfası için teknik borç diye bir dert yoktur; kampanya biter, sayfa kapanır, borç silinir. Borç yönetimi, yaşayacak siteler için anlamlıdır.

Sitenizde teknik borç olduğunu nasıl anlarsınız?

Kod okumanıza gerek yok. Şu sorulara verdiğiniz cevaplar yeterli sinyali verir:

• Küçük bir değişiklik istediğinizde cevap hep "o biraz karışık, bakmamız lazım" mı oluyor?
• Sitenin son güncellemesi ne zaman yapıldı? Cevabı kimse bilmiyorsa, muhtemelen çok oldu.
• Siteyi yapan kişi/ekip hâlâ ulaşılabilir mi? Değilse, elinizde bir belge var mı?
• Yeni bir özellik teklifi aldığınızda fiyatlar size hep beklediğinizden yüksek mi geliyor? Fark, çoğu zaman borcun faizidir.
• "Siteye dokunmayalım, çalışıyor" cümlesi ekipte bir kural haline geldi mi? Bu, borcun en ileri evresidir: site artık değiştirilemez bir kara kutu olmuştur.

Bunlardan iki-üçü tanıdık geliyorsa borcunuz var demektir. Panik gerektirmez; ama görmezden gelmek de bir strateji değildir.

Borç ne zaman ödenir, ne zaman silinir?

İki yol vardır ve ikisi de meşrudur.

Kademeli ödeme, kod tabanı temelde sağlıklıysa mantıklıdır: bağımlılıkları güncel tutmak, her yeni işte dokunulan bölgeyi biraz temizlemek, kritik akışlara test eklemek. Bu, borcu taksitle kapatmaktır — sıkıcıdır ama işe yarar.

Yeniden yapmak ise borcun anaparası, sitenin değerini aştığında doğru karardır. Kabaca şu durumda: her değişiklik haftalar sürüyorsa, siteyi anlayan kimse kalmadıysa ve altyapı bugünkü ihtiyaçlarla (hız, mobil, çok dillilik, entegrasyonlar) temelden uyumsuzsa — eski binayı güçlendirmek yerine yenisini yapmak daha ucuzdur. Buradaki dürüst uyarı: yeniden yazmak da kendi risklerini taşır ve "yeni site" birkaç yıl içinde yine borç biriktirir, eğer bakım alışkanlığı değişmezse.

Asıl mesele şudur: borç, teknik bir sorun gibi görünse de bir yönetim sorunudur. Sitenize düzenli bakım bütçesi ayırmıyorsanız — güncellemeler, küçük temizlikler, belgeleme — hangi teknolojiyle yapılırsa yapılsın borç birikecektir. Modern bir mimari (statik build, headless CMS, az bağımlılık) borcun birikme hızını ciddi biçimde düşürür, çünkü hareketli parça sayısı azdır; ama sıfıra indirmez.

Yeni site yaptırırken borcu baştan sınırlamak

Sıfırdan bir site yaptırıyorsanız, teklif aşamasında soracağınız birkaç soru ileride büyük fark yaratır:

• Site hangi bağımlılıklarla ayakta duracak, bunların güncellenmesi kimin sorumluluğunda?
• Kod ve içerik bize mi ait olacak; başka bir ekip devraldığında ne bulacak?
• Kararlar bir yerde belgeleniyor mu?
• Teslimden sonra bakım nasıl işliyor?

Bu sorulara net cevap veremeyen bir teklif, fiyatı ne olursa olsun pahalıdır — farkı faiz olarak ödersiniz.

Teknik borç yok edilemez; yalnızca yönetilir. İyi yönetilen borç bir araçtır, yönetilmeyeni ise sessiz bir vergi. Sitenizin ekstresini açıp bakmanın zamanı geldiyse — ister mevcut sitenin borcunu konuşmak, ister baştan az borçla kurulacak bir site için — Vucod'a yazabilirsiniz; her başvuruya 48 saat içinde dönüyoruz: vucod.com