Bao lâu để chờ đợi trước khi xóa một phương pháp không dùng nữa? [đóng cửa]

Tôi đang duy trì API công khai và phải từ chối một phương pháp.

Có một quy tắc chung về bao nhiêu tháng / năm / phiên bản trước khi xóa tôi nên từ chối một phương pháp?

Tối thiểu, bạn nên giữ các phương thức không dùng nữa trong một phiên bản trước khi loại bỏ chúng, điều này có vẻ hiển nhiên khi tôi viết nó ra. Tôi không nghĩ có một thời gian tối đa nhưng nếu bạn không bao giờ thực sự loại bỏ chúng, sự phản đối sẽ trở nên vô nghĩa.

Các phiên bản chính là thời điểm tốt để loại bỏ các phương pháp không dùng nữa. Các bản phát hành nhỏ thường không chứa các thay đổi vi phạm. Như cHao đã lưu ý trong các bình luận, sự phản đối không nhất thiết ngụ ý rằng sẽ có một sự loại bỏ cuối cùng vì vậy nếu bạn có kế hoạch loại bỏ mọi thứ sau khi phản đối, bạn nên lưu ý rõ ràng và cung cấp một số hướng dẫn về dòng thời gian.

Điều này chỉ phụ thuộc vào loại ổn định nào đảm bảo bạn đã cung cấp cho người dùng của mình và mức độ đau đớn mà bạn muốn gây ra cho người dùng của mình.

Lý tưởng nhất, API của bạn sử dụng semver để bất kỳ thay đổi vi phạm nào làm cho số phiên bản chính được tăng lên. Trong thực tế, nó là mong muốn để làm điều này gần như không bao giờ. Nếu API của bạn được cài đặt thông qua một số trình quản lý gói, bạn có thể muốn tạo một tên gói mới sau khi thay đổi vi phạm để nâng cấp đơn giản không gây ra xung đột (ví dụ myapi2 v2.123.4so với myapi3 v3.2.1). Điều đó có thể không cần thiết nếu trình quản lý gói của bạn hỗ trợ các phụ thuộc phiên bản chặt chẽ hơn (ví dụ: một đặc tả phụ thuộc như thế ~v2.120không bao gồm v3.*), nhưng các tên gói khác nhau có lợi thế là các phiên bản không tương thích có thể được sử dụng cạnh nhau rất dễ dàng. Ngay cả khi sử dụng semver, nó có thể hợp lý để có một khoảng thời gian khấu hao.

Semver không phải lúc nào cũng được áp dụng. Sau đó, điều quan trọng hơn là truyền đạt một chính sách ổn định rõ ràng. Ví dụ:

• Các tính năng thử nghiệm có thể được gỡ bỏ mà không cần thông báo trước.
• Các tính năng có thể bị xóa vì lý do bảo mật bất cứ lúc nào.
• Các tính năng khác sẽ chỉ bị xóa
  • Sau khi bị từ chối trong một phiên bản phát hành
  • Phiên bản mà phiên bản đó ít nhất ba tháng tuổi
  • Càng và sẽ được đánh dấu bằng một vết sưng trong phiên bản chính.

Các chính sách này hoạt động đặc biệt tốt khi bạn có các bản phát hành thường xuyên để có thời gian khấu hao rõ ràng, ví dụ: một năm.

Ngoài việc đánh dấu bất kỳ phần nào của API là không dùng nữa, bạn nên làm cho sự phản đối được biết đến rộng rãi. Ví dụ:

• Có một phần trong danh sách thay đổi của bạn về các hướng và sự phản đối trong tương lai.
• Phát tán ý định của bạn để phản đối trước khi bạn thực hiện phản đối và lắng nghe cộng đồng để xem liệu có sự phản đối đáng kể nào không.
• Truyền đạt những lợi ích sẽ đến từ những thay đổi này. Tùy thuộc vào cơ sở người dùng của bạn, bản tin, bài thuyết trình, bài đăng trên blog hoặc thông cáo báo chí có thể là phương tiện phù hợp. Có một spin spin chúng tôi đang tạo ra một tính năng mới tuyệt vời! (đòi hỏi phải loại bỏ tính năng cũ được sử dụng rộng rãi này). Ít khó chịu hơn một chút so với loại bỏ một tính năng không có ngữ cảnh.

