Vì sao hardcode feature flags là lựa chọn đúng đắn nhất (2025)

Trong giới phát triển phần mềm, feature flags (hay còn gọi là cờ tính năng) thường được dùng để kiểm soát việc bật/tắt các chức năng mới. Có khá nhiều cách triển khai, nhưng giải pháp được tiếp thị rầm rộ nhất là dùng các phần mềm quản lý cờ chuyên dụng. Ngược lại, cách đơn giản nhất là hardcode trực tiếp chúng trong mã — lại ít được viết đến nhất. Tuy nhiên, theo góc nhìn của tác giả bài viết trên code.mendhak.com, điều này cần được xem xét lại một cách nghiêm túc.

Phần mềm quản lý feature flags: nhiều rủi ro hơn lợi ích

Các phần mềm quản lý cờ tính năng có thể rất mạnh mẽ, nhưng chúng cũng là nguồn cơn của sự phức tạp và rủi ro không đáng có. Marketing xung quanh chúng mạnh đến mức việc thừa nhận rằng bạn không cần chúng nghe cứ như đang tự nhận mình "bất lực về công nghệ". Chúng ta tự thuyết phục bản thân rằng không chỉ cần một vài cờ, mà cần mở rộng lên hàng nghìn cờ. Không chỉ vậy, chúng ta còn tin rằng sẽ luôn cần thay đổi trạng thái feature ngay lúc runtime, mà không cần deploy, không cần restart, không cần xóa cache, không cần migration database — bởi vì "business đang cháy" và cách duy nhất là đổi màu nút trên trang chủ.

Sự thật là, từ góc độ kiến trúc, các hệ thống quản lý cờ này chỉ là những câu lệnh if được tô vẽ, vận hành trong một tiến trình riêng — thường đòi hỏi hạ tầng, hosting, giám sát và mọi trách nhiệm đi kèm riêng của chúng.

Vì sao hardcode feature flags lại tốt hơn

Nhìn từ vòng đời phát triển, công cụ quản lý cờ khiến hệ thống trở nên không xác định (non-deterministic), làm khó khăn hơn khi suy luận logic code. Các cờ tồn tại lâu — dù ban đầu có chủ đích tốt — dễ dẫn đến nợ kỹ thuật và làm cho codebase "hóa thạch". Rủi ro này cũng có ở cờ hardcode, nhưng nó dễ nhìn thấy và quản lý hơn nhiều.

Từ góc độ bảo mật, mỗi thành phần thêm vào hệ thống lại là một bề mặt tấn công mới. Và dù thế nào, bất kỳ thứ gì làm tăng số bộ phận chuyển động trong phần mềm đều cần được soi xét kỹ lưỡng: liệu nó có thực sự cần thiết không, và rủi ro nó mang lại có đáng để giải quyết vấn đề hiện tại hay không.

Cờ hardcode giúp loại bỏ hầu hết những vấn đề trên. Chúng đơn giản, đáng tin cậy và an toàn. Đây là cách làm "nhàm chán" nhất — và chính vì vậy, nó là cách tốt nhất.

Cách triển khai đơn giản và hiệu quả

Thay vì nhảy vào hệ thống quản lý cờ phức tạp, hãy bắt đầu với một file JSON — đọc ngay khi ứng dụng khởi động và dùng nó để điều khiển khả năng hiển thị của tính năng. Việc bảo trì cũng cần được thực hiện nghiêm túc:

• Thường xuyên rà soát và gỡ bỏ các cờ không còn dùng nữa.

• Nếu một cờ sống quá lâu, hãy biến nó thành hành vi mặc định của sản phẩm và xóa hẳn đi.

• Muốn thay đổi giá trị? Hãy thực hiện theo quy trình phát triển thông thường: được review, kiểm thử và triển khai như mọi thay đổi code khác.

Đối với hầu hết đội ngũ và sản phẩm, cách tiếp cận này "đủ tốt" và có thể sử dụng được trong thời gian dài (có quãng đường dài về hiệu năng). Khi một đội thực sự cần thay đổi feature ở runtime ở quy mô lớn — giống như bài toán quản lý state trong SPA — thì đến lúc đó, họ sẽ tự biết mình cần công cụ mạnh hơn.

Lời kết: Đừng tối ưu sớm

Tối ưu hóa sớm không phải là con đường phải đi. Nó là thiết kế tồi, kỹ thuật kém, và chỉ phục vụ cho những khoảnh khắc ngắn ngủi tự mãn khi một diễn giả bán hàng tại hội nghị công nghệ hỏi "có ai đang dùng feature flags không?" và bạn giơ tay.

Với các lập trình viên Việt Nam, đặc biệt là các startup đang phát triển nhanh, lời khuyên này rất đáng cân nhắc: hãy bắt đầu từ giải pháp đơn giản nhất — hardcode flags trong file cấu hình — và chỉ nâng cấp lên hệ thống quản lý cờ chuyên nghiệp khi thực sự có nhu cầu rõ ràng. Tránh xa cám dỗ của "công nghệ mới" để tập trung vào giá trị thực sự của sản phẩm.