Когда можно отказаться от обратной совместимости в пользу новой и улучшенной реализации интерфейса? [закрыто]

Я работаю в одной и той же софтверной компании более десяти лет. В результате я реализовал большую кодовую базу, используя различные объектно-ориентированные языки программирования. Я был начинающим программистом, когда только начинал свою карьеру, и я не знал много о хорошем интерфейсе и принципах дизайна класса. Я хотел бы думать, что со временем мои навыки проектирования улучшились, но теперь я сталкиваюсь с все большими и большими трудностями в улучшении моего более раннего кода из-за проблем обратной совместимости. Мой код используется большим количеством клиентов как часть продуктов, которые продает моя компания.

Мой вопрос: когда следует прекратить попытки поддерживать обратную совместимость старых интерфейсов и перекусить в пользу реализации совершенно нового дизайна?

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

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

• Общайтесь со своими клиентами / клиентами задолго до любого перехода. Объясните, почему и как это будет реализовано. Ссылаясь на безопасность, производительность, стабильность и будущую гибкость в качестве причин, все это справедливо.
• Если вы все равно делаете чистый перерыв, попросите обратную связь.
• Если есть сторонние разработчики, убедитесь, что вы включили их вклад в той степени, в которой это имеет смысл.
• Если это возможно, обеспечьте уровень совместимости.
• Предоставить полное руководство по обновлению.
• Сделайте обновление максимально простым и безболезненным. Сведите к минимуму боль ваших пользователей, даже если для вас это потребует немного больше работы.
• Если вы берете плату, предложите скидку на обновления до новой версии.
• Добавьте хотя бы несколько новых и полезных функций в новую версию, чтобы стимулировать обновление. Это особенно важно, чтобы сделать обновление более привлекательным для менеджеров.
• Если вы делаете перерыв, сделайте это в последний раз, когда он вам нужен. Это означает, что необходимо заранее провести комплексное планирование и убедиться, что все настроено правильно.
• Если у вас есть пользовательский интерфейс, не стесняйтесь вносить в него изменения. Думайте обновите, а не перепроектируйте. Для нетехнических пользователей резкие изменения пользовательского интерфейса с одной версии на другую могут стать причиной разочарования.
• Ваша новая версия должна быть заметно более стабильной и производительной, чем старая. Не давайте своим пользователям повод для повторного обновления. Не выпускайте новую версию без предварительного тщательного тестирования (модульное, интеграционное и бета-тестирование).
• Поддерживать старую версию одновременно в течение длительного периода времени. Если вы решите отказаться от поддержки и прекратить поддержку, сообщите об этом не менее чем за 6–12 месяцев, если возможно, больше.
• Можете ли вы позволить себе поддерживать две версии одновременно с точки зрения финансов и рабочей силы? (Кроме того, с точки зрения бизнеса, вам не следует прекращать поддержку старой версии, пока вы не можете позволить себе потерять оставшихся клиентов, которые цепляются за старую версию и не хотят обновляться. Этот момент должен быть, когда ваши расходы на поддержание этого перевешивает вашу прибыль от этого.)
• Принять обязательство делать обновления безопасности в течение периода времени после того, как старая версия была прекращена при необходимости.
• Опять же, общение огромно на протяжении всего процесса. Не оставляйте своих пользователей / клиентов / клиентов чувствовать себя покинутыми в любой момент. Их лояльность и страсть является основой вашего бизнеса. Убедитесь, что вы отвечаете на их вопросы в своем блоге или на ваших форумах. Социальный фактор не следует недооценивать.

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

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

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

Этот пример взят из одной из команд, с которыми я работаю. Они отправляют товар на регулярной основе, по крайней мере, один раз в месяц, иногда даже еженедельно. Заказчикам рекомендуется обновиться, поскольку новые функции и новые платформы поддерживаются только в новых версиях. Обновление легко, и клиенты могут даже пропустить промежуточные версии. Понижение рейтинга не поддерживается. Кроме того, версии поддерживаются только в течение 3 лет. После этого существует льготный период в один год, когда плата за обслуживание удваивается.

В результате подавляющее большинство - около 95% клиентов - обновляются регулярно, по крайней мере, один раз в год. Это также означает, что вы можете постепенно вводить новые интерфейсы.

Как насчет старых интерфейсов? Техника, которую использует эта команда, объявляет старые интерфейсы «оконченными». Затем существует 12-месячный период, в течение которого новый интерфейс доступен, и старый интерфейс еще не удален. Новые интерфейсы предлагают лучшие возможности, чем старый интерфейс, поэтому есть два стимула: конец старого интерфейса и новый интерфейс намного лучше.

Конкретный старый интерфейс в этом случае представлял собой платформо-зависимую технологию, которая постепенно заменяется сервисным интерфейсом, основанным на стандартной основной технологии.

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

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

У вас уже есть несколько хороших ответов, поэтому я просто хотел бы добавить указатель на очень хорошую статью Джоэла Спольски по этой теме. Он обсуждает планы отказа от обратной совместимости в IE 8, что по сути совпадает с вашей проблемой:

http://www.joelonsoftware.com/items/2008/03/17.html

Краткий ответ: Никогда!

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

Если вы просите своих пользователей переписать код, после того, как они закончили ругаться с вами и всеми вашими потомками, они подумают: «Если мне все равно придется переписать, может быть, мне стоит просто переключиться на ту прекрасную библиотеку ACME, которую я читал так много о?

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

Изменить, чтобы уточнить это дальше.

То, что вы, как программист, думаете, -

«Я улучшу этот API и сделаю систему как можно лучше, и все будут восхищаться мной».

Что подумают пользователи вашего API -

«А * * * е он думает , что мое время и график не важен. Я должен остановить то , что я делаю , и реорганизовать весь мой код ни по какой другой причине , чем удовлетворить свой эго. Если я должен реорганизовать тогда я буду коммутатор к другому API, просто чтобы он тоже его ".

Это действительно скорее деловое решение, чем техническое. Обычно это делается как часть основного выпуска (например, переход с версии 3.5 на версию 4.0), и часто две версии поддерживаются параллельно некоторое время. Это означает, что вы будете выполнять обслуживание старой версии, но все новые функции появятся только в новой версии. Старая версия поддерживается до тех пор, пока компания зарабатывает на этом деньги, или, по крайней мере, достаточно, чтобы компенсировать затраты на обслуживание. Будьте готовы передать это руководству.

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

В настоящее время мы обновляем нашу учетную систему. Компания, выполняющая обновление, также поддерживает предыдущую несовместимую версию. Они планируют взять данные и переместить их в новую систему, чтобы (теоретически) все старые данные были там. Мы будем платить пару сотен фунтов за преобразование данных. Нет проблем.

Сравните с предыдущей ситуацией в другой компании, на которую я работал. Поставщик не имел возможности перейти от старых систем к новым. Это ставит их в ту же ситуацию, что и любой другой поставщик. На самом деле их ситуация была хуже, потому что мы знали, что они не обязаны помогать нам с обновлениями. Они не получили новый контракт.

Вы проделали тяжелую работу по привлечению и удержанию клиентов, как вы можете облегчить переход?