Teknik borç, yazılımın bugün çalışmasını bozmayan ama sonraki değişikliği pahalılaştıran bir karardır. Büyük yeniden yazım bu faizi çoğu ekipte silmez; ikinci bir sistemi canlı tutar. Bu rehber, refaktörü özellik işinin sınırına indirger ve küçük geri ödemeyi iş kartına nasıl yazacağınızı gösterir.
Teknik borç nedir sorusu, çoğu ekipte “kodumuz kötü” yakınmasına indirgenir. Oysa borç, bugün daha çabuk teslim etmek için alınan ve yarın aynı işi yavaşlatan bir karardır. Faiz; bir alanı değiştirirken üç dosyayı aynı anda açmak, bir hatayı dört yerde düzeltmek ve kimsenin dokunmak istemediği bir modül olarak görünür. Büyük yeniden yazım bu faizi silmez. Çoğu zaman ikinci bir sistemi canlı tutar. İşe yarayan yol, her özellik işine küçük bir geri ödeme bağlamaktır.
Bu rehber borcu ahlak dersine çevirmez. Amacı, “bir gün temizleriz” cümlesini özellik işinin içine indirgemek ve dokunulan yolu biraz daha okunur bırakmaktır.
Teknik borç nedir ve nasıl birikir
Teknik borç, yazılımın bugünkü davranışını bozmayan ama sonraki değişikliği pahalılaştıran bir sapmadır. Derleme hâlâ geçer. Kullanıcı ekranı görür. Asıl fatura, bir sonraki kuralı eklerken çıkar: aynı mantık birkaç yerde yaşar, isimler işi anlatmaz, test olmadığı için korku büyür.
Borç çoğu zaman iki kaynaktan gelir. Birincisi bilinçli kısa yoldur: teslim tarihi için bilinen bir sapma seçilir, geri ödeme niyeti vardır. İkincisi rastgele sapmadır: kopyala-yapıştır, isimsiz fonksiyon, test yazmadan kapanan hata, “geçici” diye bırakılan sabit değer. Üçüncü bir kaynak daha vardır: hiç karar alınmaması. Aynı kural üç yerde yaşar çünkü kimse tek sahibi göstermemiştir.
Somut örnekler işi netleştirir. Sipariş tutarı hem sepet hem fatura hem de yönetim listesinde ayrı ayrı hesaplanır. Kullanıcı rolü bir yerde metin, başka yerde sayı tutulur. Kampanya bayrağı kodun içine gömülür ve sezon bitince unutulur. Ödeme sağlayıcısından gelen bildirim, imza kontrolü olmadan işlenir; bu da ileride ödeme ve kargo webhook akışını kırılgan hale getirir.
Her karmaşa borç değildir. Az kullanılan, durağan ve iyi sınırlanmış bir parça sade kalmış olabilir. Borç, faiz ödettiğiniz yerde başlar: sık değişen, sık bozulan ve yeni işi tıkayan yerde.
Büyük yeniden yazım hayali neden tıkanır
Yeniden yazım vaadi çekicidir. Eski kod “kirli”, yeni kod “temiz” durur. Gerçekte iş durmaz. Vergi kuralı, kargo firması, kampanya ve destek talebi eski sistemi beslemeye devam eder. Ekip iki kod tabanına bölünür. Bilgi çoğu zaman belgede değil eski kodun kıvrımlarında durduğu için yeni sistem aynı istisnaları geç keşfeder.
İkinci tuzak, yeniden yazımın kendisinin de borç üretmesidir. Süre uzadıkça “şimdilik kopyalayalım” cümleleri çoğalır. Eski kısayollar yeni isimlerle geri gelir. Canlıya geçiş geciktikçe faiz hem eski hem yeni tarafta işler.
Bu yüzden hedef, sistemi bir gecede değiştirmek değil, yeni işin geçtiği yolu boğarak küçültmektir. Yeni kural yeni yoldan gider. Eski yol, ona dokunan iş geldikçe incelir. Dokunulmayan rapor ekranı, kimseyi bekletmiyorsa bu sprintin konusu değildir.
Refaktörü özellik işine bağlamanın kuralı
İşleyen kural sadedir: özellik hangi kod yolundan geçiyorsa temizlik o yolun sınırındadır. Sepete indirim ekliyorsanız fiyatı hesaplayan fonksiyonu sadeleştirirsiniz. Kullanıcı profili modülünü bu işte yeniden yazmazsınız.
Dokunduğun yolu, işi teslim ettiğinde biraz daha okunur bırak. Dokunmadığın semti bu kartta yeniden yazma.
Bu, “izci kuralı” olarak da anılır: bulunduğunuz yeri biraz daha düzenli bırakmak. Fark, niyeti iş kartına yazmaktır. Temizlik gizli bir yan görev olursa ya hiç yapılmaz ya da sınırsız büyür. Ürün sahibi özelliği, geliştirici ise o özelliğin geçtiği dar yolu görür.
KepezWeb olarak özel yazılım işlerinde aynı sınırı kullanırız: teslim edilen ekran çalışır ve dokunulan fonksiyon bir önceki haline göre daha net durur. Tüm uygulamayı “madem açtık” diye çevirmeyiz.
“Madem buradayız” tuzağı
Sınırsız temizlik, özelliği yutar. İş uzayınca ürün tarafı refaktör kelimesine karşı çıkar. Sonra ekip ya borcu yok sayar ya da altı aylık yeniden yazım ister. İkisi de aynı kapıya çıkar: faiz görünmez hale gelir.
Sınır şöyle çizilir. Bu kartta değişecek davranış nedir? O davranışı taşıyan fonksiyon, tablo veya sözleşme hangisidir? Temizlik bu üçlünün dışına taşarsa yeni kart açılır; aynı karta yığılmaz. “Yakındaki dosya da kötü” gerekçe değildir. Yakındaki dosya, başka bir iş oradan geçene kadar bekleyebilir.
Önce hangi borcu ödersiniz
Tüm borcu ödemek hedef değildir. Önce sık değişen, sık bozulan ve yeni işi kilitleyen yer gelir. Yılda bir açılan iç rapor, günlük sipariş akışından sonra durur. Giriş, stok düşümü, ödeme durumu, fatura kalemi gibi sıcak yollar önce gelir.
Seçim için dört soru yeter:
- Bu parçaya yeni iş ne sıklıkla takılıyor?
- Aynı hata veya aynı el ile düzeltme tekrarlıyor mu?
- Değiştirmeye korkutan şey test yokluğu mu, belirsiz isim mi, yoksa yan etki mi?
- Temizlik bu özellik kartının sınırına sığıyor mu?
Cevap “takılıyor, tekrarlıyor ve sığıyor” ise geri ödeme bu işe bağlanır. Cevap “kötü görünüyor ama kimse değiştirmiyor” ise kayıt düşülür, bu kart şişirilmez. Görünür çirkinlik ile ödenen faiz aynı şey değildir.
| Durum | Büyük yeniden yazım | İşe bağlı geri ödeme |
|---|---|---|
| Kapsam | Modül veya tüm uygulama | Özelliğin geçtiği fonksiyon, tablo veya uç |
| Teslim | Uzun süre değer durur | Özellik gelir, yol biraz temizlenir |
| Risk | İki sistem, bölünmüş ekip | Küçük fark, dar test çevresi |
| İş dili | “Kod kötü, baştan yazalım” | “Bu kural tek yerde hesaplansın” |
| Ne zaman seçilir | Yol gerçekten tıkanmış ve sınır netse | Varsayılan yol budur |
İş kartına küçük geri ödeme nasıl yazılır
Borç, sohbetlerde “şunu da düzeltelim” diye durduğu sürece görünmez. Kartta üç cümle yeter: asıl davranış, sınırlı temizlik, bitti sayılma ölçütü. Ürün sahibi birinci cümleyi, geliştirici ikinciyi, ikisi birlikte üçüncüyü doğrular.
Örnek dil şöyle durur. “Sipariş notu alanı eklenecek. Not, mevcut sipariş güncelleme fonksiyonundan ayrılacak. Not boş olsa da tutar hesabı değişmeyecek.” Burada özellik not alanıdır. Geri ödeme, şişmiş güncelleme fonksiyonunu bölmektir. Ölçüt, tutarın aynı kalmasıdır.
Başka bir kart: “İade nedeni listesi yönetilebilir olacak. Neden metni, destek ekranı ile stok hareketinde aynı kaynaktan okunacak.” Temizlik, iki yere gömülmüş metni tek listeye taşımaktır. İade sürecinin tamamını yeniden tasarlamak bu kartın işi değildir.
Yazım kuralı da sadedir. “Kod kalitesi artsın” ölçüt değildir. “Şu fonksiyon tek iş yapsın”, “şu kural tek yerde dursun”, “şu kayıt tek tablodan okunsun” ölçüttür. İsim somut oldukça ürün tarafı faizi görür: aynı kuralı iki kez anlatmak zorunda kalmamak.
- Davranışı bir cümleyle yazın.
- Dokunulacak dosya, tablo veya ucu adlandırın.
- Bu kartta yapılmayacak temizliği açıkça dışarıda bırakın.
- Eski davranışın bozulmayacağı bir kontrol seçin.
- Temizlik sınırı şişerse ayrı kart açın, özelliği rehin almayın.
Sürenin kendisi vaat değildir. Sınır netse temizlik özelliğin yanında durur. Sınır net değilse sorun borç değil, işin henüz kesilmemiş olmasıdır. O zaman önce davranışı kesersiniz; refaktörü büyütmezsiniz.
Güvenli dokunuş: test ve yayın hattı
Testsiz refaktör, cesaret gösterisi gibi durur; aslında kör atlamadır. Tüm sistemi kapsamayı beklemeyin. Değişen fonksiyonun bugünkü çıktısını kilitleyen dar bir test çoğu iş için yeter. Önce mevcut davranışı sabitleyin, sonra isimleri ve parçalamayı yapın. Davranış değişecekse onu özellik olarak ayrı yazın; temizlik ile kural değişimini aynı farkta gizlemeyin.
Küçük fark, inceleme ve geri alma yükünü de düşürür. Fiyat hesabını bölen bir birleştirme, tema rengini de değiştiren bir birleştirmeden daha okunur. Yayın kapısı belirsizse temizlik canlıda korku üretir. Küçük ekipte sade bir CI/CD hattı, refaktörü “gece özel işlemi” olmaktan çıkarır: test kapıdan geçmeyen fark birleşmez.
Güvenli dokunuşun bir boyutu da veri ve sırdır. Temizlik diye canlı müşteri kaydında deneme yapmak borcu ödemez, yeni borç açar. Davranışı önce tekrarlanabilir bir ortamda görün. Canlıya giden fark, özelliğin ihtiyaç duyduğu alanla sınırlı kalsın.
Borç ile sade tasarımı karıştırmayın
Her kısa yol faiz işlemez. Yılda bir doldurulan iç form için tek parça bir akış, abartılı katmandan daha duru olabilir. İki ekran için erken parçalanmış servisler, “modern durayım” diye alınan bir borçtur. Faiz, ekibin her değişiklikte üç yayını ve üç sözleşmeyi aynı anda yürütmesi olarak ödenir.
Sade tasarım, bugünkü işi taşıyan ve yarınki komşu işe yer bırakan yapıdır. İsimler işi anlatır. Kural bir yerde durur. Yan etki görünür. Bu üçü varken kod kısa da olsa borç sayılmaz. Uzun olması da tek başına borç değildir; uzun ama tek işli bir fonksiyon, kısa ama beş işli bir fonksiyondan daha ucuz olabilir.
Aynı ayrım, özel PHP/MySQL yazılım işlerinde sık görülür. Tabloyu parçalamak her zaman temizlik değildir. Sık birlikte okunan sipariş ve kalemleri ayırmak, her listeyi pahalılaştırabilir. Önce hangi sorgu ve hangi ekran yavaşlıyor bakın; moda bir şema çizmeyin.
Karar ölçütü yine faizdir. Bu parça yeni işi geciktiriyor mu? Geciktirmiyorsa mimari gururu için dokunmayın. Geciktiriyorsa özelliğin geçtiği yeri küçültün. Yazılım geliştirme işi, birikmiş utancı tek seferde silmek değil, her teslimatta yolu biraz daha taşınabilir kılmaktır.
Sıkça Sorulan Sorular
Teknik borç her zaman kötü müdür?
Hayır. Bilinçli, sınırlı ve geri ödemesi kartta duran borç, erken teslimi mümkün kılabilir. Kötü olan, faizi ölçmeden biriktirmek ve “sonra bakarız” diye sahibi olmayan sapma bırakmaktır.
Refaktör için ayrı bir sprint gerekir mi?
Gerekmez; varsayılan yol bu değildir. Ayrı sprint, temizlik sınırsız büyüdüğünde veya ürün işi durduğunda ortaya çıkar. Önce özelliğin yoluna sığan geri ödemeyi deneyin. Sığmıyorsa işi bölün, takvimi mitolojik bir temizlik ayına ertelemeyin.
Ürün sahibi teknik borcu nasıl görür?
Kod kalitesi cümlesiyle değil, tekrar ve gecikme cümlesiyle. “Bu kural üç yerde yaşadığı için aynı değişikliği defalarca anlatıyoruz” anlaşılır. “Fonksiyonlar çirkin” anlaşılmaz. Karttaki temizlik cümlesi iş dilinde olsun.
Ne zaman yeniden yazmak mantıklı olur?
Yol gerçekten tıkanmışsa, sınır netse ve eski davranışın hangisinin taşınacağı yazılıysa. “Hepsi kötü” gerekçe değildir. Yeniden yazım bile işe bağlı dilimlerle yürür: önce yeni iş yeni yoldan çıkar, eski yol bir gecede yok olmaz.
Yorum satırı teknik borcu kapatır mı?
Kapatmaz. Yorum, neden sapıldığını kısa tutuyorsa faydalıdır. Asıl kapanış, kuralın tek yerde durması, ismin işi anlatması ve dokunulan yolun testsiz kalmamasıdır. “Burası kötü, sonra düzelt” notu borcu belgelemez; faizi ertelediğinizi belgeler.
Mevcut yazılımınızda hangi ekranın faiz ödettiğini netleştirmek ve refaktörü iş listesine bağlamak istiyorsanız KepezWeb ile konuşabilirsiniz. Dokunulacak alanı birlikte sınırlayıp teklif al sayfasından yazın; büyük yeniden yazım vaadi yerine işe sığan geri ödemeyi konuşuruz.
