Yanlış soyutlama: yazılım mühendisliğinde tekrarın neden çoğu zaman daha güvenli olduğu

Yazılım ekiplerinde herkesin bildiği bir cümle var: « DRY: Don't Repeat Yourself » — kendini tekrarlama. Bu yıllarca yazılım kalitesinin temel kuralı olarak öğretildi. Sandi Metz, 2016'da yayımladığı sade bir blog yazısında bu kuralın yanlış uygulandığını söyledi: yanlış soyutlama, tekrardan çok daha pahalıdır. Bu hafta yazı yeniden Hacker News'in en üst sırasına yükseldi ve binlerce yorum aldı.

Metz, OO Design ve Ruby topluluğunun en bilinen yazarlarından biri; « Practical Object-Oriented Design in Ruby » kitabı yazılım derslerinde standart materyal. The Wrong Abstraction yazısı yalnızca dokuz paragraflık olmasına rağmen, neden bu kadar dayanıklı olduğunu anlamak öğreticidir.

Metz'in tezi sade: Kod tabanında benzer kalıpları gördüğünüzde, hemen ortak bir soyutlama çıkarmak — bir helper fonksiyon, bir abstract sınıf, bir generic interface — caziptir. Ama bu erken karar, kalıpların gelecekte nasıl ayrışacağını henüz bilmediğiniz için riskli. Yıllar geçtikçe, soyutlama her yeni kullanım için biraz daha bükülür, parametreler eklenir, koşullu mantık genişler — soyutlama, başlangıçta çözmek istediği problemden çok daha karmaşık hale gelir.

Metz'in deyimiyle: « Tekrarlanan kod ucuzdur. Yanlış soyutlamayı geri almak çok pahalıdır. » Çünkü bir kez ekip yanlış soyutlama etrafında inşa ettiyse, geri almak için tüm kullanım yerlerini ayıklamak, doğru ayrımı bulmak ve kodu yeniden yapılandırmak gerekir. Bu, basit kopyalamaktan kat kat zor.

Metz, mühendislerin tekrarın korkutucu göründüğünü itiraf ediyor: « Üç yerde aynı 20 satırı görünce, kafanızdaki sesin 'bunu birleştir' demesi normal. Sezilerinize karşı koymak, mühendislik tecrübesinin sertleştirdiği refleksten — DRY refleksinden — vazgeçmek zor. » Ancak Metz'in önerdiği yaklaşım: erken birleştirmek yerine, kalıbın üç-dört kez tekrarlanmasını bekleyin. O zamana kadar, hangi parçaların gerçek anlamda ortak, hangilerinin bağlama özgü olduğunu görebilirsiniz.

Çağdaş yazılım uygulamalarında bu, microservice-ve-API tasarımı çağında daha da kritik. Her yeni ortak kütüphane, ekipler arasında bir bağımlılık yaratır; bu bağımlılık zamanla teknoloji borcunun bir bileşeni olur. Wikipedia editörü ve eski Google mühendisi Hyrum Wright, « Hyrum'un Yasası » olarak bilinen prensibi formüle etti: « Yeterli sayıda kullanıcısı olan bir API'nın, sözleşmesinde belirttiği davranışlardan başka, bağımlı olunan tüm davranışları da sözleşmenin parçası haline gelir. » Bu, yanlış soyutlamanın gerçek dünya maliyetinin neden bu kadar yüksek olduğunu açıklar.

2025-2026'da Metz'in yazısı yeniden popülerleşti çünkü yapay zeka destekli kod üretim araçları — GitHub Copilot, Claude Code, Cursor — kalıp tanıma ve soyutlama önerisi konusunda aşırı agresif olabiliyor. Hacker News'in tartışmasında bir kullanıcı şöyle yazdı: « Copilot bana 'bu üç fonksiyonu DRY edebiliriz' diye öneriyor; üç fonksiyon hâlâ farklı domainlerde çalışıyor olabilir. Erken birleştirme, AI çağında daha çok yapılan bir hata. »

Metz'in karşı duruşu: Soyutlama, kalıp tanımanın ürünü değil, ayrımları anlamanın ürünüdür. « İki şeyin benzer görünmesi, soyutlanması gerektiği anlamına gelmez. Önce farklı oldukları boyutları haritalandırın; sonra eğer 'tüm farklılıklar gelecekte sabit kalacak' diyebiliyorsanız soyutlayın. » Bu cümle, son on yılın en alıntı yapılan yazılım mühendisliği fikirlerinden biri.

Uzun vadeli karşılaştırma yapıldığında, yanlış soyutlamanın geri alınmasının « teknoloji borcunun yarısı » olduğunu görmek mümkün. Stripe'ın eski baş mühendislerinden Patrick Mackenzie, 2024'te yazdığı bir blog yazısında benzer noktaya değindi: « Stripe'ın ilk yıllarındaki en pahalı teknik kararlarımız, çok erken yapılan ortak soyutlamalardı. Geri sökmek için her birinin ortalama altı ay sürdü. »

Metz'in yazısının dayanıklılığının asıl sebebi, dilden ve teknolojiden bağımsız olması. C++, Java, Python, Rust veya TypeScript fark etmez; Ruby ya da Go fark etmez. Yanlış soyutlama, kodlama dilinden değil, mühendislik kararının kendisinden kaynaklanan bir problem. Bu yüzden 2016'da yayımlanan yazı, 2026'da hâlâ ilk kez okuyan bir mühendis için aynı taze faydayı taşıyor. Önemli bir not: Metz, ne « DRY her zaman yanlıştır » ne de « tekrar her zaman doğrudur » diyor — söylediği, soyutlama kararının verdiği gerçek maliyetin, çoğu mühendisin tahmin ettiğinden çok daha yüksek olduğu.