Đối lập với tất cả những người nói nay, hãy giả sử nhu cầu kinh doanh thực sự.
(ví dụ: phân phối là mã nguồn, khách hàng đến từ cùng một ngành kinh doanh và do đó là đối thủ cạnh tranh với nhau và mô hình kinh doanh của bạn hứa sẽ giữ bí mật của họ)
Hơn nữa, giả sử rằng công ty của bạn có các công cụ để duy trì tất cả các chi nhánh, đó là nhân lực (giả sử 100 nhà phát triển dành riêng cho việc hợp nhất, giả sử trì hoãn phát hành 5 ngày hoặc 10 nhà phát triển giả định độ trễ phát hành 50 ngày là OK) hoặc thử nghiệm tự động tuyệt vời như vậy mà việc hợp nhất tự động thực sự được thử nghiệm cả thông số kỹ thuật cốt lõi và thông số mở rộng trong mỗi chi nhánh và do đó, chỉ những thay đổi không hợp nhất "sạch" cần có sự can thiệp của con người. Nếu khách hàng của bạn trả tiền không chỉ cho các tùy chỉnh mà còn để bảo trì, đây có thể là một mô hình kinh doanh hợp lệ.
Câu hỏi của tôi (và nay-sayers) là, bạn có một người tận tâm chịu trách nhiệm giao hàng cho từng khách hàng không? Nếu bạn là một công ty 10.000 người thì có thể là như vậy.
Điều này có thể được xử lý bởi kiến trúc plugin trong một số trường hợp, giả sử lõi của bạn là thân cây, plugin có thể được giữ trong thân cây hoặc nhánh và cấu hình cho mỗi khách hàng là một tệp có tên duy nhất hoặc được giữ trong nhánh khách hàng.
Các plugin có thể được tải trong thời gian chạy hoặc được tích hợp vào thời gian biên dịch.
Thực sự nhiều dự án được thực hiện như thế này, về cơ bản vẫn có một vấn đề tương tự - những thay đổi cốt lõi đơn giản là không đáng kể để tích hợp, những thay đổi xung đột phải được khôi phục hoặc cần thay đổi đối với nhiều plugin.
Có những trường hợp khi các plugin không đủ tốt, đó là khi rất nhiều phần bên trong lõi phải được điều chỉnh mà số giao diện plugin trở nên quá lớn để xử lý.
Lý tưởng nhất là việc này sẽ được xử lý bằng lập trình hướng theo khía cạnh , trong đó trung kế là mã lõi và các nhánh là các khía cạnh (đó là mã bổ sung và hướng dẫn cách kết nối bổ sung với lõi)
Một ví dụ đơn giản, bạn có thể chỉ định rằng tùy chỉnh foođược chạy trước hoặc sau lõi klass.foohoặc nó thay thế nó, hoặc nó bao bọc nó và có thể thay đổi đầu vào hoặc đầu ra.
Có rất nhiều thư viện cho điều đó, tuy nhiên vấn đề xung đột hợp nhất không biến mất - việc hợp nhất sạch sẽ được xử lý bởi AOP và xung đột vẫn cần sự can thiệp của con người.
Cuối cùng, việc kinh doanh như vậy thực sự phải quan tâm đến việc bảo trì chi nhánh , cụ thể là tính năng dành riêng cho khách hàng X phổ biến đến mức rẻ hơn khi chuyển nó thành cốt lõi, mặc dù không phải tất cả khách hàng đều trả tiền cho nó?