Как обычно, прежде чем начать изложение, дадим смысловое определение понятию «обратная совместимость».
Обратная совместимость — это способность всей системы API оставаться стабильной с течением времени.
Это означает следующее: код, написанный разработчиками с использованием вашего API, продолжает работать функционально правильно с течением времени.
.
К этому определению есть два больших вопроса и два пояснения к ним.
- Что значит «функционально правильно»? Это значит, что код продолжает выполнять свою функцию — решать какую-то задачу пользователя.
Это не означает, что он продолжает работать так же: например, если вы предоставляете библиотеку пользовательского интерфейса, изменение функционально неважных деталей дизайна, таких как глубина тени или форма обводки границы, не нарушит обратную совместимость.
Но, например, изменение размера визуальных компонентов, скорее всего, приведет к тому, что некоторые пользовательские макеты развалятся.
- Что значит «долго»? С нашей точки зрения, продолжительность поддержания обратной совместимости должна быть связана с длительностью жизненного цикла приложения в соответствующей предметной области.
Хорошим ориентиром в большинстве случаев являются периоды LTS платформ.
Поскольку приложение все равно будет переписано в связи с прекращением поддержки платформы, то вполне нормально также предложить переход на новую версию API. В основных предметных областях (настольные и мобильные операционные системы) этот период исчисляется несколькими годами.
Прекращение работы приложения (полного или частичного) по вине провайдера API — крайне неприятное событие, если не катастрофа, для любого разработчика, особенно если он платит деньги за это API. Но давайте теперь повернем проблему в другую сторону: почему возникла проблема с сохранением обратной совместимости? Почему мы можем хотеть разбить его? Ответ на этот вопрос, хотя и кажется простым, гораздо сложнее предыдущего.
Мы могли бы сказать, что обратная совместимость должна быть нарушена, чтобы расширить функциональность API .
Но это хитро: новый функционал новый , что он не может повлиять на код приложения, который его не использует. Да, конечно, есть ряд сопутствующих проблем, которые приводят к желанию переписать наш code, код самого API, с выходом новой мажорной версии:
- код просто устарел, вносить в него изменения, даже в виде расширения функционала, нецелесообразно;
- в старом интерфейсе не был предусмотрен новый функционал: мы хотели бы наделить существующие сущности новыми свойствами, но не можем;
- Наконец, за время, прошедшее с момента первого выпуска, мы узнали гораздо больше о предметной области и практике использования нашего API, и многие вещи мы бы сделали по-другому.
Но и это объяснение неполное: даже если вы не собираетесь переписывать код API при добавлении нового функционала или вообще не собирались его добавлять, вам все равно придется выпускать новые версии API — мажорную и минорную.
Н.
Б.
: в рамках данной главы мы не делаем различия между минорными версиями и патчами: под словами «минорная версия» мы подразумеваем любой обратно совместимый релиз API. Напомним, что API — это мост , средство соединения различных программируемых контекстов.
И как бы нам ни хотелось починить конструкцию моста, наши возможности ограничены: мы можем починить мост, но не можем починить края ущелья, как и само ущелье.
В этом корень проблемы: мы не можем уйти мой код не изменился, поэтому рано или поздно нам придется потребовать от клиентов изменения мой .
Помимо наших собственных усилий по изменению архитектуры API, одновременно происходят три других тектонических процесса: эрозия клиентов, домена и базовой платформы.
Фрагментация клиентских приложений
В тот момент, когда вы выпустите первую версию API и первые клиенты начнут его использовать, ситуация идеальна.Версия одна, и все клиенты с ней работают. Но тогда возможны два сценария:
- Если платформа поддерживает получение кода по требованию, как старый добрый Веб, и вы не поленитесь реализовать этот поиск кода (в виде платформенного SDK, например, JS API), то разработка API более или менее под вашим контролем.
Поддержание обратной совместимости сводится к поддержанию обратной совместимости.
клиентская библиотека , но в плане серверного и клиент-серверного взаимодействия вы свободны.
Это не означает, что вы не можете нарушить обратную совместимость — вы все равно можете испортить заголовки кэширования SDK или просто допустить ошибку в коде.
Кроме того, даже системы по требованию до сих пор не обновляются мгновенно - автор столкнулся с ситуацией, когда пользователи намеренно держали вкладку браузера открытой неделями , чтобы не обновляться до новых версий.
Однако вам почти никогда не придется поддерживать более двух (последних и предпоследних) второстепенных версий клиентского SDK. Более того, вы можете в какой-то момент попробовать переписать предыдущую мажорную версию библиотеки, реализовав ее на основе API новой версии.
- Если поддержка платформой кода по требованию не поддерживается или запрещена условиями, как это произошло с современными мобильными платформами, то ситуация значительно усложняется.
По сути, каждый клиент — это «снимок» кода, работающего с вашим API, зафиксированный в том состоянии, в котором он находился на момент компиляции.
Обновление клиентских приложений занимает гораздо больше времени, чем обновление веб-приложений; самое обидное, что некоторые клиенты никогда не будет обновляться вообще - по одной из трех причин:
- разработчики просто не выпускают новую версию приложения, его разработка заморожена;
- пользователь не хочет обновляться (в том числе потому, что, по мнению пользователя, разработчики приложения «угробили» его в новых версиях);
- пользователь вообще не может обновиться, поскольку его устройство больше не поддерживается.
В современных реалиях все три категории в совокупности легко могут составлять десятки процентов аудитории.
Это означает, что прекращение поддержки любой версии API — очень заметное событие, особенно если приложения вашего разработчика поддерживают более широкий диапазон версий платформы, чем ваш API. Вы можете вообще не выпускать какой-либо SDK, предоставляя только серверный API в виде, например, конечных точек HTTP. Вы можете подумать, что таким образом, хотя ваш API менее конкурентоспособен на рынке из-за отсутствия SDK, вы облегчили себе поддержание обратной совместимости.
На самом деле это совершенно неправильно: поскольку вы не предоставляете свой SDK, либо разработчики возьмут неофициальный SDK (если кто-то его сделает), либо просто каждый из них напишет фреймворк.
Стратегия «ваш фреймворк — ваша ответственность», к счастью или к сожалению, не работает: если на вашем API пишутся некачественные приложения, значит, и само ваше API некачественное.
Наверняка по мнению разработчиков, а может и по мнению пользователей, если работа API внутри приложения видна пользователю.
Ээволюция предметной области
Другая сторона разрыва — это базовая функциональность, которой вы предоставляете API. Оно, конечно, тоже не стоит на месте и развивается в каком-то направлении:- появляется новый функционал;
- старый функционал больше не поддерживается;
- Интерфейсы меняются.
В случае с нашим пример с API кофемашины Разумно ожидать, что появятся новые модели с новыми API, которые нам придется включить в нашу платформу, и гарантировать, что мы сможем поддерживать тот же интерфейс абстракции, довольно сложно.
Даже если вы просто добавите поддержку новых типов базовых устройств, ничего не добавляя во фронтенд, это все равно изменения в коде, которые в конечном итоге могут привести к несовместимости, хотя и непреднамеренно.
Также стоит отметить, что не все поставщики API относятся к поддержанию обратной совместимости или, по сути, к качеству своего программного обеспечения так серьезно, как (мы надеемся) вы.
Вы должны быть готовы к тому, что вам придется заниматься поддержанием вашего API в рабочем состоянии, то есть написанием и сопровождением фасадов под меняющийся ландшафт предметной области, причем зачастую довольно внезапно.
Дрейф платформы
Наконец, есть и третья сторона вопроса — «ущелье», через которое вы перекинули свой мост в виде API. Код, который пишут разработчики, выполняется в некоторой среде, которой вы не можете управлять, и он также развивается.Появляются новые версии операционной системы, браузеров, протоколов и языка SDK. Разрабатываются новые стандарты и принимаются новые конвенции, некоторые из которых сами по себе обратно несовместимы, и с этим ничего нельзя поделать.
Как и в случае со старыми версиями приложений, старые версии платформ также приводят к фрагментации, поскольку разработчикам (в том числе разработчикам API) объективно сложно поддерживать старые платформы, и столь же объективно сложно обновлять их пользователям, поскольку обновление операционной системы зачастую невозможно без замены самого устройства на более новое.
Самое неприятное во всем этом то, что изменения в API подталкиваются не только прогрессивным прогрессом в виде новых платформ и протоколов, но и банальной модой и вкусом.
Всего несколько лет назад в моде были трехмерные реалистичные иконки, но все отказались от них в пользу плоских и абстрактных — и большинству разработчиков визуальных компонентов пришлось, следуя за модой, переделывать свои библиотеки, выпуская новые наборы иконок или замена старых.
Аналогично сейчас повсеместно реализуется поддержка «ночных» тем интерфейса, что требует внесения изменений в большое количество API.
Политика обратной совместимости
Итого, если сложить:- из-за итеративной разработки приложений, платформ и доменов вы рано или поздно будете вынуждены выпускать новые версии вашего API; Следует отметить, что в разных областях скорость развития различна, но никогда не равна нулю;
- в совокупности это приведет к фрагментации используемой версии API по приложениям и платформам;
- вам придется принимать решения, которые критически повлияют на надежность вашего API в глазах потребителей.
- Как часто выпускать основные версии API. Это в основном бакалея вопрос.
Новая основная версия API выпускается, когда накоплена критическая масса функций, поддержку которых в рамках предыдущей основной версии невозможно или слишком дорого.
В стабильной ситуации такая необходимость возникает, как правило, раз в несколько лет. На динамично развивающихся рынках новые мажорные версии могут выпускаться чаще; здесь ограничением является только ваша способность выделить достаточно ресурсов для поддержания зоопарка версий.
Однако следует отметить, что выпуск новой мажорной версии до стабилизации предыдущей (а это обычно занимает от нескольких месяцев до года) выглядит для разработчиков очень плохим сигналом, указывающим на риск.
постоянно сидеть на влажной платформе.
- Какое количество главный версии для одновременной поддержки.
Что касается основных версий, то теоретический Мы дали ответ выше: в идеальной ситуации жизненный цикл мажорной версии должен быть чуть дольше жизненного цикла платформы.
Для стабильных ниш, таких как настольные операционные системы, это около 5-10 лет, для новых и динамично развивающихся ниш — меньше, но все же несколько лет. Практически вам следует посмотреть на долю потребителей, которые фактически продолжают использовать эту версию.
- Какое количество незначительный версии (в пределах одной мажорной) поддерживаются одновременно.
Для минорных версий есть два варианта:
- если вы предоставляете только серверный API и скомпилированные SDK, вы в принципе не можете поддерживать какие-либо второстепенные версии API, кроме текущей: серверный API полностью под вашим контролем, и вы можете быстро исправить любые проблемы с логикой ;
- если вы предоставляете SDK с кодом по запросу, то хорошей практикой является поддержка предыдущих второстепенных версий SDK в рабочем состоянии в течение периода, достаточного для того, чтобы разработчики могли протестировать свое приложение с новой версией и внести некоторые изменения при необходимости.
Поскольку нет необходимости полностью переписывать приложения, разумно сосредоточиться на продолжительности циклов выпуска в вашей отрасли, обычно в худшем случае на несколько месяцев.
Кроме того, в разделе III мы также обсудим, как предупреждать потребителей о выпуске новых версий и прекращении поддержки старых, а также о том, как побудить их перейти на новые версии API.
Это черновик будущей главы книги, посвященной разработке API. Работа в процессе на Гитхабе .
Опубликована английская версия той же главы.
Я был бы признателен, если бы вы могли поискать это на Reddit — я сам не могу это сделать из-за политики платформы.
Теги: #api #проектирование и рефакторинг #обратная совместимость
-
Windows Phone – Выжимаем Все Соки
19 Oct, 24
