Teknik borç nedir? Ward Cunningham’ın asıl anlattığı

3 dk okuma #yazılım

“Teknik borç” bugün çoğu zaman “eski ve kötü yazılmış kod” anlamında kullanılıyor. Terimin çıktığı yere dönünce söylenen şeyin daha ince olduğunu görüyorum. Bu yazıda orijinal metni, sonradan yapılan açıklamayı ve bunun günlük işe ne söylediğini toparladım.

Terim nereden geldi?

Ward Cunningham metaforu 1992’de OOPSLA konferansına sunduğu kısa bir deneyim raporunda kullandı. Rapor, Smalltalk ile yazılmış bir tahvil portföyü yönetim sistemini (WyCash) anlatıyor. Orada şu cümleler geçiyor (çeviri bana ait):

İlk seferde yazılan kodu teslim etmek borca girmeye benzer. Küçük bir borç, bir yeniden yazımla vaktinde ödendiği sürece geliştirmeyi hızlandırır.

Devamında asıl tehlikeyi de söylüyor: doğru olmayan kodda geçen her dakika bu borcun faizi sayılır ve düzeltilmemiş bir gerçekleştirmenin borç yükü altında bütün mühendislik organizasyonları durma noktasına gelebilir. Yani metafor “borç almak kötüdür” demiyor, “ödemeyi unutursan faiz seni durdurur” diyor.

Faiz ve anapara

Martin Fowler metaforu şöyle somutlaştırıyor: yeni bir özelliği eklemek için gereken fazladan emek, borcun faizidir. Altı günlük bir işin modül yapısı yüzünden iki gün uzadığını düşün. Bu iki gün faizdir. Yapıyı düzeltmek beş gün sürüyorsa bu anapara ödemesidir ve benzer özelliklerin arka arkaya geleceğini biliyorsan mantıklıdır.

Fowler’ın bir tespiti de çok işe yarıyor: faiz yalnızca kodu değiştirirken ödenir. Dağınık ama hiç dokunulmayan, kararlı çalışan bir modül pratikte faiz ödetmez. Bu yüzden borcu sayarken “ne kadar kötü kod var” yerine “nerede sık değişiklik yapıyoruz” sorusu daha doğru bir başlangıç noktası.

2009’daki açıklama

Cunningham 2009’da kaydettiği kısa bir videoda metaforun “kötü kodu mazur göstermek” için kullanıldığını görüp açıklama yaptı. Videodan aktarılan cümle şu (çeviri bana ait):

Kodu kötü yazmaktan yana değilim, ama kodu problem hakkındaki mevcut anlayışını yansıtacak şekilde yazmaktan yanayım, bu anlayış kısmi olsa bile.

Burada borç, bilmediğin bir şeyi sonradan öğrenince ortaya çıkan farktır: kodun bugünkü anlayışına uyuyor, ama öğrendikçe anlayış ilerliyor ve kod geride kalıyor. Bunu geri ödemenin yolu da kodu yeni anlayışa göre yeniden düzenlemek.

Bu bakış açısıyla iki tür borcu ayırmak da kolaylaşıyor. Bilinçli borç, ekibin kısa vadeli bir ödünü bilerek kabul etmesidir. Farkında olmadan oluşan borç ise ekibin o anda eksik bilgiyle bir tercih yapması ve sonradan bunun bakım yükü getirdiğini görmesidir. Fowler’ın “teknik borç dörtlüsü” bu ayrımı pervasız ve ihtiyatlı eksenleriyle birleştirir.

Günlük işe yansıması

  • Borcu “rewrite” yerine, özellik geliştirirken küçük adımlarla ödemek: Fowler’ın önerisi, ilk özellikte birkaç gün fazla harcayıp dağınıklığın bir kısmını temizlemek.
  • Faizi görünür kılmak: “bu özellik normalde 6 gün, yapı yüzünden 8 gün sürdü” cümlesi, “kod kötü” cümlesinden çok daha anlaşılır.
  • Borcu bahane etmemek: Fowler bazı ekiplerin “kredi kartlarının hepsini doldurup” yine de geç teslim ettiğine dikkat çekiyor. Borç bir strateji olabilir, ama stratejinin ödeme planı olmalı.

Kaynaklar

← tüm yazılar