Saat True/False Sederhana Tidak Cukup: Menempatkan Feature Flag di Kode Anda

Anda telah membangun fitur baru. Kode berhasil dikompilasi, pengujian lulus, dan Anda siap untuk merilis. Namun, Anda tidak ingin mengaktifkannya untuk semua orang sekaligus. Mungkin Anda ingin penguji internal terlebih dahulu. Mungkin hanya pengguna di Asia. Atau mungkin hanya 10 persen dari traffic.

Di sinilah feature flag berperan. Mereka memungkinkan Anda memisahkan deployment dari rilis: Anda dapat menempatkan kode baru ke production tanpa membuatnya terlihat oleh semua orang. Tapi bagaimana tepatnya Anda menempatkan flag ini di kode tanpa mengubahnya menjadi kekacauan kondisi yang rumit?

Flag Paling Sederhana: Saklar Boolean

Pada intinya, feature flag hanyalah sebuah cabang kondisional. Jika flag aktif, jalankan kode baru. Jika tidak aktif, jalankan kode lama. Bentuk paling dasarnya terlihat seperti ini:

if fiturXEnabled:
    show_new_feature()
else:
    show_old_feature()

Di sini, fiturXEnabled adalah variabel boolean. Set ke True, dan pengguna melihat fitur baru. Set ke False, dan mereka melihat yang lama. Sederhana.

Tapi ada satu kendala: nilai flag harus ditentukan sebelum kode dijalankan. Jika Anda ingin mengubahnya tanpa melakukan redeploy, Anda perlu membaca nilai dari luar kode itu sendiri. Itu bisa berupa file konfigurasi, variabel lingkungan, atau layanan jarak jauh. Kami akan membahas kendali jarak jauh flag nanti, tapi untuk saat ini, mari fokus pada kapan flag boolean sederhana sudah cukup.

Flag boolean bekerja dengan baik ketika fitur Anda kecil dan Anda hanya membutuhkan dua status: aktif atau nonaktif. Misalnya, bayangkan tombol "cetak laporan" yang sebelumnya dibatasi untuk admin. Sekarang Anda ingin membukanya untuk semua pengguna. Anda menambahkan flag bernama printReportForAllUsers. Ketika True, tombol muncul untuk semua orang. Ketika False, hanya admin yang melihatnya. Selesai.

Ketika Sederhana Tidak Cukup: Conditional Flag

Terkadang Anda membutuhkan lebih banyak nuansa. Mungkin fitur baru hanya boleh terlihat oleh pengguna dengan ID tertentu. Mungkin hanya pengguna di wilayah tertentu. Atau mungkin hanya 10 persen traffic, yang dipilih secara acak. Boolean sederhana tidak bisa menangani ini.

Anda membutuhkan conditional flag. Flag itu sendiri masih berupa boolean, tetapi logika yang menentukan nilainya bergantung pada konteks. Pendekatan paling sederhana adalah menambahkan kondisi di luar flag:

if fiturXEnabled and user.id in trial_user_list:
    show_new_feature()
else:
    show_old_feature()

Ini berfungsi, tetapi trial_user_list harus dikelola secara terpisah. Jika daftar sering berubah, Anda memerlukan cara untuk memperbaruinya tanpa redeploy. Itu menambah kompleksitas.

Pendekatan yang lebih bersih adalah menggunakan flag provider. Flag provider adalah fungsi atau pustaka yang menerima konteks (seperti ID pengguna, wilayah, tipe perangkat) dan mengembalikan nilai flag berdasarkan aturan yang telah ditentukan. Kode Anda menjadi:

if flag_provider.is_enabled("featureX", user=current_user):
    show_new_feature()
else:
    show_old_feature()

Di balik layar, flag provider memeriksa aturan: Apakah pengguna ini dalam grup uji coba? Apakah wilayah mereka cocok? Apakah persentase traffic telah terpenuhi? Anda tidak perlu menulis ulang logika itu setiap kali menggunakan flag.

Menjaga Kode Tetap Bersih

Semakin banyak flag yang Anda tambahkan, semakin banyak cabang kondisional yang muncul di kode Anda. Tanpa disiplin, Anda akan berakhir dengan pernyataan if bersarang yang sulit dibaca dan lebih sulit dipelihara.

Beberapa prinsip membantu:

Satu flag, satu tanggung jawab. Jangan memasukkan beberapa kondisi ke dalam satu flag. Jika Anda perlu mengontrol visibilitas berdasarkan wilayah dan peran pengguna, gunakan dua flag terpisah. Itu lebih jelas dan lebih mudah dihapus nanti.

Tempatkan flag di level yang tepat. Letakkan flag sedekat mungkin dengan titik masuk fitur. Untuk komponen UI, itu mungkin fungsi render komponen. Untuk endpoint API, itu mungkin handler. Hindari menyebarkan flag yang sama di beberapa lapisan kode Anda.

Rencanakan penghapusan flag. Setiap flag yang Anda tambahkan adalah kode sementara. Ketika fitur sudah sepenuhnya dirilis, Anda akan menghapus jalur kode lama dan flag tersebut. Tulislah flag Anda sehingga mudah ditemukan dan dihapus. Kelompokkan flag terkait bersama-sama. Gunakan penamaan yang konsisten seperti featureX_enabled atau featureX_percentage.

Daftar Periksa Praktis

Sebelum Anda menulis feature flag berikutnya, periksa poin-poin ini:

  • Dapatkah fitur ini dikendalikan dengan boolean sederhana, atau Anda membutuhkan logika kondisional?
  • Dari mana nilai flag akan berasal? Hardcoded, file konfigurasi, variabel lingkungan, atau layanan jarak jauh?
  • Apakah flag ditempatkan di level yang tepat, dekat dengan tempat fitur digunakan?
  • Apakah flag memiliki satu tanggung jawab yang jelas?
  • Sudahkah Anda merencanakan cara menghapus flag dan jalur kode lama nanti?

Apa Selanjutnya

Setelah flag ada di kode, pertanyaan berikutnya adalah bagaimana mengubah nilainya tanpa redeploy. Anda memerlukan cara untuk mengontrol flag dari jarak jauh, baik melalui file konfigurasi yang dimuat ulang, variabel lingkungan yang diperbarui, atau dashboard khusus. Di situlah kekuatan sebenarnya dari feature flag muncul: Anda dapat mengaktifkan dan menonaktifkan fitur, melakukan rilis bertahap, dan bereaksi terhadap masalah tanpa menyentuh pipeline deployment.

Tapi semua itu tidak berarti jika flag Anda berantakan. Mulailah dengan flag yang bersih dan ditempatkan dengan baik di kode Anda. Sisanya akan mengikuti.