18.2 Modularitas: Membuat Perubahan Terkendali

Bayangkan Anda bekerja di sebuah perusahaan yang memiliki satu aplikasi raksasa. Semua fitur ada di dalam satu codebase yang sama. Logika bisnis, akses database, tampilan pengguna, dan aturan validasi semuanya bercampur. Ketika tim marketing minta tambah satu kolom di halaman produk, Anda harus membuka file yang sama dengan yang digunakan tim finance untuk mengelola laporan keuangan. Satu perubahan kecil bisa mengakibatkan efek samping yang tidak terduga.

Perbedaan antara kedua pendekatan ini dapat dilihat dalam diagram berikut.

flowchart TD subgraph Monolitik A1[AI] --> B1[Kode Monolitik] B1 --> C1[Fitur Produk] B1 --> C2[Fitur Pembayaran] B1 --> C3[Fitur Pengguna] C1 -.->|efek samping| C2 C2 -.->|efek samping| C3 end subgraph Modular A2[AI] --> M1[Modul Produk] A2 --> M2[Modul Pembayaran] A2 --> M3[Modul Pengguna] M1 --> D1[Antarmuka] M2 --> D2[Antarmuka] M3 --> D3[Antarmuka] D1 -.->|terisolasi| D2 D2 -.->|terisolasi| D3 end

Sekarang bayangkan aplikasi yang sama dipecah menjadi modul-modul yang lebih kecil. Modul produk menangani data produk. Modul pembayaran menangani transaksi. Modul pengguna menangani akun dan hak akses. Setiap modul punya tanggung jawab yang jelas, data yang dimiliki, dan antarmuka yang disepakati. Tim marketing bisa mengubah modul produk tanpa khawatir merusak laporan keuangan.

Inilah yang dimaksud dengan modularitas. Bukan sekadar soal kode yang rapi atau struktur folder yang indah. Modularitas adalah cara membuat sistem memiliki batas-batas yang tegas antar bagian. Setiap modul adalah sebuah domain dengan tanggung jawab dan data yang jelas. Modul lain tidak bisa seenaknya mengakses isi dalam modul tersebut. Mereka harus melalui antarmuka yang sudah disepakati.

Mengapa ini penting di era AI? Karena AI bekerja dengan memahami konteks. Semakin sempit dan jelas konteks yang diberikan, semakin akurat output yang dihasilkan. Ketika Anda meminta AI untuk mengubah sesuatu di modul produk, Anda bisa memberikan konteks yang terbatas: hanya file-file di dalam modul tersebut, hanya aturan bisnis yang relevan, hanya data yang dimiliki modul itu. AI tidak perlu membaca seluruh aplikasi untuk memahami satu perubahan.

Modularitas juga membuat verifikasi lebih mudah. Jika AI mengubah kode di modul produk, Anda cukup menjalankan tes yang terkait dengan modul tersebut. Anda tidak perlu menjalankan seluruh rangkaian tes aplikasi. Jika ada yang rusak, Anda tahu persis di mana masalahnya. Ini membuat kepercayaan terhadap hasil kerja AI meningkat.

Yang sering luput dari perhatian adalah ownership. Setiap modul harus dimiliki oleh tim atau orang yang bertanggung jawab. Ketika AI menghasilkan perubahan di modul tertentu, ada manusia yang paham betul isi modul itu dan bisa memverifikasi hasilnya. Tanpa ownership yang jelas, perubahan yang dihasilkan AI bisa mengambang tanpa ada yang berani mengesahkan.

Dalam praktiknya, modularitas dimulai dari cara Anda memikirkan sistem. Bukan dari struktur kode, tetapi dari pertanyaan: bagian mana yang punya tanggung jawab berbeda? Data mana yang harus dimiliki oleh bagian mana? Siapa yang paling paham dengan bagian ini? Jawaban atas pertanyaan-pertanyaan ini akan membentuk batas-batas alami yang kemudian bisa diwujudkan dalam service, package, atau modul.

Modularitas bukan proyek satu kali. Ini adalah disiplin yang harus dijaga setiap hari. Setiap kali ada fitur baru, tanyakan: modul mana yang paling tepat menampung perubahan ini? Apakah perubahan ini melanggar batas modul yang sudah ada? Apakah antarmuka antar modul masih jelas? Dengan disiplin ini, sistem tetap mudah dipahami dan dimodifikasi, baik oleh manusia maupun AI.

Setelah modularitas terbentuk, langkah selanjutnya adalah memastikan setiap antarmuka antar modul memiliki perjanjian yang jelas. Pintu masuknya ada di subbab berikutnya: API dan contract sebagai perjanjian antar bagian sistem.