Ward Cunningham, Wikiler ve Zaman İçinde Teknik Borç

Ward Cunningham: İki Büyük Fikrin Arkasındaki Sorun Çözücü

Ward Cunningham, orijinal bağlamlarından çıkarak günlük kullanım aracı haline gelmiş iki ifade ile en çok tanınır: “wiki” ve “teknik borç.” Kolay kaçırılacak nokta şu: bu fikirlerin hiçbiri bir marka çalışması olarak başlamadı. Her ikisi de tekrar eden ekip sorunlarına pratik yanıtlardı.

Erken yazılım topluluklarında bir yapıcı

Cunningham, modern yazılım işbirliğinin şekillendiği erken pattern ve çevik çevrelerde aktifti; ilk wikiyi birlikte yarattı, araçlar geliştirdi ve geri bildirim, öğrenme ve sadeliği vurgulayan uygulamaları etkiledi.

İtibarı büyük teorilerden çok, insanlar tarafından kopyalanabilecek küçük, çalışan çözümler sunmasından geldi.

Sürekli karşılaştığı ekip sorunları

Projeler boyunca Cunningham aynı sürtünme noktalarını gördü: e-posta dizilerinde sıkışan bilgi, toplantılardan sonra kaybolan kararlar ve her ay değişmesi zorlaşan kod tabanları.

Ekiplerin ihtiyacı sadece “daha iyi dokümantasyon” veya “daha iyi mimari” değildi. Paylaşılan anlayışı güncel tutacak yollar ve bugün hız uğruna alınan kararların yarın maliyetini görünür kılacak araçlara ihtiyaçları vardı.

Fikirlerin yayılması: gösteriş yerine uygulama

Wiki, katkıda bulunmayı ve bilgiyi düzeltmeyi engelleyen bariyerleri kaldırdığı için işe yaradı. Borç metaforu ise ekiplerin gelecekteki maliyeti suçlamadan konuşmalarını sağladığı için işe yaradı.

Her ikisi de organik şekilde yayıldı: biri denedi, işe yaradı ve başkaları bunu uyarladı.

Ana çıkarım

Cunningham’in ana çizgisi basit: paylaşılan anlayışı ve sürdürülebilir değişimi optimize et. Araçlar ve metaforlar, ekiplerin daha hızlı öğrenmesine, daha çabuk hizalanmasına ve gerçek teslim tarihlerine rağmen kod tabanını esnek tutmasına yardımcı olduğunda önem kazanır.

Wikinin Nasıl Başladığı ve Yeni Olan Neydi

Bir wiki, bir grubun içindeki herkesin tarayıcıyla oluşturup düzenleyebildiği web sayfaları kümesidir. Bir belgeyi onay için dolaştırmak yerine, sayfayı doğrudan değiştirirsiniz—ve değişiklik hemen herkes için güncellenir.

Atılım: “birçok kişi tarafından düzenlenebilir” fikri

Bu basit fikir gerçek yenilikti. Wikilerden önce “paylaşılan bilgi” genellikle üç şeyden biriydi:

• Tek bir yazarın (veya küçük bir onay grubunun) sahip olduğu bir belge
• En güncel cevabın birinin gelen kutusunda gömülü olduğu e-posta dizileri
• Kararların alındığı, sonra yavaşça (ve çoğunlukla tutarsız şekilde) yazıya döküldüğü toplantılar

Bir wiki bu modeli tersine çevirdi. Bilgiyi, ekip birlikte açıkça koruduğu şey olarak ele aldı. Bir hata görürseniz belgeyi düzeltmek için bir ticket açmazsınız—doğrudan düzeltirsiniz.

İlk wiki: Cunningham’in niyeti

Ward Cunningham, ilk wiki olan WikiWikiWeb'i 1990'ların ortasında yazılım uygulayıcılarının desenleri, fikirleri ve çalışan yaklaşımları paylaşmalarına yardımcı olmak için oluşturdu. Amacı cilalı bir yayın platformu yaratmak değildi. Zaman içinde rafine edilebilen bir “konuşma” yaratmaktı; küçük iyileştirmelerin birikerek şaşırtıcı derecede yararlı bir şeye dönüşebileceği bir yer.

