Kurumsal Web Sitesinde Teknik Borç Nasıl Ölçülür ve Azaltılır?

Kurumsal web siteleri nadiren bir gecede çöker. Daha sık görülen tablo şudur: her değişiklik bir öncekinden uzun sürer, her güncelleme biraz daha korkutur, sonunda kimse siteye dokunmak istemez. Bunun adı teknik borçtur; geçmişte hız için alınan kısa yolların bugün her bakım işine faiz olarak eklenmesi. Aşağıda borcun nasıl envanterleneceği, etki ve çabaya göre nasıl sıralanacağı ve “yeniden mi yapalım, kademeli mi iyileştirelim?” kararının hangi eşiklerle verileceği anlatılıyor.

Web projelerinde teknik borcun tipik kaynakları

Teknik borç “kötü kod”la aynı şey değildir. Bilinçli alınmış ve yazıya geçirilmiş bir kısa yol yönetilebilir; kimsenin hatırlamadığı bir alışkanlık yönetilemez. Web sitelerinde borç genellikle şu kaynaklardan birikir:

• Çalışma ortamı gerilemesi: Desteklenmeyen PHP sürümü, eski MariaDB/MySQL, yalnız eski PHP ile çalışan özel kod veya eklentiler. Güvenlik güncellemelerini doğrudan engeller.
• Tema içine gömülmüş iş mantığı: functions.php içinde yüzlerce satırlık entegrasyon kodu, tema değişince kaybolacak özel yazı türleri ve kısa kodlar.
• Şablon kopyaları: Alt temada üzerine yazılmış WooCommerce veya eklenti şablonları. Ana eklenti şablonu güncellediğinde kopya eski kalır; WooCommerce bunu Durum (System Status) ekranında güncel olmayan şablon geçersiz kılmaları olarak raporlar.
• Sayfa oluşturucu içindeki ham HTML: HTML widget’ları, satır içi CSS, sayfa başına kopyalanmış bileşenler. Görsel düzenleme biter; bir tasarım değişikliği onlarca sayfada elle yapılır.
• Eklenti yığılması: İşlevi çakışan, terk edilmiş veya lisansı bitmiş eklentiler.
• Belgelenmemiş entegrasyonlar: Sunucu crontab’ında kimsenin hatırlamadığı betikler, koda gömülü API anahtarları, yalnız bir kişinin bildiği FTP aktarımları.
• Ortam ve süreç eksikleri: Sürüm kontrolü olmayan kod, staging’in olmaması, elle yapılan dağıtımlar.
• Bağımlılık eskimesi: Eski jQuery sürümüne veya jQuery Migrate’e bağımlı scriptler, güncellenmeyen Composer ve npm paketleri.

Sahada en pahalıya patlayan kalem genellikle belgelenmemiş entegrasyondur. Betiği yazan kişi ayrılmıştır. Çalıştığı da ancak durduğunda anlaşılır.

Teknik borç envanteri nasıl çıkarılır

Envanter bir kod inceleme toplantısından değil, sistematik taramadan çıkar. Kontrol sırası: önce ortam, sonra kod, sonra içerik, en son süreç.

Ortam ve bağımlılık taraması

PHP sürümünün destek durumu PHP’nin desteklenen sürümler sayfasından doğrulanır. Özel kodun hedef sürümle uyumu PHP_CodeSniffer ve PHPCompatibilityWP kural setiyle statik olarak taranabilir:

# Composer ile geliştirme bağımlılığı olarak kur
# (Composer 2.2+ PHPCS kurulum eklentisi için allow-plugins onayı isteyebilir)
composer require --dev phpcompatibility/phpcompatibility-wp:"*"

# Tema ve özel eklentileri PHP 8.2 ve üzeri için tara
vendor/bin/phpcs -p wp-content/themes/ozel-tema wp-content/plugins/ozel-eklenti \
  --standard=PHPCompatibilityWP --runtime-set testVersion 8.2- \
  --extensions=php --report=summary

# Paket bağımlılıklarının eskime durumu
composer outdated --direct
npm outdated

Statik tarama her şeyi yakalamaz. Dinamik çağrılar ve çalışma zamanında çıkan uyarılar için staging’de hedef PHP sürümüyle gerçek senaryoları çalıştırıp hata günlüğünü izlemek gerekir. Geçişin kendisi ayrı bir proje olarak PHP sürüm geçişi planı rehberinde ele alınıyor.

Kod ve yapılandırma taraması

• Tema ve özel eklentilerde satır sayısı, sürüm kontrolünde olup olmadığı, son değişiklik tarihi.
• Alt temadaki şablon geçersiz kılmalarının listesi ve ana şablonla sürüm farkı.
• Koda sabit yazılmış URL’ler, API anahtarları ve parolalar (grep -rn "api_key\|password\|http://" wp-content/themes gibi basit bir arama başlangıç için yeterli).
• Sunucu crontab’ı (crontab -l, /etc/cron.d/) ve WordPress cron görevleri (wp cron event list).

