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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

Это зависит. Да, вы МОЖЕТЕ реорганизовать код. МОЖЕТ ЛИ ВЫ?

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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