“Çalışıyorsa karıştırma” — nedir, ilkenin özü ve riskleri

“Çalışıyorsa karıştırma” ilkesi nedir?

“Çalışıyorsa karıştırma” — geliştiricileri yeterli sebep olmadan çalışan kodu değiştirmekten uyaran ampirik bir kuraldır. İlke basit istatistiklere dayanır: hataların büyük çoğunluğu mevcut kodun değiştirilmesi sırasında ortaya çıkar.

İlke bir dogma değildir — belirsizlik koşullarında karar vermeye yardımcı olan bir buluşsal yöntemdir. Kod tabanı ne kadar karmaşık ve iç içe geçmişse, “masum” bir değişikliğin kimsenin beklemediği bir şeyi kırma olasılığı o kadar yüksektir.

Microsoft Corporation'ın bir araştırmasına (2024) göre, üretimdeki tüm kritik olayların yaklaşık %60'ı, iyi niyetle yapılan ancak gerçek yük koşullarında yeterince test edilmeyen son kod değişiklikleriyle ilgilidir.

İlkenin tarihi ve kökeni

Deyim “Bozulmamışsa tamir etme” 20. yüzyıl ortası Amerikan mühendislik kültürüne dayanır. Belgelenen en eski kullanım, ABD Senatosu Finans Komitesi'nde çalışan ve aşırı düzenlemeye karşı çıkan Bert Lance'e (1977) atfedilir.

Programlamada, ilke donanım mühendisliğinden gelmiştir; burada çalışan bir çipi yenisiyle değiştirmek öngörülemeyen sonuçlara yol açabilirdi. Yazılım bağlamında, bu ilke yazılım sistemlerinin artan karmaşıklığı ve eski kodun ortaya çıkmasıyla özellikle yaygınlaşmıştır.

Programlamada ilkenin bir de ters tarafı vardır — “çalışıyor, ama dokunmamak daha iyi” genellikle yeniden düzenlemeyi ertelemek için bir bahane haline gelir ve uzun vadede kritik teknik borç birikimine yol açar. Danışmanlık şirketi Thoughtworks'e (2023) göre, projelerin yaklaşık %40'ı değişikliklere karşı aşırı muhafazakarlık nedeniyle ciddi sorunlarla karşılaşmaktadır.

İlke ne zaman uygulanmalı

“Çalışıyorsa karıştırma” ilkesi özellikle bir hatanın maliyetinin değişikliklerin potansiyel faydasını aştığı durumlarda geçerlidir.

Testleri olmayan eski projeler

Testlerle kapsanmayan eski kodda, herhangi bir değişiklik Rus ruleti oyunudur. Bir geliştirici, değişikliğin komşu modülleri bozmadığını doğrulayamıyorsa, en iyi strateji çalışan koda dokunmamaktır. İstisna yalnızca kritik hatalar veya güvenlik gereksinimleridir.

Kritik sistemler

Kesinti süresinin kabul edilemez olduğu veya bir hatanın maliyetinin çok yüksek olduğu sistemlerde — tıbbi yazılım, aviyonik, finansal işlemler — “çalışıyorsa karıştırma” ilkesi fiili standarttır. Her değişiklik çok aşamalı onay ve testten geçer.

Sıkı teslim tarihleri

Sürüm yarınsa ve kod çalışıyorsa — mimarisini iyileştirmeye çalışmayın. Yalnızca sürüm işlevselliğini doğrudan etkileyen şeyleri değiştirin. Yeniden düzenlemeyi bir sonraki sprint'e erteleyin (ancak unutmayın).

İlkeye uymanın riskleri

“Çalışıyorsa karıştırma” ilkesini körü körüne takip etmek, sonsuz yeniden düzenlemeden daha az risk taşımaz. Başlıca tehlikeleri inceleyelim.

Teknik borç birikimi

