Làm cách nào để bắt đầu một phiên bản chính mới của ứng dụng của tôi, nhưng vẫn giữ cho phiên bản cũ 'sống'


8

Tôi có hai ứng dụng, được gọi là A và B. Phiên bản hiện tại của các ứng dụng này là 7.x (một số khách hàng chạy 7.1, một số khác chạy 7.2, ...). Cả hai ứng dụng đều sử dụng cùng một khung chung (hãy gọi C này), như thế này:

+---+ +---+
| A | | B |
+---------+
|    C    |
+---------+

Vì một số khách hàng mới quan trọng, tôi muốn có chức năng của A và B trong một ứng dụng lớn. Việc hợp nhất A và B vào một ứng dụng là không thể, vì vậy bây giờ tôi đang cố gắng tích hợp chức năng của A vào B. Cho đến nay vẫn tốt, nhưng tôi bắt đầu gặp phải một số vấn đề.

Trước hết, khách hàng chỉ sử dụng chức năng cơ bản của B không quan tâm đến tất cả các chức năng mới của A được thêm vào (và điều này gây ra thêm chi phí cho họ). Họ chỉ muốn nâng cấp phiên bản B của họ với sự hỗ trợ cho các phiên bản Windows mới, ... và có thể cũng muốn tất cả các chức năng hay được thêm vào C (khung chung).

Thứ hai, khách hàng hiện đang sử dụng ứng dụng A, không muốn trực tiếp chuyển sang ứng dụng B, mặc dù chức năng kết hợp của A + B sẽ giúp họ lâu dài. Để nâng cấp dễ dàng, họ muốn gắn bó với A và thậm chí xem một số cải tiến trong C.

Thứ ba, tất cả các phát triển tôi đang làm ở B có thể có tác động đến lớp CEg chung để cải thiện hiệu suất của mô-đun trong B, tôi phải cấu trúc lại một mô-đun trong C, nhưng vì C cũng được sử dụng trong A, Tôi cần phải làm nhiều công việc hơn. Ngoài ra, A là một ứng dụng cũ hơn, ít cấu trúc hơn và mọi thay đổi trong C có thể làm cho A không ổn định hơn.

Câu hỏi là làm thế nào để tiến hành? Tôi hiện đang suy nghĩ về việc tách B trong bản phát hành 7.x (tôi vẫn có thể thực hiện một số phát triển nhỏ ở đây và phát hành 7.3, 7.4 trong những năm tới nếu cần) và bản phát hành 8.x (sẽ chứa tất cả chức năng mới) . Để giải quyết vấn đề của lớp chung, tôi cũng có thể chia C thành C cũ (7.x) và C mới (8.x). Điều này cho kết quả như sau:

+-------+ +-------+  +-------+
| A 7.x | | B 7.x |  | B 8.x |
+-----------------+  +-------+
|      C 7.x      |  | C 8.x |
+-----------------+  +-------+

Ứng dụng A sẽ không phát triển nữa và sẽ dính vào phiên bản 7.x của lớp chung C.

Tách C có nghĩa là tất cả các phát triển trong C sẽ không được nhìn thấy trong A và B cũ (vẫn sẽ được phát hành 7.x) hoặc nếu chúng phải được thực hiện trong phiên bản 7.x của A và B, sẽ yêu cầu thực hiện phát triển trong cả hai phiên bản.

Một giải pháp thay thế có thể là tách B thành B 7.x và B 8.x, nhưng điều này sẽ hạn chế khả năng tái cấu trúc trong C, và thực tế chỉ giải quyết được hai vấn đề đầu tiên.

Có ai có bất kỳ kinh nghiệm với một loại thay đổi phát hành lớn như vậy? Còn ý tưởng nào khác không?


3
Đề xuất cuối cùng của bạn có vẻ ổn nếu bạn có ý định chỉ thực hiện các cập nhật nhỏ và sửa lỗi cho các phiên bản 7.x. Sau đó, bạn nói với khách hàng của mình rằng bạn sẽ loại bỏ 7.x và họ sẽ phải chuyển sang 8.x nếu họ muốn có thêm chức năng. Trong 8.x, bạn định cấu hình (và có thể bán riêng) các mô-đun chức năng - ban đầu là 2, rất giống với chức năng của A và B. Về mặt kỹ thuật, từ giờ trở đi, bạn duy trì 2 cơ sở mã riêng biệt.
Jan Doggen

Câu trả lời:


3

Trước hết, khách hàng chỉ sử dụng chức năng cơ bản của B không quan tâm đến tất cả các chức năng mới của A được thêm vào (và điều này gây ra thêm chi phí cho họ).

Đây thường chỉ là sự cố giao diện người dùng: đưa chức năng của A vào ứng dụng kết hợp của bạn "B 8.x", nhưng tách biệt nó theo cách mà khách hàng của B sẽ không nhìn thấy ở cấp độ UI. Xây dựng một chuyển đổi vào ứng dụng để bạn chỉ có thể kích hoạt chức năng A cho "Khách hàng A". Có lẽ bạn cần phải có một công tắc khác để ẩn chức năng B cho khách hàng A (điều này cũng mang đến cho bạn cơ hội bán cho họ chức năng B dưới dạng một mô-đun riêng biệt)

Thứ hai, khách hàng hiện đang sử dụng ứng dụng A, không muốn trực tiếp chuyển sang ứng dụng B, mặc dù chức năng kết hợp của A + B sẽ giúp họ lâu dài.

Tôi đoán điều này sẽ không có vấn đề gì nếu bạn quan tâm đến hai điều:

  • tìm cách thiết kế giao diện người dùng của bạn cho "Chức năng A" trong "B 8.x" theo cách không quá khác biệt so với A 7.x
  • cung cấp cho những khách hàng A đó sự chuyển đổi sang B 8.x với cùng mức giá từ A 7.x sang A 7. (x + 1). Hoặc, khai báo "B 8.x" với các chức năng B bị vô hiệu hóa là "A 7. (x + 1)" cho khách hàng A (cách đặt tên theo dõi có thể là vấn đề hợp đồng, bạn nên kiểm tra điều này).

Cuối cùng, nếu bạn có thể di chuyển khách hàng A của mình sang B 8.x theo cách này, bạn sẽ tự động giải quyết vấn đề thứ ba của mình.

Một điều cần nói thêm: Tôi đang duy trì một ứng dụng có tình huống rất giống khoảng 15 năm trước ("A 7.x" là một chương trình MS DOS, "B 7.x" là một chương trình Windows có nhiều tính năng mới và "B 8.x" chứa tất cả các chức năng của cả hai phiên bản trước, trong đó các chức năng "A 7.x" cũ được tích hợp vào B và được bán dưới dạng một mô-đun riêng biệt). Bạn sẽ không ngạc nhiên khi tôi nói với bạn rằng chúng tôi không có khách hàng MS DOS nào sau hơn 10 năm, vì vậy việc chuyển đổi không có vấn đề gì cả.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.