"Feature Flag-Driven Development" là gì?
Last updated: September 20, 2025 Xem trên toàn màn hình
Recommended for you
- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 613 - 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 555
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 443
- 01 May 2022 Có thể xác định vị trí địa lý của địa chỉ IP với độ chính xác đến từng địa chỉ con phố? 426
- 03 May 2022 Mô hình Hybrid Agile là gì? 415
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 414
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 350
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 345
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 323
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 316
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 310
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 273
- 04 Sep 2023 Giải mã nhóm tính cách (ISTP - Nhà kỹ thuật) 225
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 221
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 202
- 07 Jan 2025 Phân biệt Proxy, HMA và VPN 200
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 195
- 12 Sep 2021 Túi càn khôn của lập trình viên Agile cần trang bị những gì? 190
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 185
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 168
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 153
- 09 Aug 2024 Latency (độ trễ) là gì? 151
- 14 Aug 2024 Eventual Consistency và Strong Consistency trong Cơ sở dữ liệu phân tán 140
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 95
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 88
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 52
- 15 May 2025 Hiệu quả năng lượng trong phần mềm (Energy Efficiency in Software) là gì? 39
- 01 Jun 2025 Thiết Kế Hướng Miền (Domain-Driven Design) hình thành như thế nào trong kiến trúc Lưới Dữ Liệu (Data Mesh)? 38
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 26
- 01 Apr 2025 CTO ra quyết định như thế nào? 24
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 24
- 13 Sep 2024 Cấp quyền và Hủy quyền người dùng (User Provisioning & Deprovisioning) là gì? 14
Bài viết sau cung cấp một cái nhìn tổng quan rộng và toàn diện về phát triển dựa trên feature flag (cờ tính năng), từ triển khai dần dần cho đến thử nghiệm A/B.
Một buổi chiều thứ Sáu của lập trình viên
Đó là một buổi chiều thứ Sáu yên ả. Bạn đã sẵn sàng về nhà, đi tập gym và dành thời gian cho gia đình. Điều cuối cùng bạn muốn làm là triển khai một số tính năng mới cho người dùng, đúng không? Thật điên rồ. “Đợi đến thứ Hai đi… quá rủi ro… lỡ như hỏng thì sao?” Triển khai vào thứ Sáu gần như đồng nghĩa với việc làm việc cuối tuần. Nhưng bạn can đảm, bạn là “Zeus” của thế giới lập trình, và bạn cứ triển khai.
Thực tế, bạn vừa cười vừa bật nhạc to, thong thả rời văn phòng ra bến xe buýt. “Ngây thơ quá!” – có người sẽ nói vậy, nhưng bạn vẫn bước đi đầy khí thế.
Vài giờ sau, bạn đang nằm dài trên sofa da êm ái, tận hưởng cảm giác tự hào. “Bzz Bzz” – điện thoại rung trong túi. Bạn phớt lờ, nhưng nó không ngừng. Khó chịu, bạn lấy điện thoại ra và thấy hàng loạt thông báo lỗi. Ôi không! Thế là hỏng rồi, triển khai thất bại. Ván cược biến thành ác mộng… phải không? Không hề.
Bạn chỉ cần mở LaunchDarkly và gạt một công tắc. Lỗi biến mất, còn bạn chỉ bỏ lỡ 30 giây của chương trình TV.
Đó chính là sức mạnh của feature flags. Chiều hôm đó, bạn triển khai tính năng cho 1% người dùng, được bao bọc bởi feature flag. Bạn muốn kiểm tra cách nó hoạt động. Nếu có vấn đề, chẳng sao cả – bạn chỉ cần tắt cờ và mọi thứ quay về như cũ, chỉ 1% người dùng gặp chút bất tiện. Đây chỉ là một trong hàng trăm trường hợp minh họa cho sức mạnh của feature flags.
Feature Flags là gì?
Feature flags/toggles/controls về cơ bản là cách kiểm soát toàn bộ vòng đời của tính năng. Chúng cho phép bạn quản lý thành phần, phân tách rủi ro. Bạn có thể làm nhiều việc hay ho như: phát hành tính năng cho một nhóm người dùng, chặn một số nhóm, thử nghiệm A/B, và nhiều hơn nữa.
Cách thức hoạt động
Khi người dùng tải trang, ứng dụng sẽ dựa vào thuộc tính của họ để quyết định hiển thị tính năng nào. Ví dụ: nếu tôi là người dùng BETA, khi đăng nhập vào myexamplesite.com, tôi sẽ thấy tính năng BETA mới. Người dùng không thuộc nhóm BETA thì vẫn thấy tính năng cũ.
Cờ chức năng đa biến (Multivariate Feature Flags)
Thay vì chỉ có bật/tắt, bạn có thể triển khai nhiều biến thể khác nhau cho nhiều nhóm. Ví dụ: bạn có ba trang đích màu tím, cam, và xanh lá. Bạn chọn ai sẽ thấy biến thể nào, thậm chí chia theo tỷ lệ % (ví dụ: 60% người dùng thấy trang tím).
Nhắm mục tiêu người dùng (Targeting)
Nhắm mục tiêu giúp cá nhân hóa trải nghiệm:
- Quản lý gói (Normal vs. Premium): chỉ bật tính năng mới cho người dùng gói Premium, sau đó mở rộng cho Normal.
- Truy cập sớm: cho phép nhóm dùng thử tính năng mới trước.
- Chặn người dùng: loại trừ một số người không nên thấy tính năng.
Quản lý Rollout
Phát hành cho 100% người dùng ngay từ đầu rất rủi ro. Thay vào đó, bạn có thể triển khai dần: 1% → 5% → 20% → 50% → 100%. Nếu lỗi xảy ra ở 1%, bạn có thể rollback ngay. Đây chính là canary deployment – thử nghiệm trên một nhóm nhỏ trước khi mở rộng toàn bộ.
Feature Flag-Driven Development
Feature flags khai thác sức mạnh của Test-Driven Development (TDD) và Lean UX. Bạn phát hành tính năng nhỏ, nhận phản hồi thực tế từ thị trường, cải tiến rồi triển khai lại.
Điều này khác với:
- Waterfall: chỉ có một lần triển khai lớn, nhận phản hồi sau cùng.
- Agile: thử nghiệm theo iteration, nhưng chủ yếu trong môi trường nội bộ.
- Lean UX + Feature Flags: phát hành trực tiếp ra thị trường, nhận phản hồi thật, cải tiến liên tục.
Continuous Delivery với Feature Flags
Feature flags giống như nút hoàn tác vĩnh viễn. Nếu phát hành gây lỗi → rollback. Nếu ổn → mở rộng dần. Toàn bộ quá trình phát triển trở nên linh hoạt, an toàn, và khuyến khích sáng tạo.
Các nhóm marketing, thiết kế, kỹ thuật có thể phối hợp thường xuyên hơn dựa trên phản hồi thực tế từ thị trường. Điều này giúp sản phẩm tiến lên nhanh hơn và chắc chắn hơn.
Feature Flag-Driven A/B Testing
Truyền thống, A/B testing chỉ áp dụng cho giao diện: màu sắc, bố cục, nút bấm… Nhưng với feature flags, bạn có thể thử nghiệm cả chức năng backend, tính năng hoàn toàn mới, hoặc luồng đăng ký.
Ví dụ: bạn muốn kiểm tra luồng đăng ký mới. Bạn bật cờ cho một nhóm người dùng, rồi phân tích dữ liệu với Optimizely hoặc New Relic để xem luồng nào hiệu quả hơn.
→ Nhờ vậy, A/B testing không chỉ dừng ở “thay đổi bề ngoài” mà mở rộng sang chức năng cốt lõi.
Tóm lại: Feature flag-driven development cho phép bạn phát hành tính năng an toàn, thu thập phản hồi thực tế, và tối ưu sản phẩm nhanh chóng – tất cả mà không đánh đổi sự ổn định của hệ thống.
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
