Как вы справляетесь с технологическими обновлениями в долгосрочных проектах? - PullRequest
2 голосов
/ 23 мая 2009

Предположим, вы находитесь в середине долгосрочного проекта (длительный период = несколько лет), и, как ожидается, будет несколько вещей, которые появятся в новых выпусках. Это может быть новая .Net Framework с совершенно новыми функциями (например, Linq, Entity Framework, WPF, WF ...), новая Visual Studio или V.next из вашей любимой библиотеки управления, новая Mock Framework и многое другое , Каковы ваши рекомендации по работе с этими обновлениями технологии? Принимаете ли вы их сразу или игнорируете до конца проекта? У вас есть разные рекомендации по разным вещам (инструменты, рамки, вспомогательные материалы)?

Ответы [ 6 ]

4 голосов
/ 23 мая 2009

По моему опыту, эти решения всегда принимаются в индивидуальном порядке. Рассматривается несколько факторов, в том числе:

  1. Насколько зрела новая технология? Нравится ли организации быть в авангарде работы с новейшими технологиями или предпочитает работать с проверенными инструментами и методологиями?

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

  3. Какие у вас инвестиции в существующие технологии? Какова стоимость перехода на новые технологии? Сколько времени занимает переработка и переписывание кода?

  4. Какое требование? Поддерживается ли это существующей технологией, или необходимы новые инструменты для выполнения требования?

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

  6. А как насчет технологической культуры? Является ли конкретный поставщик организации (например, магазин Microsoft)? Можно ли использовать открытый исходный код?

  7. Каков объем проекта? Это большой проект, который выиграл бы от поддержки технологий, таких как фреймворки и инструменты, или это небольшой проект, который излишне отягощен и усложнен этими вещами?

  8. Как поддерживается новая технология? Есть ли у продавца хорошая документация? С кем вы можете поговорить, если у вас есть проблемы? Или вы организация, в которой есть люди, которые знают, как решать проблемы без контракта на поддержку?

  9. Удобно ли работать с этой технологией? Кажется ли это имеет смысл? Это чисто и элегантно? Кажется ли это нравится другим людям? У других людей с этим проблемы?

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

  11. Сколько времени вам нужно, чтобы изучить новую технологию и сгладить изгибы? Преимущества перевешивают затраты?

В качестве очень краткого примера я выбрал Link to SQL для своего последнего проекта, потому что проект был достаточно сложным, чтобы гарантировать ORM, L2S работает хорошо и легковесен, мы - магазин Microsoft, и я чувствую, что платформа Entity не совсем готова для прайм-тайма (хотя Microsoft и заявляет, что она станет платформой перехода к будущему).

3 голосов
/ 23 мая 2009

Придерживайтесь того, с чего вы начали.

Большой и длительный проект часто поставляется с огромной и очень сложной базой кода. Любое изменение или обновление до новой версии библиотеки может добавлять ошибки очень тонкими и неожиданными способами.

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

Всегда помни: не меняй лошадей посреди ручья. : -)

1 голос
/ 23 мая 2009

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

На более практическом уровне, если ваша инфраструктура имеет Git или SVN-репозиторий, извлеките обычный «системный» каталог из репозитория, тогда вы можете иногда вызывать «svn update», чтобы идти в ногу с последними и лучшими сборками.

1 голос
/ 23 мая 2009

Я бы сказал, что разные факторы влияют, например, -

  1. Предположим, что срок годности программного обеспечения истекает, например, в апреле прошлого года Microsoft прекратила поддержку SQL Server 2000, и ваш продукт использует его, чтобы перейти к следующей версии SQL Server в следующем выпуске. 1004 *
  2. Еще один фактор, который вступает в игру, - это то, какую ценность принесут в ваш продукт новые функции в последней версии программного обеспечения. Вполне возможно, что в новом выпуске .NET Framework есть что-то, что не добавляет ценности вашему продукту, тогда это не дает веских оснований для обновления.
  3. Бюджет также является важным фактором. Я думаю, что вам нужно обновить лицензии, чтобы перейти к следующему выпуску, если вы уже не являетесь частью чего-то вроде Software Assurance.
  4. Обучение в команде также является фактором. Если к вашему продукту добавится последний выпуск, вам также придется обучать свою команду.

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

ура

0 голосов
/ 23 мая 2009

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

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

0 голосов
/ 23 мая 2009

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

...