Когда переходить на новую версию языка или платформы?

Question

Когда появляется новая версия фреймворка или языка (например..NET 3.5, SQL2008), какой подход люди используют при внедрении/обновлении?

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

Я особенно имею в виду «текущие» системы и проекты (например, в компании по разработке программного обеспечения), которые существуют и развиваются годами, где подход «новые проекты используют новую технологию» не работает.

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

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

Или подход «если не сломалось, не чините» является правильным подходом?

Answer 1

Ознакомьтесь с техническим долгом . Это простое решение с точки зрения затрат и выгод.

Если не сломалось, не исправляйте " Это общая политика управления, которая гласит: «Доллары завтрашнего дня не стоят столько, сколько сегодня, поэтому не планируйте будущих улучшений». В конечном итоге технический долг накапливается до такой степени, что продукт больше не может хромать.

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

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

В случае программного обеспечения с открытым исходным кодом требуется тщательное техническое управление, поскольку официальная поддержка " объявление от Oracle / Sun. Плохое техническое управление, конечно, приводит к техническому банкротству.

Answer 2

Мы рассмотрим стоимость жизненного цикла поддержки . Как долго поддерживаются старые версии и сколько стоит? Такие платформы, как Windows и Java, имеют тенденцию двигаться быстрее по сравнению со средами мэйнфреймов, и часть затрат на ведение бизнеса на этих платформах заключается в периодическом обновлении. В рациональном мире это так!

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

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

Answer 3

Я думаю, что главный вопрос заключается в том, выживет ли ваше приложение в долгосрочной перспективе, если вы НИКОГДА не будете обновлять версию платформы / языка. Если вы считаете, что это невозможно, вы можете обновить его раньше, чем позже, поскольку это станет только сложнее.

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

Answer 4

Когда вам действительно нужно. .NET 1.0 была дрянной, 1.1 была хорошим обновлением, но веб-разработка с VS2003 не была настолько гладкой. Вещи улучшились с VS2005 и .NET 2.0 & # 8211; и я все еще вижу, что многие разработчики и компании придерживаются .NET 2.0. Предыдущие версии были такими свежими, версия 2.0 была зрелой технологией. Итак, если вы были довольны 1.1, зачем вам обновляться? Если вас сейчас устраивает 2.0, зачем обновляться до 3.5 или 4.0?

Answer 5

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

Answer 6

Когда вы разрабатываете для платформ на базе Microsoft, таких как приложение для Windows Forms для Windows или веб-приложение ASP.NET для Windows Server, самое подходящее время для миграции - это для каждых двух основных версий ОС. Например, если ваше приложение было разработано для Windows 2000 вы должны перейти на Vista, хотя XP можно пренебречь. Точно так же, если бы он был разработан для XP SP2, вы можете спокойно игнорировать Vista и целевой Win 7. Обычно Microsoft никогда не прерывает (или редко ломает) инкрементные обновления ОС. Таким образом, приложение, работающее на сегодняшней ОС, обязательно будет работать на следующей. Но никогда ни за кем не следуй. (Если работает, как M $ зарабатывает деньги ???)

Источник: Self ... Windows Developer более 5 лет)

Answer 7

Я готов к обновлению как можно скорее (хотя я мог бы подождать месяц после выхода новой версии на случай необнаруженных проблем).Есть несколько вещей, о которых вам нужно подумать:

1.Релизы безопасности

Многие из тех, кто говорит мне, что это не сломано, не исправляют это, также являются теми же людьми, которые закрывают глаза, когда выходят исправления безопасности.Вспомните «Эквифакс».

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

2.Привлечение и удержание талантов

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

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

3.Новые и более простые способы, предлагаемые в новой версии.

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