Yazılım projeleri çoğu zaman "hızlı yap, yayınla, sonra düzeltiriz" anlayışıyla başlar. Ürün canlıya alınır, kullanıcılar gelir, satış olur ve... kimse o "sonradan düzeltilecek" şeylere geri dönmez. Aylar geçer, yeni özellik eklemek istediğinizde "yapamayız, mevcut yapıyı bozarız" cevabını alırsınız. İşte bu nokta, teknik borçun faturasının ödenmeye başladığı andır. Bu yazıda teknik borcun ne olduğunu, neden hızla birikip projeyi felç ettiğini ve müşteri olarak baştan nasıl önlem alacağınızı anlatıyoruz.
Teknik borç nedir?
Teknik borç (technical debt), uzun vadeli doğru çözüm yerine kısa vadeli hızlı çözümün tercih edilmesinden doğan gelecekteki maliyettir. Tıpkı finansal borç gibi:
- İlk başta hızlı para sağlar (hızlı teslimat).
- Üzerine faiz işler (her yeni özellik eski "geçici çözüme" eklenmek zorunda kalır).
- Zamanla ödemek imkânsızlaşır (sistemi sıfırdan yazma gerekliliği).
Yazılım metaforu olarak ortaya atan Ward Cunningham (1992), hızlı yazılmış kodun gelecekteki düzeltme maliyetini "borç" olarak nitelendirdi. Bugün hâlâ en doğru tanım budur.
Teknik borç nasıl birikir?
Beş tipik birikme yolu vardır:
1. Aceleci teslimat baskısı
"Cuma akşamı yayında olsun" baskısıyla yazılan kod; testlerden, dokümantasyondan, mimari planlamadan eksik kalır. Her acele teslim, gelecekteki ekibe ödenmemiş borç bırakır.
2. Yanlış teknoloji seçimi
"Bu framework eski ama biz biliyoruz" diye 5 yıl önce seçilen teknoloji; bugün yedek parça bulamayan otomobil gibidir. Bakım maliyeti yıllar içinde sürekli artar.
3. Kopyala-yapıştır kodlama
Aynı iş kuralı projenin 10 farklı yerinde tekrarlanıyorsa, bir gün bir değişiklik 10 yerde birden yapılmak zorunda kalır. Tahmin edin: birinde unutulur, yanlış sonuçlar üretmeye başlar.
4. Test eksikliği
Otomatik testleri olmayan bir kodda hiçbir değişiklik güvenle yapılamaz. Geliştirici "bozarım" korkusuyla dokunmaz; sistem fosilleşir.
5. Belgelenmemiş "magic" kodlar
"Bu satırı kaldırma çalışmaz, sebebini bilmiyorum" yorumlu kod parçaları gerçek hayatta sık görülür. Bilen kişi ayrılınca, projenin kontrolü kaybedilir.
Teknik borcun ölçülebilir bedelleri
Borç ödenmediğinde işletmeye yansıyan somut maliyetler şunlardır:
Geliştirme hızında düşüş
Yeni özellik eklemek ilk başta 2 gün sürerken, 1 yıl sonra aynı tür özellik 2 hafta sürer hale gelir. Kod karmaşıklığı doğrusal değil, üstel artar.
Hata sayısında artış
Bir alan düzeltilirken iki başka yer bozulur. Regresyon hataları ürünün güvenilirliğini kemirir; müşteri kaybı başlar.
Ekip moralinde çöküş
Yetenekli geliştiriciler "spagetti kod"la çalışmak istemez; ekip bir bir ayrılır. Yerine gelen kişi sistemi anlamak için 3-6 ay harcamak zorunda kalır.
İş kararlarının imkânsızlaşması
"3 ay sonra mobil uygulama lanse edelim" dediğinizde "altyapımız buna izin vermiyor" cevabını alırsınız. Yazılım, iş kararlarının önünde engele dönüşür.
Müşteri olarak teknik borcu nasıl önleyebilirsiniz?
Yazılım geliştirici siz değilsiniz; ancak yatırımcı olarak teknik kararların gözeticisisiniz. İşte 7 somut yaklaşım:
1. "Bir kez yapalım bitsin" tuzağına düşmeyin
Yazılım yaşayan bir üründür, tek seferlik proje değildir. Geliştirme bütçesinin yanına mutlaka yıllık bakım/iyileştirme bütçesi ayırın. İyi tahmin: ilk geliştirme maliyetinin yıllık %15-25'i.
2. Sözleşmede "kabul kriterleri" net olsun
"Çalışıyor görünüyor" kabul kriteri değildir. Test kapsamı, dokümantasyon, kod kalite standartları sözleşmede yazılı olmalıdır. Profesyonel geliştirici firmalar bu kriterleri zaten kendileri önerir.
3. Kod sahipliği sizde olsun
Kaynak kodu, veritabanı, bağımlılıklar — hepsinin tam erişimi sizde olmalıdır. "Onların serverında çalışıyor, vermiyorlar" senaryosu en kötü bağımlılık tuzağıdır.
4. Teknoloji seçimini sorgulayın
"Neden bu framework?" sorusunu sormaktan çekinmeyin. Aktif topluluk, uzun vadeli destek, ekibin uzmanlığı seçim kriterleri olmalıdır. Modaya değil, sürdürülebilirliğe göre seçim.
5. Düzenli "borç ödeme" turları planlayın
Geliştirme döngülerinin %15-20'sini teknik iyileştirmeye ayırın. Her yeni özellik döneminde "bu sefer şu eski kötü kısmı düzeltelim" planı eklemek borcu sürekli kontrol altında tutar.
6. Kod incelemesi (code review) talep edin
Profesyonel ekiplerde yazılan her kod en az bir başka geliştirici tarafından incelenir. Tek geliştirici, çift kontrol yazılım dünyasının en ekonomik kalite kontrolüdür.
7. Üçüncü gözden geçirme (audit) yaptırın
Yılda bir, projenizden bağımsız bir uzmana teknik denetim yaptırın. Mevcut ekibin görmediği veya görmek istemediği sorunlar açığa çıkar.
"İyi" teknik borç da var mı?
Evet. Bilinçli, planlı, geçici teknik borç bazen doğru karardır:
- MVP (Minimum Viable Product) ile pazar testi yapmak — fikrin tutup tutmadığını görmek için.
- Acil iş gereksinimi olduğunda — örneğin BlackFriday kampanyası, sezonluk ürün.
- Belirsizliğin yüksek olduğu yeni projelerde — sonradan "doğru" mimari netleştiğinde refactor edilir.
Önemli olan bu borcun bilinçli alındığını, ne zaman ödeneceğinin planlandığını ve ekipte takip edildiğini bilmektir. Yoksa "iyi borç" da "kötü borç" haline gelir.
Sıkça sorulan sorular
Mevcut sistemimde teknik borç olduğunu nasıl anlarım?
Üç belirti: yeni özellik eklemek aylar sürüyor, küçük değişiklikler farklı yerleri bozuyor, ekip "bu kısma dokunmayalım" diyor. Bu üç işaretten biri bile teknik borç sinyalidir.
Sıfırdan yazmak mı, mevcudu iyileştirmek mi?
Genel kural: sıfırdan yazma maliyeti tahminin 2-3 katı, refactor maliyeti ise daha kontrollüdür. Sıfırdan yazma kararı için "mevcut sistemde 6 ay sonra bile %50'sini koruyamayız" emin olmak gerekir.
Açık kaynak ile özel geliştirme arasında teknik borç farkı var mı?
Açık kaynak (WordPress, Magento) başlangıçta teknik borç riskini düşürür çünkü hazır altyapı vardır. Ama aşırı eklenti ve özelleştirme yapıldığında borç birikmeye başlar. Özel geliştirme baştan daha pahalıdır, doğru yönetilirse uzun vadede borç birikimi daha düşüktür.
Bakım maliyeti ne kadar olmalı?
Sektörel olarak ilk geliştirme maliyetinin %15-25'i yıllık bakım bütçesi sağlıklıdır. Bunun altında kalan projelerde teknik borç hızla birikir.
Sonuç: Teknik borç görünmez ama kaçınılmazdır
Her yazılım projesi belli oranda teknik borç biriktirir; soru "olacak mı?" değil, "yönetebilecek miyiz?" sorusudur. Müşteri olarak en güçlü silahınız; geliştirici ortağınızı yalnız iş gereksinimleriyle değil, kod kalitesi, test, dokümantasyon ve uzun vadeli sürdürülebilirlik konularıyla da sorgulamaktır.
Şimşek Software olarak her projeyi uzun vadeli mülkiyet düşüncesiyle kuruyoruz: test ve dokümantasyon dahil, kod sahipliği sizin, teknoloji seçimi açıklamalı. Mevcut bir sisteminizin sağlığından emin değilseniz teknik denetim talep edebilir, hangi adımların atılması gerektiğini birlikte planlayabiliriz.
