Kazanimlar:
- Refactoring öncesi mevcut davranışı yakalayan bir test güvenlik ağı kurabilme
- AI'dan küçük, tek adımlı ve davranış-koruyucu dönüşümler isteyip her adımı doğrulayabilme
- Teknik borcu iş bağlamıyla tespit edip önceliklendirebilme
Refactoring, bir kodun dıştan görünen davranışını değiştirmeden iç yapısını iyileştirmektir: daha okunabilir, daha sade, daha bakımı kolay hâle getirmek. Teknik borç (technical debt) ise, hızlı çözüm uğruna verilen ve zamanla "faiziyle" geri ödenen tasarım tavizidir — bugün kestirmeden geçtiğiniz her köşe, yarın bir yavaşlama veya hata olarak geri döner. Yapay zeka, tekrar eden ve mekanik refactoring işlerini hızlandıran güçlü bir yardımcıdır; ama refactoring'in tek altın kuralı vardır ve AI onu tek başına garanti edemez: davranış değişmemeli.
Bu ünitede AI ile güvenli refactoring yapmayı öğreniyoruz: küçük ve tersine çevrilebilir adımlar, testlerle koruma altına alma, kod kokularını (code smell) tespit ettirme ve teknik borcu önceliklendirme. Kritik nokta şudur: davranışın korunduğunu kanıtlayan şey AI'nın sözü değil, geçen testlerdir.
Refactoring'in Altın Kuralı: Davranış Sabit Kalır
Refactoring'i tehlikeli yapan şey, "iyileştiriyorum" derken farkında olmadan davranışı değiştirmektir. Bir koşulu sadeleştirirken bir kenar durumu düşürmek, bir döngüyü dönüştürürken sıralamayı bozmak, bir fonksiyonu bölerken bir yan etkiyi kaçırmak — bunların hepsi "temiz görünen" ama bozuk kod üretir.
Bu yüzden refactoring'in ön koşulu testtir: değiştirmeden önce, mevcut davranışı yakalayan testleriniz olmalı. Bu testler bir "güvenlik ağı"dır; refactoring sırasında yanlışlıkla bir şeyi bozarsanız kırılıp sizi uyarırlar. Testiniz yoksa, önce (5. ünitede öğrendiğimiz gibi) mevcut davranışı sabitleyen testler yazın — burada AI hızlı bir başlangıç sağlar.
Dikkat: Test ağı olmadan yapılan AI destekli refactoring, en sinsi hata kaynaklarından biridir. "Davranışı korudum" demek kolaydır; kanıtı, değişiklikten önce ve sonra aynı testlerin geçmesidir.
Adım Adım: Güvenli Refactoring Akışı
- Güvenlik ağını kurun. Refactor edeceğiniz kodun mevcut davranışını yakalayan testler olsun; yoksa önce onları yazın (ve geçtiklerini görün).
- Kokuyu adlandırın. Neyi neden iyileştiriyorsunuz? "Bu fonksiyon 3 iş yapıyor", "aynı mantık 4 yerde tekrar ediyor", "isimler yanıltıcı".
- Küçük ve tek adımlı isteyin. AI'dan tek bir dönüşüm isteyin (ör. yalnızca "bu fonksiyonu ikiye böl"), tüm dosyayı yeniden yazmasını değil.
- Testleri çalıştırın. Her adımdan sonra. Yeşilse devam, kırmızıysa geri alın.
- Diff'i okuyun. Değişikliğin gerçekten davranış-koruyucu olduğunu satır satır teyit edin; AI "sadece yapı" derken bir mantık kaymış olabilir.
- Küçük parçalar hâlinde birleştirin. Büyük tek seferlik refactoring PR'ları hem risklidir hem incelenemez.
Üç Mini Vaka
Vaka 1 — 220 satırlık fonksiyon güvenle bölündü. Bir ekipte 220 satırlık bir sipariş işleme fonksiyonu vardı. Önce mevcut davranışı yakalayan 14 test yazıldı (AI yardımıyla), hepsi geçti. Sonra fonksiyon AI ile adım adım 5 küçük fonksiyona bölündü; her adımdan sonra testler çalıştırıldı. Bir adımda iki test kırıldı — AI bir kenar durumdaki return'ü kaçırmıştı. Testler bunu anında yakaladı, düzeltildi. Ağ olmasa hata üretime kadar gidebilirdi.
Vaka 2 — Test ağı olmadan felaket. Başka bir geliştirici, testi olmayan bir tarih hesaplama modülünü AI ile "temizledi". Kod daha güzel göründü ama artık yılı yanlış hesaplıyordu; hata iki hafta sonra bir müşteri şikâyetiyle çıktı. Kayıp, refactoring'den kazanılan zamanın kat kat üstündeydi. Ders: test yoksa refactoring bir kumar.
Vaka 3 — Teknik borç önceliklendirme. Bir ekip, birikmiş 30 kadar "iyileştirilebilir" noktayı AI'ya verip her birini "değişim sıklığı × risk × çaba" ekseninde puanlattı. Ortaya çıkan tabloda, nadiren dokunulan çirkin bir modülün aslında düşük öncelikli, sık değişen orta karmaşıklıkta bir modülün ise yüksek öncelikli olduğu görüldü. Ekip enerjisini doğru yere yönlendirdi.
Dört Kopyalanabilir Şablon
Kod kokusu tespiti ve önceliklendirme:
Bu kodda refactoring adayı "kokuları" listele: uzun fonksiyon, tekrar (DRYihlali), yanıltıcı isim, derin iç içe koşul, gizli yan etki, sihirli sayı.Her biri için: yeri, neden sorun, önerilen küçük adım, tahmini risk (düşük/orta/yüksek). Henüz kod DEĞİŞTİRME, sadece plan.{{kod}}
Tek adımlı, davranış-koruyucu dönüşüm:
SADECE şunu yap: {{tek dönüşüm, ör. bu fonksiyonu isimlendirilmiş 3 küçükfonksiyona böl}}. Dıştan görünen davranışı, imzayı ve dönüş değerleriniDEĞİŞTİRME. Değiştirdiğin her şeyin neden davranışı korduğunu 1 cümlede yaz.{{kod}}
Refactor öncesi güvenlik ağı (karakterizasyon testi):
Bu fonksiyonun MEVCUT davranışını (doğru olsun olmasın) yakalayan testler yaz;amaç refactoring sırasında davranış değişirse yakalamak. Tipik + kenar girdilerikapsa. Beklentileri fonksiyonun şu anki çıktısına göre yaz.{{fonksiyon}}
Teknik borç kaydı (backlog) üretimi:
Aşağıdaki koku listesini bir önceliklendirme tablosuna dök: madde, etkilenenalan, değişim sıklığı (bilgim: {{...}}), risk, tahmini çaba, önerilen öncelik.Yüksek etki + düşük çaba olanları en üste koy.{{koku_listesi}}
Zayıf prompt / Güçlü prompt
Zayıf: "Bu kodu temizle ve daha iyi yap."
Güçlü: "Bu 90 satırlık fonksiyonu, dıştan davranışını ve imzasını değiştirmeden, tek sorumluluklu 3 küçük fonksiyona böl. Yan etkileri (DB yazma) mevcut sırayla koru. Testlerim var, davranış aynı kalmalı. Diff'i ver ve her bölmenin neden davranış-koruyucu olduğunu tek cümleyle açıkla. [kod]"
Güçlü sürüm; belirli tek bir dönüşüm ister, davranış ve imza kısıtını açıkça koyar ve gerekçe talep eder. "Daha iyi yap" gibi belirsiz istekler, kontrolsüz ve riskli değişiklikler doğurur.
Refactoring tipi
AI güvenilirliği
Ön koşul
Yeniden adlandırma
Yüksek
Kapsam doğru mu?
Fonksiyon bölme
Orta-yüksek
Test ağı şart
Tekrarı ortaklaştırma
Orta
Davranış farkı gizli olabilir
Algoritma/yapı değişimi
Düşük
Kapsamlı test + insan onayı
Mimari yeniden düzen
Düşük
İnsan liderliğinde, AI destek
Teknik Borcu Yönetmek, Sıfırlamak Değil
Teknik borç tümüyle kötü değildir; bazen bilinçli bir borçlanma (bir teslimatı yetiştirmek için) doğru karardır. Amaç borcu sıfırlamak değil, görünür ve yönetilebilir kılmaktır. AI, borcu tespit etmede ve önceliklendirmede hızlıdır ama "hangi borç ödenmeli, hangisi bırakılmalı" kararı iş bağlamı gerektirir: bu modül ne sıklıkta değişiyor, kaç kişiyi etkiliyor, riski ne? Bu kararı, kod tabanını ve ürünü bilen ekip verir; AI yalnızca seçenekleri netleştirir.
İpucu: Refactoring PR'ınızı, davranış değişikliği içeren PR'lardan ayrı tutun. "Bu PR sadece yeniden yapılandırma, davranış aynı" diyebilmek, incelemeyi kolaylaştırır ve bir sorun çıkarsa nedeni hızla daraltmanızı sağlar.
Sık yapılan hatalar
- Test ağı olmadan refactor etmek. Davranışın korunduğunu kanıtlayacak hiçbir şeyiniz kalmaz.
- "Tüm dosyayı temizle" demek. Büyük, kontrolsüz değişiklikler hatayı gizler ve incelenemez.
- Diff'i okumadan kabul etmek. AI "sadece yapı" derken bir mantığı kaydırmış olabilir.
- Refactoring ile davranış değişikliğini karıştırmak. İkisini aynı PR'da yapmak, kök neden takibini imkânsızlaştırır.
- Her kokuyu düzeltmeye çalışmak. Nadiren değişen çirkin kod çoğu zaman düşük önceliklidir; enerjiyi sık değişen yere ayırın.
Özetle
Refactoring'in tek kuralı davranışın sabit kalmasıdır ve bunun kanıtı testlerdir. AI, kod kokularını tespit etmede, tek adımlı dönüşümlerde ve teknik borcu önceliklendirmede güçlüdür; ama güvenlik ağını siz kurmalı, her adımdan sonra testleri çalıştırmalı ve diff'i okumalısınız. Küçük, tersine çevrilebilir adımlarla ilerleyin; refactoring'i davranış değişikliğinden ayırın; ve hangi borcun ödeneceğine iş bağlamını bilen ekip karar versin.
Uygulama görevi
Kod tabanınızdan gözünüze uzun veya karmaşık görünen bir fonksiyon seçin. Önce "güvenlik ağı" şablonuyla mevcut davranışını yakalayan testler yazdırın ve hepsinin geçtiğini görün. Sonra "tek adımlı, davranış-koruyucu dönüşüm" şablonuyla fonksiyonu tek bir yolla (ör. ikiye bölme) refactor ettirin ve testleri tekrar çalıştırın. Bir test kırılırsa nedenini bulun; hiç kırılmazsa diff'i satır satır okuyup davranışın gerçekten korunduğunu teyit edin.
Kontrol listesi
- [ ] Refactoring'in davranışı değiştirmemesi gerektiğini ve kanıtının testler olduğunu biliyorum.
- [ ] Refactor öncesi mevcut davranışı yakalayan bir güvenlik ağı kuruyorum.
- [ ] AI'dan büyük tek seferlik değil, küçük ve tek adımlı dönüşümler istiyorum.
- [ ] Her adımdan sonra testleri çalıştırıp diff'i okuyorum.
- [ ] Refactoring PR'ını davranış değişikliği PR'ından ayrı tutuyorum.
- [ ] Teknik borcu iş bağlamıyla önceliklendiriyor, körü körüne sıfırlamaya çalışmıyorum.