Son dönemde çalıştığım şirkette backend tarafında da daha fazla sorumluluk almaya başladım. Önceden ağırlıklı olarak frontend tarafında geliştirme yaparken, proje ihtiyaçları ve aldığım görevler doğrultusunda backend tarafına da daha fazla dahil oldum.

Bu süreçte kendimi backend mimarisi, yazılım tasarımı ve sürdürülebilir kod yapısı konularında daha fazla geliştirmem gerektiğini fark ettim. Bunun üzerine Amerika merkezli, online bir yazılım mimarisi eğitimi almaya başladım.

Eğitim boyunca üzerinde en çok durulan konulardan biri Big Ball of Mud kavramıydı. Derslerde bu terimi oldukça detaylı konuştuk. Hatta neredeyse tüm ders boyunca yazılım projelerinin zamanla nasıl karmaşıklaştığı, mimarisiz büyüyen sistemlerin nasıl yönetilemez hale geldiği ve bunun projeye ne gibi zararlar verdiği üzerinde duruldu.

Ben de hem bu kavramın gerçek projelerde ne kadar sık karşımıza çıktığını gördüğüm için hem de kendi yaşadığım tecrübelerle çok örtüştüğünü düşündüğüm için bu konuyla ilgili bir yazı yazmak istedim.

Big Ball of Mud Ne Demek?

Yazılım geliştirme sürecinde bazen proje ilk başta gayet düzenli başlar. Klasör yapısı nettir, kodlar anlaşılırdır, iş kuralları belirli yerlerde tutulur ve herkes neyin nerede olduğunu bilir.

Ama zaman geçtikçe işler değişir.

Yeni özellikler eklenir, acil bug fix’ler yapılır, müşteri talepleri yetiştirilmeye çalışılır, “şimdilik böyle yapalım sonra düzeltiriz” denilen yerler birikir. Bir süre sonra proje hâlâ çalışıyor olabilir ama içerideki yapı artık kontrolü zor bir hale gelir.

İşte bu duruma yazılım dünyasında Big Ball of Mud denir.

Türkçeye kabaca “büyük çamur topu” gibi çevrilebilir. Aslında çok yerinde bir benzetmedir. Çünkü projede artık her şey birbirine karışmıştır. Kodun nerede başladığı, nerede bittiği, hangi parçanın hangi sorumluluğa sahip olduğu belli değildir.

Big Ball of Mud Nasıl Görünür?

Bir projede şu tarz durumlar varsa, o proje büyük ihtimalle Big Ball of Mud yapısına doğru gitmiştir:

Controller içinde iş mantığı vardır.
Service sınıfları gereğinden fazla büyümüştür.
Aynı kod farklı yerlerde tekrar tekrar yazılmıştır.
Bir fonksiyon yüzlerce satır olmuştur.
Bir değişiklik yapıldığında alakasız başka bir yer bozulur.
Kodun nereye yazılacağı belli değildir.
Yeni gelen bir geliştirici projeyi anlamakta çok zorlanır.
“Buraya dokunma, orası hassas” cümlesi sık sık duyulur.

Bu tarz projeler genellikle dışarıdan bakıldığında çalışıyor gibi görünür. Fakat geliştirme yapmak, hata çözmek veya yeni özellik eklemek giderek zorlaşır.

Bu Terim Yazılımda Ne İçin Kullanılır?

Big Ball of Mud, tercih edilen bir mimari yaklaşım değildir. Yani kimse normalde “hadi projemizi Big Ball of Mud yapalım” demez.

Bu terim daha çok kötüleşmiş veya kontrolsüz büyümüş yazılım projelerini tarif etmek için kullanılır.

Bir geliştirici “bu proje artık Big Ball of Mud olmuş” dediğinde aslında şunu söylemek ister:

“Bu projede mimari düzen bozulmuş, sorumluluklar karışmış ve bakım yapmak riskli hale gelmiş.”

Bu yüzden Big Ball of Mud, yazılım projelerinde teknik borcun ve plansız büyümenin en net göstergelerinden biridir.

Big Ball of Mud Neden Oluşur?

Bu yapının ortaya çıkmasının birçok sebebi olabilir.

1. Aceleyle Geliştirme Yapmak

Yazılım projelerinde bazen işin hızlıca yetişmesi gerekir. Bu durumda “şimdilik böyle yapalım” denir. İlk başta bu mantıklı görünebilir. Fakat bu geçici çözümler temizlenmezse kalıcı hale gelir.

Zamanla bu geçici çözümler üst üste eklenir ve proje çamurlaşmaya başlar.

2. Mimari Planlama Eksikliği

Proje küçükken her şeyi tek bir dosyada veya basit bir yapıda tutmak sorun olmayabilir. Ancak proje büyüdükçe daha düzenli bir mimariye ihtiyaç duyar.

Bu geçiş yapılmazsa proje büyür ama kod yapısı aynı kalır. Sonuç olarak sistem karmaşıklaşır.

3. Teknik Borcun Ertelenmesi

Teknik borç, bugün hızlı ilerlemek için gelecekte ödenecek maliyettir. Refactor yapılmayan, test yazılmayan, tekrar eden kodlar temizlenmeyen projelerde teknik borç büyür.

Bir noktadan sonra artık yeni özellik eklemek bile ciddi risk haline gelir.

4. Standart Eksikliği

Ekip içinde ortak kod yazım standartları yoksa herkes kendi yöntemini kullanır. Bir geliştirici logic’i controller içine yazar, bir başkası helper’a koyar, başka biri component içinde çözer.

Bu durumda proje bir bütün olarak değil, birbirinden kopuk parçalar halinde büyür.

5. Sürekli Değişen Talepler