Erken kullanım durumları pragmatikti: yaygın çözümleri kaydetmek, terimleri açıklığa kavuşturmak, örnekleri kaydetmek ve ilgili konuları birbirine bağlayarak okuyucuların klasörler arasında aramak yerine keşfetmesini sağlamak.

Dokümanlar, e-postalar ve toplantılardan farkı

Geleneksel dokümantasyon genellikle bitmiş ve yetkili olmaya çalışır. Bir wiki bitmemiş olmaya razıdır—şaşırmazsınız, yeter ki şu an yardımcı olsun.

E-postalar kronolojiktir; wikiler örgütlüdür. Toplantılar gelip geçicidir; wikiler yeni gelenlerin birinin takviminden zaman ayırmadan öğrenebileceği bir iz bırakır.

Bu kombinasyon—düşük sürtüşmeli düzenleme, hızlı bağlantı kurma ve paylaşılan sahiplik—wikileri “dokümantasyon”dan çok yazıya dökülmüş takım çalışması gibi hissettirdi.

Wikiler ve İşbirliği: Daha Hızlı Öğrenme, Daha Az Silolar

Erken wiki fikri sadece “herkesin düzenleyebileceği bir web sitesi” değildi. İnsanların bildiklerini tüm takımın kullanabileceği bir şeye çeviren basit bir mekanizmaydı.

Bu değişim önemlidir çünkü çoğu yavaşlık yazma hızından gelmez—beklemekten gelir: dağıtım adımlarını hatırlayan tek kişi için beklemek, bir kenar durumunu bilen tek kişi için beklemek, bir kararın neden alındığını bilen tek kişi için beklemek.

Örtük bilgiyi ortak notlara dönüştürmek

İyi bir takım wikisi, küçük pratik gerçekleri taze iken yakalar: gördüğünüz hata mesajı, işe yarayan geçici çözüm, tekrar eden müşteri kısıtı.

Bu notlar tek bir yerde durduğunda, özellikle yeni katılanlar için öğrenme hızlanır—bir dizi "bana açıklar mısın" toplantısı planlamak yerine kendi kendilerine çözüm bulabilirler.

Ağır süreç olmadan darboğazları azaltmak

Wikiler hafif kaldıklarında en iyi çalışır: kısa sayfalar, hızlı düzenlemeler, net sahiplik ve “yeterince iyi” yazım. Amaç mükemmel dokümantasyon değil; uyumdur.

Tekrarlayan bir yanlış anlamayı önleyen iki paragraflık bir sayfa, kimsenin güncellemediği cilalı bir belgeden daha değerlidir.

Hızlı geri dönüş sağlayan örnekler

Günlük işleri kolaylaştıran ortak wiki sayfaları:

• Runbook’lar: nasıl deploy edilir, nasıl geri alınır, anahtarlar nasıl döndürülür ve ortak olaylar nasıl yönetilir
• Mimari notlar: ne kiminle konuşur, ayrıca üretimde öğrenilen “tuzağı”nı gösteren noktalar
• Karar kayıtları (ADR’ler): problem, düşünülen alternatifler, yapılan seçim ve ödünleşmeler

Zamanla bu sayfalar takımın hafızası olur. Konuşmaları değiştirmezler—konuşmaları daha kısa, daha özel ve harekete geçirilebilir hale getirirler.

Teknik Borç: Cunningham’ın Ne Demek İstediği (Sadece “Kötü Kod” Değil)

Ward Cunningham “teknik borç”u çirkin kod için hakaret olarak icat etmedi. Bunu, öğrenmek veya daha hızlı yayınlamak için bilerek alınan bir kestirmeyi tanımlamak için kullandı; bunun ileride ekstra iş yükü yaratacağını bilirsiniz.

Orijinal anlam: maliyeti olan bilinçli bir kestirme

Cunningham’in çerçevesinde borç genellikle kasıtlı alınır. Gerçek kullanıcı geri bildirimi almak için daha basit bir tasarım seçebilirsiniz veya problemi daha iyi anlamadan zarif bir soyutlamayı atlayabilirsiniz.

