Обратная совместимость что это
Что такое обратная совместимость
Это когда старая игра запускается на новой приставке
Совместимость — это когда что-то одно может работать с чем-то другим без дополнительных настроек, переделок или костылей.
Например, есть дизельное топливо. Оно совместимо с дизельными автомобилями — независимо от их марки, года выпуска, пробега или других параметров. А ещё можно приехать на своей машине на любую заправку с дизелем, а не искать специальную заправку только для определённой марки машин. Вот это всё — совместимость.
В ИТ чаще всего говорят про прямую и обратную совместимость, когда в одну сторону совместимость работает, а в другую — нет.
Когда совместимости нет
Допустим, на предприятии есть программа, которая обслуживает базу данных в нестандартном формате. Проходит время, разработчики увольняются и перестают поддерживать программу. Но программа нужна предприятию, поэтому ей продолжают пользоваться.
Чтобы код всегда оставался актуальным и чистым, используют рефакторинг. Про это у нас есть отдельная статья.
Спустя пять лет программа конкретно устарела: в ней нет поддержки современных удобных протоколов и она не работает на новых операционных системах. Но зато она работает со старой базой.
Предприятие ищет какое-то решение своей проблемы, но выясняется, что ни одна программа не совместима с её базой данных. Это ситуация, когда совместимости нет.
Обычная (или прямая) совместимость
Предприятие обращается за помощью к новым разработчикам: нужно сделать программу, которая умеет работать с нужным форматом баз данных. И, кроме этого, в программе должны быть все современные протоколы и поддержка современных операционок. Разработчики создают этот софт. Это прямая совместимость.
Прямая совместимость — это когда что-то одно может работать с другим. Это относительно простая задача для разработчика, потому что для неё достаточно добавить поддержку нужного формата данных или протоколов.
Обратная совместимость
А теперь представим другую ситуацию: разработчики не ушли с предприятия, а продолжили работать над проектом. В итоге за пять лет они придумали новую версию базы: тоже нестандартную, но более быструю. Но данные за пять лет всё ещё живут в старой базе данных, а переносить их нельзя.
Теперь перед программистами стоит противоречие:
Это обратная совместимость: новая версия программы поддерживает и новое, и старое.
Пример обратной совместимости — операционная система Windows. В каждой новой версии есть поддержка части программ, которые написаны для старых версий. Даже если вы попробуете запустить аудиоплеер, разработанный для Windows 95, в свежей Windows 10, то, вероятно, у вас это получится.
Также обратная совместимость позволяет нам взять игру для PlayStation 4 и запустить её на новой PlayStation 5 (скорее всего). А вот прямой совместимости у них нет: игра, написанная специально для PS5, вряд ли запустится на PS4.
В чём подвох
Обратная совместимость — головная боль для разработчиков. Ради полноценной поддержки старого формата иногда приходится жертвовать скоростью работы или надёжностью.
Например, в новой версии используется более современный протокол передачи данных. Но чтобы старые версии тоже смогли работать, разработчикам приходится поддерживать одновременно два протокола — новый и старый, каждый проверять на ошибки. Чем больше отличий в версиях — тем сложнее это поддерживать. Иногда для реализации старых технологий тратится намного больше ресурсов, чем для такой же работы — в новых.
Бесконечность проблемы обратной совместимости
(с)
Обратная совместимость применительно к аппаратным или программным системам означает способность успешно использовать интерфейсы и данные из более ранних версий системы. Этот принцип распространяется не только на программы, которые работают с файлами, созданными в более ранних версиях этих же программ, но и касается ситуаций работы со схожими алгоритмами. Например, Perl поддерживает обратную совместимость с другим языком — Awk, — который Perl был предназначен заменить.
Обратную совместимость легче выполнять, если предыдущие версии системы были разработаны с поддержкой встроенных функций, таких как хуки, плагины или API, которые позволяют добавлять новые возможности вашему софту, однако все из области backward compatibility (c упором на back) может стать головной болью для разработчиков.
Откажешься от нее совсем — расстроятся пользователи предыдущих версий систем и продуктов, вмиг потеряв весь парк накопленных гаджетов или программ. Обеспечишь полную обратную совместимость — станешь заложником прошлых решений, сделав свой продукт тяжелым, неповоротливым, или даже не способным на нужный прирост характеристик.
Разработчик каждый раз принимает трудное решение: должен ли продукт быть обратно совместимым. «Объективно правильного» решения здесь просто нет — в мире достаточно примеров успешной обратной совместимости и отказов от нее. Возможно, чей-то опыт поможет сделать вам правильный выбор прямо сейчас.
Давайте снова поменяем стандарт
Один из самых ярких примеров, когда об обратной совместимости решили забыть, это появление разъема USB 3.1 Type C (USB-C). Многие годы мы не ведали проблем: любой гаджет с разъемом micro- или miniUSB можно было воткнуть в любой соответствующий USB-порт. Но консорциум USB-IF создал разъем Type C, совершенно несовместимый механически ни с одним из сотен миллионов, а то и миллиардов смартфонов, кабелей, зарядных устройств и прочих гаджетов.
Еще одна проблема заключается в том, что не каждый USB-C кабель, порт, устройство и питание совместимы между собой: некоторые кабели с USB-C на обоих концах могут передавать лишь 5 Гбит/с, другие совместимы с 10 Гбит/с, а есть и те, что нельзя использовать для питания.
Ситуация привычная для тех, кто когда-то собирал себе компьютеры самостоятельно или занимался их апгрейдом. За последние 20–30 лет на наших глазах сменилось множество поколений шин и портов, почти каждое из которых не было обратно совместимо с предыдущими. Поменялись буквально все разъемы на материнской плате, и не по одному разу: сокеты процессоров, шины видеокарт и оперативной памяти, разъемы для подключения накопителей и периферии.
Нездоровая чехарда в мире процессоров продолжается до сих пор: вполне себе бодрые модели, которые гонять и гонять, через несколько лет уже нельзя поставить на новые материнские платы. Производителям трудно устоять перед соблазном регулярно делать бесполезными запасы железа у пользователей, заставляя их нести деньги на новые модели. Отсутствие обратной совместимости не греет душу, когда купленный три года назад процессор приходится менять на практически такой же, потому что умерла материнская плата.
Универсальный разъем, предназначенный для передачи данных и питания, способен стать единственным портом на устройстве — и в этом несомненный плюс USB Type-C. Можно смириться с отсутствием обратной совместимости в гаджетах, и даже отметить для себя плюсы (более высокую скорость передачи данных и иные параметры электропитания), но в сфере ПО болезненнее воспринимается несовместимость новых версий со старыми. Особенно это касается корпоративных продуктов, стоимость которых и влияние на бизнес-процессы слишком велики.
Геймдев
В экосистеме ПК игры обратно совместимы в течение десятилетий. Такие утилиты как DOSBox позволяют нам играть даже в самые ранние ПК-релизы. Фактор совместимости, при которой переход на новую версию системы с большой вероятностью не влечет за собой проблем, похоже, сыграл роль в текущем доминировании Windows. Да, в результате 32-битные версии Windows поддерживали запуск 16-битного программного обеспечения Windows и некоторый софт MS-DOS (а в 64-битных версиях, соответственно, работают 32-битные программы), но Microsoft получили огромную тяжелую платформу, в которой есть совместимость даже с ошибками.
А как дела у приставок?
Отчет Ars Technica показал, как пользователи Xbox One и Xbox 360 используют свои устройства. Интересно, что данные из отчета по приставке Microsoft совпадают с мнением корпорации Sony, которая не рассматривает обратную совместимость в PlayStation 4 как нечто важное. По мнению руководителя Sony Interactive Entertainment Europe Джима Райана, об этой функции больше говорят, чем реально пользуются. Хотя Sony действительно предоставила возможность скачать игры для PS1 и PS2 на PS4.
Некоторые сайты проводили свои собственные опросы в преддверии выхода Xbox One и PS4 — тогда было отмечено, что многие игроки заявляли о желании обратной совместимости. Microsoft привлекла большое внимание к обратной совместимости с Xbox One. Функция была в целом хорошо реализована, но сейчас не особо привлекает геймеров.
В линейках Nintendo DS и Wii также есть много примеров обратной совместимости.
Геймдевелоперы усилия компаний встретили более воодушевленно — больше не требуется изучать архитектуру с нуля, чтобы воспользоваться преимуществами нового консольного оборудования. Обратная совместимость позволяет относительно просто поддерживать релизы для всех устройств, созданных на основе общей архитектуры.
Обратная совместимость в языках
(с)
Каждый популярный язык программирования имеет ясную эволюцию, большую часть его жизни обозначенную версией: у вас есть Java 5, 6, 7 и т. д., PHP 5.1, 5.2, 5.3 и т. д. Каждая новая версия исправляет ошибки и добавляет функции, но если язык (или платформа) имеет фундаментальные изъяны, то разработчики либо избегают их (если могут), либо учатся жить с ними.
Разработчики языков получают много отзывов от программистов, использующих тот или иной язык программирования в своей работе. Кажется, что однажды выйдет версия языка, в которой все проблемы исчезнут. Но этого не происходит. Почему так? Один из вариантов — обратная совместимость.
У популярного PHP есть недостатки, и те, кто давно с ним работают, прекрасно знают, как можно обойти все ловушки и ямы языка. Теперь предположим, что в новой версии языка исправили все минусы, но потеряли обратную совместимость. В результате разработчик тратит время на обновление кода до актуальной версии PHP. То самое время, которое он мог бы потратить на выполнение запросов клиентов или внедрение новых функций.
Учитывая эти проблемы, понятен мотив тех, кто не хочет переходить на новую версию PHP, даже если она лучше, понятнее и безопаснее и т. д. Вы скажете, что это гипотетический пример. Возможно… Но в мире еще есть программисты, которые до сих пор работают на COBOL! Язык появился в 1958 году. К 1997 году активно использовалось около 240 миллиардов строк кода на COBOL, кодом на этом языке обрабатывалось около 90% финансовых транзакций в мире и 75% коммерческих транзакций. Самое интересное — это потрясающая совместимость языка: тот COBOL, который использовался в 60-х, может работать и на современном оборудовании.
Есть продукты, которые в принципе не могут поломать обратную совместимость, потому что это поставит на них крест. Например, Java: основная сфера применения этого языка — бизнес-приложения, по всему миру написано астрономическое количество строк кода, в том числе в огромных корпоративных кодовых базах. Код, написанный 20 лет назад, до сих пор работает. И если завтра выйдет версия Java, в которой разработчики накрутят фантастические фичи, но без обратной совместимости, то никто больше не станет инвестировать очень большие деньги в разработку серьезных — и дорогих — приложений. Так что Oracle придется либо всю жизнь тянуть за собой груз старых версий, либо открывать дорогу нововведениям, но при этом теряя большую долю клиентов. На третий вариант — поддерживать одновременно две ветки Java, с полноценным сопровождением и развитием — не согласится сама корпорация.
В свое время разработчики Python нарушили обратную совместимость, тем самым разозлив кучу пользователей. Большинство программистов не считало язык Python 2.x «ошибочным» или содержащим «фундаментальные изъяны». У них не было таких жалоб, какие появляются у разработчиков на PHP.
Сегодня сообщество языка разделено на два лагеря, при этом масса готовых библиотек под вторую версию не дает многим мигрировать на третью, хотя та и привнесла в язык ряд сильных улучшений. В результате закрепилось мнение, что «Python 3 — это худшее, что могло случиться с сообществом Python».
У проблемы есть и обратная сторона — Python 3 был выпущен в декабре 2008 года, но поддержка языка во фреймворке Django появилась только спустя пять лет.
Хотя нет 100% совместимости между C и C ++, но даже в C ++ есть обратная совместимость с очень ранними функциями языка (включая некоторые функции, унаследованные непосредственно от C).
Накопление технического долга
Иногда проблема возникает потому, что мы просто не в силах предсказать будущее. В 1981 году «Интернета» хватало всем и каждому — была описана первая широко используемая версия протокола IPv4, использующая 32-битные адреса, ограничивающие адресное пространство 4 294 967 296 возможными уникальными адресами.
4,3 миллиарда адресов IPv4 выглядели более чем достаточно для ARPANet. IPv6 появился в 1998 году (описан в RFC2460), но популярности протокол не снискал. Потребовалось более десяти лет, чтобы на проблему ограниченного количества адресов обратили внимание. И вот тогда стало понятно, что гигантская база разработанного и установленного программного и аппаратного обеспечения IPv4 требует сохранения обратной совместимости IPv6 с IPv4.
«Внезапно» выяснили, что IPv6 был разработан без полноценной совместимости с предыдущей версией — узел с поддержкой только IPv6 не может подключиться к узлу, работающему только по IPv4. Переход от IPv4 к IPv6 требовал «двухстековой» фазы, во время которой хост-компьютер взаимодействовал бы с обоими стеками протоколов одновременно, используя стек протокола IPv6 для взаимодействия с другими хост-компьютерами IPv6, а стек протокола IPv4 для взаимодействия с другими хост-компьютерами IPv4.
Некоторые коммутаторы, маршрутизаторы и устройства безопасности также оказались не совместимы с IPv6. Таким образом процесс перехода на IPv6 столкнулся со множеством проблем, решать которые предлагается разными способами. Ни одно из существующих решений нельзя назвать идеальным, но каждое из них найдет свое применение.
Философия обратной совместимости в ПО
Когда задумался, нужно ли в новой версии поддерживать совместимость (с)
В софте обратная совместимость, как правило, подразумевает сильное увеличение размеров файлов и всего приложения, но самое главное не это. Обратная совместимость обычно требует тащить за собой исторический багаж, что в интерпретируемых языках нередко приводит к заметным потерям в производительности.
При обратной совместимости раздувается кодовая база, усложняется архитектура приложения, затрудняется апгрейд приложений. Возникает желание отринуть старое и написать компактный, легкий код, использующий самые современные наработки.
Например, новая версия Skype больше не может устанавливать голосовые и видеосоединения с версиями под Windows XP. И, конечно, некоторые пользователи хотят проигнорировать новый релиз, предпочтя остаться на старом, но таком привычном.
Да, обратная совместимость сегодня считается одним из важнейших условий при разработке программных продуктов. Она позволяет пользователям наименее безболезненно — а значит, и комфортно — переходить на новые продукты. Производителям игровых приставок, например, важно обеспечивать обратную совместимость новых игр со старыми гаджетами, чтобы максимально расширять аудиторию потенциальных покупателей. Но при этом разработчикам труднее реализовывать новый уровень реалистичности графики и физики, что, по иронии, может снизить привлекательность системы для геймеров.
Мы сами периодически сталкиваемся со схожими вопросами. При написании облачного решения «горячего» хранения данных Hotbox можно было все полностью создать с «нуля» или использовать существующие наработки в Почте и Облаке Mail.Ru. Написание с нуля позволяет разом избавиться от всего накопившегося технического долга, однако это долго. Минус использования текущих наработок в том, что мы остаемся на языке Perl, для которого сложно находить новых разработчиков в связи с его не самой большой популярностью. Но плюсы этого решения существенно перевешивают: в этом языке у нас огромная экспертиза и наработанные годами инструменты. Так как было критично выпустить продукт в срок — мы решили остановиться на использовании Perl.
В результате получился продукт, который на данный момент нас полностью устраивает. В этом случае «обратная совместимость» вышла за пределы одного лишь сервиса — мы сделали совместимость не только с наработками в других проектах, но и с нашим собственным опытом. Осознание этого факта приводит к простой мысли: не всегда новый язык, новая версия программы или новый гаджет является универсальным решением поставленной перед вами задачи.
Как правильно разрабатывать API с поддержкой обратной совместимости. Семинар в Яндексе
Привет! Меня зовут Сергей Константинов, в Яндексе я руковожу разработкой API Карт. Недавно я поделился опытом поддержки обратной совместимости со своими коллегами. Мой доклад состоял из двух неравных частей. Первая, большая, посвящена тому, как правильно разрабатывать API, чтобы потом не было мучительно больно. Вторая же про то, что делать, если вам нужно что-то рефакторить и не сломать по дороге обратную совместимость.
Если заглянуть в Википедию, то про обратную совместимость там будет написано, что это сохранение интерфейса системы при выпуске новых версий. На самом деле, для конечных пользователей обратная совместимость означает, что код, написанный для предыдущей версии системы, работает функционально так же и в следующей версии.
Для разработчика обратная совместимость в первую очередь подразумевает, что единожды принятое обязательство предоставлять какую-либо функциональность невозможно отменить, исправить или перестать поддерживать.
Зачем нужно брать на себя обязательства? Во-первых, вы экономите время и деньги своим пользователям. Наивно думать, будто бы не поддерживать обратную совместимость дешевле. На самом деле, вы просто размазываете стоимость поддержки по клиентам. Один факап в продакшене может стоить гораздо больше, чем вся разработка всего продукта.
Во-вторых вы поддерживаете свою карму. Сознательный слом обратной совместимости расстраивает пользователей куда больше, чем баги. Людям очень не нравится, когда им явно демонстрируют равнодушие к их проблемам.
В-третьих, обратная совместимость – это конкурентное преимущество. Она подразумевает возможность переходить на более свежие версии без затрат на разработку, гарантию того, что сервис не сломается продакшене.
Обратная совместимость: правильная архитектура
Что можно сделать на этапе проектирования, чтобы потом не было мучительно больно? Тут нужно сделать три предварительных замечания. Во-первых, обратная совместимость не бывает бесплатной. Выстраивание правильной архитектуры влечёт за собой накладные расходы. Вам придётся больше думать, вводить больше сущностей, писать избыточный код.
Во-вторых, прежде чем приступать к разработке, нужно обозначить сферу ответственности, четко прояснить, что именно будет поддерживаться. Сводите к минимуму ситуации, когда какое-то публично доступное API не описано в документации. Никогда не давайте на чтение (и, тем более, на запись) сущности, формат которых не описан.
В-третьих, предполагается, что ваш API спроектирован правильно и структурирован по уровням абстракции.
Предположим, что все это мы поняли и осознали. Пора переходить к правилам, которые которые мы вынесли из нашего почти пятилетноего опыта.
Правило №1: больше интерфейсов
В пределе в вашей публичной документации не должно быть ни одной сигнатуры, принимающей конкретные типы, а не интерфейсы. Исключение может быть сделано для базовых глобальных классов и явно подчинённых компонент.
Почему это помогает избежать потери обратной совместимости? Если в сигнатуре заявлен интерфейс, у вас не будет проблем, когда у вас появится вторая (третья, четвёртая) реализация интерфейса. Атомизируется ответственность объектов. Интерфейс не накладывает условий, чем должен быть передаваемый объект: он может быть как наследником стандартного объекта, так и самостоятельной реализацией.
Почему это полезно при проектировании API? Выделение интерфейсов в первую очередь необходимо разработчику для наведения порядка в голове. Если ваш метод принимает в качестве параметра объект с 20 полями и 30 методами, очень рекомендуется задуматься, что конкретно необходимо из этих полей и методов.
В результате применения этого правила вы должны получить на выходе много дробных интерфейсов. Ваши сигнатуры не должны требовать от входного параметра больше 5±2 свойств или методов. Вы получите представление о том, какие свойства ваших объектов важны в контексте общей архитектуры системы, а какие – нет. Как следствие, снизится избыточность интерфейсов
Правило №2: иерархия
Ваши объекты должны быть выстроены в иерархию: кто с кем взаимодействует. Когда на эту иерархию наложатся интерфейсы, которые вы предъявили к своим объектам, вы получите некую иерархию интерфейсов. Теперь самое важное: объект имеет право знать только об объектах соседних уровней.
Почему это помогает избежать потери обратной совместимости? Снижается общая связанность архитектуры, меньше связей – меньше side-эффектов. А при изменении какого-либо объекта вы можете задеть только его соседей по дереву.
Добиться этого очевидными способами можно не всегда. Нужные методы и свойства нужно пробрасывать по цепочке через промежуточные звенья (с учетом уровня абстракции, разумеется!). Тем самым вы автоматически получите набор точек расширения, которые потом могут пригодиться.
Правило №3: контексты
Рассматривайте любую промежуточную ступень иерархии как информационный контекст для нижележащей ступени.
Пример:
Map = картографический контекст (наблюдаемая область карты + масштаб).
IPane = контекст позиционирования в клиентских координатах.
ITileContainer = контекст позиционирования в тайловых координатах.
Ваше дерево объектов можно будет рассматривать как иерархию контекстов. Каждый уровень иерархии должен соответствовать какому-то уровню абстракции.
Почему это помогает избежать потери обратной совместимости? Правильно построенное дерево контекстов практически никогда не изменится при рефакторинге: потоки информации могут появляться, но очень вряд ли пропадут. Правило контекстов позволяет эффективно изолировать уровни иерархии друг от друга.
Это полезно при проектировании API, так как держать в голове информационную схему проекта существенно проще, чем полное дерево. А описание объектов в терминах предоставляемых ими контекстов позволяет правильно выделять уровни абстракции.
Правило №4: consistency
В данном случае я использует термин consistency в парадигме ACID для баз данных. Это означает, что между транзакциями состояние объектов всегда должно быть валидным. Любой объект должен предоставлять полное описание своего состояния в любой момент и полный набор событий, позволяющий отслеживать все изменения своего состояния.
Подобные паттерны нарушают consistency:
В частности, отсюда следует правило: избегайте методов update, build, apply.
Это помогает избежать потери обратной совместимости, т.к. внешний наблюдатель всегда может полностью восстановить состояние и историю объекта по его публичному интерфейсу. Кроме того, такой объект всегда можно подменить или склонировать, не обладая знанием о его внутреннем устройстве.
Когда у вас организовано такое взаимодействие, что есть state объекта и событие о его изменении, номенклатура методов и событий ваших объектов становится менее разнообразной и более консистентной. Вам станет проще выделять интерфейсы и держать все это в голове.
Правило №5: события
Организуйте взаимодействие между объектами с помощью событий, причём в обе стороны.
Рассмотрим два примера, как можно организовать взаимодействие между кнопкой и макетом:
Вторая схема взаимодействия получается нативно при соблюдении требования consistency:
В первом случае кнопка и макет знают подробности о внутреннем устройстве друг друга, во втором – нет.
Это помогает избежать потери обратной совместимости, т.к. события необязательны к исполнению для обоих объектов: вы легко сможете поддерживать такие реализации обоих объектов, которые реагируют только на часть событий и отображают только часть состояния второго объекта. Если у вас появится третий объект, которому необходимо реагировать на то же действие – у вас не будет проблем.
Если вы верно выполнили и предыдущие четыре шага, у вас получается стандартный паттерн: у вас есть, state, события об его изменении, нижележащий объект, который слушает это событие и реагирует на него каким-то образом. Ваша организация взаимодействия между объектами значительно унифицируется. Взаимодействие между объектами таким образом базируется на общих методах и событиях, а не частных, т.е. будет содержать гораздо меньше специфики конкретных объектов
Правило №6: делегирование
Шестое правило логично вытекает из первых пяти. Вы построили всю систему, у вас есть интерфейсы и события, уровни абстракции. Теперь нужно насколько это возможно перенести всю логику на нижний уровень абстракции. Поскольку чаще всего изменяется реализация и функциональность именно нижнего уровня абстракции (верстка, протоколы взаимодействия, etc), интерфейс к нижнему уровню абстракции должен быть максимально общим.
При таком подходе связи между объектами становятся насколько это возможно абстрактными. Вы сможете безболезненно переписать объекты нижнего уровня абстракции целиком при необходимости
Правило №7: тесты
Пишите тесты на интерфейс.
Правило №8: внешние источники
В абсолютном большинстве случаев самые большие проблемы с сохранением обратной совместимости возникают вследствие несохранения обратной совместимости другими сервисами. Если вы не контролируете смежный сервис (источник данных) – заведите к нему версионируемую обёртку на своей стороне.
Обратная совместимость: рефакторинг
Прежде, чем приступать
Полтора приёма рефакторинга:
От релиза к релизу
Заведите себе блокнотик душевного покоя: