Çoğu işletme sahibi teknik borcu programcıların uydurduğu bir bahane sanır. "Kod kirlendi" lafını duyduğunda aklına gelen şey, yeni bir fatura. Oysa teknik borç muhasebeden tanıdığın bir şeyin aynısı: bugün hızlı gitmek için aldığın krediye, yarın her değişiklikte faiz ödersin. Faizi de para olarak değil zaman olarak ödersin. Basit bir kampanya kurulumu iki saat yerine iki gün sürmeye başladığında, o faizi çoktan ödüyorsundur.
Bu borcun dijital ürün satış scripti tarafında özel bir hali var. Çünkü burada kod sadece sayfa göstermiyor; para alıyor, stok kilitliyor, kod teslim ediyor. Bir blog sitesinde bozuk fonksiyon en fazla görüntü bozar. Sende ise aynı bozukluk müşteriye ikinci kez kod gönderir, ya da hiç göndermez. Bu yazıda borcun nerede biriktiğini, hangi kalemin acil hangisinin bekleyebileceğini ve büyümeyi durdurmadan nasıl ödeyeceğini konuşacağız.
Teknik Borç Tam Olarak Nerede Birikiyor?
Borç büyük hatalardan değil, küçük istisnalardan doğar. Bir ürün için özel indirim gerekti, kodun içine tek satır koşul eklendi. Bir bayi farklı formatta kod gönderiyordu, teslim fonksiyonuna ikinci bir dal yazıldı. Bir kampanyada kargo alanı gerekti, sipariş tablosuna kullanılmayan bir kolon açıldı. Her biri tek başına masum. Yirmi tanesi bir araya geldiğinde artık kimse teslim fonksiyonuna dokunmaya cesaret edemez.
Bu birikimin en tehlikeli biçimi kopyalanmış mantık. Fiyat hesabı hem ürün sayfasında hem sepette hem de ödeme dönüşünde ayrı ayrı yazılmışsa, kur güncellemesi geldiğinde üç yerden ikisini düzeltir, üçüncüsünü unutursun. Müşteri sepette gördüğü fiyattan farklı bir tutarla karşılaşır, sen de bunu "ödeme kuruluşu hatası" sanarak haftalarca yanlış yerde arama yaparsın. Sağlıklı bir e-pin satış scripti fiyatı tek yerde hesaplar ve her ekran o tek kaynağa sorar.
Hangi Borç Acil, Hangisi Bekleyebilir?
Bütün borcu aynı gün ödemeye çalışmak işi durdurur. Onun yerine borcu iki eksende sırala: paraya dokunuyor mu ve ne sıklıkla dokunuyorsun. Paraya dokunan ve sık değiştirdiğin kod en pahalı borçtur; oradaki her karmaşa doğrudan iade, itiraz ve güven kaybına dönüşür. Paraya dokunmayan ve yılda bir kez açtığın bir yönetim ekranındaki dağınıklık ise bekleyebilir, hatta hiç ödenmeyebilir.
Bu sıralamayı yaptığında genelde şaşırtıcı bir sonuç çıkar: acil borç listesi sandığından kısadır. Beş ila sekiz dosya. Ödeme dönüşü, stok kilitleme, kod teslimi, fiyat hesabı, kullanıcı bakiyesi. Geri kalan her şey kozmetik. Bu farkı görmek, "her şeyi sıfırdan yazalım" kararının çoğu zaman gereksiz olduğunu da gösterir.
| Borç türü | Belirti | Risk | Öncelik |
|---|---|---|---|
| Kopyalanmış fiyat mantığı | Sepet ve ödeme tutarı farkı | Yüksek | Hemen |
| Gevşek stok kilidi | Aynı kodun iki kişiye gitmesi | Kritik | Hemen |
| Doğrudan düzenlenmiş çekirdek dosya | Güncelleme sonrası her şeyin bozulması | Yüksek | Bu ay |
| Desteği bitmiş PHP veya kütüphane | Sunucu taşımada çalışmayan sayfalar | Orta-yüksek | Bu çeyrek |
| Kullanılmayan kolon ve tablolar | Şişen veritabanı, yavaş sorgu | Orta | Bu çeyrek |
| Belgesiz özel geliştirme | Yazan kişi gidince kimse dokunamıyor | Orta | Fırsat buldukça |
| Dağınık yönetim arayüzü | Eğitim süresi uzun | Düşük | Gerekirse |
Çekirdek Dosyayı Düzenlemek Neden En Pahalı Karardır?
Elindeki e-pin yazılımı güncelleme alıyorsa, çekirdeğine attığın her müdahale bir sonraki sürümde ya silinir ya çatışır. Bu noktada iki kötü seçenek arasında sıkışırsın: güncellemeyi hiç almamak, ya da her güncellemede aynı yamaları elle geri koymak. Birincisi güvenlik açığı biriktirir, ikincisi zaman yakar. İşin acı tarafı, bu kararı genelde bir yılın sonunda fark edersin.
Doğru yol en baştan eklenti veya kanca noktası kullanmaktır. Özel indirim kuralın çekirdeğin içinde değil, kendi dosyanda yaşasın ve yazılımın sunduğu olay noktasına bağlansın. Böylece güncelleme geldiğinde senin kodun yerinde kalır. Bu ilkeye uymayan bir kurulum devraldıysan, ilk iş mevcut müdahaleleri tek bir dosyada toplamak ve hangisinin gerçekten gerekli olduğunu sorgulamak. Genelde yarısı artık kullanılmayan bir kampanya için yazılmıştır.
Teknik borcun kaynak dağılımı
- Kontrolsüz yama ve özel ekleme 40%
- Test edilmemiş ödeme ve teslim kodu 30%
- Eski sürüm PHP ve kütüphaneler 20%
- Belge ve bilgi eksikliği 10%
Test Yazmadan Güvenli Değişiklik Yapmak Mümkün mü?
Küçük bir ekiple çalışıyorsan kapsamlı test altyapısı kurmak gerçekçi olmayabilir. Ama tamamen testsiz kalmak da değil. Ortada bir yol var: sadece para yolunu test et. Sipariş oluşturma, ödeme onayı, kod teslimi ve iade. Dört senaryo. Bunları elle bile olsa her sürüm öncesi aynı sırayla geçirmek, gerçek hayatta yaşadığın felaketlerin büyük kısmını engeller.
İkinci koruma katmanı geri dönüş planıdır. Her değişiklik öncesi veritabanı ve dosya yedeği al, değişikliği tek seferde değil parça parça yayına ver, ilk yarım saat sipariş akışını izle. Bir epin yazılım kurulumunda ödeme kaydı ile teslim kaydı arasında uyumsuzluk raporu varsa, bozulmayı müşteri değil sen fark edersin. Fark etme sırasını değiştirmek, teknik borç yönetiminin en ucuz kazanımıdır.
Borcu Ödemeye Ne Kadar Zaman Ayırmalısın?
Pratik bir oran şu: geliştirmeye harcadığın zamanın beşte biri borç ödemeye gitsin. Haftada bir gün, ya da her beş işten biri. Bunu takvime yazmazsan asla sıra gelmez, çünkü borç ödemenin görünür bir getirisi yoktur; sadece gelecekteki acıyı azaltır. Takvime yazdığında ise altı ay içinde değişiklik hızının belirgin biçimde arttığını görürsün.
Bir de bırakma kararı var. Her borç ödenmez. Beş yıl önce yazılmış, kimsenin kullanmadığı bir modülü düzeltmek yerine silmek daha akıllıdır. Silinen kod bakım gerektirmez, açık barındırmaz, yavaşlatmaz. En iyi refactor, kaldırılan koddur. Envanterini çıkardığında listenin üçte birinin doğrudan silinebileceğini göreceksin; bu da borç ödemenin en tatlı kısmı.
Her acil yamanın yanına tek satır not düş: neden yapıldı, nerede duruyor, ne zaman düzeltilecek. Bu not defteri altı ay sonra envanterin kendisi olur ve seni tahmin yürütmekten kurtarır.
Yeniden Yazmak mı, Hazır Altyapıya Geçmek mi?
Borç belli bir eşiği geçtiğinde ödemek yeniden kurmaktan pahalı hale gelir. Bu eşiği anlamanın üç işareti var: basit değişiklikler kimsenin öngöremediği yerleri bozuyor, güvenlik güncellemesi alınamıyor, ve kodu yazan kişiyle iletişim yok. Üçü birden varsa borç ödemeyi bırak, taşınmayı planla.
Taşınma kararında kritik soru "yeni yazılım daha güzel mi" değil, "borcu yeniden biriktirmemi engelliyor mu". Kanca noktaları var mı, tema ile çekirdek ayrılmış mı, ödeme ve teslim modülleri değiştirilebilir mi, güncellemeler senin özelleştirmelerini eziyor mu. Bu sorulara net cevap veren bir e-pin satış yazılımı ile aynı hataya ikinci kez düşme riskin çok düşer.
| Kontrol sorusu | İyi cevap | Uyarı işareti |
|---|---|---|
| Fiyat hesabı kaç yerde yazılı? | Tek merkezde | Üç veya daha fazla |
| Çekirdek dosyalarda elle düzenleme var mı? | Yok, kancalarla çözülmüş | Var ve listesi bilinmiyor |
| PHP ve kütüphane sürümleri destekli mi? | Güncel sürüm | Desteği bitmiş sürüm |
| Sürüm öncesi para yolu denenir mi? | Her seferinde | Hiç denenmiyor |
| Geri dönüş planı hazır mı? | Yedek ve adım yazılı | Yedek belirsiz |
| Kullanılmayan modüller kaldırıldı mı? | Düzenli temizlik var | Hepsi duruyor |
| Yamalar kayıt altında mı? | Tek dosyada not var | Kimse hatırlamıyor |
Borcu biriktirmeyen bir altyapı kur
Pinova, özelleştirmeni çekirdekten ayırır; güncelleme geldiğinde senin kodun yerinde kalır. Fiyat, stok ve teslim mantığı tek merkezde çalışır.
Teknik borcu nasıl ölçebilirim, teknik biri değilim?
İki sayıya bak: basit bir değişikliğin ne kadar sürdüğü ve son üç ayda kaç kez beklenmedik bozulma yaşandığı. İkisi de artıyorsa borç büyüyor demektir; kod okumaya gerek yok.
Her şeyi sıfırdan yazmak en temiz çözüm değil mi?
Genelde değil. Acil borç çoğu zaman beş sekiz dosyada toplanır. Sıfırdan yazmak o dosyaları düzeltirken çalışan geri kalanı da riske atar. Yeniden yazma, güncelleme alınamaz hale gelindiğinde mantıklıdır.
Yamaları çekirdekten ayırmak pratikte ne kazandırır?
Güncelleme alabilmeyi kazandırır. Bu da güvenlik yamalarını ve yeni ödeme entegrasyonlarını ücretsiz almak anlamına gelir. Ayrım yoksa her güncelleme ayrı bir proje olur.
Borç ödemeye ayıracak zamanım yok, ne yapmalıyım?
En küçük adımla başla: yamaların listesini çıkar ve kullanılmayanları sil. Silmek zaman almaz, risk azaltır ve genelde envanterin üçte birini temizler.
Teknik borç kaçınılmaz; yönetilmemesi ise tercih. Elindeki kurulumun borcu biriktirmeye mi yoksa sınırlamaya mı meyilli olduğunu anlamak için mimarisine bakman yeterli: özelleştirme nerede yaşıyor, güncelleme neyi eziyor, fiyat ve teslim mantığı kaç yerde duruyor. Özellikleri ve paketleri gözden geçir, ardından canlı demo içinde panelin modül yapısını kendi gözünle incele; kendi kurulumundaki en pahalı borç kalemini o ekranda fark edeceksin.