Khi nào thì người ta sẽ từ bỏ khả năng tương thích ngược để ủng hộ việc thực hiện giao diện mới và được cải thiện? [đóng cửa]

Tôi đã làm việc tại cùng một công ty phần mềm trong hơn mười năm. Kết quả là, tôi đã triển khai một cơ sở mã lớn bằng các ngôn ngữ lập trình hướng đối tượng khác nhau. Tôi là một lập trình viên mới bắt đầu khi tôi bắt đầu sự nghiệp và tôi không biết nhiều về các nguyên tắc thiết kế lớp và giao diện tốt. Tôi muốn nghĩ rằng các kỹ năng thiết kế của tôi đã được cải thiện theo thời gian, nhưng bây giờ tôi gặp phải nhiều khó khăn hơn trong việc cải thiện mã trước đây vì những lo ngại về khả năng tương thích ngược. Mã của tôi được sử dụng bởi một số lượng lớn khách hàng như một phần của các sản phẩm mà công ty tôi bán.

Câu hỏi của tôi là: khi nào nên ngừng cố gắng giữ khả năng tương thích ngược của các giao diện cũ và cắn viên đạn để ủng hộ thực hiện một thiết kế hoàn toàn mới?

Tôi nghĩ rằng có một điểm mà việc giữ khả năng tương thích ngược trở thành một gánh nặng lớn đến nỗi những thay đổi hữu ích đối với các giao diện trở nên không thể. Có ai có kinh nghiệm tương tự, ai có thể cung cấp một số thông tin phản hồi?

Trong khi "khi nào" là một câu hỏi hay, tôi nghĩ "làm thế nào" thậm chí còn phù hợp hơn. Có thể khó thực hiện chuyển đổi đột phá theo cách không khiến người dùng thất vọng hoặc không hài lòng. Một số mục để xem xét:

• Giao tiếp với khách hàng / khách hàng của bạn trước khi chuyển đổi. Giải thích tại sao và làm thế nào nó sẽ được thực hiện. Trích dẫn bảo mật, hiệu suất, ổn định và tính linh hoạt trong tương lai là lý do đều có giá trị.
• Nếu bạn đang thực hiện một nghỉ ngơi sạch sẽ, xin ý kiến ​​phản hồi.
• Nếu có bất kỳ nhà phát triển bên thứ 3 nào, hãy đảm bảo rằng bạn bao gồm đầu vào của họ cũng nhiều như vậy có ý nghĩa.
• Nếu có thể, hãy cung cấp một lớp tương thích.
• Cung cấp một hướng dẫn nâng cấp toàn diện.
• Làm cho việc nâng cấp dễ dàng và không đau đớn nhất có thể. Giảm thiểu nỗi đau của người dùng, ngay cả khi điều đó có nghĩa là bạn sẽ làm việc nhiều hơn một chút.
• Nếu bạn tính phí, hãy giảm giá để nâng cấp lên phiên bản mới.
• Thêm ít nhất một vài tính năng mới và hữu ích trong phiên bản mới để khuyến khích nâng cấp. Điều này đặc biệt quan trọng trong việc làm cho việc nâng cấp trở nên hấp dẫn hơn đối với các nhà quản lý.
• Nếu bạn nghỉ ngơi, hãy làm cho lần cuối bạn cần. Điều đó có nghĩa là một số kế hoạch toàn diện trước và đảm bảo rằng tất cả mọi thứ được thiết lập đúng.
• Nếu bạn có một giao diện người dùng, hãy dễ dàng thay đổi nó. Hãy suy nghĩ làm mới hơn là thiết kế lại. Đối với người dùng không có kỹ thuật, việc thay đổi giao diện người dùng mạnh mẽ từ phiên bản này sang phiên bản khác có thể là nguyên nhân lớn gây ra sự thất vọng.
• Phiên bản mới của bạn sẽ ổn định và hiệu suất hơn đáng kể so với phiên bản cũ. Đừng cho người dùng của bạn một lý do để bực bội nâng cấp. Không phát hành phiên bản mới mà không có thử nghiệm mở rộng trước đó (đơn vị, tích hợp và thử nghiệm beta).
• Duy trì phiên bản cũ đồng thời trong một khoảng thời gian dài. Nếu bạn quyết định loại bỏ nó và ngừng hỗ trợ, hãy thông báo ít nhất 6-12 tháng, nhiều hơn nếu bạn có thể.
• Bạn có đủ khả năng để duy trì hai phiên bản cùng một lúc về cả tài chính và nhân lực không? (Ngoài ra, từ góc độ kinh doanh, bạn không nên ngừng hỗ trợ phiên bản cũ cho đến khi bạn đủ khả năng để mất các khách hàng còn lại đang bám vào phiên bản cũ và không muốn nâng cấp. Đó là khi chi phí của bạn duy trì nó lớn hơn lợi nhuận của bạn từ nó.)
• Cam kết thực hiện cập nhật bảo mật trong một khoảng thời gian sau khi phiên bản cũ đã bị ngừng nếu cần thiết.
• Một lần nữa, truyền thông là rất lớn trong suốt quá trình. Đừng để người dùng / khách hàng / khách hàng của bạn cảm thấy bị bỏ rơi bất cứ lúc nào. Lòng trung thành và niềm đam mê của họ là nền tảng của doanh nghiệp của bạn. Hãy chắc chắn rằng bạn trả lời câu hỏi của họ trên blog hoặc trong diễn đàn của bạn. Yếu tố xã hội không nên được đánh giá thấp.

