30 saniyelik özet
Technical Debt, yani teknik borç, yazılımın iç yapısındaki sorunların sonraki bakım ve değişikliklerde ek çaba oluşturmasını anlatan bir benzetmedir. Bu sorunlar bilinçli bir kısa vadeli tercih sonucunda oluşabilir; ekip öğrendikçe daha önce fark edilmeyen tasarım eksikleri de görünür hale gelebilir. Her eski kod teknik borç değildir. Bir alanın borç olarak ele alınabilmesi için gelecekteki çalışmayı nasıl zorlaştırdığı açıklanmalıdır. Product Owner, yani ürün sahibi, bu etkiyi ürün öncelikleriyle birlikte değerlendirmelidir. Amaç bütün sistemi kusursuzlaştırmak değil, önemli değişiklikleri engelleyen veya risk yaratan sorunlar hakkında kanıta dayalı karar vermektir.
Neden önemli?
Bir kurumsal üründe yeni kullanıcı rolü eklemek için farklı ekranlarda ayrı ayrı yetki kuralları değiştirmek gerekiyor. Geliştiriciler her değişiklikte aynı kontrolleri yeniden inceliyor. Destek ekibi bazı hesaplarda tutarsız davranış görüyor. Yeni özellik küçük görünse de mevcut yapı nedeniyle yapılması gereken iş büyüyor.
Yönetici yalnızca özellik listesini incelerse bu ek çaba görünmeyebilir. Ekip sürekli “Beklediğimizden uzun sürdü” derken sorunun belirli bir yapıda tekrar ettiği fark edilmeyebilir. Teknik borcu konuşmanın değeri, gecikmeyi genel bir mühendislik sorunu olmaktan çıkarıp değişiklik maliyeti ve risk üzerinden açıklayabilmesidir.
Ürün sahibi açısından soru, teknik düzenlemenin hangi ürün kararını destekleyeceğidir. Yaklaşan kurumsal ihtiyaçlar aynı yetki alanını tekrar değiştirecekse iyileştirme anlamlı olabilir. Nadiren değişen, güvenilir çalışan başka bir alanın görünümü beğenilmiyor diye yeniden yazılması aynı önceliği taşımayabilir.
Bu değerlendirme fırsat maliyetini de içerir. Fırsat maliyeti, bir seçeneğe kaynak ayırırken vazgeçilen diğer seçeneğin değeridir. Teknik düzenlemeye ayrılan kapasite yeni bir özelliği geciktirebilir; düzenlemeyi sürekli ertelemek de gelecekteki özellikleri zorlaştırabilir. Karar, bu iki etkiden yalnızca birini görerek verilmemelidir.
Finansal tutar hesaplamak mümkün olmadığında konuşma durmamalıdır. Tekrarlayan ek işler, değişiklik sırasında çıkan sorunlar ve engellenen ürün ihtiyaçları somut örneklerle gösterilebilir. Ancak gözlenen gecikmenin tamamını tek bir kod sorununa bağlamak da yanıltıcıdır. Erişim bekleme, kapsam değişikliği ve bilgi eksikliği gibi diğer nedenler ayrılmalıdır.
Terim nedir?
Martin Fowler, teknik borç benzetmesinde sonraki özellikler için harcanan ek çabayı borcun faizi olarak açıklar. İç yapıyı iyileştirmek ise anaparayı azaltmaya benzetilir. Bu, gerçek bir finansal hesap değildir. Özellikle iyileştirme yapılmış olsaydı işin ne kadar süreceğini kesin bilmek zordur.
Refactoring, dışarıdan görülen davranışı koruyarak yazılımın iç yapısını iyileştirmektir. Teknik borç çalışması bununla sınırlı olmayabilir; bağlama göre bağımlılıkların veya doğrulama düzeninin değiştirilmesi gerekebilir. “Refactor yapılacak” başlığı tek başına problemi ve beklenen katkıyı açıklamaz.
Fowler’ın Technical Debt Quadrant yaklaşımı, borcun bilinçli veya farkında olmadan oluşmasını ve kararın ölçülü veya düşüncesiz olmasını ayrı değerlendirir. Bu ayrım, bütün borcu aynı şekilde ele almamaya yardımcı olur. Yeni bilgiyle ortaya çıkan bir tasarım eksikliğini geçmişteki ekibin özensizliğinin kanıtı saymak doğru olmayabilir.
- Kavram kaynakları
- Martin Fowler, Technical Debt, 21 Mayıs 2019; Technical Debt Quadrant, 14 Ekim 2009.
- https
- //martinfowler.com/bliki/TechnicalDebt.html
- https
- //martinfowler.com/bliki/TechnicalDebtQuadrant.html
Hata, bakım ihtiyacı ve teknik borç ilişkili olabilir; aynı kayıt türüne indirgenmemelidir. Kullanıcının karşılaştığı yanlış davranış bir hatadır. Borç kaydı ise bu hatayı veya değişiklik güçlüğünü üreten yapısal neden hakkında bilgi taşımalıdır. Nedeni değiştirmeden yalnızca belirtileri düzeltmek, benzer işlerin tekrar çıkmasına yol açabilir.
Product Backlog, ürünün geliştirilmesi için gereken işlerin sıralı listesidir. Teknik borç bu listede problem, etki ve seçenekleriyle görünür tutulabilir. Her kayıt müşteri ekranı biçiminde yazılmak zorunda değildir. Teknik bir çalışma da hangi ürün ihtiyacını desteklediğini açıklayabilir.
Gerçek vaka: Monolitten mikroservislere geçişte borcun değişmesi
Valentina Lenarduzzi ve çalışma arkadaşlarının endüstriyel vaka araştırması, bir işletmenin yazılımını monolitten mikroservislere taşırken teknik borcun nasıl değiştiğini inceliyor. Monolit, uygulamanın bütünleşik bir yapı olarak ele alındığı yaklaşımı; mikroservisler ise uygulamanın ayrı servisler üzerinden düzenlenmesini ifade eder.
Araştırma, dört yıldan uzun proje geçmişini değerlendiriyor. İki takım, beş iş sürecini ayrı servislere taşıyor. Araştırmacılar kod analiz aracı SonarQube’un bulgularını geliştiricilerle yapılan nitel incelemeyle birlikte kullanıyor.
Çalışmanın özeti, yeni servislerin geliştirilmesi sırasında teknik borcun başlangıçta arttığını, sonrasında borcun monolitik sisteme göre daha yavaş büyüme eğilimi gösterdiğini bildiriyor. Bu sonuç, dönüşümün ilk günden borcu ortadan kaldırdığı anlamına gelmiyor.
Vaka tek bir işletmeye dayanıyor. Kod analizi bulguları doğrudan parasal borç veya gerçekleşmiş tasarruf olarak okunamaz. Buradan her ürünün mikroservislere geçmesi gerektiği sonucu da çıkarılamaz. Yönetim açısından ilgili ders, mimari değişikliğin etkisini süreç boyunca izlemek ve geçişte oluşan ek çalışmayı da değerlendirmektir.
Varsayımsal örnek: Dağınık yetki kurallarını düzenlemek
Bir kurumsal yazılım ürünü, müşterilerin farklı ekipler için yeni kullanıcı rolleri tanımlamasını istiyor. Mevcut yetki kuralları çeşitli ekranlarda tekrar edilmiş. Aynı rolün davranışı bazı alanlarda farklı yorumlanıyor. Ekip, yeni rol geliştirmesinin yanında bu yapının etkisini de inceliyor.
Ürün sahibi “Yetkilendirmeyi yeniden yazalım” talebini doğrudan kabul etmiyor. Geliştiricilerden etkilenen alanları, tekrar eden değişiklikleri ve gözlenen sorunları açıklamalarını istiyor. İş analisti müşteri senaryolarını topluyor; destek uzmanı hangi tutarsızlıkların kullanıcıları etkilediğini gösteriyor.
Ekip, bütün sistemi tek seferde değiştirmek yerine yaklaşan rol ihtiyacının geçtiği akışta ortak bir yetki yaklaşımı oluşturmayı değerlendiriyor. Refactoring sırasında mevcut davranışı korumak için gerekli testler belirleniyor. Beklenen yeni davranış da ayrıca açıklanıyor; teknik düzenleme ile yeni özellik birbirine karıştırılmıyor.
Alternatifler kaydediliyor: Mevcut yapıyla devam etmek, sınırlı düzenleme yapmak veya daha geniş dönüşüme başlamak. Her seçenek için kapsam, belirsizlik ve sonraki değişikliklere etkisi konuşuluyor. Kesin veri bulunmadığından maliyet tasarrufu yüzdesi yazılmıyor.
Sınırlı düzenleme seçilirse sonraki rol çalışmalarında hangi kontrollerin tekrarlandığı ve hangi engellerin sürdüğü izleniyor. İlk değişikliğin sorunsuz olması, bütün yetki yapısının iyileştiğini kanıtlamıyor. Beklenen katkı görülmezse varsayımlar yeniden ele alınıyor.
Yaygın üç hata
- Eski olan her şeyi borç saymak
Yaş veya teknoloji adı tek başına öncelik gerekçesi değildir. Değişiklik güçlüğünü, riskleri ve yakın ürün ihtiyaçlarını açıklayın. İyileştirme isteğinin hangi gözleme dayandığını görünür tutun.
- Borcu yalnızca “Boş zamanda” ele almak
Sürekli ertelenen bir sorun, yeni ihtiyaçlarla daha fazla çalışma yaratabilir. Teknik iyileştirmeyi ilgili özelliklerle veya ayrı bir ürün yatırımıyla planlayın. Her ürüne uygulanacak sabit bir kapasite oranını gerekçesiz kural haline getirmeyin.
- Büyük dönüşümü otomatik çözüm saymak
Yeni mimari yeni bağımlılıklar ve işletim yükü oluşturabilir. Önce çözülmek istenen sorunu ve başarı kanıtını belirleyin. Teknoloji değişikliğini, etkisi doğrulanmadan borcun kapatılması olarak raporlamayın.
Mini uygulama / şablon
Bir teknik borç kaydını aşağıdaki alanlarla hazırlayın.
- Sorunlu yapı ve etkilenen alan
- —
- Sorunun oluşma veya fark edilme nedeni
- —
- Gözlenen ek çalışma ve risk
- —
- İlgili müşteri veya ürün ihtiyacı
- —
- Kanıtlar ve eksik bilgiler
- —
- Mevcut yapıyla devam etmenin etkisi
- —
- Sınırlı ve geniş çözüm seçenekleri
- —
- Tahmini çalışma ve belirsizlikler
- —
- Gerekli kalite doğrulamaları
- —
- Beklenen katkıyı değerlendirme yöntemi
- —
- Sorumlu ve yeniden değerlendirme zamanı
- —
Ardından kaydı teknik olmayan bir yöneticiye anlatın. “Kod kötü” yerine hangi ürün kararının zorlaştığını açıklayabiliyor musunuz? Gözlemle tahmini ayırın. İyileştirme sonrasında aynı soruları yeniden inceleyin; çalışma tamamlandı diye beklenen etkinin gerçekleştiğini varsaymayın.
İlgili terimler
Refactoring, Product Backlog, Prioritization, Definition of Done, Legacy System, Software Architecture, Microservices, Monolith, Opportunity Cost, Risk Management, Regression Testing, Dependency Management, Product Roadmap, Technical Spike