05 Ağu 2025·8 dk
Ward Cunningham, Wikiler ve Zaman İçinde Teknik Borç
Ward Cunningham’in wiki fikri ve "teknik borç" metaforu, ekip işbirliğini, refaktörleme alışkanlıklarını ve uzun vadeli kod yönetimi kararlarını nasıl etkilediğini keşfedin.
Ward Cunningham’in wiki fikri ve "teknik borç" metaforu, ekip işbirliğini, refaktörleme alışkanlıklarını ve uzun vadeli kod yönetimi kararlarını nasıl etkilediğini keşfedin.
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ı.
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.
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ı.
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ı.
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.
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.
Bu basit fikir gerçek yenilikti. Wikilerden önce “paylaşılan bilgi” genellikle üç şeyden biriydi:
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.
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.
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.
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.
İ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.
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.
Günlük işleri kolaylaştıran ortak wiki sayfaları:
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.
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.
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.
Borç güçlüdür çünkü aynı anda iki şeyi ima eder:
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, 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.
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.
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.
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.
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.
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.
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.
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.
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 ö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 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.
Günlük işte şu borç sinyallerine dikkat edin:
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ç 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 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.
İ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.
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.
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.
Her günkü işi yavaşlatan veya riskli hâle getiren borçla başlayın:
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.
“Özellik vs. refaktör” tartışması yerine ikisini eşleştirin:
Bu, iç işi kullanıcı etkisiyle somutlaştırır ve “yeni özellik” çalışmasının çukuru daha da derinleştirmesini engeller.
Takımlar gördüklerini önceliklendirir. Basit tutun:
debt, risk, slow-build, hard-to-test gibi etiketlerGörünürlük belirsiz şikayetleri yapılabilir seçeneklere dönüştürür.
Bazen kasıtlı borç alınır (teslimatlar olur). Bunu kontrollü bir karar yapın:
Bu, “geçici” kestirmelerin kalıcı mimariye dönüşmesini engeller.
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ı.
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.
Bir wiki birkaç hafif şablon izlediğinde en iyi çalışır:
Her sayfayı kısa tutun. Anlamak için toplantı gerekiyorsa, sayfa çok uzundur.
Dokümanlar eskidiğinde zararlı olur. Küçük alışkanlıklar bunu önler:
“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.
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.
“%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:
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:
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.”
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.
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.
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:
Her madde için iki not ekleyin: “Bozulduğunda ne olur?” ve “Hangi işler gecikir?” Bu konuşmayı çıktı odaklı tutar.
Sadece 1–3 öğe seçin. Her biri için yazın:
Bir kural gerekirse: önümüzdeki haftanın işini en çok iyileştiren borcu seçin, teorik geleceği değil.
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.
“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.
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ç” 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.
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:
“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.
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.
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.
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.
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:
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).
Tutarlılık ayrıntıdan iyidir. Şunlarla başlayın:
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.
Ward Cunningham, en çok iki pratik fikriyle tanınır: ilk wiki (WikiWikiWeb) ve “teknik borç” metaforu.
Her iki durumda da amaç marka değil pratik bir çözümdü—kayıp bağlam, yavaş bilgi paylaşımı ve zaman içinde değiştirmesi zorlaşan kod gibi tekrar eden ekip sorunlarını çözmekti.
Cunningham, 1990'ların ortasında yazılım uygulayıcılarının desenleri paylaşabilmesi ve fikirleri zaman içinde birlikte geliştirebilmesi için ilk wikiyi oluşturdu.
Amaç yaşayan bir diyalogtu: küçük düzenlemeler, hızlı bağlantılar ve paylaşılan sahiplik—bilgi tabanı topluluk öğrendikçe evrilebilsin diye.
Bir wiki “yerinde” korunur: sayfayı kendiniz düzenlersiniz ve herkes güncellenmiş hâlini anında görür.
Tipik alternatiflerle karşılaştırıldığında:
Bir wiki hızlı düzeltmelere ve ortak, güncel anlayışa odaklanır.
Tekrarlayan darboğazları kaldıran sayfalarla başlayın; büyük bir dökümantasyon girişimiyle başlamayın.
Pratik başlangıç seti:
Her sayfayı kısa ve bugün kullanılır tutun; daha sonra iyileştirebilirsiniz.
İnsanların hızlı yazabileceği ve okuyucuların kolayca tarayabileceği birkaç tutarlı şablon kullanın.
İyi, hafif şablonlar:
Şablonlar sürtüşmeyi azaltmalı, mükemmelliği zorlamamalı.
Bayatlamayı ana başarısızlık modu olarak görün ve bunu görünür kılacak küçük alışkanlıklar ekleyin.
Pratik güvenlik önlemleri:
Daha küçük, güvenilir bir wiki, büyük ama güncelliğini yitirmiş bir wikiden iyidir.
Cunningham’in orijinal çerçevesinde teknik borç bilinçli bir takastır: şimdi daha basit veya daha hızlı bir yol seçersiniz, öğrenmek veya daha çabuk yayınlamak için, ve bunun gelecekte bir yükümlülük yaratacağını bilirsiniz.
Bu, otomatik olarak “kötü kod” anlamına gelmez. Ödünç aldığınız zamanı refaktörleme, testler, yeniden tasarım veya geliştirilmiş araçlarla geri ödemeyi beklersiniz.
Planlanmış borç, bağlamı ve bir geri ödeme planı olan bilinçli bir kestirmedir; kazara oluşan karışıklık ise açık sahiplik veya takip eksikliği olan, yönetilmeyen bir karmaşadır.
Farkı anlamanın yolları:
Her şeyi “borç” diye adlandırmak gerçekten sorunu (güvenilirlik riski, belirsiz gereksinimler, sahiplik eksikliği) gizleyebilir.
Teslimatı yavaşlatan veya riski artıran “yüksek faizli” borcu önceliklendirin; sadece çirkin olanı değil.
Uygulamada işe yarayan karar kuralları:
Amaç öngörülebilir değişimdir, mükemmel kod değil.
Sahte hassaslıktan kaçının; somut etki ifadeleriyle başlayın ve küçük, dürüst göstergeler kullanın.
Söylemeniz gerekenler yerine “bizde %37 borç var” gibi ifadeler yerine:
Yardımcı göstergeler:
Bir hikayeyle bir metriği eşleştirin: hikaye netlik sağlar, metrik güvenilirlik katar.