Як мій багатонаціональний перехід від однієї платформи розвитку до іншої?

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

Тому ми придумали два основні способи переміщення цих додатків:

1. Підтримка лише однієї платформи. Що це означало б? Створіть домашню сторінку та буквально перенесіть усі додатки у форматі до .NET (не вдосконалюючи їх, поки ми це робимо). Після запуску нової інтранет ми почнемо відновлювати міграційні програми та вдосконалювати їх. Це врятувало б нам розвивати інтранет у .NET, маючи необхідність підтримувати PHP платформу.

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

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

Хтось із вас натрапив на щось подібне? Що б ви вибрали? А може, є навіть інший, кращий шлях до тих, кого я представив? Я хотів би знати, що ви думаєте, і як би ви до цього підійшли.

Розглянемо обидва сценарії:

Все одночасно міграція

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

Поетапна міграція

У цьому сценарії ви матимете кращий контроль над подвійними зусиллями, але у вас все ще буде багато додаткових витрат. Для розгортання будуть задіяні дві окремі платформи, що потребують подвійних проблем із розгортанням та додаткових ресурсів сервера. Якщо у вас є дуже модульно організований додаток, ви виявите, що часто фрагмент коду присутній на іншій платформі, ніж на тій, яка вам потрібна, що спричиняє додаткові зусилля для перенесення та обслуговування. Поки міграція не буде виконана, вартість розробки буде вище. У той же час, тиск на функцію означає, що для завершення міграції вам знадобиться дуже багато часу.

Висновок

З особистого досвіду можу сказати вам дві речі:

• Перемикання мов програмування рідко окупається. Згідно з аналізом витрат і вигод, малоймовірно, що буде вигідно перейти на .NET від PHP. Тому моя головна порада: не варто. Спробуйте вирішити свої проблеми з наявною базою даних коду.
• Поетапно - це найкращий підхід, але вам буде важко це робити на рівні модулів додатків. Ви побачите, що вам доведеться розробляти та підтримувати функції з обох сторін архітектури до тих пір, поки міграція не буде повністю виконана. Непогано визначити пріоритетність функцій не на основі того, що найбільше потребує клієнтів, а на тому, що обмежить кількість подвійних зусиль (тим самим знизивши вартість).

З фінансової причини більшість компаній, над якими я працював, пішли з другим підходом, справедливо можу додати. Для їх отримання потрібно багато грошей, часу та ризиків. Користувач здебільшого розуміє №2 до тих пір, поки побачить ваш прогрес та взаємодію з ними. У цій худкій та середній економіці я сумніваюся, що хтось скористається підходом №1.

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

Я був би схильний перейти з варіантом два та обробляти повторні роботи у кожному конкретному випадку. Справді, це може зайняти більше часу, ніж підхід на папері, але насправді ви відкриваєте значну кількість ділових ризиків, взявши підхід до одного, і я дійсно не хотів би бути поруч за дзвінками підтримки в перший день, якщо є навіть лише одна маленька проблема на кінці користувача.

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

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

По-перше, я згоден з усім, що говорить Джорі.

Варіант перший справді жахливий. Якщо ви це зробите і не продовжуєте підтримку, як описує Joeri, ви можете вимкнути підтримку на пару років, наскільки ваш клієнт її бачить. Через два роки вони фактично отримують один і той самий сайт із усіма тими ж проблемами, про які останні роки знають і ненавиджу. Плюс ризик того, що ринок змінився в проміжок часу і зробив заявку застарілою і потребує значного оновлення. Крім того, якщо ви припиняєте підтримку на два роки, як ви думаєте, що станеться з усіма запитами на обслуговування? Вони не підуть. Принаймні, деякі ваші користувачі будуть «переходити в шахрайство» і розробляти критично важливі системи в (ймовірно) доступі, щоб усунути прогалини в системах, які ви переписуєте, - тоді ви все одно підтримуєте дві платформи ...

Варіант другий означає, що ви будете підтримувати обидві технології протягом тривалого періоду часу. Цей проміжок часу буде довшим, ніж ви думаєте, і у вас може виникнути постійно фрагментована екосистема - тобто значна кількість PHP-коду, що не є економічним для перезапису, змішаного з новішим кодом .NET.

Відштовхуйтесь від того, хто це пропонує. Буде набагато дешевше написати код для інтеграції програм PHP з запропонованими вами продуктами, ніж переписувати все в .NET, потім інтегрувати переписаний код з продуктами, не забувайте, інтеграція не стане магічним, якщо ви будете використовувати .NET .

Ще одне - взяти кількість рядків PHP-коду і вкласти його в інструмент COCOMO 2, щоб отримати уявлення про те, як довго і скільки розробників вам знадобиться для завершення перезапису.

У вас є третій варіант: -

Перемістіть php-код на свій Windows-сервер та ISS (той самий, який ви плануєте запустити .NET у!)

Потім ви можете додавати нові програми в .NET (і повільно конвертувати деякі старіші в .NET), представляючи своїм користувачам те, що схоже на єдину систему.