Developer Summit 2021'de gerçekleştirdiğim ve monolitik sistemlerde (özellikle legacy kabul edilen katmanlı modellerde) teknik borçla nasıl mücadele edileceğine dair anlatımın yer aldığı sunumdur. Sunumda teknik borçla ilgili istatistikler, tanım, mücadele şekilleri, yazılım mimariler arasındaki farklılıklara da yer verilmektedir.

1. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Burak Selim Şenyurt
Uzman Yazılım Geliştirici
Doğuş Teknoloji
Monolitik Uygulamalarda Teknik
Borç ile Mücadele (Teori)

2. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.

3. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Rakamlarla Teknik Borç
● 1.31 Trilyon $ : Sadece Birleşik Devletler’ de ciddi sorunlara yol açabilecek teknik
borç düzeltme maliyeti 1.31 Trilyon dolar civarında (CISQ)
● 2.84 Trilyon $ : Gartner’ a göre ciddi sorunlara yol açabilecek teknik borç düzeltme
maliyeti sadece 2020 için 2.84 Trilyon $.
● 45”, 462 Milyon $: Bir regülasyonu hatalı uygulayan NYSE firması 45 dakikada 462
milyon dolar zarar ediyor.
● %60 : CIO’ların %60’ı son üç yıllık dönemde teknik borçların gözle görülür şekilde arttığını
ifade ediyor (McKinsey)
● %10 - %20 : Yeni ürünlere ayrılan bütçenin teknik borç için harcanan miktarı.
(McKinsey)
● 3.61 $ : CAST’ a göre kod satırı başına ortalama teknik borç maliyeti.

4. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Code Base
Büyüyor !
CISQ raporuna göre
2005’te yıllık bazda
ortalama 35 milyar satır
kod üretilirken bu rakam
2020’de 100 milyar olarak
revize edilmiş. Bu artışa
göre dünya genelinde
yaklaşık 1.655 trilyon kod
satırı olduğu
tahminlenmiş.

5. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teknik Borç Tanımı
Proje olgunlaştıkça çevikliği azaltan
herhangi bir koddur ve gerçek teknik
borç tesadüfi değil kasıtlı olarak
ortaya çıkar.
Shawn McCormick - Big Commerce
Bir işletmenin doğru çözüm için
gereken zaman ve parayı harcamak
yerine mevcut kodu yeni kodlarla
yükseltmeyi seçtiğinde maruz kaldığı
gerçek maliyettir.
Brad Sousa - Forbes
Hızlı kazançlar elde etmek için
yazılıma eklenen ve ileride düzeltilmesi
için daha fazla çaba gerektiren
herhangi bir koddur.
Trey Huffine - GitConnected
Kasti veya değil müşteri isteklerine
veya uygulama kısıtlarına(deadline
gibi) öncelik veren yazılım geliştirme
eylemlerinin sonucudur.
Science Direct
Hedefe daha hızlı ulaşmak için koda
kestirme yollar eklediğinizde bugün
normalden daha fazlasını
yapabilirsiniz ama sonra daha yüksek
bir maliyet ödersiniz.
Hackernoon’dan Biri

6. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Belirli sebeplerle yeni
bir özelliğin
geliştirilmesi ya da
bir sorunun çözümü
sırasında kullanılan
ancak tam olarak
doğru olmayan
yaklaşımların
çoğalmasıyla oluşan
ve ivmesi sürekli
yükselen faizli kredi
borcudur.

7. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
The Silent Company Killer

8. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teknik Borç Türleri
2007
Steve
McConnel
Intentional
Stratejik sebeple
kasıtlı yapılan.
UnIntentional
2014
Software Engineering
Institute
(Carnegie Mellon)
Architecture
Build
Code
Defect
Design
Documentation
Infrastructure
People
Process
Requirement
Service
Test Automation
Test
Technical Debt Quadrant
(Martin Fowler)
Reckless
(Umursamaz/
Pervasız)
Prudent
(Tedbirli/
İhtiyatlı)
Inadvertent(Kazara)
Deliberate(Kasten/Planlı)
Tasarım için zaman yok.
Hemen çıkmalı ve
sonuçlara katlanmalıyız.
Katman ne demek ki?
Artık nasıl yapmamız
gerektiğini biliyoruz.

9. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teknik Borçlanma Sebepleri
● Stratejik
Etkiyi ölçememek, bütçe ile uyum sorunu, ürün karmaşıklığı, birleşemeler sonrası
yetersiz teknoloji entegrasyonu...
● Süreçsel
Önceliklendirme zaafları, zayıf bakım yönetimi, kod kalite ölçümü yetersizliği,
tutarsız disaster recovery operasyonu...
● Yetenek Bazlı
Teslimatı geciktiren beceri eksikliği, teknik borç azaltmaya nadiren kaynak
tahsisi yapılması, karar noktalarında teknik borcun göz ardı edilmesi...
● Mimari
Yapısal güncelleme hataları, legacy sistemlerden kalan problemler, ürünleşmiş
PoC uygulamaları, yeniden kullanılabilirliği zayıf bloklar, değiştirilmesi zor iş
kuralları, tutarsız veri modelleri, fazla point-to-point entegrasyon noktası,
özelleştirilmiş değiştirilmesi zor bileşenler...

10. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teknik Borç Nasıl Yönetilir? (Genel)
Ortak Tanım
Kabullenme
Şeffaflık
Karar Verme Süreci
Kaynak Tahsisi (Task Force)
Big Bang (Maraton Projeler)
İflas Noktası (>%50)

11. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.

12. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teknik Borcun Üstesinden Gelenler
İyi Proje Yönetimi
Yeterli Seviyede Yetenek
Tanımlı Geliştirme Süreçleri
Başarılı Süre Tahminleri
Müşteri Memnuniyeti
Toplam Kalite Yönetimi Kültürü
Kusur Önleme

13. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Yazılım Mimarisinden
Haber Ver!

14. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Temel Mimariler
Monolitik
Tüm kod için tek bir
dağıtım birimi
Distributed
Remote Access Protocol’ ler ile
birbirine bağlı çoklu dağıtım birimleri
Layered
Pipeline
Mikro Kernel
Service Based
Event Driven
Space Based
Service Oriented
Microservices

15. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Monolitik Uygulamalar
Presentation Layer
Component
Business Layer
Component Component Component
Service Layer
Shared
Component
Persistence Layer
Database Layer
closed
closed
open
closed
closed

16. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Monolitik Uygulamalar
Presentation
Layer
Business
Layer
Persistence
Layer
DB Layer
deployable
deployable
Presentation
Layer
Business Layer
deployable
Persistence Layer
deployable
DB Layer
deployable
Presentation
Layer
Business Layer
Persistence Layer
DB Layer
deployable

17. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Layered Pipeline Mikro Kernel
Service
Based
Event Driven Space Based
Service
Oriented
Microservices
Partition Type Technical Technical
Domain +
Technical Domain Technical
Domain +
Technical Technical Domain
Number of
Quanta 1 1 1 1...* 1...* 1...* 1 1...*
Deployability ⭐ ⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐ ⭐⭐⭐⭐
Elasticity ⭐ ⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐⭐
Evolutionary ⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐ ⭐⭐⭐⭐⭐
Fault
Tolerence ⭐ ⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐
Modularity ⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
Overall Cost ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐ ⭐ ⭐
Performance ⭐⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐
Reliability ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐
Scalability ⭐ ⭐ ⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Simplicity ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐ ⭐ ⭐ ⭐
Testability ⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐ ⭐ ⭐⭐⭐⭐
Monolithic Styles Distributed Styles
* Richards & Ford, Fundamentals of Software Architecture, O’Reilly

18. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Tipik Semptomlar
● Loglar sorun tespitinde yetersiz kalıp üretim ortamında sık debug yapılırsa,
● Anti Pattern pratikleri çoğalırsa,
● Yerleşik iş kurallarını dışarıya almak zor hatta imkansız olursa,
● Test yazmak zorsa,
● Yazılım tek paket olarak üretime çıkıyor ve bu sırada kesintiler olup diğer
paydaşlar da bundan etkileniyorsa,
● Bir katmandaki hata diğerlerini de etkiliyorsa,
● Basit bir sınıf değişikliği yeniden dağıtımı gerektiriyorsa,
● Mean Time to Recovery süreleri dakikalar mertebesinde artıyorsa

19. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Legacy
Sistemler
için
Verimli
Dokunuşlar
● Encapsulate: Tüm sistem detaylarını izole edecek
şekilde API’lere ve Container’lara geçmek.
● Repair: Sadece bug’lar ile uğraşıp bakım yapmak.
● Replatform: Yeni donanımlara geçerek sistemi
hızlandırmak.
● Rebuild : Build aşamalarını optimize etmek.
● Re-Architect: Yeni bir teknolojik platforma adapte
etmeye çalışmak.
● Rehost: Mainframe gibi parçaları bulut servis
sağlayıcılarına taşımak.
● Replace: Çözümü Software as a Service ile
değiştirmek.
● Refactor: Teknik borçları azaltıp olası hataların
önüne geçmek.

20. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
TDML (Büyük Ölçek)
Keşfet
Öncelik
Ver
Ön
Gereksinimleri
Tamamla
Dağıt
Refactor
Yap
Raporla
Kontrol Et

21. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
TDLM Kimlik Kartı
Revize Tarihi Formun son güncelleme tarihidir.
Tanım Şirketin tüm iş ve IT operasyonu için anlam ifade eden bir tanımıdır. Şirketin neleri teknik borç
olarak ele aldığı da burada belirtilmelidir.
Minimum Refactor
Süresi
Kişi başı günlük ne kadarlık bir eforun bu döngüye ayrılacağı rakamsal olarak belirlenir. Günde
iki saat, bir sprint ’in %15’ i gibi ifadeler ile bu planlama netleştirilir. Süre tüm paydaşlarca kabul
edilmiş olmalıdır.
Güncel Maliyet İnsan/Gün üstünden hesaplanmış bir rakamdır ve güncel durumu özetler. Toplam borcumuz 725
insan gündür gibi.
Mali Kayıp Teknik borcun yarattığı maliyetin parasal değerini yansıtır. Bu paydaşlar açısından tartışılabilir
bir konudur ancak durumun ciddiyetini göstermek ve pozitif gelişmelerin yarattığı motivasyon
açısından önemlidir. Şeffaflık da teknik borç mücadelesinin temel taşlarındandır.
Sıçrama Noktası Bir mimari dönüşüm için yeterli bir noktada olunup olunmadığının kontrolü için hedeflenen
rakamsal değerlerin ifadesidir. Örneğin İnsan/Gün maliyeti ve Mali Kayıp belli bir değerin altına
inerse mimari dönüşüm kararı tartışılabilir.
Araçlar Mücadele sırasında kullanılacak araçlar belirlenir. Statik/Dinamik kod analiz araçları, raporlama
düzenekleri vb

22. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
Teşekkürler
www.buraksenyurt.com
github.com/buraksenyurt
medium.com/@burakselyum

23. Bu dokümanda HASSAS bilgi bulunmamaktadır. / This document does not contain SENSITIVE information.
CAST(1998)
Architectural,
Design, Code Time to remove issues Windows Jenkins, Maven API, GUI
Security, Efficiency,
Changeability, Robustness,
Transferability,
Sonargraph(2006)
Architectural,
Design
Computation of several
metrics Bağımsız
Eclipse, Gradle,
IntelliJ Jenkins,
Maven, VS GUI Changeability
NDepend (2007)
Architectural,
Design, Code
Estimated man-time to
fix issues Windows
Azure, Jenkins,
VS GUI
Changeability, Robustness,
Testability
SonarQube (2007) Code Time to remove issues Bağımsız
Eclipse, IntelliJ,
VS
API,GUI, CLI,
CI Security, Reliability
Squore (2010) Design, Code Time to remove issues Bağımsız Yok API,GUI
Changeability, Reliability,
Efficiency, Portability,
Security, Testability
CodeMRI (2013 Design Not estimated
Windows,
Linux Yok CLI
Security, Efficiency,
Robustness, Portability,
Testability
Code Inspector
(2019)
Architectural,
Design, Code
Effort needed to avoid
high TD Bağımsız
Github, Gitlab,
Bitbucket
Jenkins, Travis API
Security, Changeability,
Portability, Testability,
Maintainability
DV8 (2019) Architectural
Number of affected
files and lines of code
Windows,
MAC
Depends,
Jenkins GUI
Maintainability,Evolvability,
Security
SymfonyInsight
(2019) Code Time to remove issues Bağımsız Yok GUI,CI
Security, Maintainability,
Reliability