Apa praktik terbaik untuk menghapus kode usang?


9

Saya perlu menghapus metode yang usang. Saya tahu [Obsolete]atributnya. Apakah Microsoft memiliki panduan praktik terbaik yang disarankan untuk melakukan ini?

Inilah rencana saya saat ini:

A. Saya tidak ingin membuat majelis baru karena pengembang harus menambahkan referensi baru ke proyek mereka dan saya berharap mendapatkan banyak kesedihan dari bos dan rekan kerja saya jika mereka harus melakukan ini. Kami juga tidak mempertahankan beberapa versi perakitan. Kami hanya menggunakan versi terbaru. Mengubah praktik ini akan membutuhkan perubahan proses penerapan kami yang merupakan masalah besar (harus mengajarkan orang bagaimana melakukan sesuatu dengan TFS, bukan FinalBuilder dan membuat mereka menyerah FinalBuilder)

B. Tandai metode lama sudah usang.

C. Karena implementasinya berubah (bukan metode tanda tangan), saya perlu mengganti nama metode daripada membuat kelebihan. Jadi, untuk membuat pengguna mengetahui metode yang tepat, saya berencana untuk menambahkan pesan ke [Obsolete]atribut. Bagian ini mengganggu saya, karena satu-satunya perubahan yang saya lakukan adalah memisahkan metode dari string koneksi. Tapi, karena saya tidak menambahkan majelis baru, saya tidak melihat jalan keluarnya.

Hasil:

[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.
        }

Jawaban:


5

Microsoft menggunakan atribut [usang] untuk memberi tahu pengembang bahwa metode, properti, atau kelas sudah usang, dan dapat diubah (atau tidak didukung sama sekali) di rilis mendatang.

Itu memberi Anda setidaknya satu siklus rilis untuk memberi tahu pengguna API Anda bahwa fitur mereka "akan pergi," dan untuk menghapus referensi untuknya dalam rilis perangkat lunak mereka di masa mendatang.

Berapa lama Anda meninggalkan fitur asli sepenuhnya terserah Anda. Jika Anda ingin "sangat mendorong" pengembang untuk menggunakan fitur baru Anda di atas yang lama, Anda hanya perlu satu siklus rilis tambahan untuk menghapusnya. Jika Anda bermaksud memiliki kompatibilitas mundur permanen, Anda dapat membiarkannya selamanya.

Seperti yang ditunjukkan Brian, jika Anda hanya mengubah implementasi yang mendasarinya, tetapi tidak menggunakan metode signature, Anda mungkin tidak perlu melakukan ini sama sekali.


Praktik Microsoft umumnya untuk menghapus hal yang usang dalam rilis besar berikutnya. Sebaliknya, Java tidak pernah menghapus hal-hal yang sudah usang - jadi terserah Anda.
Scott C Wilson

Kami tidak versi majelis di luar level aplikasi (1 aplikasi raksasa dengan banyak solusi). Gabungkan ini dengan fakta bahwa # solusi yang bergantung pada rakitan yang diberikan tidak ditentukan. Saya tidak dapat menguji aplikasi yang tidak saya ketahui. Tapi, jika saya melakukan perubahan yang menyebabkan kerusakan aplikasi yang saya tidak tahu ... yah itu salah saya. Inilah sebabnya saya mengganti nama metode. Jadi, dari apa yang saya baca sejauh ini, tidak ada cara yang lebih baik untuk membahas hal ini.
P.Brian.Mackey

4

Karena implementasinya berubah (bukan metode tanda tangan), saya perlu mengganti nama metode daripada membuat kelebihan.

Saya tidak mengerti. Jika implementasinya berubah tetapi tanda tangannya tidak, mengapa Anda melakukan ini? Biarkan metode "lama" menggunakan implementasi yang baru dan lebih baik. Setiap pengembang yang menggunakan API ini akan memutar mata mereka ketika mereka melihat metode dengan tanda tangan yang sama persis dibuat dan peringatan penghentian pada panggilan metode yang ada. (Dapatkah Anda memikirkan saat ini pernah terjadi dalam API?)

Jika Anda tidak yakin apakah mengubah implementasi yang mendasari metode ini akan berhasil, verifikasi perilaku dengan unit test sebelum dan setelah Anda mengubah implementasi.


Itu ide yang bagus. Masalahnya adalah kita tidak memiliki harness pengujian. Itu adalah masalah lain yang saya harap bisa diselesaikan. Jadi karena tidak ada pengujian integrasi, saya tidak bisa melakukan apa yang Anda rekomendasikan. Ada terlalu banyak hal yang belum terdefinisi di tempat yang tidak akan diuji.
P.Brian.Mackey

Alasan saya menyebutkan pengujian adalah karena Anda jelas ingin melakukan ini sehingga mereka yang menggunakan API Anda akan melakukan pengujian dan membantu Anda mengetahui masalah apa pun di antara 2 panggilan. Pilihan terbaik Anda tampaknya melemparkan pengembang menggunakan kode Anda ke api dan membuat mereka menggunakan implementasi baru dan berharap mereka melakukan QA menyeluruh atau memiliki tes sendiri.
brian

Saya akan melemparkan diri ke dalam api. Saya lebih suka tetap dengan kode asli yang saya posting. Dengan begitu tidak ada yang menelepon saya jam 3 pagi bertanya-tanya mengapa kode produksi rusak. Kemudian, bergantung pada pengembang untuk menyelesaikan kode usang saat mereka melewati dan memperbaiki bendera peringatan mereka. Jika mereka tidak memperbaikinya pada saat itu, maka ketika string koneksi mulai gagal pada mereka itu kesalahan mereka karena tidak memperbaiki bendera peringatan mereka ... bukan milikku.
P.Brian.Mackey

Setiap kali Anda menulis kode baru, Anda berisiko menimbulkan masalah. Tes akan membiarkan Anda melakukan refactor tanpa merasa takut. Ketakutan adalah pembunuh pikiran. Plus Anda hanya menunda yang tak terhindarkan; mereka akan dengan enggan menambahkan "2" ke panggilan mereka beberapa iterasi dari sekarang dan Anda akan mendapatkan panggilan telepon yang sama jika itu tidak berhasil.
brian
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.