İçerik ve sayfa oluşturucu taraması

HTML widget’ı, satır içi stil ve özel kısa kod kullanan sayfa sayısı çıkarılır. Elementor sayfa verisini _elementor_data meta alanında JSON olarak tuttuğu için widget türü bu alanda aranabilir. Aşağıdaki sorgu HTML widget’ı içeren yazı ve şablon sayısını verir (tablo önekini wp db prefix çıktısına göre düzeltin; sonuç revizyonları da sayabilir):

wp db query 'SELECT COUNT(DISTINCT post_id) FROM wp_postmeta
  WHERE meta_key = "_elementor_data"
  AND meta_value LIKE "%\"widgetType\":\"html\"%";'

Bu sayı “bir tasarım değişikliği kaç sayfaya dokunuyor?” sorusunun cevabıdır. Yöneticiye gösterilecek ilk rakam da budur.

Süreç taraması

Sürüm kontrolü, staging, yedek geri yükleme testi, dağıtım yöntemi ve dokümantasyon evet/hayır olarak kaydedilir. Süreç eksiği tek başına kod sorunu değildir; ama diğer bütün borçların ödenmesini pahalılaştırır. Staging yoksa her düzeltme canlıda yapılır.

Etki ve çaba matrisi ile önceliklendirme

Envanterdeki her kalem iki eksende puanlanır. Etki, kalemin bugün yarattığı risk ve sürtünmedir: güvenlik açığı, engellenen güncelleme, performans kaybı, uzayan değişiklik süresi. Çaba, kalemi kapatmanın iş miktarı ve riskidir. 1–3 ölçeği çoğu ekip için yeterli; amaç hassas hesap değil, tartışmayı ortak bir dile taşımak.

Örnek kalem	Etki	Çaba	Karar
Desteklenmeyen PHP sürümü	Yüksek	Orta	Hemen planla
Koda gömülü API anahtarı	Yüksek	Düşük	Hemen yap
Eski WooCommerce şablon kopyaları	Orta	Düşük	Hemen yap
Terk edilmiş form eklentisi	Yüksek	Orta	Hemen planla
HTML widget’larıyla kurulmuş sayfalar	Orta	Yüksek	Kademeli, yeniden tasarımla birleştir
Belgelenmemiş cron betiği	Orta	Düşük	Belgele, sonra değerlendir
Kullanılmayan özel yazı türü	Düşük	Düşük	Fırsat bulundukça

Dört bölge şöyle okunur: yüksek etki ve düşük çaba “hemen yap”; yüksek etki ve yüksek çaba “proje olarak planla”; düşük etki ve düşük çaba “o bölgeye dokunulduğunda yap”; düşük etki ve yüksek çaba “bilinçli kabul et ve kaydet”. Son grubu hafife almayın. Her borcun ödenmesi gerekmez; ama kabul edildiği yazılı olmalı ki her toplantıda yeniden açılmasın.

Güvenlik ve güncelleme engelleyen kalemler matristen bağımsız olarak öne alınır. Desteklenmeyen PHP sürümüne bağımlı tek bir eklenti, sitedeki diğer bütün bileşenlerin güncellenmesini durdurabilir. Zincirleme etki budur.

Bakım planına borç azaltma işlerini yerleştirmek

Ayrı bir “temizlik projesi” beklenerek borç nadiren azalır; o proje yeni özellik talepleri karşısında hep ertelenir. İşleyen yöntem, borç azaltmayı düzenli bakımın sabit parçası yapmaktır:

• Sabit kapasite: Her ay bakım saatlerinin belirli bir bloğu borç kalemlerine ayrılır. Acil işler dışında başka işe aktarılmaz.
• Dokunduğun yeri düzelt: Bir sayfa veya bileşen yeni bir talep için açıldığında o bölgedeki küçük borç kalemleri aynı işte kapatılır.
• Yeni borç kaydı: Teslim tarihi yüzünden bilinçli alınan kısa yollar envantere aynı gün yazılır; “sonra düzeltiriz” sözlü kalmaz.
• Çeyreklik gözden geçirme: Envanter yeniden puanlanır, kapananlar işaretlenir, yeniler eklenir.

Borç azaltmanın bakım sözleşmesinde nasıl karşılık bulacağı, kapsam ve öncelik tanımlarıyla birlikte web bakım sözleşmesinde SLA yazısında anlatılıyor. Eklenti kaynaklı borcu ayıklamak için eklenti envanteri ve güvenli kaldırma rehberi doğrudan uygulanabilir.

