Постоянно меняющиеся фреймворки / API-интерфейсы

Question

Этот вопрос на самом деле не для какой-либо конкретной технологии, а скорее для общего вопроса разработчика.

Все мы знаем из опыта, что все меняется. Фреймворки развиваются, добавляются новые функции и удаляются вещи.

Например, как может продукт, использующий версию 1.0 среды ABC, адаптироваться, когда появится версия 2.0 (ABC может быть .NET, Java, Cocoa или что-то еще)?

Одним из решений может быть сделать фреймворки обратно совместимыми; так что код, написанный для 1.0, все еще будет работать в версии 2.0 платформы.

Другим может быть выборочное нацеливание только на версию 1.0 фреймворка, но это может оставить многие необычные новые функции неиспользованными (многие приложения .NET 2.0, похоже, делают это)

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

Answer 1

Ожидайте и инвестируйте в изменения.

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

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

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

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

Изменения следует принимать, а не бояться. Разработчики, заинтересованные стороны и деловые люди должны быть в курсе новых технологий и структур. Всегда будьте готовы к изменению адреса. В Советской России API не отставал от вас!

Answer 2

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

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

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

Или выбери что-нибудь еще посреди дороги.

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

Answer 3

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

Answer 4

О, возможные ответы ....

Мои мысли, хотя и не уникальные (чтобы быть уверенными), идут примерно так.

1. Внесите свой код в систему контроля версий - вы используете систему контроля версий, верно?
2. На ветке обновите фреймворк (или что у вас)
3. Исправьте проблемы в ваших юнит-тестах. Воспользуйтесь преимуществами новых API-интерфейсов Framework, удалите устаревшие ссылки и т. Д.
4. Тщательный тест.
5. [опционально] задвинуть обратно в транк (это и 4, вероятно, можно перевернуть)
6. Выпуск в производство - поздравляю, теперь вы на новой платформе.

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