Я работаю в отделе информационных технологий крупной международной компании. Мы разрабатываем различные интранет-приложения для бизнеса (жалобы, скидки, служба поддержки и т. Д.). Теперь мы решили перейти с платформы PHP на .NET (среди многих причин - интеграция с MS CRM Dynamics, Exchange и MS Office). Поскольку на текущей платформе PHP используется около 20 различных приложений, нам нужно будет найти лучший способ перевести их все на новую платформу. Я не хочу вдаваться в подробности о том, как конвертировать код и т. Д., Поскольку во время миграции мы хотим улучшить все эти приложения.
Итак, мы придумали 2 основных способа перемещения этих приложений:
Поддержка только одной платформы. Что бы это значило? Создайте домашнюю страницу и буквально перенесите все приложения такими, какие они есть, в .NET (без их улучшения, пока мы это делаем). После запуска новой интрасети мы начнем перестраивать перенесенные приложения и улучшать их. Это спасло бы нас от разработки интрасети в .NET, в то же время поддерживая платформу PHP.
Поддержите обе платформы в течение некоторого времени. Это будет означать создание только домашней страницы и 1 или 2 новых приложений (которых нет на нашей платформе PHP). Делая их доступными для пользователей, но не снимая платформу PHP (мы включили бы меню и ссылки, чтобы пользователям было проще перемещаться между приложениями на странице PHP и новыми). Затем мы начинаем переписывать приложения PHP, одновременно улучшая их.
Теперь я не уверен, что было бы лучше, с одной стороны (вариант 1), мы потенциально сделаем все проще для пользователей, не заставляя их использовать две разные платформы одновременно. Хотя они не увидят никакого улучшения в новой платформе, кроме того, что выглядит лучше, функциональность приложений на новой платформе в течение некоторого времени будет прежней. Также я думаю, что мы добавили бы себя (ИТ-отдел) больше работы, так как по сути мы бы писали каждое приложение дважды.
С другой стороны, в варианте два (2) пользователи будут иметь худший опыт, поскольку две платформы выглядят по-разному, но они осознают преимущества новой платформы по мере продвижения новых приложений.
Кто-нибудь из вас сталкивался с чем-то подобным? Что бы вы выбрали? Или, может быть, есть даже другой, лучший способ для тех, кого я представил? Я хотел бы знать, что вы думаете и как бы вы подошли к этому.
Ответы:
Давайте рассмотрим оба сценария:
Миграция все сразу
Пока вы переносите свою кодовую базу, ваши клиенты будут продолжать использовать ваши существующие приложения. Поскольку миграция займет нетривиальное количество времени, это означает, что вам потребуется команда поддержки старой базы кода для исправления ошибок и разработки функций. Каждое изменение, которое вы делаете в старой кодовой базе, должно происходить в новой кодовой базе. Вы закончите писать каждую строку кода вдвое дольше, чем миграция не будет завершена, что сделает ее более дорогой, чем дольше она будет мигрировать. Итак, все сводится к следующему: каков будет срок выполнения полной миграции? Ваши затраты на разработку будут стремительно расти до тех пор, пока продолжается срок выполнения.
Пошаговая миграция
В этом сценарии вы будете лучше контролировать двойные усилия, но у вас все равно будет много дополнительных затрат. В вашем развертывании будут задействованы две отдельные платформы с удвоенными проблемами развертывания и дополнительными ресурсами сервера. Если у вас нет очень модульно организованного приложения, вы обнаружите, что часто фрагмент кода присутствует на другой платформе, отличной от той, на которой он вам нужен, что требует дополнительных усилий по переносу и обслуживанию. Пока миграция не завершена, ваши затраты на разработку будут выше. В то же время, давление функции будет означать, что вам потребуется очень много времени, чтобы закончить миграцию.
Вывод
Из личного опыта могу сказать вам две вещи:
источник
По финансовым причинам большинство компаний, с которыми я работал, пошли со вторым подходом, по праву могу добавить. Им нужно много денег, времени и рисков, чтобы достичь №1. Пользователь в основном понимает # 2, если видит ваш прогресс и взаимодействие с ними. В этой скудной и подлой экономике я сомневаюсь, что кто-нибудь выберет подход №1
источник
Подходы большого взрыва редко бывают конструктивными, если речь идет о конечных пользователях. Я бы посоветовал против этого и, честно говоря, я не могу поверить, что кто-то всерьез рассматривал бы это как вариант, учитывая количество рассматриваемых заявок.
Я был бы склонен пойти со вторым вариантом и обрабатывать переделки в каждом конкретном случае. По общему признанию, это может занять больше времени, чем подход на бумаге, но на самом деле вы открываете значительный бизнес-риск, выбирая подход один, и я действительно не хотел бы присутствовать на звонках в службу поддержки в первый день, если есть даже только одна маленькая проблема на стороне пользователя.
Кроме того, если подавляющая часть ваших приложений на основе веб-сервисов уже написана на php, каков доступный опыт .Net?
Я думаю, что в любом случае вашим пользователям придется столкнуться с изменениями, либо большим взрывом (например, много звонков в службу поддержки), либо частичным (увеличение знакомства). Я склонен думать, что вы на самом деле не определили, сколько именно работы придется проделать, чтобы перейти от почти полностью php к полностью .Net.
источник
Во-первых, я согласен со всем, что говорит Джори.
Первый вариант действительно ужасен. Если вы сделаете это и не продолжите поддержку, как описывает Джоэри, вы отключите поддержку на несколько лет, насколько ваш клиент это увидит. Через два года они фактически получают один и тот же сайт со всеми теми же проблемами, с которыми они знакомы и ненавидят последние несколько лет. Плюс риск того, что рынок тем временем изменился и сделал приложение устаревшим и нуждающимся в серьезном обновлении. Кроме того, если вы отключите поддержку на два года, что, по вашему мнению, произойдет со всеми запросами на обслуживание? Они не уйдут. По крайней мере, некоторые из ваших пользователей будут «воровать» и разрабатывать критически важные системы в (возможно) доступе, чтобы заполнить пробелы в системах, которые вы переписываете - тогда вы все равно в конечном итоге поддержите две платформы ...
Второй вариант означает, что вы будете поддерживать обе технологии в течение длительного периода времени. Этот период времени будет дольше, чем вы думаете, и вы можете получить постоянно фрагментированную экосистему - то есть значительный объем кода PHP, который не экономично переписывать, смешанный с новым кодом .NET.
Оттолкнись против того, кто предлагает это. Написание кода для интеграции приложений PHP с предлагаемыми вами продуктами будет намного дешевле, чем переписывать все в .NET, а затем интегрировать переписанный код с продуктами, не забывайте, что при использовании .NET волшебная интеграция не произойдет. ,
Еще одна вещь: возьмите количество строк кода PHP и поместите его в инструмент COCOMO 2, чтобы получить представление о том, сколько и сколько разработчиков вам понадобится для завершения переписывания.
источник
У вас есть третий вариант: -
Перенесите код php на ваш сервер Windows и ISS (тот же, на котором вы планируете запускать .NET!)
Затем вы можете добавлять новые приложения в .NET (и медленно конвертировать некоторые старые в .NET), одновременно предоставляя своим пользователям то, что похоже на единую систему.
источник