Миграция приложений — мифы и реальность +6


Предыстория


Ни для кого из опытных IT профессионалов не секрет, что на большинстве крупных предприятий как нашей необъятной Родины, так и во всех остальных точках мира, где есть IT профессионалы и крупные предприятия, накопился достаточно большой багаж различных программных систем, разработанных для предприятия, а зачастую — на самом предприятии.

Самым старым системам из тех, что еще в эксплуатации, может быть уже 15-20-25 лет — многие из них написаны еще на FoxBASE для DOS и постоянно расширяются с тех пор. Некоторые, конечно, мигрировали, постепенно, в FoxPro для DOS, а самые везучие — даже в FoxPro для Windows и дальше — Visual FoxPro.

Системы 15-20 летней давности зачастую написаны на Delphi, некоторые — переводились с версии на версию, но большинство Delphi систем так и остались на последних именно Borland версиях, то есть Delphi 6/7.

На текущий момент существует огромное количество подобных систем, разработанных на старых или не старых, но не самых удобных программных платформах/языках программирования (перечисленные выше языки — лишь примеры).

Главная головная боль для IT отделов таких предприятий — «что с этим делать?!». Ведь старые платформы/средства разработки перестают поддерживаться (тот же FoxPro), сами программы начинают плохо работать на современных ОС (если это — FoxPro для DOS — тут вообще без комментариев), старые ОС на новое железо ставить — тоже проблематично. Ну а главная проблема — на рынке труда все меньше и меньше тех, что хорошо знает старые языки и может качественно поддерживать систему.

Рано или поздно возникает понимание, что нужно переходить на современные платформы и тут возникает новая проблема — стоимость, как по деньгам, так и по времени.

Для тех, кто интересуется этой проблемой — под катом более детальное описание того, почему переписывание систем — дорого и что же делать со старыми системами.

Стоимость


На первый взгляд кажется, что переписать готовую систему не проблема, ведь есть весь код. «А давайте по-быстрому его „перепишем на Джава“ — и всё!». Первый раз такое заявление я услышал году этак в 2001-м. Речь шла о «небольшой» системе, которую коллектив из 10 ОЧЕНЬ продвинутых программистов разрабатывал в течение 13 лет. Объём кода, по примерным прикидкам, составлял более 10 млн строк.

А теперь немного математики: в среднем неплохой программист может переписать вручную за день 30 (да, да — тридцать) строк кода. Причём далеко не любой программист. Здесь необходимо:
  1. Хорошее знание платформы, на которую переносится код;
  2. Как минимум, неплохое знание платформы, с которой переносится код.

В принципе, я встречал людей, которые могли работать производительнее при условии 16 часового рабочего дня, великолепного знания обеих платформ и личной заинтересованности в проекте (человек был одновременно идеологом старой системы, владельцем предприятия и идеологом новой системы — такой «сплав» я встречал только один раз в жизни).

Для остальных вышеприведённая цифра в 30 строк кода / 8 часов — среднее значение.

Итак, на примере системы из 2001 года посчитаем: 10 000 000 / 30 * 8 = 2 666 666, 6(6) человеко-часов, что примерно равно 11 000 1388,8(8) человеко-лет. Если даже посчитать, что такому программисту надо платить 40 000 рублей в месяц (480 000 в год + налоги = примерно 700 000 рублей в год), умножаем на 11 000 1 400 (округлим). Эммм. Получается 14 * 7 * 1 000 000, то есть 7.7 миллиардов 980 миллионов рублей только зарплаты и налоги!

Предположим, у предприятия не такая громадная система и в ней содержится «всего лишь» 1 миллион строк кода. Кроме того, предположим, что предприятие найдет 5-6 действительно супер программистов, которые будут переписывать проект со средней скоростью 300 строк кода в день (цифра абсолютно нереальная — 40 строк в час писать возможно только в случае, когда пишешь алгоритм «из головы», который продумывал долгое время, но тогда накладывается это самое время на обдумывание, да и алгоритмов таких не слишком много, а нам важна средняя скорость). Тогда затраты на проект упадут примерно в 30-40 раз (таким суперам и платить надо больше), но все равно останется 100 человеко-лет, которые коллективом из 5 человек растянутся на 20 календарных лет2,8 календарных года при стоимости, например, 200 000 000 (двести миллионов) 20 000 000 (двадцать миллионов) на, опять-таки, зарплату + налоги.

Итог расчётов можно выразить просто: действительно большую систему переписать руками, конечно, можно, но стоимость и сроки — абсолютно нереальные.

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

Что же делать?


Что же делать? Выходов из ситуации, конечно, есть несколько.

Для некоторых компаний подойдёт переход на готовые решения, благо их хватает — тут и Аксапта, и 1С: Предприятие, и Галактика, и многое другое.

Кому-то вообще хватит правильной настройки SharePoint + Office 365, например.

