​​#breakfront_analysis_fails

ОБРАТНАЯ СОВМЕСТИМОСТЬ

Начну рубрику "Ошибки анализа", где буду писать про фейлы, которые встречала или делала сама.

Первой расскажу про распространенную и довольно опасную проблему: отсутствие обратной совместимости при обновлениях.

Обратная совместимость - это способность ПО при обновлении поддерживать и новую, и старую функциональности.

Хороший пример обратной совместимости - мобильные приложения. Допустим, на главном экране банковского приложения отображался баланс на счете. А в новой версии приложения вы решили показать на главном экране весь триллион услуг банка.

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

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

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

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

К сожалению, об этом нередко забывают. В результате ломаются процессы, системы, уведомления и другие потребители "старых" данных.

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

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

Добавлю, что для контроля обновлений, например, API, часто оперируют версионированием вроде 1.2.3. Где:

- 1 - мажорный номер версии, подразумевающей несовместимые изменения.
- 2 - минорные изменения с обратной совместимостью.
- 3 - номер релиза с исправлением ошибок с сохранением обратной совместимости.