Ana fikir, kestirmenin bir gelecek yükümlülük yaratmasıdır—takım dikkatsiz olduğu için değil, bugün hız ve öğrenmenin değerli olduğu için.

Neden “borç” kelimesi ve ne çağrıştırır

Borç güçlüdür çünkü aynı anda iki şeyi ima eder:

• Önden değer alırsınız (zaman, öğrenme, ivme)
• Eğer uzun süre taşırsanız faiz ödersiniz (değişiklikler yavaşlar, risk artar)

Bu “faiz” ahlaki bir başarısızlık değildir; artık bildiklerinizle uyumlu olmayan bir kod tabanı üzerinde çalışmanın doğal maliyetidir.

Geri ödeme: refaktörleme ve yeniden tasarım

Geri ödeme, refaktörleme, testleri iyileştirme ve zamanla merkezi hâle gelen parçaları yeniden tasarlama ile örtüşür. Her şeyi yeniden yazarak “ödemek” zorunda değilsiniz—gelecekteki işi öngörülebilir kılmak için sürtüncüleri yavaş yavaş kaldırırsınız.

Planlı borç vs. kazara karışıklık

Cunningham’in fikri en çok planlı borca uyar: bilinçli, belgelenmiş ve gözden geçirilen.

Kazara karışıklık farklıdır: belirsiz sahiplik, test eksikliği, acelelemiş birleştirmeler ve ihmal edilmiş tasarım. Bunların hepsine “borç” demek gerçek sorunu saklar—karar alma ve takip eksikliğini.

Metaforun Doğru Anlattığı ve Yanılttığı Şeyler

Ward Cunningham’in “teknik borç” metaforu, ekiplerin hissettiği gerçek bir duyguyu anlattığı için yayıldı: bugün daha hızlı yayınlayabilirsiniz, ama sonra bunun bedelini ödeyebilirsiniz.

İyi anlattığı şeyler

Finansal borç gibi, teknik borcun da faizi vardır. Hızlı düzeltmeler, eksik testler veya belirsiz tasarım ilk başta zarar vermez—ancak sonraki her değişikliği daha yavaş, daha riskli ve daha stresli hâle getirir.

Ayrıca takaslar ve zamanlamayı vurgular. Bazen borç almak rasyoneldir: bir son teslimi karşılamak, bir fikri doğrulamak veya bir müşteriyi engellemek için geçici bir çözüm. Önemli olan bunu bir tercih olarak kabul etmektir, sanki “bitmiş” gibi davranmamak.

Ve ödeme konuşmasını kolaylaştırır. Refaktörleme, test ekleme, bağımlılıkları sadeleştirme ve dökümantasyonu iyileştirme, gelecekteki maliyeti düşürmenin yollarıdır.

Nerede yanıltır

Metafor sessizce ahlaki bir yük oluşturabilir: “borç” yanlış yapılmışlık gibi gelebilir ve bu da suçlamayı tetikler (“Bunu kim yaptı?”) yerine öğrenmeyi (“Bizi buraya hangi baskı getirdi?”) tercih etmek daha iyidir.

Ayrıca basitleştirebilir. Her karışıklık öngörülebilir faizi olan bir borç gibi davranmaz. Bazı problemler “bilinmeyen risk”, “karmaşıklık” veya “eksik ürün kararları”na daha yakın olabilir. Her şeyi borç olarak görmek yanlış bir kesinlik hissi yaratabilir.

Dilin planlama toplantılarını nasıl şekillendirdiği

Bir şeye “borç” derseniz, odadaki insanlar bunu bazen “mühendislik temizlik sprinti istiyor” olarak duyar. Etkiyi tarif ettiğinizde—daha yavaş sürümler, daha fazla kesinti, daha zor onboarding—insanlar bunu diğer iş hedefleriyle birlikte tartabilir.

Kılavuz

Metaforu şu amaçla kullanın: ne kazandık, maliyeti ne olacak ve ne zaman ödemeyi planlıyoruz? Geçmişteki gerçek kısıtlar altında alınmış kararlar için insanları utandırmak amacıyla kullanmayın.