Но что же делать тем, у кого системы выходят за рамки стандартных?

Ниже будет приведено несколько вариантов решений.

Глубокая настройка готовых решений с переносом участков кода

В принципе, на рынке сейчас хватает компаний-интеграторов, которые могу выполнить настройку готовой коробочной системы под нужды клиента. Оставим за кадром то, что некоторые коробочные решения очень плохо живут с большим объемом данных/количеством транзакций. Рассмотрим только тот факт, что если старая система имеет большой объем, в нем много нестандартных «фишек», или же людей, которые в ней ориентируются и смогут чётко выделить небольшие участки кода, которые отвечают за эти самые фичи нет — мы скатываемся почти к случаю переписывания «ручками». Точно так же надо искать код, переносить его и интегрировать с готовой системой.

Настройка готовых решений по ТЗ

Еще есть некоторое количество предприятий, которые смогут составить грамотное ТЗ по дополнительным функциям, выбрать подходящую платформу. Тогда они смогут относительно малой кровью и своими (или интеграторскими/аутсорсерскими) силами доработать подходящую «коробочную» платформу под свои нужды, но количество таких компаний мало — не везде есть действительно грамотные постановщики задач и ТЗписатели.

А остальные?

Рассмотрим самый частый вариант:
  1. У предприятия есть большая система, которая работает в предприятии много лет, для системы имеются исходники;
  2. Из изначальных разработчиков системы никого не осталось, либо оставшиеся саботируют процесс переноса системы, так как перестанут быть «незаменимыми»;
  3. Система не ложится «легко и быстро» на функции готовых коробочных решений;
  4. В системе имеется огромный набор данных, которые необходимо сохранить;
  5. У системы есть большое количество пользователей, которые привыкли к старому внешнему виду системы и расположению элементов Gui;
  6. В компании нет толпы мега-супер-разработчиков, которые могли бы писать код по 1000хотя бы 100 строк в сутки в процессе переноса кода с платформы на платформуза еду за разумные смешные для лубого программиста деньги.

Выглядит очень грустно. Таких предприятий и систем много, а решений вроде бы нет- всё вышеперечисленное не подходит:
  1. Переписать руками — долго и очень дорого;
  2. Готовое решение — быстро, приемлемо по цене, но можно потерять старые данные (или часть) и часть функционала, интерфейс, скорее всего, будет непривычен пользователям;
  3. Адаптированное готовое решение — либо получаем все проблемы первого варианта при адаптации/настройке/дописывании, либо же скатываемся ко второму решению.

На самом деле, как я с удивлением узнал в 2009 году, решение есть, оно придумано в далеком (сейчас) 2000 году и заключается оно в автоматической миграции данных и исходных текстов приложения. И да, вопреки мнению большинства, это решение вполне рабочее и несёт ОГРОМНУЮ выгоду предприятию, которое на него идёт.

Автоматическая миграция


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

Рассмотрим детальнее.

Миграция данных

Здесь всё более-менее прости и больших нареканий не вызывает — почти всегда данные, предназначенные для старых систем, можно перенести на современные платформы (Oracle, MS SQL, в экзотических случаях — на post-SQL БД).

Для многих связок существуют готовые решения (например, MS SQL Data Transformation Wizard, Borland DataPump и т.д.) в случае, когда решение сложнее обычного. Можно адаптировать то, что есть, либо написать небольшое pump-приложение, которое перенесет данные. Думаю, что особо на этом пункте останавливаться не нужно.

Миграция кода

Вот этот пункт как раз и вызывает основной скепсис в IT-сообществе. Правда чаще всего возражения носят вид:
  • «Если бы это было возможным, я бы об этом знал и вообще сам бы умел» — здесь можно только вспомнить байку про Колумба и яйцо;
  • «Да я быстрее сам перепишу это руками» — перечитываем пункт про переписывание и особенно — стоимость и сроки работ.

На самом, деле почти все возражения сводятся к вышеперечисленным.

Итак, как это работает?

Все очень просто — исходный текст, на старой платформе, транслируется в текст на новой платформе. В некоторых случаях дописывается миграционная библиотека.

Выглядит просто? Да.

Тогда заглянем поглубже.

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

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

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

UPD


В комментариях резонно указали на ошибки в вычислениях — они помечены теперь как зачёркнутые неверные значения и за ними курсивом новые — верные. Огромное спасибо господам erp_shnik и asis — благодаря их внимательности внесены исправления. В целом, порядок цифр все равно не меняет вывода. (во втором исправлении будет обоснование).

UPD2


В ответ на множество комментариев (особенное спасибо господам vladsharikov, lair, berez за конструктивные вопросы и уточнения), на этой неделе будет написана вторая статья — там будут приведены примеры сконвертированного кода.

UPD3


Вот вторая статья, с примерами конвертации кода и GUI




К сожалению, не доступен сервер mySQL