Использование устаревшего атрибута

Question

Мне недавно сказали, что это плохая практика - помечать несколько методов в нашем коде атрибутом [Obsolete].Эти методы были внутренними для нашей кодовой базы, а не на API.Методы обрабатывали более старую функцию шифрования.

Я чувствовал, что это был быстрый и безопасный способ показать остальным членам команды, что эти методы не следует использовать, и дал сообщение с предложением альтернатив.

Другие считали, что я должен был полностью удалить методы, переписать или реорганизовать существующий код по мере необходимости.Кроме того, считалось, что слишком просто игнорировать предупреждения компилятора.

Существует ли «наилучшая практика» для маркировки кода как устаревшего, когда он не используется третьими лицами?Или это в значительной степени субъективно?

Answer 1

Шаг 1. Пометьте элемент или класс как [Устаревшие]

Шаг 2. Обновите все внутренние применения элемента или класса, чтобы либо использовать новый подход, который заменяет устаревший подход, либо отметить этот элемент иликлассифицируйте себя как [устаревший]

Шаг 3. Если вы пометили новый материал как [устаревший] на шаге 2, повторите этот шаг при необходимости.

Шаг 4. Удалите все устаревшие элементы иклассы, которые не являются ни общедоступными, ни используются устаревшими общедоступными членами или классами.

Шаг 5. Обновите документацию, чтобы дать более четкое описание подхода, рекомендованного для замены любых общедоступных устаревших членов или классов.

В конце этого у вас не будет устаревшего кода, который используется исключительно внутренним кодом.Там нет ничего, чтобы сказать, что вы должны сделать все это за один раз, хотя;на каждом этапе вы добились прогресса.Время между началом шага 1 и завершением шага 5 может составлять 5 секунд или 5 лет, в зависимости от многих факторов (большинство из них связано со сложностью).

Кстати, если кому-то будет легко игнорировать предупреждения компилятора,проблема не в устаревшем.Тем не менее, одна из причин не оставлять такие вызовы в коде надолго (то есть сделать это как можно скорее до шага 2) состоит в том, чтобы убедиться, что люди не привыкнут к предупреждениям компилятора, поскольку они являются частьюпривычный ответ на компиляцию кода.

Answer 2

Я бы подумал, что это субъективно.Если он внутренний и довольно быстрый процесс, я бы внес изменение.

Однако у меня также была ситуация, когда соответствующий рефакторинг занимал намного больше времени (много вызовов по всей базе кода), и в этом случае я использовал атрибут [Obsolete].В этом случае новая разработка будет использовать новые функции, и тот, кто успел выполнить рефакторинг до тех пор, пока не исчезнут все вызовы, что означало, что метод можно было удалить.

Answer 3

Это зависит. Да, вы могли бы рефакторинг кода. ВЫ МОГЛИ?

Проблема в том, что вы можете РЕАКТОР ВНУТРИ ОДНОЙ ПРОГРАММЫ. Это намного сложнее, если API открыт для публики, и вы просто НЕ МОЖЕТЕ рефакторинг кода, используя ваш API. Это то, для чего сделан устаревший.

если API является внутренним для вашего кода, то рефакторинг - это путь. Очистите код, не оставляйте беспорядок.

Но если публичный API изменяется, это следует - если возможно - делать медленно.

Остальное все еще субъективно. Мне не нравится "Устаревший" для внутренних API.

Answer 4

Я использовал это раньше как временное состояние дел, когда у нас есть старый код, который необходимо реорганизовать в конечном итоге , но не срочно . Чаще всего это тот случай, когда был написан какой-то новый код, который делает работу лучше, чем то, что было до нее, но никто в команде не имеет времени вернуться и заменить много старого кода в данный момент. Очевидно, это подразумевает ситуацию, в которой простая замена встраиваемых программ не возможна сразу (иногда новый код выполняет почти все, что делал старый код, но есть небольшая часть функциональности, которая еще не была реализована) .

Тогда все эти предупреждения компилятора будут напоминать о том, что кто-то должен вернуться и завершить рефакторинг, когда у него будет немного свободного времени.

Является ли это действительно хорошей или плохой вещью, довольно субъективно. Это инструмент, как и любой другой.

Answer 5

Это не простой случай.Если вы удалите методы из работающего приложения и проведете рефакторинг кода, вы создадите возможность появления новых ошибок и поломки работающего приложения.Если это приложение критически важно, воздействие может быть огромным и стоить компании больших денег, подобные изменения должны быть тщательно спланированы и протестированы.В этом случае маркировка устаревших методов может стоить того, чтобы они не позволяли людям использовать их в дальнейшей разработке, что облегчает последующий рефакторинг.Однако если приложение не является критически важным или если вероятность появления ошибок невелика, то может быть лучше провести рефакторинг, если у вас есть время.В конечном итоге добавление атрибута [Obsolete] немного похоже на задачу, и его использование зависит от многих факторов.