Постоянно изменяющиеся рамки/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

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

Мои мысли, а не уникальный (чтобы быть уверенным) идут довольно много, как это.

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

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

Answer 3

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

Answer 4

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

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

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

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

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