Які найкращі практики для поетапного припинення застарілого коду?


9

У мене є необхідність припинити застарілий метод. Я знаю [Obsolete]атрибут. Чи має Microsoft рекомендований посібник з найкращих практик для цього?

Ось мій поточний план:

А. Я не хочу створювати нову асамблею, тому що розробники повинні були б додати нове посилання на свої проекти, і я очікую, що отримаю багато горя від мого шефа та колег, якщо вони повинні це зробити. Ми також не підтримуємо кілька варіантів складання. Ми використовуємо лише останню версію. Зміна цієї практики вимагає змінити наш процес розгортання, що є великою проблемою (доведеться навчити людей, як робити справи з TFS замість FinalBuilder, і змусити їх відмовитися від FinalBuilder)

В. Позначте старий метод застарілим.

C. Оскільки реалізація змінюється (не підпис методу), мені потрібно перейменувати метод, а не створювати перевантаження. Отже, щоб зрозуміти користувачів про правильний метод, я планую додати повідомлення до [Obsolete]атрибуту. Ця частина мене турбує, тому що єдиною зміною, яку я вношу, є роз'єднання методу від рядка з'єднання. Але, оскільки я не додаю нової збірки, я не бачу цього шляху.

Результат:

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

Відповіді:


5

Microsoft використовує атрибут [застарілий], щоб повідомити розробникам, що метод, властивість або клас застаріли і можуть бути змінені (або зовсім не підтримуються) у майбутніх випусках.

Це дає вам принаймні один цикл випуску повідомляти користувачів вашого API про те, що їх функція "відходить" та видалити посилання на неї в майбутніх випусках їх програмного забезпечення.

Як довго ви залишатимете оригінальну функцію, залежить тільки від вас. Якщо ви хочете "настійно заохотити" розробників використовувати ваші нові функції над старими, вам потрібно лише один додатковий цикл випуску, щоб видалити його. Якщо ви маєте намір мати постійну зворотну сумісність, ви можете залишити її назавжди.

Як зазначає Брайан, якщо ви змінюєте лише базову реалізацію, але не підпис методу, вам може не потрібно взагалі нічого робити.


Практика Microsoft, як правило, видаляє застарілу річ у наступному великому випуску. Навпаки, Java ніколи не знімає застарілі речі - тож саме вам належить.
Скотт C Вілсон

Ми не версії збірок за межі додаткового рівня (1 гігантська програма з багатьма рішеннями). Поєднайте це з тим, що кількість рішень, які залежать від будь-якої збірки, не визначена. Я не можу перевірити програму, про яку я не знаю. Але якщо я внесу зміни, які спричинить злом програми, про яку я не знаю ... ну, це моя вина. Саме тому я перейменував метод. Отже, з того, що я читав до цього часу, немає кращого способу зробити це.
P.Brian.Mackey

4

Оскільки реалізація змінюється (не підпис методу), мені потрібно перейменувати метод, а не створювати перевантаження.

Я не розумію. Якщо реалізація змінюється, але підпис відсутній, навіщо вам це робити? Нехай "старий" метод використовує нову та вдосконалену реалізацію. Будь-які розробники, які споживають цей API, переглянуть очі, коли побачать метод із точно створеною такою ж підписом та попередження про депрекацію на їхніх існуючих викликах методів. (Чи можете ви придумати час, коли це коли-небудь траплялося в API?)

Якщо ви не впевнені в тому, що зміна основної реалізації цього методу буде спрацьовувати, перевіряйте поведінку за допомогою модульних тестів до та після зміни реалізації.


Це приємний ідеал. Справа в тому, що у нас немає тестових джгутів. Це ще одне питання, яке я сподіваюся вирішити. Отже, оскільки немає інтеграційного тестування, я не можу робити те, що ви рекомендуєте. Існує занадто багато ще не визначених покарань, які залишаться неперевіреними.
P.Brian.Mackey

Причина, про яку я згадував тестування, полягає в тому, що ви, очевидно, хотіли це зробити, щоб ті, хто споживає ваш API, зробили тестування і допоможуть вам з’ясувати будь-які проблеми між двома дзвінками. Здається, найкращим варіантом є кинути розробників, використовуючи ваш код у вогонь, і змусити їх використовувати нову реалізацію, і сподіваюся, що вони роблять ретельний QA або мають власні тести.
Брайан

Я б кинувся у вогонь. Я вважаю за краще дотримуватися оригінального коду, який я розмістив. Таким чином, ніхто не дзвонить мені о 3 ранку, дивуючись, чому зламався виробничий код. Тоді залежати від розробників, щоб вирішити застарілість коду під час проходження та ремонту своїх попереджувальних прапорів. Якщо вони не виправлять це в той момент, тоді, коли ланцюги з'єднання починають виходити з ладу, їхня вина, що вони не відремонтують свої попереджувальні прапори ... не моя.
P.Brian.Mackey

Щоразу, коли ви пишете новий код, ви ризикуєте виникнути проблеми. Тести дозволять вам рефактор, не так боячись. Страх - вбивця розуму. Плюс ти просто затягуєш неминуче; вони будуть з грубою допомогою додавати "2" до свого дзвінка через кілька повторень, і ви отримаєте той самий телефонний дзвінок, якщо він не працює.
Брайан
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.