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

10

Я работаю в отделе информационных технологий крупной международной компании. Мы разрабатываем различные интранет-приложения для бизнеса (жалобы, скидки, служба поддержки и т. Д.). Теперь мы решили перейти с платформы PHP на .NET (среди многих причин - интеграция с MS CRM Dynamics, Exchange и MS Office). Поскольку на текущей платформе PHP используется около 20 различных приложений, нам нужно будет найти лучший способ перевести их все на новую платформу. Я не хочу вдаваться в подробности о том, как конвертировать код и т. Д., Поскольку во время миграции мы хотим улучшить все эти приложения.

Итак, мы придумали 2 основных способа перемещения этих приложений:

  1. Поддержка только одной платформы. Что бы это значило? Создайте домашнюю страницу и буквально перенесите все приложения такими, какие они есть, в .NET (без их улучшения, пока мы это делаем). После запуска новой интрасети мы начнем перестраивать перенесенные приложения и улучшать их. Это спасло бы нас от разработки интрасети в .NET, в то же время поддерживая платформу PHP.

  2. Поддержите обе платформы в течение некоторого времени. Это будет означать создание только домашней страницы и 1 или 2 новых приложений (которых нет на нашей платформе PHP). Делая их доступными для пользователей, но не снимая платформу PHP (мы включили бы меню и ссылки, чтобы пользователям было проще перемещаться между приложениями на странице PHP и новыми). Затем мы начинаем переписывать приложения PHP, одновременно улучшая их.

Теперь я не уверен, что было бы лучше, с одной стороны (вариант 1), мы потенциально сделаем все проще для пользователей, не заставляя их использовать две разные платформы одновременно. Хотя они не увидят никакого улучшения в новой платформе, кроме того, что выглядит лучше, функциональность приложений на новой платформе в течение некоторого времени будет прежней. Также я думаю, что мы добавили бы себя (ИТ-отдел) больше работы, так как по сути мы бы писали каждое приложение дважды.
С другой стороны, в варианте два (2) пользователи будут иметь худший опыт, поскольку две платформы выглядят по-разному, но они осознают преимущества новой платформы по мере продвижения новых приложений.

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

Даниэль Грушчик
источник
1
Разве # 2 не шаг к # 1?
Тэ Сон Шин
Нет, это две разные вещи. В первом случае мы перенесли бы всю интрасеть, прежде чем позволить пользователям ее использовать, а затем мы работали над улучшением приложений. Во 2 мы перенесли бы основную часть интрасети, позволили бы пользователям использовать ее, а затем начали бы мигрировать другие приложения и улучшать их, пока мы мигрировали ...
@greengit: прочитайте тему, одна из причин - интеграция с другими критически важными бизнес-приложениями. Мой вопрос не о том, почему мигрировать, а о том, как мигрировать.
Даниэль Грущик
Я прочитал тему и у меня был тот же вопрос. Я очень сомневаюсь, может ли проект когда-либо быть оправданным по стоимости. Можете ли вы назвать нам название компании, чтобы мы могли ее продать? ;)
Mcottle
ха-ха, я не беспокоюсь о затратах, чтобы быть честным, поскольку я просто студент по ИТ на рабочем месте в компании. Я просто прошу моих собственных знаний ... Похоже, мой менеджер оправдал затраты, достаточные для того, чтобы получить одобрение от генерального директора ...
Даниэль Грушчик

Ответы:

5

Давайте рассмотрим оба сценария:

Миграция все сразу

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

Пошаговая миграция

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

Вывод

Из личного опыта могу сказать вам две вещи:

  • Переключение языков программирования редко окупается. Из анализа затрат и выгод очень маловероятно, что будет выгодно перейти на .NET с PHP. Поэтому мой главный совет: не надо. Попробуйте решить ваши проблемы с существующей кодовой базой.
  • Пошаговое решение является лучшим подходом, но вам будет трудно сделать это на уровне модулей приложения. Вы обнаружите, что вам придется разрабатывать и поддерживать функции на обеих сторонах архитектуры до тех пор, пока миграция не будет полностью завершена. Хорошей идеей будет расставить приоритеты для функций, основываясь не на том, что больше всего нужно клиентам, а на том, что ограничит объем двойных усилий (тем самым снизив стоимость).
