Skip to main content

> teknik_borç:_faiz_ve_anapara_yönetimi

Teknik Borç: Faiz ve Anapara Yönetimi

Mühendislik liderleri teknik borcun ne zaman stratejik bir avantajdan operasyonel bir krize dönüştüğünü nasıl ölçer?

Stack: LEGACY GRAVITY STACK →Staff+ (L6+)tradeoff

⚡ÖZET VE TEKNİK CEVAP

Geçici çözümlere, yavaş derleme sürelerine ve kriz triyajlarına harcanan kayıp mühendislik saatlerini ('faiz'), temel kusuru düzeltmek için gereken eforla ('anapara') kıyaslayarak.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Teknik borç Ward Cunningham tarafından ortaya atılan finansal bir metafordur. Hızlı bir yama ile canlıya çıkıp pazarı doğrulamak bilinçli bir borçlanmadır. Ancak ödenmeyen her borç; artan hata oranları, zorlaşan yeni çalışan adaptasyonu ve kırılgan dağıtımlar şeklinde 'faiz' işletir. Aylık faiz ödemeleri ekibin yeni özellik çıkarma kapasitesini aştığında organizasyonel iflas başlar.

🎯2. Doğru Kullanım Senaryosu

Kapsam

6 aydan daha eski canlı kod tabanlarını yöneten tüm yazılım ekiplerinde sürekli sprint kapasitesi planlaması.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

40 sahipsiz eski servisin API katmanı olmadan doğrudan veritabanı tablolarına bağlı olması yüzünden basit bir şema değişikliğinin 6 hafta sürmesi.

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    Mühendis sayısı iki katına çıkarken özellik teslimat hızının yıldan yıla >%50 düşmesi

  • ✓

    geliştiricilerin ortak modülleri değiştirmeye korkması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Her sprint kapasitesinin sabit %20'sini teknik borç temizliğine ayırın

  • ✓

    yüksek faizli borç kalemlerinin ROI hesaplamalı takip biletlerine sahip olmasını şart koşun

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Sürdürülebilir teslimat hızı ve düşük MTTR karşılığında kısa vadeli ürün baskılarına direnmeyi gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

TinyCTO Bölüm 5: Ekip haftada 15 saatini bozulan kullanıcı oturumlarını elle düzeltmeye harcıyordu. 2 sprint ayırıp Redis oturum yönetimini kurmak 3 aydan kısa sürede kendini amorti etti.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Teknik borcun 'faizi' nedir?

Kötü kod, otomatikleştirilmemiş testler ve kırılgan altyapı yüzünden mühendislerin sürekli kaybettiği ekstra zaman ve sürtünmedir.
Q2

Teknik borç almak ne zaman doğru bir ticari karardır?

Pazardaki yeni bir iş hipotezini rakiplerden önce doğrulamak için hızın kritik olduğu durumlarda.
Q3

'Teknik iflas' anında ne olur?

Mühendislik kapasitesinin %100'ü hataları düzeltmeye ve yamaları ayakta tutmaya harcanır, yeni özellikler için sıfır kaynak kalır.

Teknik Borç: Faiz ve Anapara Yönetimi — Sıkça Sorulan Sorular

Teknik liderler refactor sprintlerini teknik olmayan yöneticilere nasıl açıklamalıdır?

Borcu iş metriklerine çevirin: gelecekteki özelliklerin pazara çıkış süresinin kısalması, bulut faturalarının düşmesi ve canlı kesintisi riskinin azalması.

Ekipler borcu silmek için tüm sistemi sıfırdan baştan yazmalı mıdır?

Çok nadir. Sıfırdan baştan yazmalar neredeyse her zaman başarısız olur. İş süreçlerini aksatmadan parçaları kademeli değiştiren Strangler Fig kalıbını kullanın.

Sprint kapasitesinin ne kadarı teknik borca ayrılmalıdır?

Sektör standardı her sprintte kesintisiz %15 ila %20 oranında kapasite ayrılmasıdır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸

    Teknik borcu görmezden gelmek kıdemli mühendislerin şirketten ayrılma oranını 2.5 kat artırır.

  • ▸

    Yüksek faizli borç 2-3 çeyrek içinde ödenmezse katlanarak büyür.

Yaygın Yanılgılar

  • ✗

    Sizin yazmadığınız her kodun 'teknik borç' olduğunu sanmak.

Karar Kılavuzu & Önceliklendirme

Refactor çalışmalarını nadiren değişen eski modüllere değil, sürekli geliştirme yapılan sıcak kod yollarına odaklayın.

Doğrulanmış Kaynaklar & Referanslar

İlgili Kavramlar

/learn/engineering-leadership