Ketika Feature Flag Menjadi Utang Teknis

Anda mengirimkan fitur baru menggunakan feature flag. Berhasil. Pengguna mengadopsinya. Flag tetap aktif untuk semua orang. Berbulan-bulan berlalu. Sekarang flag itu masih ada di kode, bersebelahan dengan tiga flag lain dari kuartal lalu, dua dari enam bulan lalu, dan satu yang tidak ada yang ingat apa yang dikendalikannya.

Ini bukan hal yang aneh. Banyak tim mulai menggunakan feature flag dengan niat baik: rilis yang lebih aman, peluncuran bertahap, kill switch untuk keadaan darurat. Namun flag yang tidak pernah dihapus perlahan berubah menjadi masalah yang berbeda. Mereka berhenti menjadi alat kontrol rilis dan mulai menjadi utang teknis yang memperlambat semua orang.

Biaya Nyata dari Flag yang Terbengkalai

Setiap flag yang Anda tinggalkan di kode menambahkan titik keputusan. Ketika seorang pengembang membaca sebuah fungsi, mereka harus bertanya: apakah cabang ini masih digunakan? Apakah yang itu aman untuk dihapus? Bisakah saya menghapus jalur kode lama, atau masih ada pengguna yang mengaksesnya?

Dengan satu atau dua flag, ini masih bisa dikelola. Dengan puluhan flag, membaca kode menjadi permainan tebak-tebakan. Anda berakhir dengan blok if-else di mana tidak ada yang yakin jalur mana yang masih aktif. Kode yang tadinya sederhana berubah menjadi labirin logika kondisional yang semua orang takut untuk menyentuhnya.

Ada juga biaya runtime. Setiap kali aplikasi berjalan, ia mengevaluasi setiap flag. Pemeriksaan satu flag itu murah. Ratusan pemeriksaan flag di jalur kode panas (hot code paths) akan terakumulasi. Siklus CPU yang dihabiskan untuk mengevaluasi flag yang selalu mengembalikan nilai yang sama adalah sia-sia. Memori yang digunakan untuk menyimpan konfigurasi flag yang tidak pernah berubah juga sia-sia. Seiring waktu, overhead ini menjadi terukur, terutama di layanan dengan lalu lintas tinggi.

Setiap Flag Membutuhkan Siklus Hidup

Solusinya bukan berhenti menggunakan feature flag. Solusinya adalah memperlakukan setiap flag sebagai sesuatu yang pada akhirnya harus dihapus. Sebuah feature flag harus memiliki siklus hidup yang jelas sejak dibuat:

Diagram berikut menunjukkan siklus hidup yang dimaksud dari sebuah feature flag dan apa yang terjadi ketika penghapusan dilewati:

flowchart TD A[Flag Dibuat] --> B[Pengujian Internal] B --> C[Peluncuran Bertahap] C --> D[Peluncuran Penuh] D --> E[Fitur Stabil] E --> F[Flag Dihapus] E -.-> G[Flag Tidak Dihapus] G --> H[Utang Teknis Menumpuk] H --> I[Kompleksitas Kode Meningkat] H --> J[Overhead Runtime] H --> K[Kebingungan Pengembang] F --> L[Kode Bersih]
  1. Flag ditambahkan ketika pekerjaan pada fitur baru dimulai.
  2. Flag diaktifkan untuk pengujian internal.
  3. Flag diluncurkan secara bertahap ke sebagian pengguna.
  4. Flag diaktifkan untuk semua pengguna.
  5. Fitur diverifikasi stabil di produksi.
  6. Flag dihapus.

Langkah keenam adalah yang paling sering dilewati tim. Fiturnya berfungsi. Semua orang menggunakannya. Flag masih aktif, jadi mengapa repot-repot menghapusnya? Karena setiap hari flag itu bertahan, ia menambah gesekan. Kode menjadi lebih sulit dibaca. Perubahan berikutnya memakan waktu lebih lama. Risiko memperkenalkan bug meningkat karena tidak ada yang yakin jalur kode mana yang benar-benar aktif.

Kapan Harus Menghapus Flag

Waktu yang tepat untuk menghapus flag adalah segera setelah fitur yang dikendalikannya stabil dan diluncurkan sepenuhnya. Beberapa tim menetapkan aturan keras: hapus flag dalam satu atau dua sprint setelah fitur mencapai 100% pengguna. Yang lain menggunakan pengingat otomatis yang menandai kunci konfigurasi yang telah aktif melebihi periode tertentu.

