Статьи

Безопасно устаревшие API

Устаревание — это позиция в жизненном цикле разработки программного обеспечения, где необходимо удалить или отказаться от определенной функции, поскольку она устарела. Устаревшие функции не устранены сразу; скорее они сохраняются, но выдают предупреждающие сообщения, которые рекомендуют использовать альтернативные методы. Это дает пользователям время обновить свой код, прежде чем ненужный код будет окончательно удален.

Устаревание может происходить по разным причинам — возможно, API больше не является полезным и его срок службы истек, или рефакторинг кода для улучшения его повторного использования и тестируемости устаревает конкретными методами.

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

Подготовка к рефакторингу

Хотя это утомительно, сначала убедитесь, что вы документировали свой код. Это поможет вам лучше понять, какой код отвечает за какую функциональность и как он функционирует в целом. Используйте стандартизированный формат документа, чтобы он мог использоваться вашей IDE и легко компилироваться в удобочитаемую документацию.

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

Используйте принцип единой ответственности

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

Общайтесь с вашими пользователями

В зависимости от размера вашей пользовательской базы, установление хорошего общения может быть затруднено. Хорошим решением является создание списка рассылки, на который они могут подписаться. Период времени, в течение которого вы можете разрешить пользователям продолжать использовать старые методы после объявления о предполагаемых изменениях в списке, зависит от таких факторов, как важность и причина внесения изменений.
В зависимости от вашего API и ресурсов, доступных для вашего проекта, также может быть полезно разместить вики проекта, где разработчики могут делиться альтернативными стратегиями и обходными путями, чтобы избежать устаревших вызовов методов.

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

Удалить старый код

После внесения необходимых изменений обязательно внимательно прочитайте код, чтобы убедиться, что ненужный, неиспользованный или старый код можно безопасно удалить. Инструменты анализа кода также могут быть полезны.

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

Резюме

Устаревание может улучшить внутреннюю согласованность веб-службы или библиотеки в программном коде, его структуре или пользовательском интерфейсе. Это облегчает пользователям понимание того, как работает система, снижая стоимость разработки новой системы.
Рефакторинг помогает улучшить взаимодействие с пользователем вашего API и облегчает реализацию будущих изменений в вашем коде. Код становится более пригодным для повторного использования и тестирования. Но процесс рефакторинга также означает некоторый код, потому что он не нужен и должен быть удален, чтобы сохранить проект в чистоте.

Устаревшие функции до того, как они будут устранены или преобразованы, дают пользователям, которые зависят от вашего кода, время для обновления своего собственного кода. Следуя советам, приведенным в этой статье, вам будет проще поддерживать свежий код, и у ваших пользователей не будет неприятных сюрпризов.

Изображение через Fotolia