Dự án tốn bao nhiêu thời gian và công sức để tương thích ngược?

Question

Cho rằng mọi dự án phần mềm chỉ có quá nhiều giờ lập trình dành riêng cho nó, bạn sẽ chi bao nhiêu cho việc đảm bảo sản phẩm tương thích ngược với các phiên bản trước? Trên thực tế, có một số điểm cần xem xét:

• Độ tuổi của phần mềm có ảnh hưởng đến quyết định của bạn không? Bạn sẽ đầu tư ít thời gian hơn vào khả năng tương thích ngược khi chương trình mới hơn?
• Quyết định chỉ dựa trên số lượng khách hàng có bản sao đã cài đặt?
• Bạn có nỗ lực tích cực để tạo ra các định dạng mã và tệp hỗ trợ các thay đổi trong tương lai không?
• Khi bạn đang phát triển v1.0, bạn có cố gắng xây dựng để làm cho v2.0 trở nên tương thích ngược với v1.0 dễ dàng hơn không? (Để trường "dành riêng" là một ví dụ.)
• Làm cách nào để bạn quyết định rằng "Không, chúng tôi sẽ không hỗ trợ thêm nữa" trên các tính năng?

Answer 1

Cơ sở khách hàng là yếu tố quyết định xem bạn có nên hỗ trợ vấn đề tương thích ngược lớn hay không.

Về cơ bản, bạn cần phải đánh giá rằng giống như bất kỳ yêu cầu phi chức năng khác bạn cần phải thực hiện, và bạn cần phải cẩn thận xác định những gì được bao gồm trong một "backward compatibility" feature:

• API tương thích. Điều này có nghĩa là các phiên bản tiếp theo của thư viện cung cấp cùng API mà các phiên bản trước đó thực hiện, vì vậy các chương trình được viết dựa trên phiên bản trước đó sẽ vẫn có thể biên dịch và chạy với phiên bản mới. Ngoài việc thực sự rời khỏi các chức năng tương tự, điều này cũng ngụ ý rằng tất cả các chức năng đó đều hoạt động tương tự trong phiên bản mới hơn mà chúng đã thực hiện ở các phiên bản cũ hơn
• Giao diện nhị phân ứng dụng hoặc ABI, khả năng tương thích. Điều này có nghĩa là khả năng tương thích ngược được duy trì ở mức của mã đối tượng nhị phân được tạo ra khi bạn biên dịch thư viện.
  Thường có một số trùng lặp giữa khả năng tương thích API và ABI, nhưng có những khác biệt quan trọng.Để duy trì khả năng tương thích ABI, tất cả những gì bạn phải làm là đảm bảo rằng chương trình của bạn xuất tất cả các ký hiệu giống nhau.
  Điều này có nghĩa là tất cả các chức năng giống nhau và các đối tượng có thể truy cập trên toàn cầu cần phải có, để các chương trình được liên kết với phiên bản trước vẫn có thể chạy với phiên bản mới.
  Có thể duy trì khả năng tương thích ABI trong khi phá vỡ khả năng tương thích API. Trong mã C, để lại các ký hiệu trong các tệp C nhưng xóa chúng khỏi các tiêu đề công khai, do đó mã mới cố gắng truy cập các biểu tượng sẽ không biên dịch được, trong khi mã cũ mà người dùng đã biên dịch so với phiên bản trước sẽ tiếp tục chạy
• tương thích giao thức máy khách-máy chủ. Điều này có nghĩa là một máy khách sử dụng phiên bản của giao thức mạng được cung cấp trong các phiên bản cũ sẽ tiếp tục hoạt động khi phải đối mặt với một máy chủ mới hơn và các chương trình máy khách mới hơn sẽ tiếp tục làm việc với một máy chủ cũ hơn.
• khả năng tương thích định dạng dữ liệu. Các phiên bản mới hơn của mã cần có khả năng làm việc với các tệp dữ liệu được viết ra bởi các phiên bản cũ hơn và ngược lại. Lý tưởng nhất là bạn cũng có thể xây dựng một số khả năng tương thích về phía trước thành các định dạng dữ liệu. Nếu các thói quen xử lý tệp của bạn có thể bỏ qua và bảo toàn các trường không được nhận dạng, thì chức năng mới có thể sửa đổi định dạng dữ liệu theo cách không phá vỡ các phiên bản cũ hơn. Đây là một trong những loại tương thích quan trọng nhất, đơn giản bởi vì người dùng trở nên rất khó chịu khi họ cài đặt phiên bản mới của chương trình và đột nhiên không thể truy cập dữ liệu cũ của họ.

Nếu bạn kết hợp các tiêu chuẩn trước đó (bản chất của tính tương thích ngược) với bản chất của cơ sở khách hàng của bạn, bạn có thể quyết định rằng:

• Nếu khách hàng của bạn là nội bộ để công ty của bạn, nhu cầu thấp hơn và 2.0 có thể phá vỡ các chức năng quan trọng.

• Nếu khách hàng của bạn là bên ngoài, một 2.0 có thể vẫn phá vỡ mọi thứ, nhưng bạn có thể cần phải provide migration guide

• Trên cực đoan, nếu khách hàng của bạn là thế giới tất cả, như tôi đã mentionned trong này SO question about java , bạn có thể sẽ cung cấp các chức năng mới mà không bao giờ phản đối những chức năng cũ! Hoặc thậm chí preserving BUGS of your old products, vì ứng dụng của khách hàng phụ thuộc vào những lỗi đó !!

---