Metafordan Pratiğe: Refaktörleme, Testler, Iterasyon

Teknik borç yalnızca Pazartesi sabahı yaptıklarınızı değiştiriyorsa faydalıdır. Cunningham’in noktası “kodunuz kötü” demek değil; “şimdi hız için borç alabilirsiniz—eğer kasıtlı geri ödeyecekseniz.” Geri ödemenin adı: refaktörleme.

Küçük, sık değişiklikler büyük temizlemelerden iyidir

Borç, değişiklikler nadir ve riskli olduğunda büyür. Bir takım “temizlik sprinti” için beklerse, kod tabanı onların altında kaymış olabilir ve temizlik hem pahalı hem de siyasi olarak zorlaşır.

Küçük, sık refaktörler—özellikle özellik çalışmalarıyla birlikte yapılanlar—değişme maliyetini düşük tutar. Sürekli küçük faiz ödersiniz, bileşik faiz gibi büyümesine izin vermezsiniz.

Refaktörleme ana ödemedir; testler riski kontrol eder

Refaktörleme “ana ödeme”dir: davranışı değiştirmeden yapıyı iyileştirmek. Yakalanması gereken nokta güvence.

Otomatik testler risk kontrolü gibidir: geri ödeme planınızın üretimi bozma olasılığını azaltır.

Pratik bir kural: bir alanı güvenle refaktörleyemiyorsanız, önce o davranış etrafında ince bir test katmanı yatırımı yapın.

Iterasyon, hatalara kilitlenmeden öğrenmeyi destekler

Iterasyon sadece daha hızlı yayınlamak değil; daha erken öğrenmektir. Küçük dilimler halinde teslim ettiğinizde, geri bildirim değişikliklerin hâlâ ucuz olduğu sırada gelir. Bu, yanlış bir tasarımın erken sertleşmesini önler.

Yatırım yapma sinyalleri

Günlük işte şu borç sinyallerine dikkat edin:

• Kapsam benzerken bile teslimat yavaşlıyor
• “Kırılgan” değişiklikler: küçük düzenlemeler beklenmedik bozulmalara yol açıyor
• Aynı modüllerde tekrarlayan hatalar
• Mühendislerin belirli dosyalardan veya bileşenlerden kaçınması

Bunlar görünürse, refaktörleme ve test kapsamını planlı iş olarak ele alın—kahramanca yan görevler gibi değil.

Teknik Borç Gerçekte Günlük İşten Nereden Gelir

Teknik borç genellikle dramatik bir “yanlış mimari seçtik” anı ile gelmez. Gerçek baskı altında alınan küçük takaslar olarak ortaya çıkar—sonra sessizce birikir ve ekip daha yavaş, daha az güvenli ve daha tepkisel hisseder.

Yaygın suçlular: hız, belirsizlik ve eskime

Yaygın bir kaynak aceleyle yapılan sürümdür: bir teslimat tarihler sizi “şimdilik yeterli” bir çözüme zorlar, ama “şimdi” aylarca sürer.

Bir diğeri belirsiz gereksinimlerdir. Amaç sürekli değiştiğinde, ekipler temiz çözümler yerine esnek geçici çözümler kurma eğilimindedir—çünkü sürekli yeniden inşa etmek israf gibi gelir.

Eski bağımlılıklar da pratik bir sürücüdür. Kütüphaneler, çerçeveler ve servisler evrilir; güncel kalmak zaman alır. Kısa vadede geride kalmak rasyonel olabilir, ama bu gelecekte maliyeti artırır: güvenlik güncellemeleri zorlaşır, entegrasyonlar bozulur ve yığın sıkışmış hissedilirse işe alım zorlaşır.

Tasarım sürüklenmesi: hızlı düzeltmeler tasarım olur

İyi tasarlanmış sistemler bile sürüklenebilir. Bir kenar durumunu ele alan küçük bir yama bir emsal olur. Ardından başka bir yama üstüne gelir. Zamanla “gerçek” tasarım, üretimde ayakta kalan şey olur; kimsenin amaçladığı şey olmayabilir.

