01Sorun ve çözüm
Teknik borç analizinde borcun nerede durduğunu, ne kadar faiz ürettiğini ve hangisinin önce ödenmesi gerektiğini ortaya koyarız. Kod ölçümleri, sürüm geçmişi, hata kayıtları ve ekiple yapılan görüşmeler aynı tabloda birleşir. Sonuç, yönetimin bütçe kararı verebileceği ve ekibin sprint planına alabileceği, önceliklendirilmiş bir borç kaydıdır. Her borcun ödenmesi gerekmez. Nadiren değişen ve sorunsuz çalışan bir modüldeki eski kod, dokunulmadıkça faiz üretmez; analiz bunu da açıkça gösterir.
02Kimler için
Teknik borç analizi kimin gündemine girer
Analiz talebi genellikle hız kaybı hissedildiğinde ya da büyük bir karar öncesinde gelir.
- Geliştirme hızı belirgin biçimde düşen ama nedenini somut gösteremeyen ürün ekipleri
- Yeniden yazma ile iyileştirme arasında karar vermeye çalışan teknik yöneticiler
- Yatırım, satın alma ya da ortaklık öncesinde yazılım varlığının durumunu görmek isteyen yönetim ekipleri
- Yazılımı dış bir firmadan devralan ve ne devraldığını bilmek isteyen şirketler
- Teknik iyileştirme için zaman isteyen ekibinin talebini gerekçelendirmek isteyen kurucular
03İhtiyaçlar
Borcun biriktiği yerler
Teknik borç yalnızca kötü kod değildir; sistemin her katmanında farklı bir biçimde görünür.
- 01
Kod düzeyi
Tekrarlanan kod, binlerce satırlık sınıflar, iç içe koşullar ve anlamsız isimler değişiklik maliyetini artırır. Bunların hepsi borç sayılmaz; ancak sık değişen dosyalardaysa faizleri yüksektir.
- 02
Mimari düzey
Modüller arasında sınırların silikleşmesi, her şeyin aynı veritabanı tablolarına erişmesi ve döngüsel bağımlılıklar, tek bir değişikliğin sistemin geneline yayılmasına neden olur.
- 03
Bağımlılıklar
Destek süresi bitmiş çatı sürümleri, bilinen güvenlik açığı taşıyan paketler ve bakımı bırakılmış kütüphaneler zamanla zorunlu ve pahalı bir yükseltmeye dönüşür.
- 04
Test ve yayın süreci
Otomatik testin olmaması, elle yapılan yayınlar ve ortamlar arasındaki farklar her sürümü riskli kılar. Bu borç doğrudan yayın sıklığını düşürür.
- 05
Bilgi borcu
Yalnızca bir kişinin bildiği modüller, belgelenmemiş kararlar ve güncelliğini yitirmiş yapılandırmalar, o kişi ayrıldığında aniden görünür hâle gelir.
04Özellikler
Teknik borç analizi hizmetinde izlediğimiz yöntem
Analiz, araç çıktısı ile insan değerlendirmesini birlikte kullanır; ikisi tek başına yanıltıcıdır.
- 01
Sıcak nokta analizi
Git geçmişinden hangi dosyaların ne sıklıkla değiştiği çıkarılır ve karmaşıklık ölçümleriyle çakıştırılır. Hem karmaşık hem sık değişen dosyalar, borcun en çok faiz ürettiği yerlerdir.
- 02
Statik analiz ve bağımlılık taraması
SonarQube gibi araçlarla kod kokuları, tekrar ve test kapsamı ölçülür; bağımlılıklar bilinen güvenlik açıkları ve destek durumu açısından taranır.
- 03
Ekip görüşmeleri
Geliştiricilerle, hangi modüle dokunmaktan kaçındıklarını ve hangi işin beklenenden uzun sürdüğünü konuşuruz. Araçların göremediği borcun büyük kısmı bu görüşmelerde ortaya çıkar.
- 04
Borç kaydı
Her borç kalemi için konum, belirti, iş etkisi, tahmini düzeltme büyüklüğü ve ertelemenin riski yazılır. Kalemler etki ve çaba eksenlerinde sıralanır.
- 05
Ödeme planı
Önceliklendirilmiş kalemler, iş geliştirmeyle birlikte yürütülebilecek bir plana dönüşür; her sprintte borca ayrılacak payın nasıl belirleneceği önerilir.
05Entegrasyonlar
Teknik borç analizi için erişmemiz gereken kaynaklar
Analiz salt okunur erişimle yapılır; sistemlerinizde hiçbir değişiklik yapmayız.
- 01
Kod deposu ve sürüm geçmişi
GitHub, GitLab, Bitbucket ya da Azure DevOps deposunun geçmişiyle birlikte okunması, sıcak nokta analizinin temelidir.
- 02
İş ve hata takip sistemi
Jira ya da benzeri bir araçtaki hata kayıtları, hangi modülün ne sıklıkla sorun çıkardığını gösterir.
- 03
Derleme ve yayın hattı
CI/CD kayıtlarından derleme süreleri, başarısız yayınlar ve geri almalar incelenir.
- 04
Üretim izleme verisi
Hata günlükleri ve uygulama izleme araçları, kodda görünen borcun canlıda ne kadar soruna yol açtığını doğrular.
06Süreç
Teknik borç analizi hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Borcu iş diline çevirmek
Yönetim için “bu sınıfın karmaşıklığı yüksek” cümlesi bir şey ifade etmez. Bu yüzden her önemli borç kalemini bir iş sonucuna bağlarız: ödeme modülüne yapılan her değişikliğin neden uzun sürdüğü, bir müşteri özelleştirmesinin neden haftalar aldığı, hangi güvenlik açığının hangi müşteri verisini riske attığı. Teknik ayrıntı ekip için ekte kalır, özet ise karar vericiye hitap eder.
Devamını okuDaha az göster
Analizin amacı kimseyi suçlamak değildir. Teknik borcun büyük kısmı, o günün koşullarında makul olan kararlardan doğar; teslim tarihi baskısı, değişen iş gereksinimleri ya da küçük bir ekip. Raporu bu dille yazarız, çünkü ekibin savunmaya geçtiği bir analiz, ödeme planının uygulanmasını da engeller.
Kaynak kodunuz analiz süresince yalnızca bizim erişimimizde kalır ve iş bitince kopyalar silinir. Gerekirse çalışma öncesinde gizlilik sözleşmesi imzalanır.
08Çalışma modelleri
Bu hizmette çalışma modelleri
09Sık sorulan sorular
Teknik borç analizi hakkında sık sorulan sorular
Teknik borç analizi fiyatları neye göre değişir?
Kod tabanının büyüklüğü, depo ve servis sayısı, kullanılan dil çeşitliliği, ekip görüşmelerinin kapsamı ve raporun yönetim sunumu içerip içermeyeceği belirleyicidir. Depoya kısa bir ön bakıştan sonra sabit kapsamlı teklif veririz.
Analiz sonunda yeniden yazmamız gerektiğini söyler misiniz?
Veriler bunu gösteriyorsa söyleriz; ancak çoğu durumda tümüyle yeniden yazmak yerine en çok faiz üreten bölümlerin hedefli biçimde iyileştirilmesini öneririz. Karar için iki yolun riskleri ve maliyet etkenleri yan yana konur.
Ekibimiz bu çalışmayı bir denetim gibi algılar mı?
Çalışmayı ekiple birlikte yürütür, bulguları önce onlarla paylaşırız. Raporda kişi adı geçmez; odak, kod ve süreçtir.
Teknik borç analizi firması olarak hangi dilleri inceliyorsunuz?
Yaygın web ve mobil teknolojilerinde, örneğin PHP, .NET, Java, JavaScript ve TypeScript, Python, Kotlin ve Swift ile yazılmış kod tabanlarında çalışırız. Farklı bir teknoloji söz konusuysa ön görüşmede açıkça belirtiriz.
Analiz ne kadar sürer?
Kod büyüklüğüne ve görüşülecek kişi sayısına bağlıdır. Ön bakıştan sonra rapor teslim tarihini içeren yazılı bir takvim veririz.
Analizden sonra borcu ödemek için de destek veriyor musunuz?
İsterseniz ödeme planındaki işleri ekibinizle birlikte ya da ayrı bir proje olarak üstleniriz. Belirli aralıklarla analizi tekrarlayıp borcun azalıp azalmadığını da ölçebiliriz.
10İlgili hizmetler