• Liệu tuổi của phần mềm ảnh hưởng đến quyết định của bạn? Bạn sẽ đầu tư ít thời gian hơn vào khả năng tương thích ngược khi chương trình mới hơn?
  Tôi tin rằng điều này phải làm với những gì đã được triển khai: một chương trình gần đây sẽ phải đối phó với ít nhu cầu tương thích ngược hơn so với nhu cầu từ 20 năm trở lên.

• Quyết định chỉ dựa trên số lượng khách hàng có bản sao đã cài đặt?
  Nó phải dựa trên một trường hợp kinh doanh: di chuyển của bạn - nếu cần thiết vì thiếu khả năng tương thích ngược - có thể được "bán" hiệu quả cho khách hàng của bạn (vì tất cả các tính năng sáng bóng mới mang lại?)

• Bạn có nỗ lực tích cực để tạo ra các định dạng mã và tệp hỗ trợ các thay đổi trong tương lai không?
  Cố gắng dự đoán "thay đổi trong tương lai" có thể rất phản tác dụng và nhanh chóng biên giới với YAGNI (Bạn không cần nó): một bộ công cụ di chuyển tốt có thể hiệu quả hơn nhiều.

• Khi bạn đang phát triển phiên bản 1.0, bạn có cố gắng xây dựng để làm cho v2.0 trở nên tương thích ngược với v1.0 dễ dàng hơn không? (Để trường "đã đặt trước" là một ví dụ.)
  Đối với các ứng dụng nội bộ tôi đã làm việc, không. Một Parallel Run là cách của chúng tôi để đảm bảo khả năng tương thích ngược "chức năng". Nhưng đó không phải là một giải pháp phổ quát.

• Làm cách nào để bạn quyết định rằng "Không, chúng tôi sẽ không hỗ trợ thêm nữa" trên các tính năng?
  Một lần nữa, đối với nội bộ ứng dụng, quá trình quyết định có thể rất khác so với một ứng dụng được triển khai bên ngoài. Nếu một đối tượng địa lý không mang lại bất kỳ giá trị gia tăng nào cho doanh nghiệp thì nhiệm vụ "kết hợp" nội bộ được đặt để kiểm tra với mọi ứng dụng nội bộ khác chi phí di chuyển của họ (tức là "không sử dụng tính năng này nữa"). Nhiệm vụ tương tự cũng khó thực hiện hơn với các khách hàng bên ngoài tổ chức của bạn.

Answer 2

Đưa tôi về khả năng tương thích ngược của phần mềm:

1.) Nếu nó là một sản phẩm sử dụng rộng rãi đã được nhiều khách hàng, sau đó tôi sẽ đảm bảo rằng phiên bản mới của sản phẩm này vẫn được sử dụng cùng một " mã cơ bản "(Mã đạt được chức năng cơ bản của ứng dụng đang được phát triển). Các tính năng mới nên được tính vào cơ sở mã này hoặc được xây dựng trên nền tảng mã này với ít thay đổi cần thiết trong môi trường thực thi của ứng dụng này càng tốt. Bạn không muốn làm cho người dùng hiện tại của mình thực hiện nhiều thay đổi trong các cài đặt hiện có của họ. Vì vậy, một sự cân bằng giữa việc hỗ trợ một chức năng mới và cải tiến trong quá trình thiết lập và sử dụng hiện tại cho khách hàng.

2.) Trong một sản phẩm mới, Nếu có thể xác định tất cả các tính năng có thể có của ứng dụng đó ngay trong phần đầu ngay cả trước khi v1.0 hết. Xác định các tính năng u sẽ xuất xưởng trong phiên bản v1.0. và cái nào sẽ được giữ lại để phát hành sau này. Bất cứ nơi nào có thể giữ những "tính năng thời gian sau này" trong tâm trí trong khi thiết kế, thực hiện mã, hoàn thành đầu ra từ/của ứng dụng để chứa các tính năng trong các phiên bản trong tương lai. ví dụ. Để lại các phần tử/bit bổ sung trong cấu trúc dữ liệu của bạn.

-AD.

Answer 3

Rất nhiều. Nếu bạn không muốn piss off mỗi một trong những khách hàng trung thành của bạn!

Answer 4

Hệ thống của bạn càng được sử dụng hàng ngày, bạn càng tập trung vào nó.

Hệ thống của bạn càng được nhúng sâu trong các quy trình cốt lõi của khách hàng, bạn càng tập trung vào nó.

Càng có nhiều hệ thống của bạn có đối thủ cạnh tranh, bạn càng tập trung vào nó.

Càng nhiều người dùng sử dụng các phiên bản cũ hơn thì bạn càng nên tập trung vào nó.

Việc mua thêm phức tạp và sâu hơn cho khách hàng vào hệ thống của bạn, về mức độ ảnh hưởng của phần mềm đối với doanh nghiệp của họ, bạn càng tập trung vào khả năng tương thích ngược.

Nếu bạn không thể giúp họ chuyển sang phiên bản mới thông qua giá hấp dẫn, v.v., có thể đáng xem xét đến rủi ro buộc mọi người phải làm.

Giống như Vista hoặc Office 2007. Thật tuyệt vời khi giúp tôi với Apple.

Answer 5

Trải nghiệm của tôi là với các hệ thống thu hẹp phức tạp với số người dùng tương đối ít (100 - 5000).
Tiếp thị thường phải có thái độ về tính tương thích ngược mà không có sự đánh giá đầy đủ về chi phí vòng đời. Ví dụ, khoản tiết kiệm cho việc duy trì các lỗi trong hệ thống của bạn cho cơ sở người dùng hiện tại có thể dễ dàng bị lúng túng bởi chi phí hỗ trợ cho người dùng mới trong suốt thời gian tồn tại của hệ thống.