Bu yüzden takımlar bazen “kimse bu modülü anlamıyor” der. Bu ahlaki bir başarısızlık değil—sürüklenmedir.

Bilgi borcu ve araç borcu (gözden kaçan türler)

Tüm borç kodda değildir.

Bilgi borcu, kararların yakalanmadığı durumlarda oluşur: neden bir kestirme alındı, hangi riskler kabul edildi, hangi alternatifler reddedildi. Bir sonraki kişi göremediğini geri ödeyemez.

Araç borcu da eşit derecede gerçektir: yavaş build’ler, güvenilmez testler, kırılgan CI boru hattı ve tutarsız geliştirme ortamları. Bunlar günlük sürtünme yaratır ve daha fazla kestirme alınmasını teşvik ederek döngüyü besler.

Borcu erken tespit etmeye çalışıyorsanız, tekrarlanan işleri, artan “korku refaktörleri”ni ve araçlarla uğraşmaya harcanan zamanı izleyin.

Borcu Önceliklendirme: Takımlar İçin Pratik Karar Kuralları

Teknik borç tek bir “temizlik sprinti” değildir. Bir takımlar akışı olan takaslardır. Zor kısım hangi takasların önce tersine çevrileceğine karar vermektir—teslimatı durdurmadan veya karmayı büyütmeden.

1) Görüşleri engelleyenleri öde (sadece çirkin olanı değil)

Her günkü işi yavaşlatan veya riskli hâle getiren borçla başlayın:

• Sık kırılan alanlar, deploy için kahramanlık gerektiren parçalar veya uzun hata zincirleri tetikleyen yerler
• Kimsenin dokunmak istemediği modüller
• Küçük özellik taleplerinin rutin olarak büyük yeniden yazımlara dönüştüğü ürün parçaları

Basit bir test: bir borç parçası her hafta kullanıcıya değer sunma süresini artırıyorsa, yüksek faizli bir kredidir.

2) Kullanıcı değeri ile iç iyileştirmeyi “paketleyin”

“Özellik vs. refaktör” tartışması yerine ikisini eşleştirin:

• Kırılgan bir alanda bir özellik yayınlarken, dokunduğunuz yerin yerel borcunu azaltmak için zaman ayırın
• Temizliği belirli bir çıktıya (daha az olay, daha hızlı sürüm, daha kolay onboarding) bağlayın

Bu, iç işi kullanıcı etkisiyle somutlaştırır ve “yeni özellik” çalışmasının çukuru daha da derinleştirmesini engeller.

3) Borcu hafif yollarla görünür kılın

Takımlar gördüklerini önceliklendirir. Basit tutun:

• İzleyicide bir borç kaydı: kısa başlık, konum, etki ve önerilen düzeltme
• Issue ve PR'larda debt, risk, slow-build, hard-to-test gibi etiketler
• “Neden bu garip?” açıklayan küçük notlar

Görünürlük belirsiz şikayetleri yapılabilir seçeneklere dönüştürür.

4) Sınırlar koyun: yeni borç sahibi ve planı olmadan olmasın

Bazen kasıtlı borç alınır (teslimatlar olur). Bunu kontrollü bir karar yapın:

• Bir sahip atayın
• Geri ödeme tetikleyicisini tanımlayın (sonraki sürüm, bir metrik eşiği, müşteri başlatması sonrası)
• Minimum planı yakalayın: ne değişecek ve “bitti” ne demek

Bu, “geçici” kestirmelerin kalıcı mimariye dönüşmesini engeller.

Wikileri Borcu Yönetmek İçin Kullanma: Gerçekten Yardımcı Olan Dokümantasyon

Teknik borcun tekrar etmesinin büyük bir nedeni ekiplerin neden bir karar aldığını unutmasıdır.

Bir wiki, kod tabanının “hafızası” olarak hareket edebilir: sistemin ne yaptığı kadar hangi takasların kabul edildiği, neyin ertelendiği ve hangi varsayımların gelecekte bozulabileceğinin kaydı.

