Сколько времени и усилий должен потратить проект на обратную совместимость?

Question

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

• Возраст программного обеспечения влияет на ваше решение? Будете ли вы тратить меньше времени на обратную совместимость, когда программа новее?
• Основано ли решение исключительно на количестве клиентов с установленными копиями?
• Прилагаете ли вы активные усилия для создания кода и форматов файлов, которые поддерживают будущие изменения?
• Когда вы разрабатываете v1.0, вы пытаетесь собрать, чтобы облегчить v2.0 обратную совместимость с v1.0? (В качестве примера можно оставить «зарезервированные» поля.)
• Как вы решаете, что "Нет, мы больше не будем поддерживать это" в функциях?

Answer 1

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

По сути, вам нужно оценить, что, как и любые другие нефункциональные требования , вам необходимо реализовать, и вам нужно тщательно указать, что входит в функцию «обратной совместимости» :

• API-совместимость . Это означает, что последующие версии библиотеки предоставляют тот же API, что и предыдущие версии, поэтому программы, написанные для предыдущей версии, все равно смогут компилироваться и работать с новой версией. Помимо того, что на самом деле остаются те же функции, это также означает, что все эти функции в более новой версии выполняют то же самое, что и в более старых версиях
• Двоичный интерфейс приложения, или ABI, совместимость . Это означает, что обратная совместимость сохраняется на уровне двоичного объектного кода, создаваемого при компиляции библиотеки.
  Как правило, между совместимостью API и ABI существует некоторое совпадение, но есть важные различия. Чтобы поддерживать совместимость с ABI, все, что вам нужно сделать, это убедиться, что ваша программа экспортирует все одинаковые символы.
  Это означает, что должны присутствовать все те же функции и глобально доступные объекты, чтобы программы, связанные с предыдущей версией, могли работать с новой версией.
  Можно поддерживать совместимость ABI, нарушая совместимость API . В коде C оставляйте символы в файлах C, но удаляйте их из общедоступных заголовков, поэтому новый код, пытающийся получить доступ к символам, не сможет скомпилироваться, в то время как старый код, скомпилированный пользователями с предыдущей версией, продолжит работать
• совместимость протокола клиент-сервер . Это означает, что клиент, использующий версию сетевого протокола, предоставленную в более старых выпусках, будет продолжать работать, когда сталкивается с более новым сервером, и что более новые клиентские программы будут продолжать работать со старым сервером.
• совместимость формата данных . Более новые версии кода должны иметь возможность работать с файлами данных, записанными в более старых версиях, и наоборот. В идеале вы также должны иметь возможность встроить некоторую прямую совместимость в форматы данных. Если ваши процедуры обработки файлов могут игнорировать и сохранять нераспознанные поля, то новые функциональные возможности могут изменять форматы данных таким образом, чтобы не нарушать старые версии. Это один из наиболее важных видов совместимости, просто потому, что пользователи очень расстраиваются, когда устанавливают новую версию программы, и внезапно не могут получить доступ к своим старым данным.

Если вы объедините предыдущие критерии (характер обратной совместимости) с характером клиентской базы, вы можете решить, что:

• Если ваши клиенты находятся внутри вашей компании, потребность в них ниже, а 2.0 может нарушить важные функции.

• Если ваши клиенты являются внешними, 2.0 все равно может сломать вещи, но вам может понадобиться предоставить руководство по миграции

• В крайнем случае, если ваши клиенты - весь мир, как я уже упоминал в этом ТАК вопрос о java , вы можете в конечном итоге предоставлять новые функциональные возможности без осуждающие старые! Или даже сохраняя ошибки ваших старых продуктов , потому что клиентские приложения зависят от этих ошибок !!

---

• Возраст программного обеспечения влияет на ваше решение? Будете ли вы тратить меньше времени на обратную совместимость, когда программа новее?
  Я полагаю, что это связано с тем, что уже развернуто: последняя программа будет иметь дело с меньшим количеством потребностей в обратной совместимости, чем та, которая существует примерно за 20 лет.

• Основано ли решение исключительно на количестве клиентов с установленными копиями?
  Он должен быть основан на экономическом обосновании: может ли ваша миграция - при необходимости из-за отсутствия обратной совместимости - эффективно «продаваться» вашим клиентам (из-за всех новых блестящих функций, которые она приносит?)

• Прилагаете ли вы активные усилия для создания кода и форматов файлов, которые поддерживают будущие изменения?
  Попытка предсказать «будущие изменения» может быть очень контрпродуктивной и быстро граничит с YAGNI (вам это не нужно): хороший набор инструментов миграции может быть гораздо более эффективным.

• Когда вы разрабатываете v1.0, вы пытаетесь собрать, чтобы облегчить v2.0 обратную совместимость с v1.0? (В качестве примера можно оставить «зарезервированные» поля.)
  Для внутренних приложений, над которыми я работал, нет. A Parallel Run - это наш способ обеспечить «функциональную» обратную совместимость. Но это не универсальное решение.

• Как вы решили, что "Нет, мы больше не будем поддерживать это" в функциях?
  Опять же, для внутренних приложений процесс принятия решений может сильно отличаться от внешнего развертывания. Если функция не приносит никакой дополнительной выгоды для бизнеса, внутренняя задача «согласованности» устанавливается для проверки с каждым другим внутренним приложением стоимости их миграции (т.е. «больше не использует эту функцию»). Та же задача гораздо сложнее сделать с клиентами за пределами вашей организации.

Answer 2

Чем больше ваша система используется ежедневно, тем больше вы должны сосредоточиться на ней.

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

Чем больше у вашей системы конкурентов, тем больше вы должны сосредоточиться на ней.

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

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

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

Как Vista или Office 2007. Они были потрясающими, помогая мне в Apple.

Answer 3

много. Если вы не хотите разозлить каждого из ваших постоянных клиентов!

Answer 4

Мой взгляд на обратную совместимость программного обеспечения:

1.) Если этот продукт уже широко используется многими клиентами, я бы позаботился о том, чтобы в новой версии этого продукта все еще использовался тот же «базовый код» (код, обеспечивающий базовую функциональность разрабатываемого приложения) , Новые функции должны быть учтены в этой кодовой базе или построены поверх этой кодовой базы с минимально необходимыми изменениями в среде выполнения этого приложения. Вы не хотите, чтобы ваши существующие пользователи выполняли множество изменений в своих существующих установках. Таким образом, это компромисс между поддержкой новой функциональности и обновлением существующего процесса установки и использования для клиента.

2.) В новом продукте, если возможно, идентифицируйте все возможные функции этого приложения в самом начале, даже до выхода версии 1.0. Определите, какие функции вы собираетесь отправить в версии 1.0. и какие будут сохранены для более поздних выпусков. Везде, где возможно, помните об этих «функциях более позднего времени» при проектировании, реализации кода и окончательной доработке вывода из / приложения, чтобы приспособить функции в будущих версиях. например Оставьте дополнительные элементы / битовые поля в ваших структурах данных.

-AD.

Answer 5

Мой опыт работы со сложными системами термоусадочной упаковки с относительно небольшим числом (100 - 5000) пользователей.
Маркетинг часто имеет отношение к обратной совместимости без полного понимания стоимости жизненного цикла. Например, экономия на поддержке ошибок в вашей системе для текущей пользовательской базы может быть легко уменьшена расходами на поддержку новых пользователей в течение срока службы системы.