Yeniden yazma mı kademeli iyileştirme mi

Borç büyüdükçe “sıfırdan yapalım” önerisi cazip gelir. Bazen doğru karardır. Ama eski sitenin yıllar içinde biriktirdiği örtük gereksinimleri (yönlendirmeler, form entegrasyonları, özel alanlar, SEO değeri olan URL’ler) yeniden keşfetmeyi gerektirir; keşfedilmeyen her biri yeni sitede arıza olarak geri döner. Karar için şu eşikler kullanılabilir:

Durum	Kademeli iyileştirme	Yeniden yapım
Çekirdek ve eklentiler güncellenebiliyor	Uygun	Gerekmez
Çalışma ortamı desteklenen sürüme taşınamıyor	Zor	Güçlü aday
Tasarım değişikliği sayfa sayfa elle yapılıyor	Bileşen bazında dönüşüm	Yeniden tasarımla birleşirse uygun
İş mantığı tema dosyalarına dağılmış	Önce eklentiye taşı	Mimari değişiyorsa uygun
Bilgi mimarisi ve içerik de değişecek	Sınırlı fayda	Uygun

Kademeli iyileştirmede sık kullanılan desen, yeni bileşenleri eskisinin yanına kurup trafiği adım adım yeniye almaktır: önce şablon ve global stiller, sonra en çok değişen sayfa grupları, en son nadir dokunulan sayfalar. Her adım tek başına yayına alınabilir ve geri alınabilir olmalı. Geri alınamayan adım, kademeli değildir.

Yeniden yapım seçildiğinde en büyük risk URL ve içerik kaybıyla arama görünürlüğünün düşmesidir; taşıma sırasında SEO kaybını önleme rehberindeki yönlendirme ve doğrulama adımları planın parçası olmalı. Platform değişikliği de masadaysa WordPress ile Next.js karşılaştırması ek bir karar çerçevesi verir.

Teknik borç değerlendirme kontrol listesi

• PHP, veritabanı ve web sunucusu sürümleri destek takvimine göre kontrol edildi.
• Özel tema ve eklentiler sürüm kontrolünde; son değişikliği yapan kişi biliniyor.
• PHP uyumluluk taraması hedef sürüm için çalıştırıldı, sonuçlar kaydedildi.
• Şablon geçersiz kılmaları listelendi, ana şablonla sürüm farkları not edildi.
• Koda gömülü gizli bilgiler (anahtar, parola) tespit edildi; ortam değişkenlerine veya yapılandırma dosyasına taşınması planlandı.
• Sunucu ve WordPress cron görevleri belgelendi.
• HTML widget’ı ve satır içi stil kullanan sayfa sayısı çıkarıldı.
• Her kalem etki ve çabaya göre puanlandı; kabul edilen borçlar gerekçesiyle kaydedildi.
• Bakım planında borç azaltma için sabit kapasite ayrıldı.
• Yeniden yapım değerlendiriliyorsa URL envanteri ve yönlendirme planı hazır.

Envanterden modernizasyon kararı çıktığında eski web sitelerinin modernizasyonu hizmeti, borcun düzenli bakım içinde azaltılması tercih edildiğinde web sitesi bakım ve destek sözleşmeleri sayfası ilgili kapsamı açıklar.

Sık sorulan sorular

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

Hayır. Bir teslim tarihi için bilinçli alınan ve kaydedilen kısa yol makul bir karardır. Sorun, borcun belgelenmemesi ve geri ödeme planı olmadan birikmesidir. Düşük etkili bazı borçlar bilinçli kabul edilip hiç ödenmeyebilir.

Teknik borcu yönetime nasıl anlatabilirim?

Kalemleri teknik terimlerle değil iş sonucuyla yazın: güncelleme yapılamaması, güvenlik açığının kapatılamaması, bir değişikliğin kaç gün sürdüğü. Etki ve çaba matrisi, hangi işin neden önce yapılacağını görsel olarak anlatmayı kolaylaştırır.

Siteyi sıfırdan yeniden yapmak teknik borcu sıfırlar mı?

Kısa vadede birçok kalemi kapatır; ama eski sitedeki örtük gereksinimler keşfedilmezse yeni sorunlar doğar. Yeni sitede de envanter, bakım ritmi ve kayıt disiplini kurulmazsa borç yeniden birikir.

PHP uyumluluk taraması tek başına yeterli mi?

Hayır. PHPCompatibility statik analiz yapar; dinamik çağrıları ve çalışma zamanı uyarılarını yakalayamayabilir. Taramayı, staging’de hedef PHP sürümüyle gerçek kullanım senaryolarını çalıştırıp hata günlüğünü izleyerek tamamlayın.