Wiki nasıl tutarlı kararları destekler

Yeni insanlar katıldığında veya bir ekip bir modüle aylar sonra geri döndüğünde, bir wiki onlara kod içinde görünmeyen bağlamı verir. Bu bağlam ekiplerin tutarlı seçimler yapmasına yardımcı olur, böylece hatalar, yeniden yazımlar veya yavaş teslimat yoluyla aynı dersleri yeniden öğrenerek “faiz” ödemek zorunda kalmazsınız.

Anahtar, bilgiyi kararların alındığı anlarla (sürümler, olaylar, göçler ve büyük refaktörler) bağlamaktır.

Yararlı şablonlar (basit ve tekrarlanabilir)

Bir wiki birkaç hafif şablon izlediğinde en iyi çalışır:

• ADR’ler (Mimari Karar Kayıtları): karar, düşünülen alternatifler ve sonuçları
• Olay incelemeleri: ne oldu, katkıda bulunan faktörler ve takipler (borç öğelerini dahil ederek)
• Kodlama standartları: tekrarlayan temizlik işlerini engelleyen küçük kurallar
• Borç günlüğü: bilinçli olarak ertelenen iyileştirmeler ve "neden şimdi/neden değil" kaydı

Her sayfayı kısa tutun. Anlamak için toplantı gerekiyorsa, sayfa çok uzundur.

Dokümanları güvenilir tutmak

Dokümanlar eskidiğinde zararlı olur. Küçük alışkanlıklar bunu önler:

• Sahiplik: her sayfanın bir sahibi olsun (takım veya kişi)
• Tarihler: “Son gözden geçirildi” ve “Sonraki gözden geçirme” alanları ekleyin
• Hafif gözden geçirme: sprint incelemesi veya aylık teknik senk sırasında hızlı bir kontrol—beş dakika yeterli

İş öğelerini bağlama bağlayın

“Refaktör X” veya “temizle Y” için bir ticket açtığınızda, onu ilgili ADR, olay incelemesi veya borç-günlüğü girdisine bağlayın.

Biri “neden buna zaman ayırıyoruz?” diye sorduğunda cevap bir tık uzak olur—ve gelecekteki değişiklikler amacın açık olması sayesinde daha kolay olur.

Borcu İletişim Kurarken Ölçümlerde Aşırı Söz Vermeyin

Teknik borç, insanlar etkiyi anladığında en kolay fonlanır; “borç puanları” tablosu vermek değil. Cunningham’in metaforu mühendislik takaslarını iş diline tercüme ettiği için işe yarar—bu yüzden mesajı basit, spesifik ve çıktı odaklı tutun.

Etki ifadeleriyle başlayın (sahte kesinlik değil)

“%37 borcumuz var” veya “bu modül 12 gün geride” gibi iddialardan kaçının. Bunun yerine borç yüzünden takımın ne yapamadığını veya neyi güvenle yapamadığını anlatın.

Örnekler:

• “Şimdi küçük bir fiyat kuralı eklemek bir gün sürüyor çünkü değişiklik üç servis arasında dalga etkisi yapıyor.”
• “Yayınlar manuel kontrol listesi ve iki kişi bekleme gerektiriyor; bu yüzden daha az sık yayınlıyoruz.”
• “Faturalama akışına dokunmaktan kaçınıyoruz; bu, sonunda dokunduğumuzda yüksek şiddetli bir olaya yol açma riskini artırıyor.”

Küçük bir dürüst gösterge seti kullanın

Metrikler yardımcı olabilir, ama onları gösterge olarak görün—kanıt olarak değil.

Çoğu takımın ağır araçlara ihtiyaç duymadan ölçebileceği iyi seçenekler:

• Lead time (fikirden üretime): borç genellikle bunu uzatır
• Değişiklik hata oranı: borç daha fazla rollback ve hotfix olarak görünür
• Build/test süresi: borç geri bildirim döngüsünü yavaşlatır
• Hata eğilimleri: özellikle aynı alanlarda tekrarlayan hatalar

“Faiz”i basitçe açıklayın