Đối với 'khi nào', có lẽ bạn sẽ có một ý tưởng tốt hơn cho ứng dụng của mình hơn bất kỳ ai khác. Tuy nhiên, nói chung, có lẽ đã đến lúc phải giải tỏa khi nợ kỹ thuật và kiến ​​trúc của bạn hoàn toàn ức chế sự ổn định, ngăn chặn hiệu suất hợp lý và làm cho việc phát triển các tính năng mới trở nên khó khăn hoặc không cần thiết.

Tất cả những gì đã nói, đừng thực hiện bước này nhẹ nhàng. Thậm chí được thực hiện đúng, phá vỡ khả năng tương thích ngược là một vấn đề lớn. Bạn nên cân nhắc mạnh mẽ việc tăng phạm vi kiểm tra và tái cấu trúc trước và nếu có thể trước khi xem xét nghỉ.

Nói chung tôi đồng ý với James Anderson. Tuy nhiên, theo kinh nghiệm của tôi, có những khía cạnh bổ sung có thể đảm bảo sự cân nhắc và điều đó có thể hướng đến một tùy chọn thực sự cho phép phát triển giao diện.

Ví dụ này là từ một trong những đội tôi đang làm việc cùng. Họ vận chuyển một sản phẩm một cách thường xuyên, ít nhất một lần mỗi tháng đôi khi thậm chí hàng tuần. Khách hàng được khuyến khích nâng cấp vì các tính năng mới và nền tảng mới chỉ được hỗ trợ trên các phiên bản mới hơn. Nâng cấp rất dễ dàng và khách hàng thậm chí có thể bỏ qua các phiên bản ở giữa. Hạ cấp không được hỗ trợ. Ngoài ra các phiên bản chỉ được hỗ trợ trong 3 năm. Sau đó, thời gian ân hạn là một năm khi phí bảo trì tăng gấp đôi.

Kết quả là đại đa số - khoảng 95% khách hàng - đang nâng cấp thường xuyên, ít nhất mỗi năm một lần. Điều này cũng có nghĩa là bạn có thể dần dần giới thiệu các giao diện mới.

Làm thế nào về giao diện cũ? Kỹ thuật mà nhóm này sử dụng là tuyên bố các giao diện cũ là 'cuối đời'. Sau đó, có một khoảng thời gian 12 tháng trong đó giao diện mới có sẵn và giao diện cũ chưa được nghỉ hưu. Các giao diện mới cung cấp các tính năng tốt hơn so với giao diện cũ, do đó, có hai ưu đãi: Giao diện cũ và giao diện mới tốt hơn nhiều.

Giao diện cũ cụ thể trong trường hợp này là một công nghệ dành riêng cho nền tảng đang trong quá trình dần dần được thay thế bằng giao diện dịch vụ dựa trên công nghệ chính thống tiêu chuẩn.

Tất nhiên sự thay đổi này không xảy ra trong đêm và phải mất nhiều năm cho đến khi hoàn thành. Nhưng nó cho phép dừng đầu tư vào công nghệ cũ và thay vào đó đầu tư vào công nghệ mới. Khách hàng được hỗ trợ và có một con đường phía trước. Hầu hết trong số họ đang chào đón sự chuyển hướng sang công nghệ mới hơn.

