BİLGİ BANKASI
Teknik Borcu Önleyen Mimari Tasarım: Yazılım Projelerinde Kalıcı Kalite Nasıl Sağlanır?
İçindekiler — Türkçe
Teknik Borç Nedir ve Nasıl Birikir?
Teknik borç, yazılım geliştirme sürecinde hız veya kolaylık uğruna alınan kısa vadeli kararların uzun vadede ödenmesi gereken maliyetidir. Ward Cunningham'ın önerdiği bu metafor, finansal borca birebir benzer: borç alındığında bir şeyler elde edilir, ancak faiz birikmeye devam eder.
SOLID Prensipleri: Kod Kalitesinin Temeli
S — Single Responsibility Principle
Her sınıf veya modül, yalnızca tek bir iş yapar. Bir sınıfın değişmesi için tek bir neden olmalıdır. Bu prensip ihlali, en yaygın teknik borç kaynağıdır: her şeyi yapan 'God Class'lar.
O — Open/Closed Principle
Yazılım varlıkları genişlemeye açık, değişime kapalı olmalıdır. Yeni özellik eklemek, mevcut kodu değiştirmeyi değil; yeni sınıf veya modül eklemeyi gerektirmelidir.
L — Liskov Substitution Principle
Alt sınıflar, üst sınıfların yerine kullanılabilmelidir. Bu prensip, kalıtım hiyerarşisinin doğru kurulmasını zorunlu kılar.
I — Interface Segregation Principle
İstemciler, kullanmadıkları arayüzleri implemente etmeye zorlanmamalıdır. Büyük arayüzler, küçük ve özel arayüzlere bölünmelidir.
D — Dependency Inversion Principle
Yüksek seviyeli modüller, düşük seviyeli modüllere bağımlı olmamalıdır. Her ikisi de soyutlamalara bağımlı olmalıdır. Bu prensip, test edilebilirliğin ve değişime açıklığın temelidir.
Clean Architecture: Katmanlı Bağımsızlık
Robert C. Martin tarafından kavramsallaştırılan Clean Architecture, iş mantığını (domain layer) framework, veritabanı ve UI'dan bağımsız tutar. Bu bağımsızlık, test edilebilirliği maksimize eder ve teknoloji değişikliklerinin iş mantığını etkilememesini sağlar.
Test-Driven Development: Tasarımı Test Yönlendirir
TDD döngüsü basittir: önce başarısız test yaz (Red), testi geçecek minimum kodu yaz (Green), kodu iyileştir (Refactor). Bu döngü, kodun test edilebilir tasarlanmasını zorunlu kılar — ve test edilebilir tasarım çoğu zaman temiz tasarımdır.
- Unit testler: Her fonksiyon ve sınıf izole edilmiş
- Integration testler: Katmanlar arası etkileşimler
- E2E testler: Kullanıcı senaryoları baştan sona
- Test coverage hedefi: Kritik business logic için %80+
Continuous Refactoring: Borcu Birikimden Önce Ödemek
Teknik borç kaçınılmazdır; tamamen yokluğu değil, kontrol altında tutulması hedeflenir. Her sprint'in %15–20'sini refactoring'e ayırmak, borcun faiz öncesi ödenmesini sağlar.
- Code smell tespiti: Uzun metotlar, derin iç içe geçme, dead code
- Static analysis araçları: SonarQube, PHPStan, ESLint
- Dependency audit: Güncel olmayan veya güvenlik açıklı bağımlılıklar
- Documentation debt: Güncel olmayan veya eksik dokümantasyon
AI Perspective: 2026–2030
AI destekli kod analiz araçları, teknik borcu gerçek zamanlı olarak tespit edip önceliklendirmeye başlamıştır. GitHub Copilot, Amazon CodeWhisperer ve benzeri araçlar, kod yazarken SOLID ihlallerini ve anti-pattern'leri anlık olarak işaret edecektir.
SIKÇA SORULAN SORULAR
Temel Çıkarımlar
- Teknik borç, kötü niyetin değil; mimari farkındalık eksikliğinin ürünüdür.
- SOLID prensipleri, teknik borcu önleyen temel tasarım kuralları seti olarak evrensel geçerlidir.
- Clean Architecture, iş mantığını teknoloji değişimlerinden korur.
- TDD, hem kod kalitesini hem de tasarım kalitesini birlikte artırır.
- Continuous refactoring, borcu faiz öncesi ödemenin sistematik yoludur.