Faiz, o alanda her değişiklik yaptığınızda ödediğiniz ekstra maliyettir. Bunu şöyle söyleyin: “Her değişiklik ek olarak 2–3 saat yeniden çalışma, koordinasyon veya manuel test maliyeti getiriyor. Bu borcu ödemek bu süregelen fazlayı azaltır.”

Önce hikaye sonra sayılarla raporlayın

Kısa bir örneği (ne yavaşlattı, hangi risk arttı) bir destekleyici metrikle eşleştirin. Hikayeler netlik sağlar; metrikler güvenilirlik katar—her şeyi tam ölçebileceğinizi iddia etmeden.

Mini Oyun Kitapçığı: Bir Projede Wiki + Borç Düşüncesini Uygulayın

Ward Cunningham’in iki büyük fikrinden faydalanmak için şirket çapında bir girişime ihtiyacınız yok. Bir projede küçük, tekrarlanabilir bir döngü yürütün: ortak hafıza olarak bir wiki sayfası kullanın ve teknik borcu geri ödenebilir bilinçli bir takas olarak ele alın.

Adım 1: Envanter (30–60 dakika)

Tek bir wiki sayfası oluşturun: “Proje X: Borç & Öğrenme Günlüğü.” Kısa bir toplantıda takımın sürekli çarptığı sıcak noktaları listeleyin.

Tekrarlayan acıya odaklanın, soyut kod kalitesi değil:

• Değiştirilmesi yavaş olan alanlar
• Sürekli geri dönen hatalar
• İnsanların güncellemekten kaçındığı testler
• Haftada sorulan onboarding soruları

Her madde için iki not ekleyin: “Bozulduğunda ne olur?” ve “Hangi işler gecikir?” Bu konuşmayı çıktı odaklı tutar.

Adım 2: Plan (15 dakika)

Sadece 1–3 öğe seçin. Her biri için yazın:

