Các thực tiễn tốt nhất để loại bỏ mã lỗi thời là gì?


9

Tôi có nhu cầu loại bỏ một phương pháp lỗi thời. Tôi nhận thức được [Obsolete]thuộc tính. Microsoft có hướng dẫn thực hành tốt nhất để làm việc này không?

Đây là kế hoạch hiện tại của tôi:

A. Tôi không muốn tạo ra một hội đồng mới bởi vì các nhà phát triển sẽ phải thêm một tài liệu tham khảo mới cho các dự án của họ và tôi hy vọng sẽ nhận được nhiều đau buồn từ ông chủ và đồng nghiệp của mình nếu họ phải làm điều này. Chúng tôi cũng không duy trì nhiều phiên bản lắp ráp. Chúng tôi chỉ sử dụng phiên bản mới nhất. Thay đổi cách làm này sẽ yêu cầu thay đổi quy trình triển khai của chúng tôi, đây là một vấn đề lớn (phải dạy mọi người cách làm mọi thứ với TFS thay vì FinalBuilder và khiến họ từ bỏ FinalBuilder)

B. Đánh dấu phương pháp cũ lỗi thời.

C. Vì việc triển khai đang thay đổi (không phải chữ ký phương thức), tôi cần đổi tên phương thức thay vì tạo quá tải. Vì vậy, để làm cho người dùng nhận thức được phương pháp thích hợp, tôi dự định thêm một thông điệp vào [Obsolete]thuộc tính. Phần này làm phiền tôi, bởi vì thay đổi duy nhất tôi đang thực hiện là tách phương thức khỏi chuỗi kết nối. Nhưng, bởi vì tôi không thêm một hội đồng mới, tôi không thấy cách nào khác.

Kết quả:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

Câu trả lời:


5

Microsoft sử dụng thuộc tính [lỗi thời] để thông báo cho các nhà phát triển rằng phương thức, thuộc tính hoặc lớp bị phản đối và có thể bị thay đổi (hoặc không được hỗ trợ) trong các bản phát hành trong tương lai.

Điều đó mang lại cho bạn ít nhất một chu kỳ phát hành để thông báo cho người dùng về API của bạn rằng tính năng của họ sẽ "biến mất" và xóa các tham chiếu đến nó trong các bản phát hành phần mềm của họ trong tương lai.

Thời gian bạn để lại tính năng ban đầu hoàn toàn phụ thuộc vào bạn. Nếu bạn muốn "khuyến khích mạnh mẽ" các nhà phát triển sử dụng các tính năng mới của bạn so với các tính năng cũ, bạn chỉ cần một chu kỳ phát hành bổ sung để xóa nó. Nếu bạn dự định có khả năng tương thích ngược vĩnh viễn, bạn có thể để nó mãi mãi.

Như Brian chỉ ra, nếu bạn chỉ thay đổi triển khai cơ bản, nhưng không phải chữ ký phương thức, bạn có thể không cần thực hiện bất kỳ điều nào trong số này.


Thông lệ của Microsoft nói chung là để loại bỏ một điều không được chấp nhận trong phiên bản chính tiếp theo. Ngược lại, Java không bao giờ loại bỏ những thứ không dùng nữa - vì vậy nó tùy thuộc vào bạn.
Scott C Wilson

Chúng tôi không phiên bản lắp ráp vượt quá cấp ứng dụng (1 ứng dụng khổng lồ với nhiều giải pháp). Kết hợp điều này với thực tế là # của các giải pháp phụ thuộc vào bất kỳ lắp ráp cụ thể nào là không xác định. Tôi không thể kiểm tra một ứng dụng mà tôi không biết. Nhưng, nếu tôi thực hiện một thay đổi gây ra sự cố cho ứng dụng mà tôi không biết ... đó là lỗi của tôi. Đây là lý do tại sao tôi đổi tên phương thức. Vì vậy, từ những gì tôi đã đọc cho đến nay không có cách nào tốt hơn để đi về điều này.
P.Brian.Mackey

4

Vì việc triển khai đang thay đổi (không phải chữ ký phương thức), tôi cần đổi tên phương thức thay vì tạo quá tải.

Tôi không hiểu Nếu việc triển khai thay đổi nhưng chữ ký thì không, tại sao bạn lại làm điều này? Hãy để phương thức "cũ" sử dụng triển khai mới và được cải thiện. Bất kỳ nhà phát triển nào sử dụng API này sẽ đảo mắt khi họ thấy một phương thức có cùng chữ ký được tạo và cảnh báo khấu hao đối với các lệnh gọi phương thức hiện có của họ. (Bạn có thể nghĩ về một thời gian điều này đã từng xảy ra trong một API không?)

Nếu bạn không chắc chắn nếu thay đổi triển khai cơ bản của phương pháp này sẽ hoạt động, hãy xác minh hành vi với các kiểm tra đơn vị trước và sau khi bạn thay đổi triển khai.


Đó là một lý tưởng tốt đẹp. Vấn đề là chúng tôi không có khai thác thử nghiệm tại chỗ. Đó là một vấn đề khác hoàn toàn mà tôi hy vọng sẽ được giải quyết. Vì vậy, vì không có thử nghiệm tích hợp, tôi không thể làm những gì bạn đề xuất. Có quá nhiều cơ sở chưa được xác định tại chỗ sẽ không được kiểm tra.
P.Brian.Mackey

Lý do tôi đề cập đến thử nghiệm là vì bạn rõ ràng muốn thực hiện việc này để những người tiêu thụ API của bạn sẽ thực hiện thử nghiệm và giúp bạn tìm ra bất kỳ vấn đề nào giữa 2 cuộc gọi. Tùy chọn tốt nhất của bạn dường như là ném các nhà phát triển sử dụng mã của bạn vào lửa và khiến họ sử dụng triển khai mới và hy vọng họ thực hiện QA kỹ lưỡng hoặc có các bài kiểm tra của riêng họ.
brian

Tôi sẽ ném mình vào lửa. Tôi thà gắn bó với mã gốc mà tôi đã đăng. Bằng cách đó, không ai gọi cho tôi lúc 3 giờ sáng, tự hỏi tại sao mã sản xuất bị hỏng. Sau đó, phụ thuộc vào các nhà phát triển để giải quyết lỗi thời mã khi họ đi qua và sửa chữa các cờ cảnh báo của họ. Nếu họ không sửa nó vào thời điểm đó, thì khi các chuỗi kết nối bắt đầu không thành công thì đó là lỗi của họ vì đã không sửa cờ cảnh báo của họ ... không phải của tôi.
P.Brian.Mackey

Bất cứ khi nào bạn viết mã mới, bạn có nguy cơ giới thiệu các vấn đề. Các xét nghiệm sẽ cho phép bạn tái cấu trúc mà không quá sợ hãi. Sợ hãi thường giết chết tư duy. Thêm vào đó bạn chỉ trì hoãn là không thể tránh khỏi; họ sẽ thêm "2" vào cuộc gọi của họ một vài lần lặp lại từ bây giờ và bạn sẽ nhận được cùng một cuộc gọi nếu nó không hoạt động.
brian
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.