Фон Ни для кого из опытных ИТ-специалистов не секрет, что на большинстве крупных предприятий, как на нашей необъятной Родине, так и во всех других уголках мира, где есть ИТ-специалисты и крупные предприятия, накоплен достаточно большой запас различных программных комплексов, разработанных для предприятии, а зачастую - на самом предприятии.
Самым старым системам, которые все еще используются, может быть 15-20-25 лет - многие из них были написаны на FoxBASE для DOS и с тех пор постоянно расширялись.
Некоторые, конечно, постепенно перешли на FoxPro для DOS, а самые удачливые даже перешли на FoxPro для Windows и далее на Visual FoxPro. Системы 15-20 лет назад часто писались на Delphi, некоторые переводились из версии в версию, но большинство систем Delphi остались на последних версиях Borland, то есть Delphi 6/7. В настоящее время существует огромное количество подобных систем, разработанных на старых или не старых, но не самых удобных программных платформах/языках программирования (перечисленные выше языки являются лишь примерами).
Основная головная боль ИТ-подразделений таких предприятий – «что с этим делать?!» Ведь старые платформы/средства разработки перестают поддерживаться (например, FoxPro), сами программы начинают плохо работать на современных ОС (если это FoxPro для DOS, вообще без комментариев), установка старых операционок на новое железо тоже нежелательна.
проблематично.
Ну а главная проблема в том, что на рынке труда становится все меньше людей, которые хорошо знают старые языки и могут эффективно поддерживать систему.
Рано или поздно приходит понимание, что необходимо переходить на современные платформы, и здесь возникает новая проблема – стоимость, как по деньгам, так и по времени.
Для тех, кого интересует данная проблема, ниже под катом более подробное описание того, почему переписывать системы дорого и что делать со старыми системами.
Цена
На первый взгляд кажется, что переписать готовую систему не проблема, ведь весь код есть.«Давайте быстренько «перепишем на Java» — и все!» Впервые такое заявление я услышал в 2001 году.
Речь шла о «маленькой» системе, которую команда из 10 ОЧЕНЬ продвинутых программистов разрабатывала за 13 лет. Объем кода, по приблизительным оценкам, составил более 10 миллионов строк.
А теперь немного математики: в среднем хороший программист может за день вручную переписать 30 (да-да, тридцать) строк кода.
И не просто программист. Здесь вам понадобится:
- Хорошее знание платформы, на которую портируется код;
- Как минимум хорошее знание платформы, с которой портируется код.
В остальном приведенная выше цифра 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 1400 (округлено) .
ЭМ-м-м.
Получается 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 (двадцать миллионов) опять же зарплата + налоги.
Результат вычислений можно выразить просто: действительно большую систему переписать вручную можно, но стоимость и сроки абсолютно нереальны.
Временные рамки, по идее, можно сократить, но нельзя забывать, что чем больше команда разработчиков, работающих над одним и тем же кодом (а старые системы часто имеют очень плохую модульность), тем ниже эффективность каждого отдельного разработчика.
На согласования тратится много времени.
И здесь рост производительности команды в зависимости от количества разработчиков не линейный, а логарифмический.
Что делать?
Что делать? Конечно, есть несколько выходов из ситуации.Для некоторых компаний подходит переход на готовые решения, благо их достаточно – здесь и Axapta, и 1С:Предприятие, и Galaxy, и многое другое.
Некоторым достаточно, например, правильной настройки SharePoint + Office 365. А как быть тем, у кого есть системы, выходящие за рамки стандарта? Ниже приведены несколько возможных решений.
Глубокая кастомизация готовых решений с переносом участков кода
В принципе, сейчас на рынке достаточно компаний-интеграторов, которые могут настроить готовую коробочную систему под нужды клиента.Оставим в стороне тот факт, что некоторые пакетные решения очень плохо справляются с большими объемами данных/количеством транзакций.
Учтем только тот факт, что если старая система большая, в ней много нестандартных "фич", либо людей, которые с ней знакомы и могут четко выделить небольшие участки кода, отвечающие за эти самые фичи, нет. - мы практически свелись к переписыванию корпуса вручную.
Точно так же нужно искать код, переносить его и интегрировать с готовой системой.
Настройка готовых решений по техническому заданию
Еще есть ряд предприятий, которые смогут составить грамотное техническое задание на дополнительные функции и выбрать подходящую платформу.Тогда они смогут сравнительно небольшими усилиями и своими силами (или интегратора/аутсорсера) доработать подходящую «коробочную» платформу под свои нужды, но количество таких компаний невелико — не везде есть по-настоящему компетентные постановщики задач и составители технических спецификаций.
А что насчет остального?
Рассмотрим самый распространенный вариант:- На предприятии имеется крупная система, которая работает на предприятии уже много лет, исходный код системы доступен;
- Никого из первоначальных разработчиков системы не осталось, либо оставшиеся саботируют процесс переноса системы, так как они уже не будут «незаменимыми»;
- Система не «легко и быстро» выполняет функции готовых коробочных решений;
- В системе имеется огромное количество данных, которые необходимо хранить;
- В системе имеется большое количество пользователей, привыкших к старому внешнему виду системы и расположению элементов графического интерфейса;
- В компании нет толпы мега-супер-разработчиков, которые могли бы написать 1000 кода, хотя бы 100 строк в день в процессе переноса кода с платформы на платформу за еду за разумные деньги, смешные для любого программиста.
Таких предприятий и систем много, но решений вроде бы нет - все вышесказанное не относится:
- Копирование вручную требует много времени и очень дорого;
- Готовое решение — быстрое, доступное, но можно потерять старые данные (или некоторые) и часть функционала, интерфейс, скорее всего, будет незнаком пользователям;
- Адаптированное готовое решение - либо получаем все проблемы первого варианта при адаптации/настройке/дополнении, либо скатываемся ко второму решению.
И да, вопреки мнению большинства, это решение вполне работоспособно и приносит ОГРОМНУЮ выгоду предприятию, которое на него пойдет.
Автоматическая миграция
Автоматическая миграция — достаточно сложная с точки зрения первоначальной разработки, но очень быстрая и качественная услуга для конечного пользователя.Давайте посмотрим поближе.
Перенос данных
Здесь все более-менее просто и не вызывает особых нареканий — почти всегда данные, предназначенные для старых систем, можно перенести на современные платформы (Oracle, MS SQL, в экзотических случаях — в базу данных Post-SQL).Для многих комбинаций есть готовые решения (например, MS SQL Data Transformation Wizard, Borland DataPump и т.п.
) в случаях, когда решение сложнее обычного.
Вы можете адаптировать то, что у вас есть, или написать небольшое приложение-насос, которое будет передавать данные.
Думаю, нет необходимости слишком подробно останавливаться на этом вопросе.
Миграция кода
Именно этот момент вызывает основной скептицизм в ИТ-сообществе.Правда, чаще всего возражения принимают форму:
- «Если бы это было возможно, я бы знал об этом и вообще смог бы сделать это сам» — здесь можно вспомнить только историю о Колумбе и яйце;
- «Да я это быстро сам перепишу от руки» — перечитываем абзац о переписывании и особенно стоимости и сроках выполнения работ.
Итак, как это работает? Все очень просто — исходный текст на старой платформе переводится в текст на новой платформе.
В некоторых случаях добавляется библиотека миграции.
Выглядит просто? Да.
Тогда давайте посмотрим глубже.
На самом деле разработать такой транслятор зачастую сложнее, чем разработать классический транслятор с PL в машинный код. Первая часть работы — парсинг и анализ кода.
По сути, это то же самое, что и при обычном эфире, но дальше все усложняется.
Языки программирования разные, конструкции одного не всегда легко вписываются в конструкции другого, и эту проблему тоже сложно решить.
Первые конвертеры просто модифицировали исходный код через RegExps, что оставляло много места для ручной работы.
Текущее поколение конвертеров выполняет полный перевод исходного кода в новый исходный код. Поскольку данная публикация не содержит прямой рекламной информации, никаких ссылок или чего-либо еще не будет. Это пища для размышления для тех, перед кем стоит задача перевести большую систему на современную платформу.
УПД
В комментариях резонно указали на ошибки в расчетах - теперь они отмечены как неправильные значения зачеркнуты а за ними курсивом новые правда .Большое спасибо, господа erp_шник И как есть — благодаря их внимательности были внесены исправления.
В общем, порядок чисел по-прежнему не меняет вывод. (во второй поправке будет обоснование).
УПД2
В ответ на многочисленные комментарии (особая благодарность господам владшариков , логово , берез за конструктивные вопросы и разъяснения), на этой неделе будет написана вторая статья — она будет содержать примеры конвертированного кода.
UPD3
Здесь вторая статья , с примерами преобразования кода и графического интерфейса Теги: #устаревшие приложения #миграция #разработка сайтов #дизайн и рефакторинг-
Разминочный Этап Rcc 2014.
19 Oct, 24 -
Стали Известны Цены На Htc Dream
19 Oct, 24 -
Как Работает Настоящее Юзабилити
19 Oct, 24 -
Проект 10^100
19 Oct, 24
