Big Ball of Mud: Sistem yang Jalan Terus… Sampai Tidak Ada yang Berani Menyentuhnya

Sebagian besar sistem tidak rusak karena satu bug besar. Mereka rusak pelan-pelan karena terlalu sering “berhasil”. Fitur nambah. User nambah. Revenue jalan. Semua terlihat baik-baik saja — sampai suatu hari tidak ada satu pun orang di tim yang benar-benar berani menyentuh bagian tertentu dari codebase.

Kalau ada area yang selalu dihindari saat refactor, selalu bikin deg-degan saat deploy, dan selalu dijawab dengan, “Jangan sentuh dulu deh,” kemungkinan besar kamu sedang duduk di atas Big Ball of Mud.

Istilah ini menggambarkan sistem yang tumbuh organik tanpa boundary yang jelas. Bukan karena timnya bodoh. Justru sering karena timnya terlalu fokus deliver. Setiap keputusan kecil masuk akal pada masanya. Tapi akumulasi keputusan pragmatis itu, tanpa disiplin arsitektur, berubah jadi lumpur.

Image Source

Visualisasi dependency graph: banyak modul saling terkait, tidak ada boundary modular yang jelas.

Masalahnya Bukan Kode Jelek — Tapi Tidak Ada Batas

Big Ball of Mud bukan soal indentation berantakan atau naming variabel aneh. Itu kosmetik. Masalahnya ada di coupling dan tidak adanya separation of concerns.

Bayangkan satu fungsi seperti ini:

function processOrder(order) {
  if (!order.customerId) throw new Error('Invalid customer');
  
  const inventory = database.query('SELECT * FROM inventory');
  const item = inventory.find(i => i.id === order.itemId);
  if (!item || item.quantity < order.quantity) {
    throw new Error('Out of stock');
  }
  
  const paymentResult = paymentService.charge(order.total);
  
  database.update('orders', order);
  database.update('inventory', {
    id: order.itemId,
    quantity: item.quantity - order.quantity
  });
  
  emailService.send(order.customerId, 'Order processed');
}

Kode ini jalan. Mungkin sudah jalan 3 tahun.

Tapi coba jawab ini: kalau mau ganti payment gateway, kamu harus masuk ke fungsi yang sama dengan logic inventory dan database update. Mau unit test validasi? Nggak bisa tanpa nyentuh database call. Mau ubah notifikasi? Risiko efek sampingnya ke mana-mana.

Di sinilah lumpur mulai terasa. Semua hal tahu terlalu banyak tentang hal lain.

Sekarang bandingkan dengan pendekatan yang punya boundary jelas:

class OrderProcessor {
  constructor(validator, inventoryService, paymentService, notificationService) {
    this.validator = validator;
    this.inventory = inventoryService;
    this.payment = paymentService;
    this.notification = notificationService;
  }
  
  async process(order) {
    await this.validator.validate(order);
    await this.inventory.reserve(order.itemId, order.quantity);
    await this.payment.charge(order.customerId, order.total);
    await this.persistOrder(order);
    await this.notification.sendConfirmation(order.customerId);
  }
}

Ini bukan soal lebih "cantik". Ini soal tiap komponen punya tanggung jawab yang jelas. Mau swap payment? Tinggal ganti implementasi paymentService. Mau test validasi? Mock dependency lain. Boundary membuat perubahan jadi lokal, bukan global.

Source

Contoh sebelum-sesudah: satu fungsi monolit berantakan vs versi yang sudah di-encapsulate ke service kelas terpisah.

Rewrite Total? Biasanya Itu Ego, Bukan Strategi

Ini mungkin terdengar keras: banyak tim memilih rewrite bukan karena sistemnya tidak bisa diselamatkan, tapi karena mereka bosan dengan stack lama dan ingin mulai dari nol.

Rewrite terdengar heroik. Realitanya sering jadi proyek setahun yang akhirnya menghasilkan sistem baru dengan pola lama. Lumpur baru. Framework berbeda.

Masalah terbesar rewrite adalah ilusi kontrol. Sistem lama sudah mengandung ratusan edge case yang mungkin tidak terdokumentasi tapi sudah teruji oleh waktu. Rewrite menghapus itu semua — lalu kamu harus menemukannya kembali dengan cara yang menyakitkan.

Pendekatan yang lebih realistis adalah bergerak inkremental. Bungkus sistem lama, bangun modul baru dengan boundary yang tegas, lalu alihkan traffic sedikit demi sedikit. Bukan dramatis, tapi jauh lebih aman.

Dan sebelum refactor apapun, bangun dulu safety net. Refactoring tanpa automated test itu seperti operasi tanpa anestesi. Mungkin berhasil. Tapi kenapa ambil risiko itu kalau tidak perlu?

Big Ball of Mud Itu Masalah Budaya

Ini bagian yang sering tidak nyaman.

Big Ball of Mud jarang murni kesalahan teknis. Ia tumbuh karena budaya:

Deadline selalu menang atas kualitas. Code review jadi formalitas. Tidak ada waktu eksplisit untuk cleanup. Knowledge terkunci di satu atau dua orang.

Kalau hanya satu engineer yang “ngerti sistemnya”, itu bukan keunggulan. Itu single point of failure.

Dan kalau setiap PR hanya dinilai dari “jalan atau tidak”, tanpa diskusi soal boundary dan coupling, maka lumpur akan terus menebal.

Arsitektur yang baik bukan hasil satu meeting design yang panjang. Ia terbentuk dari ratusan keputusan kecil: memecah fungsi yang terlalu panjang, menolak dependency yang tidak perlu, menambahkan test sebelum refactor, mendokumentasikan keputusan penting.

Kecil. Konsisten. Setiap hari.

Pertanyaan yang Perlu Dijawab Jujur

Apakah ada bagian dari codebase kamu yang tidak ada yang berani sentuh?

Bukan karena kompleks secara algoritma. Tapi karena tidak ada yang tahu apa yang akan rusak kalau disentuh.

Kalau jawabannya iya, itu bukan sekadar legacy system. Itu Big Ball of Mud yang sedang tumbuh.

Dan keluar dari situ bukan soal menunggu momentum besar untuk rewrite. Tapi soal memutuskan, mulai hari ini, setiap perubahan kecil akan membuat sistem sedikit lebih bisa dipahami daripada kemarin.

Tags:

Pengetahuan