#breakfront_analysis_fails ОБРАТНАЯ СОВМЕСТИМОСТЬ Начну ру | Системный сервант
#breakfront_analysis_fails
ОБРАТНАЯ СОВМЕСТИМОСТЬ
Начну рубрику "Ошибки анализа", где буду писать про фейлы, которые встречала или делала сама.
Первой расскажу про распространенную и довольно опасную проблему: отсутствие обратной совместимости при обновлениях.
Обратная совместимость - это способность ПО при обновлении поддерживать и новую, и старую функциональности.
Хороший пример обратной совместимости - мобильные приложения. Допустим, на главном экране банковского приложения отображался баланс на счете. А в новой версии приложения вы решили показать на главном экране весь триллион услуг банка.
Но не все пользователи обновляют мобильные приложения одновременно. Поэтому, даже когда вы выкатили обновление серверной части приложения - многие устройства все еще ожидают получить баланс для главной страницы. И совершенно не знают, что делать со всем многообразием услуг банка.
Соответсвенно, вам необходимо в новой версии серверной части оставить данные о балансе для главного экрана, которые будут отдаваться в приложение наряду со списком услуг. И каждая версия получит то, что ожидает от сервера, и не сломается.
Можно, конечно, еще принуждать пользователя обновляться: когда при входе в приложение вы не можете ничего сделать без обновления. Но люди такое не очень любят и это вариант для совсем уж старых и несовместимых версий.
Вопрос обратной совместимости актуален не только для мобильных приложений. В мире интеграций почти всегда у данных есть много потребителей. От других систем в контуре компании до государственных органов, в которые вы автоматически отправляете отчеты. И не все из них готовы меняться вместе с вами.
К сожалению, об этом нередко забывают. В результате ломаются процессы, системы, уведомления и другие потребители "старых" данных.
Однако спроектировать обратную совместимость получается не всегда. Иногда обновление конфликтует с предыдущей версией. Иногда реализация обратной совместимости требует слишком много ресурсов. Иногда поддержка старой версии невозможна. И так далее. В этих случаях аналитик отслеживает все зависимости и описывает необходимые доработки во всех задействованных системах/частях системы. Часто такая ситуация требует совместного релиза нескольких команд и даже компаний.
Понятно, что релиз несовместимых с предыдущей версией обновлений - очень хлопотное дело с высокой вероятностью ошибки. Поэтому при проектировании лучше сразу задумываться о возможных вариантах развития системы. И стараться описывать архитектуру, пригодную для масштабирования с обратной совместимостью.
Добавлю, что для контроля обновлений, например, API, часто оперируют версионированием вроде 1.2.3. Где:
- 1 - мажорный номер версии, подразумевающей несовместимые изменения.
- 2 - минорные изменения с обратной совместимостью.
- 3 - номер релиза с исправлением ошибок с сохранением обратной совместимости.