Her geliştirici bu ilkeyi takip ederse, kod tabanı hızla eski çözümlerden, geçici çözümlerden ve optimal altı algoritmalardan oluşan bir “katmanlı pasta” haline gelir. Er ya da geç, teknik borç dayanılmaz hale gelir — herhangi bir değişiklik haftalarca analiz gerektirir.

Kaçırılan optimizasyon

Bazen riskli görünen bir değişiklik aslında performansı veya güvenliği önemli ölçüde iyileştirir. “Çalışıyorsa karıştırma” ilkesi, ölçülebilir fayda sağlayan değişiklikleri — sunucu maliyetlerini azaltmak, sayfa yüklemeyi hızlandırmak, güvenliği artırmak — engellememelidir.

Yetenek kaybı

Bir ekip kodun belirli bölümlerine yıllarca dokunmadığında, nasıl çalıştıklarını anlama yeteneğini kaybeder. Anahtar geliştirici gider — ve kod destek imkanı olmayan eski kod haline gelir. İlke, projenin uzun vadeli bakımı göz önünde bulundurularak uygulanmalıdır.

Altın orta: fanatizm olmadan yeniden düzenleme

En iyi strateji ilkeyi körü körüne takip etmek değil, bağlamı göz önünde bulundurarak bilinçli bir şekilde uygulamaktır. Yeniden düzenleme gereklidir, ancak güvenli olmalıdır.

İzci kuralı

Programlamada izci kuralı: “Kodu bulduğundan daha temiz bırak.” Bir geliştirici bir modülde değişiklik yapıyorsa, yapısını iyileştirmeli, ancak makul sınırlar içinde. Her şeyi sıfırdan yazmak yerine, en azından okunamayan değişkenleri yeniden adlandırın ve yorumlar ekleyin.

Test koruması altında yeniden düzenleme

Testler, “çalışıyorsa karıştırma” ilkesini güvenli bir şekilde uygulamanın tek yoludur. Kod testlerle kapsanmışsa, herhangi bir yeniden düzenleme öngörülebilir hale gelir: geliştirici kodu değiştirir, testleri çalıştırır ve bir şeyin bozulup bozulmadığını görür. Test yoksa — dokunma. Test varsa — güvenle yeniden düzenle.

// Örnek: test kapsamı altında güvenli yeniden düzenleme
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Eski ama çalışan kod
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Gerilemeye karşı koruyan test
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Bu örnek doğru yaklaşımı gösteriyor: önce test, sonra yeniden düzenleme. Test geçerse, değişiklik güvenlidir. “Çalışıyorsa karıştırma” ilkesi “testler altında çalışıyorsa cesurca yeniden düzenle” şeklinde dönüşür.

Pratikten gerçek örnekler

“Çalışıyorsa karıştırma” ilkesinin hem kurtarıcı hem de yıkıcı olduğu gerçek senaryoları inceleyelim.

Kurtarıcı durum: Y2K benzeri sorun

Bir geliştirici, tarih işleme kodunun YYYY yerine GG/AA/YY biçimini kullandığını keşfetti. Kod 2000'den 2025'e kadar doğru çalışıyordu. “Düzeltme” isteğine rağmen, kodu olduğu gibi bıraktı ve sadece bir yorum ekledi. 2026'da şirket sistemi güncelledi ve yeni çözüm yüzyılları doğru şekilde işliyordu. Erken bir değişiklik çalışan mantığı bozardı.

Yıkıcı durum: “İyileştirme” nedeniyle veri kaybı

Bir mühendis, eski ama çalışan veri alma kodunu modern bir kütüphaneyle değiştirerek “iyileştirmeye” karar verdi. Eski kütüphanenin belgelenmemiş belirli bir uç durumu işlediğini hesaba katmadı. Sürümden sonra — büyük çaplı veri kaybı. “Çalışıyorsa karıştırma” ilkesi ihlal edildi ve hatanın maliyeti ekibin kurtarma çalışması için iki haftası oldu.