Tuy nhiên, hãy nhớ rằng phương pháp cụ thể này có thể không hoạt động trong kịch bản của bạn. Nó chắc chắn làm việc cho nhóm mà tôi đang làm việc.

Bạn đã có một số câu trả lời hay ở đây, vì vậy tôi chỉ muốn thêm một con trỏ vào một bài viết rất hay từ Joel Spolsky liên quan đến chủ đề này. Anh ta đang thảo luận về kế hoạch từ bỏ khả năng tương thích ngược trong IE 8, về cơ bản giống như vấn đề của bạn:

http://www.joelonsoftware.com/items/2008/03/17.html

Câu trả lời ngắn gọn là Không bao giờ!

Kinh nghiệm cho thấy rằng việc giảm khả năng tương thích ngược ít nhất gây khó chịu cho khách hàng và người dùng, và tệ hơn là mất hoàn toàn.

Nếu bạn đang yêu cầu người dùng viết lại mã, sau khi họ kết thúc lời nguyền thông thường của bạn và tất cả con cháu của bạn, họ sẽ nghĩ "Nếu tôi phải viết lại thì có lẽ tôi nên chuyển sang thư viện ACME tuyệt vời mà tôi đã đọc rất nhiều về? ".

Bí quyết là tăng cường giao diện hiện tại theo cách không phá vỡ khả năng tương thích ngược, hoặc, để cung cấp một giao diện hoàn toàn mới sáng bóng và rõ ràng vượt trội trong khi vẫn duy trì giao diện cũ. Tại một số điểm sẽ có các tính năng trong giao diện mới không thể có trong giao diện cũ, nhưng, điều này chỉ mang lại cho mọi người một động lực để di chuyển, mà không buộc vấn đề.

Chỉnh sửa để làm rõ điều này hơn nữa.

Những gì bạn là một lập trình viên nghĩ là -

"Tôi sẽ cải thiện API này và làm cho hệ thống tốt nhất có thể và mọi người sẽ ngưỡng mộ tôi".

Những gì người dùng API của bạn sẽ nghĩ là -

"A * * * e anh ấy nghĩ rằng thời gian và lịch trình của tôi không quan trọng. Tôi phải dừng những gì tôi đang làm và cấu trúc lại tất cả mã của tôi không vì lý do nào khác ngoài việc thỏa mãn cái tôi của anh ấy. Nếu tôi phải tái cấu trúc thì tôi sẽ chuyển đổi đến một API khác chỉ để gắn bó với anh ấy. "

Đây thực sự là một quyết định kinh doanh nhiều hơn là một kỹ thuật. Thông thường, điều này được thực hiện như một phần của bản phát hành chính (ví dụ: đi từ phiên bản 3.5 đến phiên bản 4.0) và thường hai phiên bản được hỗ trợ song song trong một thời gian. Điều này có nghĩa là bạn sẽ bảo trì phiên bản cũ nhưng tất cả các tính năng mới sẽ chỉ xuất hiện trong phiên bản mới. Phiên bản cũ được hỗ trợ miễn là công ty kiếm được tiền từ nó, hoặc ít nhất là đủ để bù đắp chi phí bảo trì. Hãy chuẩn bị để điều này để quản lý.

Tôi đã đứng về phía khách hàng của vấn đề này vì vậy tôi nói rằng điều đó thực sự phụ thuộc vào những gì bạn dự định làm về quá trình chuyển đổi.

Chúng tôi hiện đang nâng cấp hệ thống tài khoản của chúng tôi. Công ty thực hiện nâng cấp cũng hỗ trợ phiên bản không tương thích trước đó. Họ dự định lấy dữ liệu và chuyển nó sang hệ thống mới để (về lý thuyết) tất cả dữ liệu cũ sẽ ở đó. Chúng tôi sẽ trả vài trăm bảng cho việc chuyển đổi dữ liệu. Không vấn đề gì.

So sánh với một tình huống trước đây tại anothe RCompany tôi đã làm việc cho. Nhà cung cấp không có cách nào để chuyển từ hệ thống cũ sang hệ thống mới. Điều này đặt họ trong tình trạng giống như mọi nhà cung cấp khác. Trên thực tế, tình hình của họ tồi tệ hơn vì chúng tôi biết rằng họ không cam kết giúp chúng tôi nâng cấp. Họ đã không nhận được hợp đồng mới.

Bạn đã thực hiện công việc khó khăn trong việc giữ và giữ khách hàng, làm thế nào bạn có thể dễ dàng chuyển đổi?