Müşteri veya ürün tarafı sürekli yeni isteklerle geliyorsa ve bu istekler mimariye uygun şekilde ele alınmıyorsa proje zamanla karmaşıklaşır.

Her yeni özellik eski yapının üzerine plansızca eklenirse, sistemin anlaşılması giderek zorlaşır.

Basit Bir Örnek

Bir Laravel projesinde sipariş oluşturma işlemini düşünelim.

Kötü bir yapıda controller içinde şunların tamamı bulunabilir:

public function store(Request $request)
{
    // Validasyon
    // Kullanıcı kontrolü
    // Sipariş oluşturma
    // Stok düşme
    // Ödeme işlemi
    // Fatura oluşturma
    // Mail gönderme
    // Bildirim gönderme
    // Log kaydı
}

Bu kod ilk bakışta çalışıyor olabilir. Fakat controller artık sadece request’i karşılayan bir yapı olmaktan çıkmıştır. İş mantığı, ödeme süreci, stok yönetimi, bildirim ve loglama aynı yere yığılmıştır.

Daha sağlıklı bir yapıda bu işlemler ayrı sorumluluklara bölünebilir:

OrderController
 └── OrderService
      ├── PaymentService
      ├── StockService
      ├── InvoiceService
      ├── NotificationService
      └── LogService

Bu şekilde her parçanın görevi daha net olur. Kodun okunması, test edilmesi ve değiştirilmesi kolaylaşır.

Big Ball of Mud’ın Zararları Nelerdir?

Big Ball of Mud haline gelmiş projelerde en büyük problem bakım maliyetidir.

Başta hızlı geliştirme avantaj gibi görünür. Ancak uzun vadede her değişiklik daha fazla zaman almaya başlar. Çünkü geliştirici sadece yeni özelliği yazmakla uğraşmaz; aynı zamanda mevcut yapıyı bozmamaya da çalışır.

Bu tarz projelerde sık görülen problemler şunlardır:

Yeni özellik eklemek zorlaşır.
Bug fix yaparken yeni bug oluşur.
Kod tekrarları artar.
Test yazmak zorlaşır.
Deploy süreçleri stresli hale gelir.
Yeni geliştiricilerin projeye adapte olması uzun sürer.
Proje büyüdükçe geliştirme hızı düşer.

En tehlikeli nokta ise şudur: Proje çalıştığı için problem uzun süre fark edilmeyebilir. Fakat içerideki karmaşa büyümeye devam eder.

Her Karmaşık Proje Big Ball of Mud mıdır?

Hayır.

Büyük projeler doğal olarak karmaşık olabilir. Bir ERP, CRM, e-ticaret altyapısı, ödeme sistemi vs. zaten birçok modül içerir. Buradaki mesele projenin büyük olması değil, kontrolsüz büyümesidir.

Sağlıklı bir projede karmaşıklık yönetilir. Big Ball of Mud yapısında ise karmaşıklık yönetilemez hale gelir.

Yani sorun şudur:

Proje büyük olduğu için değil, mimari olarak dağınık büyüdüğü için problem olur.

Big Ball of Mud’dan Nasıl Kaçınılır?

Bunun için her projeye çok ağır mimariler kurmak gerekmez. Küçük bir projeye gereğinden fazla Clean Architecture, DDD veya karmaşık katmanlar eklemek de doğru değildir.

Önemli olan projenin ihtiyacına göre dengeli bir yapı kurmaktır.

Dikkat edilmesi gereken bazı noktalar şunlardır:

Kodun sorumluluğu net olmalıdır.
Controller, component veya model içine her şey doldurulmamalıdır.
Tekrar eden kodlar ortak yapılara taşınmalıdır.
İş mantığı mümkün olduğunca doğru katmanda tutulmalıdır.
Refactor düzenli olarak yapılmalıdır.
Ekip içinde ortak kod standartları belirlenmelidir.
Yeni özellik eklerken mevcut mimari düşünülmelidir.
Test yazılabilir bir yapı hedeflenmelidir.

Buradaki amaç mükemmel mimari kurmak değildir. Amaç, projenin zamanla sürdürülebilir kalmasını sağlamaktır.

Refactor Neden Önemli?

Refactor, çalışan kodun davranışını bozmadan iç yapısını iyileştirme işlemidir.

Big Ball of Mud haline gelmiş projelerde refactor genellikle ertelenir. Çünkü herkes kodun bir yerleri bozmasından korkar. Fakat refactor ertelendikçe problem daha da büyür.

Küçük ve düzenli refactor işlemleri uzun vadede projeyi kurtarır.

Örneğin:

Çok büyük fonksiyonları parçalamak.
Tekrar eden kodları ortak fonksiyonlara almak.
Controller içindeki iş mantığını service katmanına taşımak.
Gereksiz bağımlılıkları azaltmak.
Dosya ve klasör yapısını daha anlaşılır hale getirmek.

Bunlar küçük gibi görünür ama proje sağlığı açısından çok önemlidir.

Yaniii günün özetine gelecek olursam

Big Ball of Mud, yazılım projelerinde sık karşılaşılan ama çoğu zaman geç fark edilen bir problemdir.

Başta hızlı ilerlemek için yapılan küçük tavizler, zamanla projenin tamamını etkileyen büyük bir karmaşaya dönüşebilir. Bu yüzden yazılım geliştirirken sadece kodun çalışmasına değil, sürdürülebilir olmasına da dikkat etmek gerekir.

İyi bir proje sadece bugün çalışan proje değildir. Aynı zamanda yarın da geliştirilebilen, anlaşılabilen ve güvenle değiştirilebilen projedir.

Big Ball of Mud bize şunu hatırlatır:

Kod yazmak sadece problemi çözmek değildir. Problemi, gelecekte de yönetilebilir kalacak şekilde çözmektir.