Trong nhiều dự án web/app, chúng ta thường nghĩ rằng “muốn đưa tính năng mới lên production thì deploy là xong”. Nhưng thực tế không phải lúc nào cũng đơn giản như vậy. Có tính năng cần thử với một nhóm nhỏ người dùng, có tính năng phụ thuộc vào đối tác bên ngoài, hoặc có phần chưa đủ tự tin để mở cho toàn bộ hệ thống. Đây là lúc feature flag trở thành một công cụ rất đáng dùng. Feature flag là gì? Feature flag, có thể hiểu đơn giản là một “công tắc” trong hệ thống cho phép bật hoặc tắt một tính năng mà không cần sửa code và deploy lại. Thay vì viết logic kiểu: Nếu code đã deploy thì tính năng luôn chạy. Ta chuyển sang: Nếu flag đang bật thì tính năng chạy, nếu không thì dùng luồng cũ. Ví dụ thực tế: bạn đang phát triển giao diện thanh toán mới. Thay vì thay thế ngay giao diện cũ cho tất cả người dùng, bạn có thể tạo flag tên new_checkout_ui. Ban đầu chỉ bật cho tài khoản nội bộ, sau đó mở cho 5% người dùng, rồi tăng dần nếu không có lỗi nghiêm trọng. Khi nào nên dùng feature flag? Feature flag hữu ích trong các trường hợp sau: - Ra mắt tính năng theo từng nhóm người dùng: nội bộ, beta tester, khách hàng doanh nghiệp, người dùng ở một khu vực nhất định. - Giảm rủi ro khi deploy: code đã lên production nhưng tính năng vẫn tắt, chỉ bật khi sẵn sàng. - A/B testing ở mức đơn giản: so sánh hai cách hiển thị hoặc hai luồng xử lý khác nhau. - Tắt nhanh tính năng có vấn đề: nếu tính năng mới gây lỗi, chỉ cần tắt flag thay vì rollback toàn bộ hệ thống. - Phát triển song song: nhiều lập trình viên có thể merge code sớm hơn mà không ảnh hưởng người dùng cuối. Một ví dụ triển khai đơn giản Giả sử trong backend có một hàm kiểm tra flag: isFeatureEnabled(user, "new_checkout_ui") Khi render giao diện thanh toán, hệ thống có thể xử lý như sau: Nếu flag new_checkout_ui bật với user hiện tại, trả về giao diện mới. Nếu không, trả về giao diện cũ. Ở mức đơn giản, danh sách flag có thể lưu trong database, file cấu hình hoặc hệ thống quản trị nội bộ. Với dự án nhỏ, chỉ cần một bảng gồm các cột như key, enabled, rollout_percentage, created_at, updated_at là đã đủ dùng. Với dự án lớn hơn, có thể cần thêm điều kiện theo role, tenant, quốc gia, phiên bản app hoặc nhóm người dùng. Những lỗi thường gặp khi dùng feature flag 1. Để flag tồn tại mãi mãi Đây là lỗi rất phổ biến. Ban đầu flag được tạo để thử nghiệm, nhưng sau khi tính năng đã ổn định, không ai xóa nó. Vài tháng sau, codebase đầy các nhánh if/else khó hiểu. Vì vậy, mỗi flag nên có “ngày dọn dẹp” hoặc người chịu trách nhiệm rõ ràng. 2. Đặt tên flag mơ hồ Tên như test_1, new_feature, temp_checkout rất dễ gây nhầm lẫn. Nên đặt tên thể hiện đúng mục đích, ví dụ: checkout_new_ui, enable_wallet_payment, search_use_new_ranking. 3. Không log trạng thái flag khi có lỗi Khi debug, biết người dùng đang đi qua nhánh tính năng nào là rất quan trọng. Nếu hệ thống báo lỗi thanh toán nhưng không biết user đó đang dùng checkout cũ hay mới, việc điều tra sẽ mất nhiều thời gian hơn. 4. Dùng feature flag thay cho phân quyền Feature flag không nên bị lạm dụng để thay thế authorization. Nếu một API chỉ dành cho admin, vẫn phải kiểm tra quyền ở backend. Đừng chỉ ẩn nút trên giao diện bằng flag rồi cho rằng đã an toàn. Lời khuyên áp dụng - Bắt đầu đơn giản: không cần xây hệ thống quá phức tạp ngay từ đầu. - Mỗi flag nên có mô tả, người phụ trách và thời điểm dự kiến gỡ bỏ. - Luôn kiểm tra cả hai nhánh bật và tắt trong quá trình test. - Với tính năng quan trọng, cần có cách tắt flag nhanh mà không phụ thuộc vào deploy. - Định kỳ rà soát các flag cũ để tránh làm code rối dần theo thời gian. Feature flag không phải là công cụ “thần kỳ”, nhưng nếu dùng đúng, nó giúp đội phát triển kiểm soát rủi ro tốt hơn, ra mắt tính năng linh hoạt hơn và giảm áp lực mỗi lần deploy. Với các dự án web/app đang lớn dần, đây là một thói quen kỹ thuật rất đáng đưa vào quy trình phát triển.