Về thời gian khấu hao chính xác để lựa chọn, trước tiên hãy xem liệu bạn có phải tôn trọng bất kỳ hợp đồng hỗ trợ nào với người dùng của mình không. Những hợp đồng như vậy có thể yêu cầu bạn duy trì khả năng tương thích trong một khoảng thời gian. Nếu không, xem xét bất kỳ tác động hạ lưu. Cố gắng thay đổi ít nhanh hơn so với người dùng xuôi dòng để họ có thể trải qua chu kỳ khấu hao của chính họ. Người dùng xuôi dòng sẽ mất một chút thời gian để thích ứng với các thay đổi của bạn, vì vậy bạn sẽ không bao giờ có thời gian khấu hao ngắn hơn một tháng.

Lý tưởng nhất là bạn sẽ muốn đợi cho đến khi không còn ai sử dụng phương pháp không dùng nữa. Xem xét bạn đang sử dụng API công khai, điều đó dễ theo dõi, nhưng bạn có thể sẽ phải chờ rất lâu.

vào năm 2015, Google đã gặp vấn đề tương tự với API stlport trên HĐH Android của họ. Họ đã phản đối và muốn xóa nó, nhưng hàng tấn ứng dụng vẫn đang sử dụng nó. Họ tìm thấy một giải pháp thông minh:

Về cơ bản, họ đã thêm một giấc ngủ 8 giây () trong quá trình khởi động của bất kỳ ứng dụng nào vẫn sử dụng API với thông báo nhật ký thích hợp cho các nhà phát triển. Một tháng sau, họ nhân đôi nó lên 16 giây. sau đó một tháng nữa, họ có thể gỡ bỏ giao diện API một cách an toàn vì không còn ai sử dụng nó.

Đây có thể là một cách rất hiệu quả để làm điều này. Vấn đề thực sự duy nhất là nếu API của bạn rất cũ và đã sử dụng tích cực người tiêu dùng không còn được hỗ trợ tích cực. Thật không may, có lẽ bạn sẽ không thể tự khắc phục những người tiêu dùng như vậy, nhưng tại thời điểm đó, bạn thực sự không thể làm gì hơn là xóa phương thức và phá vỡ người tiêu dùng.

Thời gian tối thiểu để cung cấp các phương thức không dùng nữa phụ thuộc vào chu kỳ phát triển của các chương trình sử dụng API của bạn. Là một con số trên sân bóng, 1 năm là đủ.

Về thời gian tối đa trước khi bạn phải loại bỏ các phương pháp không dùng nữa, tôi cho rằng không có điều đó. Cho dù bạn chờ đợi bao lâu, loại bỏ một phương pháp không dùng nữa sẽ luôn phá vỡ một cái gì đó. Một số chương trình sử dụng API không dùng nữa của bạn không được duy trì tích cực và việc phá vỡ tính tương thích sẽ có nghĩa là hết tuổi thọ cho các chương trình đó.

Tôi khuyên bạn nên xóa các phương thức không dùng nữa khi bạn đạt được điều gì đó từ việc xóa :

• một lỗi được phát hiện ảnh hưởng đến các phương pháp không dùng nữa
• bạn sắp sửa cấu trúc lại mã và duy trì các phương thức không dùng nữa sẽ đòi hỏi nỗ lực đáng kể
• bạn đang tối ưu hóa cấu trúc bên trong của thư viện và các phương pháp không dùng nữa không phù hợp nữa.

Loại bỏ các phương pháp không dùng nữa chỉ vì chúng không được dùng trong X tháng / năm hoặc vì bạn đang phát hành một phiên bản mới với mức độ tùy tiện gây hại cho khả năng tương thích mà không có lý do chính đáng.

Trước tiên, bạn nên xem xét liệu bạn muốn phản đối hay lỗi thời.

Không dùng nữa nên được sử dụng cho các phương pháp có hại theo cách nào đó: bảo mật, hiệu suất, kết quả không chính xác. Bạn muốn loại bỏ chúng tương đối nhanh chóng, không quá 2 phiên bản chính và đi thứ 3. Đối với các vấn đề đủ quan trọng, không dùng nữa có thể bị xóa trong phiên bản nhỏ tiếp theo.

Lỗi thời là vì những thứ ít hữu ích hơn vì một số lý do, ví dụ trả về ít thông tin hơn hoặc không hoạt động tốt, không bao gồm nhiều tùy chọn và vv. Chúng có thể treo xung quanh vô thời hạn, nhưng tối thiểu phải có mặt trong phiên bản chính tiếp theo.

Câu trả lời phụ thuộc vào loại dịch vụ bạn đang cung cấp cho khách hàng của bạn.

Ở một đầu cực đoan, có những sai lầm trong Windows.h từ kỷ nguyên Win 3.1 đã lan truyền trong hai thập kỷ vì Microsoft tin tưởng rất mạnh mẽ vào khả năng tương thích ngược.