Джори Себрехтс
источник
Вы сделали очень интересные моменты. Хотя не мне решать, поменяем ли мы платформу или нет, и я буду работать в компании только до конца сентября (я с ними в универе). Переключение с PHP на .NET может быть хорошей идеей, хотя, поскольку у нас есть старая PHP-среда, потребуются некоторые ОСНОВНЫЕ работы, в том числе базы данных, система, которую компания использует в настоящее время, является OLD и создана людьми, которые не обладали большими навыками разработки. ..
Даниэль Грушчик
Также мой вопрос будет: «Заморозка изменений» на старой платформе - хорошая идея? Под этим я подразумеваю, что любые изменения в существующих системах на платформе PHP, кроме исправлений ошибок, замораживаются до тех пор, пока мы не начнем перемещать данное приложение в .NET. Это часть моего менеджера по плану миграции ...
Даниэль Грущик
Если это нетривиальная система, очень маловероятно, что замораживание изменений сработает на практике. Если кому-то действительно нужна функция, она переходит на более высокий уровень, чем ваш менеджер, и вы будете вынуждены вносить изменения. Кроме того, исправления сами по себе могут занимать значительное количество командных ресурсов. И всегда имейте в виду, что старые системы претерпели множество изменений, а новые дизайны, скорее всего, забудут все эти небольшие однострочные исправления, которые должны произойти снова и снова, чтобы пользователи могли принять обновленный продукт.
Джори Себрехтс
Еще один момент: если система будет перестроена, какие существуют меры безопасности для обеспечения лучшего качества кода на этот раз? Я видел приложение, которое было переписано 4 раза из-за проблем с платформой и качеством кода.
Джори Себрехтс
2

По финансовым причинам большинство компаний, с которыми я работал, пошли со вторым подходом, по праву могу добавить. Им нужно много денег, времени и рисков, чтобы достичь №1. Пользователь в основном понимает # 2, если видит ваш прогресс и взаимодействие с ними. В этой скудной и подлой экономике я сомневаюсь, что кто-нибудь выберет подход №1

Тае Сунг Шин
источник
Это была именно моя мысль. Мой менеджер хочет продолжить работу с № 1, что мне трудно понять.
2

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

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

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

Я думаю, что в любом случае вашим пользователям придется столкнуться с изменениями, либо большим взрывом (например, много звонков в службу поддержки), либо частичным (увеличение знакомства). Я склонен думать, что вы на самом деле не определили, сколько именно работы придется проделать, чтобы перейти от почти полностью php к полностью .Net.

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

Во-первых, я согласен со всем, что говорит Джори.

Первый вариант действительно ужасен. Если вы сделаете это и не продолжите поддержку, как описывает Джоэри, вы отключите поддержку на несколько лет, насколько ваш клиент это увидит. Через два года они фактически получают один и тот же сайт со всеми теми же проблемами, с которыми они знакомы и ненавидят последние несколько лет. Плюс риск того, что рынок тем временем изменился и сделал приложение устаревшим и нуждающимся в серьезном обновлении. Кроме того, если вы отключите поддержку на два года, что, по вашему мнению, произойдет со всеми запросами на обслуживание? Они не уйдут. По крайней мере, некоторые из ваших пользователей будут «воровать» и разрабатывать критически важные системы в (возможно) доступе, чтобы заполнить пробелы в системах, которые вы переписываете - тогда вы все равно в конечном итоге поддержите две платформы ...

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

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

Еще одна вещь: возьмите количество строк кода PHP и поместите его в инструмент COCOMO 2, чтобы получить представление о том, сколько и сколько разработчиков вам понадобится для завершения переписывания.

mcottle
источник
Хорошая точка зрения. Что бы вы сделали тогда, если бы не ваше решение, перенести ли вы систему или нет. Какой подход вы бы выбрали? Или, может быть, есть другой подход к ним, который я перечислил? Если ваш менеджер не согласится с вами, попытаетесь ли вы доказать, что ваш подход лучше?
Даниэль Грущик
Пишите PHP-приложения более многослойным способом, ориентированным на обслуживание. Используйте служебную служебную шину для буферизации интерфейса между PHP и Microsoft land. Ключевым моментом является оценка COCOMO, которая должна напугать переизбыток вашего менеджера.
Маккотл
1

У вас есть третий вариант: -

Перенесите код php на ваш сервер Windows и ISS (тот же, на котором вы планируете запускать .NET!)

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

Джеймс Андерсон
источник
PHP действительно работает под управлением IIS
Барт