Menghapus flag bukan hanya tentang menghapus pemeriksaan kondisional. Anda juga perlu membersihkan kode lama yang dilindungi oleh flag tersebut. Jika fitur baru menggantikan yang lama, hapus seluruh jalur kode lama. Jangan tinggalkan kode mati. Kode mati tidak berbahaya? Justru sebaliknya. Itu membingungkan pengembang, membuang waktu build, dan dapat menyebabkan bug halus jika seseorang kemudian memodifikasinya dengan mengira masih digunakan.

Di sisi konfigurasi, hapus juga flag dari sistem manajemen flag Anda. Flag yang dihapus dari kode tetapi masih terlihat di dasbor atau file konfigurasi akan menyebabkan kebingungan. Seseorang pada akhirnya akan bertanya apakah flag itu masih diperlukan, dan tidak ada yang akan memiliki jawaban yang jelas.

Jadikan Penghapusan sebagai Bagian dari Proses

Cara paling efektif untuk mencegah flag menumpuk adalah dengan mewajibkan rencana penghapusan saat flag dibuat. Ketika seorang pengembang membuka pull request yang menambahkan feature flag baru, PR tersebut harus menyertakan catatan tentang kapan dan bagaimana flag akan dihapus. Ini bisa berupa komentar di kode, tugas di alat manajemen proyek Anda, atau tanggal kedaluwarsa otomatis di sistem flag itu sendiri.

Beberapa tim melangkah lebih jauh dengan memberlakukan kedaluwarsa flag secara terprogram. Sistem flag menolak flag baru apa pun yang tidak menyertakan tanggal kedaluwarsa wajib. Ketika tanggalnya lewat, sistem mengirimkan notifikasi atau bahkan secara otomatis menonaktifkan flag. Ini memaksa tim untuk menghapus flag atau secara eksplisit memperpanjang masa pakainya dengan justifikasi.

Ini mungkin terdengar seperti beban berlebih untuk tim kecil yang mengirimkan satu fitur per bulan. Namun polanya berskala. Begitu Anda memiliki beberapa tim yang mengirimkan banyak fitur secara paralel, manajemen flag manual menjadi tidak berkelanjutan. Disiplin yang Anda bangun sejak awal akan menyelamatkan Anda dari pembersihan yang menyakitkan di kemudian hari.

Daftar Periksa Praktis untuk Pembersihan Flag

Jika Anda ingin mulai membersihkan flag hari ini, berikut adalah proses sederhana:

  • Identifikasi semua flag yang saat ini ada di basis kode dan sistem konfigurasi Anda.
  • Untuk setiap flag, tentukan apakah fitur yang dikendalikannya sudah diluncurkan sepenuhnya dan stabil.
  • Jika fitur sudah stabil, hapus flag dari kode dan hapus jalur kode lama.
  • Hapus flag dari sistem konfigurasi atau manajemen flag Anda.
  • Perbarui dokumentasi atau runbook apa pun yang merujuk pada flag tersebut.
  • Untuk flag baru apa pun, tambahkan rencana penghapusan di pull request yang memperkenalkannya.

Ini bukan latihan satu kali. Jadikan ini praktik rutin. Beberapa tim mendedikasikan satu sprint per kuartal untuk pembersihan flag. Yang lain menambahkannya ke definisi selesai (definition of done) untuk setiap fitur. Temukan ritme yang cocok untuk tim Anda dan patuhi.

Intinya

Feature flag adalah alat yang ampuh untuk mengontrol rilis dan mengurangi risiko. Namun mereka tidak gratis. Setiap flag yang Anda pertahankan melebihi masa pakainya menambah kompleksitas, memperlambat pengembangan, dan meningkatkan kemungkinan kesalahan. Tujuannya bukan untuk menghindari flag. Tujuannya adalah menggunakannya dengan disiplin dan menghapusnya ketika telah memenuhi tujuannya.

Jika Anda membiarkan flag menumpuk, mereka berhenti menjadi mekanisme kontrol rilis dan menjadi beban yang dibawa tim Anda setiap hari. Bersihkan mereka. Diri Anda di masa depan, dan pengembang yang harus membaca kode Anda bulan depan, akan berterima kasih.