Cerrahinin en karanlık, en trajik ama aynı zamanda en hayat kurtarıcı müdahalelerinden biri amputasyondur.

Ağır bir diyabetik ayak yarası, kontrolsüz bir enfeksiyon ya da ezilme travması sonucu kan dolaşımı durduğunda; doku yavaş yavaş oksijensiz kalır ve hücreler ölmeye başlar. Tıpta buna nekroz, halk arasında ise kangren denir. Kangrenli bir bacak artık bir insan uzvu değildir; tüm vücuda zehir (toksin ve bakteri) pompalayan ölümcül bir fabrikadır.

Dünyadaki hiçbir cerrah bir hastanın bacağını keyifle kesmez. Her hekim önce dokuyu kurtarmayı, antibiyotikle enfeksiyonu kurutmayı, damarı açıp kan akışını geri getirmeyi dener. Ama öyle bir eşik vardır ki; o çizgiyi geçtiğinizde bacağı kurtarmaya çalışmak, hastayı mezara göndermekle eşdeğerdir. Zehir kana karışır (sepsis), böbrekler iflas eder, kalp durur.

O an cerrah neşteri ve kemik testeresini eline alır. Bacağı kesip atar.

Bu bir başarısızlık değildir. Bu, hastanın yaşaması için ödenen acımasız ama zorunlu bir bedeldir: Bütünün yaşaması için parçayı feda etmek.

Peki, yazılım mühendisliği masasına oturduğumuzda ne yapıyoruz?

Kod Fetişizmi ve Bitmeyen "Refactoring" Masalı

Yazılımcılar olarak kodlarımıza karşı hastalıklı, romantik bir bağ geliştiririz. Bir zamanlar şirketimizin ilk MVP'sini sırtlamış, gece yarıları kahve eşliğinde bin bir emekle yazılmış o 10 bin satırlık monolitik modül; bizim gözümüzde bir başyapıttır.

Ama zaman geçmiştir. Şirket büyümüş, gereksinimler değişmiş, teknolojiler evrilmiştir. O eski kod artık sistemin en karanlık köşesinde kokuşmaya başlamıştır:

İç içe geçmiş 15 katlı if-else blokları,
Global değişkenlerin havada uçuştuğu fonksiyonlar,
Dokümantasyonu olmayan, testleri çalışmayan, kimsenin içine girmeye cesaret edemediği spagetti yapılar...

Sisteme her yeni özellik eklenmeye çalışıldığında o modül patlar. Bir yeri düzeltirsiniz, bambaşka üç yer çöker. Veritabanını kilitler, belleği sömürür, sprint'leri felç eder.

Ve ekibin kıdemli mühendisleri toplantıda aynı tanıdık cümleyi kurar:
"Bunu azar azar refactor edeceğiz. Her sprint'te birkaç dosyasını temizleyip 'Clean Code' standartlarına getireceğiz."

İşte bu, kangren olmuş ve çürümeye yüz tutmuş bir bacağa sargı bezi sarıp, "Her gün biraz krem sürersek zamanla iyileşir" demekle aynı şeydir.

O kod artık iyileşemez. O kod artık doku nekrozuna uğramıştır. İçine kattığınız her yeni temiz fonksiyon, o çürük çorbanın içinde anında kirlenir ve çürür. Siz onu kurtarmaya çalıştıkça, şirketin mühendislik enerjisi ve motivasyonu sepsise girer.

Batık Maliyetin (Sunk Cost) Kanlı Prangası

Peki neden kesip atamıyoruz? Neden o modülü tamamen çöpe gönderip sıfırdan inşa etme cesaretini gösteremiyoruz?

Çünkü insan beyni Batık Maliyet Yanılsaması (Sunk Cost Fallacy) ile sakatlanmıştır.

Yöneticinin kafasında tek bir hesap döner: "Biz o modüle iki yıl önce 100 bin dolar harcadık, üç mühendisimiz altı ay boyunca gece gündüz çalıştı. Şimdi nasıl çöpe atarız?"

Bir cerrahın, "Ama bu bacak 40 yıldır hastayı taşıyordu, üzerinde ne kadar çok emek var, şimdi nasıl kesip atayım?" demesi ne kadar absürtse; bir yazılım yöneticisinin veya mimarın geçmişte harcanan zamana sığınarak çürümüş kodu sistemde tutması da o kadar trajikomiktir.

Geçmişte harcanan zaman gitmiştir. O para ödenmiştir. Geleceği belirleyen tek şey şudur: Bu kod parçası bugün sisteme değer mi katıyor, yoksa sistemi zehirliyor mu?

Eğer bir modülü ayakta tutmak için harcadığınız bakım maliyeti (maintenance cost) ve yarattığı krizler, onu sıfırdan yazmanın maliyetini aşmışsa; orada mühendislik bitmiş, sadece duygusal inat başlamış demektir.

Ne Zaman Refactoring, Ne Zaman Amputasyon?

Bir sistemin hasta yatağında refactoring mi yoksa amputasyon mu gerektirdiğini nasıl anlarsınız? Deneyimlerim bana şu üç semptomun cerrahi bir gösterge olduğunu öğretti:

Korku Eşiği: Eğer ekibinizdeki mühendisler o modüldeki bir dosyayı değiştirmekten korkuyor, "Aman oraya dokunmayalım, ne olacağı belli olmaz" diyorsa; o kod artık canlı değildir, zombidir.
Test Edilemezlik: Kodun bağımlılıkları o kadar birbirine dolanmıştır ki, tek bir birim testi (unit test) yazabilmek için 40 farklı servisi ayağa kaldırmanız gerekiyordur.
Değişim Maliyetinin Orantısızlığı: İki saatlik basit bir arayüz değişikliği, o modülün içindeki karmaşık bağımlılıklar yüzünden iki haftalık bir regresyon testine ve üç ayrı prod patlamasına yol açıyorsa.

Bu üç semptom bir aradaysa, elinizdeki kremleri ve pansuman bezlerini yere bırakın. Refactoring masalı sona ermiştir.

Amputasyon Bir Sanattır

Bir uzvu kesmek, kör bir baltayla rastgele vurmak demek değildir. Cerrah damarları bağlar, sinir uçlarını özenle kapatır, temiz dokuyu korur ve protez takılabilecek steril bir güdük bırakır.

Yazılımda da bir modülü ampute etmek; git rm -rf yapıp kaçmak değildir.
Önce sınırları net bir arayüz (Interface / API Gateway) çizersiniz. Eski modülün arkasında sessizce yepyeni, sade ve modern bir servis inşa edersiniz. Trafiği adım adım yeni servise yönlendirir (Strangler Fig Pattern), eski kodun bağlantılarını tek tek ve soğukkanlılıkla kesersiniz.

Ve son bağlantı koptuğunda, o eski 10 bin satırlık kamburu tek bir commit ile depodan silip atarsınız:
feat: remove legacy billing module. Rest in peace.

O gün terminalinizde 10 bin satırın kırmızıyla silindiğini gördüğünüzde hissedeceğiniz hafiflik; kangrenli bacağından kurtulup yoğun bakımdan sağ salim çıkan bir hastanın aldığı ilk derin nefes gibidir.

Bazen en büyük mühendislik, kod yazmak değil; doğru zamanda, doğru parçayı gözünü kırpmadan kesip atabilme cesaretidir.

refactoring

Refactoring mi, Amputasyon mu? Ne Zaman Yüzleşip Kesip Atmalıyız?