Ở đầu kia của phổ, nhiều ứng dụng web xóa các tính năng mà không đưa ra cảnh báo phản đối.

Khách hàng của bạn trả bao nhiêu cho phần mềm của bạn thường là vấn đề, cũng như công việc của họ. Các nhà khoa học nghiên cứu thường sẵn sàng chấp nhận sự phản đối như là một phần của sự tiến bộ hơn là, các chủ ngân hàng hoặc FAA.

Tôi đã làm việc cho một công ty phát triển phần mềm để sử dụng nội bộ. Tôi đã hỗ trợ nhiều nhóm trong những năm qua. Một nhóm có tâm lý "không bao giờ loại bỏ bất kỳ tính năng". Họ cần khả năng quay lại các tệp 5-10 năm trước và phân tích chúng về thời gian quá nhanh để khiến các nhà phát triển đưa các tính năng trở lại. Thái độ của một nhóm là "đảm bảo tất cả các phản đối đều nằm trong ghi chú vá, vì vậy chúng tôi có thể tìm thấy chúng sau. " Ở giữa, chúng tôi có một nhóm có quy tắc là "Các tính năng phải không được chấp nhận cho ít nhất 1 phiên bản có cảnh báo được in nếu chúng được sử dụng trước khi xóa chúng." Nhóm đó có một bộ thử nghiệm bao gồm các tính năng họ cần. Bất cứ khi nào chúng tôi phát hành một phiên bản mới, họ nhanh chóng chạy bộ thử nghiệm của họ để xem liệu có bất kỳ sự phản đối nào khiến họ gặp rắc rối không.

Tôi đang duy trì API công khai và phải từ chối một phương pháp.

Tại sao bạn cần phải làm điều này? Có phải vì có một cách sáng bóng mới để làm mọi thứ, nên phương pháp cũ bây giờ không được khuyến khích, nhưng vẫn hoạt động tốt? Hay phương pháp cũ thực sự cần phải đi bởi vì mọi thứ đã thay đổi về cơ bản?

• Nếu phương pháp cũ không gây ra bất kỳ vấn đề thực tế nào và có thể xảy ra , thì nó cũng có thể. Nếu không bị hỏng, đừng sửa nó. Bạn có thực sự cần phải loại bỏ nó? Có thể đánh dấu nó là lỗi thời và bao gồm một ghi chú trong tài liệu rằng một phương pháp khác có thể hiệu quả hơn, hoặc bất cứ điều gì, nhưng có lẽ tốt để giữ nó đúng chỗ.

• Nếu phương pháp cũ thực sự cần phải đi, bởi vì nó khiến bạn phải đau đầu bảo trì hoặc vì đơn giản là nó không còn ý nghĩa do những thay đổi khác, thì hãy theo dõi việc sử dụng nó và truyền đạt sự phản đối rõ ràng cho khách hàng. Cung cấp cho họ một ngày rõ ràng sau đó phương pháp sẽ được gỡ bỏ. (Lý tưởng nhất là không thực sự xóa nó ngay lập tức vào ngày này: đợi cho đến khi không ai còn sử dụng nó trước khi thực sự gỡ bỏ nó. Nó có thể cần phải đi sớm hơn, nếu nó thực sự gây ra sự cố, nhưng ít nhất hãy đợi việc sử dụng giảm xuống ít.)

• Nếu phương thức cũ gây ra sự cố bảo mật, bạn có thể cần phải di chuyển nhanh hơn thế, thậm chí có thể xóa nó mà không cần cảnh báo, nhưng bạn nên ghi lại sự thay đổi này ở đâu đó rất rõ ràng và cũng trả lại các thông báo hợp lý cho khách hàng cố gắng sử dụng phương thức cũ.

(Hai gạch đầu dòng thứ hai được bao phủ tốt trong các câu trả lời khác, nhưng tôi nghĩ rằng điểm đầu tiên là mới.)

Đối với một dự án công cộng, chỉ loại bỏ nó khi và chỉ khi bạn cần.

Khi bạn thực hiện xóa API không cần thiết, bạn sẽ phải trả tiền cho các công ty và nhà thầu theo cách mà bạn thậm chí không thể tính toán được do chi phí rất cao.

Bạn muốn các công ty và lập trình viên độc lập ngừng sử dụng dự án của bạn? Phá vỡ công cụ của họ đủ lần khi bạn không cần thiết và bạn sẽ ở trong chiếc thuyền đó ngay lập tức.

deprecation != eventual_removal. Nếu một API nguy hiểm, bạn loại bỏ nó. Nếu nó chỉ cũ, hãy để nó và ghi lại sự thay thế của nó.