Sử dụng tính năng Toggling và IoC thay cho Branching Code - Good or Bad Idea?

Question

Khách hàng của chúng tôi có thể chọn thời điểm nâng cấp. Vì vậy, nhóm của tôi theo nghĩa đen phải duy trì và hỗ trợ hàng chục phiên bản sản phẩm phần mềm của chúng tôi. Như bạn có thể tưởng tượng rằng kết quả trong rất nhiều phân nhánh và sáp nhập như sửa chữa nóng và gói dịch vụ phải được tuyên truyền trên tất cả các hương vị này. Tôi không hài lòng với tình hình. Giải pháp hiển nhiên đơn giản là không duy trì quá nhiều phiên bản khác nhau của sản phẩm của chúng tôi, nhưng giải pháp hiển nhiên đó không có sẵn cho tôi. Vì vậy, tôi đang khám phá các tùy chọn sáng tạo để giảm công việc bảo trì của nhóm. Tôi đang xem xét việc sử dụng một kết hợp của tính năng Toggling và IoC như một cách để thực hiện n-số phiên bản của sản phẩm phần mềm của chúng tôi. Ý tưởng là tôi có thể sử dụng một mã cơ sở duy nhất cho sản phẩm của mình và quản lý các hành vi và tính năng thông qua quản lý cấu hình. Điều này sẽ thay vì phải truyền mã trên nhiều nhánh. Đây có phải là một cách tiếp cận hợp lý hoặc tôi chỉ giao dịch một vấn đề cho người khác?

Answer 1

Điều đó nghe có vẻ hợp lý, vì đây sẽ là cách tôi giải quyết vấn đề như vậy trong môi trường greenfield.

Chúng ta không gọi nó là Tính năng Chuyển đổi. Như tên của nó, một Feature Toggle là công tắc bật/tắt, có thể không phải là thứ bạn cần.

Đôi khi, bản nâng cấp cũng liên quan đến thay đổi hoạt động trong các tính năng hiện có. Điều đó ngụ ý rằng bạn có thể sẽ cần một cái gì đó tinh vi hơn một công tắc bật/tắt.

Strategy pattern là cách linh hoạt hơn trong việc mô hình hóa các biến thể trong hành vi. Mỗi Chiến lược có thể đại diện cho một phiên bản cụ thể của một hành vi cụ thể và nếu bạn không muốn hành vi đó, bạn có thể cung cấp triển khai Null Object. Nói cách khác, tính năng Toggle có thể được thực hiện với một chiến lược.

Bạn có thể đưa các chiến lược vào hạt nhân ứng dụng của bạn bằng cách sử dụng Dependency Injection, và bạn có thể lựa chọn các chiến lược cấu hình thông qua một hệ thống cấu hình. Hầu hết DI Containers tôi đã nghe nói về (trên .NET và Java) hỗ trợ cấu hình dựa trên tập tin.

Điều này về cơ bản mô tả cấu trúc bổ sung bổ trợ.

Bây giờ, ngay cả đối với một ứng dụng greenfield, đây không phải là kỳ công dễ dàng để kéo ra. Nếu bạn có một hệ thống không đầu, nó không phải là rằng khó, nhưng khi bạn có giao diện người dùng, bạn bắt đầu nhận ra rằng bạn cũng cần phải cấu thành kiến ​​trúc UI để có thể cắm các phần tử giao diện người dùng thông qua các chiến lược .

Trên cơ sở mã thập niên, đây sẽ là điều tôi muốn gọi là 'thử thách thú vị', để nói ít nhất.