• Bitti demek: somut bir bitiş durumu (örn. “API için kenar durumları A/B/C'yi kapsayan testler var”)
• Zaman kutusu: 2–10 saat veya 1–3 gün—bitirilebilecek kadar küçük
• Sahip + gözden geçiren: yarım kalmış temizlikleri önlemek için

Bir kural gerekirse: önümüzdeki haftanın işini en çok iyileştiren borcu seçin, teorik geleceği değil.

Adım 3: Çalışmayı yapın (normal geliştirme sırasında)

Bunu özellik işi gibi ele alın: küçük commit’ler, mümkünse testler ve wiki'ye kısa bir not—ne değişti ve neden—eklemek.

Adım 4: Gözden geçir ve wikiyi güncelle (10 dakika)

“Kazanımlarımız” kısmına kısa bir not ekleyin: sizi ne şaşırttı, ne daha uzun sürdü ve bir dahaki sefer neyi farklı yaparsınız. Ardından listenizi ayarlayın ve döngüyü haftalık veya iki haftalık tekrarlayın.

Araç notu: izleri kaybetmeden döngüyü hızlandırma

Takımınız yeni iç araçlar veya prototipler inşa ediyorsa, Koder.ai gibi platformlar bu iş akışına iyi uyabilir: planlamayı yakalamak için sohbet tabanlı planlama modu kullanabilir, hızlı bir React/Go/PostgreSQL (veya Flutter) dilimi yayınlayabilir ve anlık görüntüler ile geri alma ile denemelerin kazara uzun ömürlü borca dönüşmesini önleyebilirsiniz. Gerekirse kaynak kodunu dışa aktarabilir ve projeyi olağan repo ve inceleme sürecinize getirebilirsiniz.

“Teknik Borç”ün Yaygın Yanlış Kullanımları (ve Daha İyi Alternatifleri)

“Teknik borç” faydalı bir metafordur—ta ki her rahatsız edici şeyin etiketine dönüşene kadar. Bu olduğunda takımlar net takaslar yapma yeteneğini kaybeder.

Kötü Kullanım 1: “Teknik borç” = hiç sevmediğim her kod

Her dağınık kod borç değildir. Borç, şimdi daha hızlı ilerlemek için alınmış bilinçli bir kestirmedir; gelecekte bir maliyeti olduğu anlaşılmıştır.

Daha iyi alternatifler:

• Net değilse: buna okunabilirlik veya sürdürülebilirlik işi deyin
• Riskliyse: güvenilirlik sorunu veya defect pattern olarak adlandırın
• Yavaşsa: performans işi olarak adlandırın

Kötü Kullanım 2: Borcu tek seferlik bir temizliğe dönüştürmek

“Tümünü ödeyelim” sprinti genellikle başarısız olur çünkü ertesi hafta yeni borç oluşur. Cunningham’in fikri daha çok bir alışkanlık: dikkatli borç almak, düzenli ödemek.

Daha iyi alternatif: küçük, sık düzeltmeler için sürekli bir refaktörleme bütçesi oluşturun (özelliğe bağlı, kısa işleri bağlayın) yerine büyük temizliklere başvurmayın.

Kötü Kullanım 3: Bireyleri suçlamak

Borç nadiren tek kişinin hatasıdır. Teslim tarihleri, belirsiz gereksinimler, eksik test ortamları ve el değişimleri kestirmelerin rasyonel olduğu koşulları yaratır.

Daha iyi alternatif: sistem kısıtını tanımlayın (“test ortamı yok”, “sahiplik belirsiz”, “acele sürümler”) ve önce onu düzeltin.

Kötü Kullanım 4: Dokümanların çürümesine izin vermek (özellikle wikiplerde)

Bayat wiki güncelliğini yitirmiş bir wiki’den daha kötüdür: yanlış varsayımları yayar.

Daha iyi alternatif: wiki sayfalarını küçük, sahipli ve gözden geçirilebilir tutun—“son doğrulama” notları ekleyin, kaynak ticket'lara bağlayın ve bakımı olmayan sayfaları silin.

Eylem Kontrol Listesi: Bu Hafta Ne Yapmalı

Cunningham’in “wiki + borç” düşüncesinden fayda almak için yeniden yapılanmaya veya yeni bir araca ihtiyacınız yok. Görünür ve tekrarlanabilir takaslar yapan birkaç hafif alışkanlığa ihtiyacınız var.

1) Canlı kalan bir borç günlüğü başlatın

Takım wiki’nizde Borç Günlüğü adında tek bir sayfa oluşturun. Kısa ve güncel tutun.

Her giriş için yakalayın:

• Ne rahatsız ediyor (kullanıcı/mühendis semptomu)
• Nerede (repo/modül/servis)
• Neden şimdi (ne tetikledi)
• Bir sonraki küçük ödeme (günde birden az sürecek somut adım)
• Sahip + gözden geçirme tarihi (sonsuz bir backlog değil)

2) Refaktörlemeyi normal planlamaya koyun

Sprint/haftalık planlamada tekrar eden bir bütçe ekleyin (küçük bile olsa): örn. %10–20 kapasite veya özellik başına bir refaktör hikayesi.

Bunu açıkça yapın: “Her hafta faiz ödüyoruz; bu planlı bir ödemedir.” Refaktörleme görevlerini kullanıcıya görünen hedeflere bağlayın (daha hızlı değişiklik, daha az olay, daha kolay test).

3) 2–3 wiki şablonunu standardize edin

Tutarlılık ayrıntıdan iyidir. Şunlarla başlayın:

• Karar Kaydı (ADR-lite): bağlam → karar → sonuçlar
• Modül Sayfası: amaç → ana akışlar → yaygın tuzaklar → nasıl test edilir
• Borç Kaydı Girdisi: yukarıdaki alanlar

4) Takım dili üzerinde anlaşın (böylece “borç” her sevmediğim şeyi ifade etmez)

Wikide kısa bir “Borç Tanımı” yazın: ne sayılır, kim etiketleyebilir ve ödemenin nasıl onaylanacağı.

Yararlı bir kural: Borç, geri ödeme planı olan bilinçli bir takastır. Eğer sadece belirsizse, ona “bilinmeyen”, “bug” veya “tasarım riski” deyin.