Сколько времени и усилий должен потратить проект на обратную совместимость?[закрыто]
https://stackoverflow.com/questions/527499
-
22-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Учитывая, что на каждый программный проект отводится не так уж много программистских часов, сколько бы вы потратили на то, чтобы убедиться, что продукт обратно совместим с предыдущими версиями?На самом деле есть несколько моментов, которые следует учитывать:
- Влияет ли возраст программного обеспечения на ваше решение?Будете ли вы тратить меньше времени на обратную совместимость, когда программа станет более новой?
- Основано ли решение исключительно на количестве клиентов с установленными копиями?
- Прилагаете ли вы активные усилия для создания кода и форматов файлов, поддерживающих будущие изменения?
- Когда вы разрабатываете версию v1.0, пытаетесь ли вы встроить, чтобы упростить обратную совместимость версии v2.0 с версией v1.0?(Примером может служить оставление полей "зарезервировано".)
- Как вы решаете, что "Нет, мы больше не собираемся это поддерживать" в отношении функций?
Решение
Клиентская база играет ключевую роль в определении того, следует ли вам поддерживать большие проблемы с обратной совместимостью.
В принципе, вам нужно оценить это, как и любое другое нефункциональные требования вам необходимо реализовать, и вам нужно тщательно указать, что входит в функция "обратной совместимости":
- Совместимость с API.Это означает, что последующие версии библиотеки предоставляют тот же API, что и предыдущие версии, поэтому программы, написанные на основе предыдущей версии, по-прежнему смогут компилироваться и запускаться с новой версией.Помимо фактического сохранения одних и тех же функций, это также подразумевает, что все эти функции в более новой версии выполняют то же самое, что и в более старых
- Совместимость с двоичным интерфейсом приложения, или ABI.Это означает, что обратная совместимость сохраняется на уровне двоичного объектного кода, создаваемого при компиляции библиотеки.
Обычно существует некоторое совпадение между совместимостью API и ABI, но есть важные различия.Чтобы поддерживать совместимость с ABI, все, что вам нужно сделать, это убедиться, что ваша программа экспортирует все одинаковые символы.
Это означает, что должны присутствовать все те же функции и глобально доступные объекты, чтобы программы, связанные с предыдущей версией, по-прежнему могли запускаться с новой версией.
Можно поддерживать совместимость с ABI, нарушая совместимость с API.В коде C оставьте символы в файлах C, но удалите их из общедоступных заголовков, поэтому новый код, который пытается получить доступ к символам, не сможет скомпилироваться, в то время как старый код, который пользователи скомпилировали для предыдущей версии, продолжит выполняться - совместимость протокола клиент-сервер.Это означает, что клиент, использующий версию сетевого протокола, предусмотренную в более старых выпусках, будет продолжать функционировать при работе с более новым сервером, и что более новые клиентские программы будут продолжать работать со старым сервером.
- совместимость с форматами данных.Более новые версии кода должны быть способны работать с файлами данных, записанными более старыми версиями, и наоборот.В идеале вы также должны быть в состоянии обеспечить некоторую прямую совместимость с форматами данных.Если ваши процедуры обработки файлов могут игнорировать и сохранять нераспознанные поля, то новые функциональные возможности могут изменять форматы данных таким образом, чтобы не нарушать работу старых версий.Это один из наиболее важных видов совместимости просто потому, что пользователи очень расстраиваются, когда устанавливают новую версию программы и внезапно не могут получить доступ к своим старым данным.
Если вы объедините предыдущие критерии (характер обратной совместимости) с характером вашей клиентской базы, вы можете решить, что:
Если ваши клиенты являются внутренними по отношению к вашей компании, потребность в них ниже, а версия 2.0 может нарушить важные функции.
Если ваши клиенты являются внешними, версия 2.0 все равно может привести к сбоям, но вам может потребоваться предоставьте руководство по миграции
В крайнем случае, если ваши клиенты - это весь мир, как я уже упоминал в этом ИТАК, вопрос о java, вы можете в конечном итоге предоставлять новые функциональные возможности, никогда не отказываясь от старых!Или даже сохранение ОШИБОК в ваших старых продуктах, потому что клиентские приложения зависят от этих ошибок!!
Влияет ли возраст программного обеспечения на ваше решение?Будете ли вы тратить меньше времени на обратную совместимость, когда программа станет более новой?
Я полагаю, что это связано с тем, что уже развернуто:недавняя программа должна будет иметь дело с меньшим количеством потребностей в обратной совместимости, чем та, которой около 20 лет.Основано ли решение исключительно на количестве клиентов с установленными копиями?
Это должно быть основано на бизнес-кейсе:может ли ваша миграция - если это необходимо из-за отсутствия обратной совместимости - быть эффективно "продана" вашим клиентам (из-за всех новых блестящих функций, которые она приносит?)Прилагаете ли вы активные усилия для создания кода и форматов файлов, поддерживающих будущие изменения?
Попытка предсказать "будущие изменения" может быть очень контрпродуктивной и быстро перейти границу ЯГНИ (вам это не понадобится).:хороший набор инструментов миграции может быть гораздо более эффективным.Когда вы разрабатываете версию v1.0, пытаетесь ли вы встроить, чтобы упростить обратную совместимость версии v2.0 с версией v1.0?(Примером может служить оставление полей "зарезервировано".)
Для внутренний приложений, над которыми я работал, нет.A Параллельный запуск это наш способ обеспечить "функциональную" обратную совместимость.Но это не универсальное решение.Как вы решаете, что "Нет, мы больше не собираемся это поддерживать" в отношении функций?
Опять же, для внутренний приложений, процесс принятия решений может сильно отличаться от процесса принятия решений, развернутого извне.Если функция не приносит никакой дополнительной ценности для бизнеса, ставится внутренняя задача "согласованности" для проверки с каждым другим внутренним приложением стоимости их миграции (т.е."больше не использую эту функцию").Ту же задачу гораздо сложнее выполнить с клиентами за пределами вашей организации.
Другие советы
Чем больше ваша система используется изо дня в день, тем больше вы должны сосредоточиться на ней.
Чем глубже ваша система внедрена в основные процессы ваших клиентов, тем больше вы должны уделять ей внимания.
Чем больше у вашей системы конкурентов, тем больше вы должны уделять ей внимания.
Чем больше пользователей используют более старые версии, тем больше вы должны уделять этому внимания.
Чем сложнее и глубже клиент привыкает к вашей системе с точки зрения того, насколько большое влияние ваше программное обеспечение оказывает на его бизнес, тем больше вам следует уделять внимания обратной совместимости.
Если вы не можете помочь им перейти на новые версии с помощью привлекательных цен и т.д., возможно, стоит подумать о риске принудительного внедрения всех.
Например, Vista или Office 2007.Они были потрясающими помощниками мне в Apple.
Мое мнение об обратной совместимости программного обеспечения:
1.) Если его продукт уже широко используется многими клиентами, то я бы позаботился о том, чтобы новая версия этого продукта по-прежнему использовала тот же "базовый код" (код, который обеспечивает базовую функциональность разрабатываемого приложения).Новые функции должны быть учтены в этой кодовой базе или построены поверх этой кодовой базы с минимальными изменениями, необходимыми в среде выполнения этого приложения, насколько это возможно.Вы же не хотите, чтобы ваши существующие пользователи вносили много изменений в свои существующие установки.Таким образом, это компромисс между поддержкой новой функциональности и обновлением существующего процесса настройки и использования для клиента.
2.) В новом продукте, по возможности, определите все возможные функции этого приложения в самом начале, еще до выхода версии 0.Определите, какие функции вы собираетесь поставлять в версии v1.0.и какие из них будут сохранены для более поздних выпусков.По возможности учитывайте эти "функции более позднего времени" при проектировании, реализации кода, доработке выходных данных приложения для включения функций в будущие версии.например ,Оставьте дополнительные элементы / битовые поля в ваших структурах данных.
-РЕКЛАМА.
Очень много.Если вы не хотите разозлить каждого из ваших постоянных клиентов!
Мой опыт связан со сложными системами термоусадочной упаковки с относительно небольшим количеством пользователей (100-5000).
Маркетинг часто придерживается позиции "должен иметь ИТ" в отношении обратной совместимости без полной оценки затрат на жизненный цикл.Например, экономия на исправлении ошибок в вашей системе для текущей базы пользователей может быть ничтожно мала по сравнению с затратами на поддержку новых пользователей в течение срока службы системы.
