Предыстория
Ни для кого из опытных 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 (да, да — тридцать) строк кода. Причём далеко не любой программист. Здесь необходимо:
- Хорошее знание платформы, на которую переносится код;
- Как минимум, неплохое знание платформы, с которой переносится код.
В принципе, я встречал людей, которые могли работать производительнее при условии 16 часового рабочего дня, великолепного знания обеих платформ и личной заинтересованности в проекте (человек был одновременно идеологом старой системы, владельцем предприятия и идеологом новой системы — такой «сплав» я встречал только один раз в жизни).
Для остальных вышеприведённая цифра в 30 строк кода / 8 часов — среднее значение.
Итак, на примере системы из 2001 года посчитаем: 10 000 000 / 30 * 8 = 2 666 666, 6(6) человеко-часов, что примерно равно
Предположим, у предприятия не такая громадная система и в ней содержится «всего лишь» 1 миллион строк кода. Кроме того, предположим, что предприятие найдет 5-6 действительно супер программистов, которые будут переписывать проект со средней скоростью 300 строк кода в день (цифра абсолютно нереальная — 40 строк в час писать возможно только в случае, когда пишешь алгоритм «из головы», который продумывал долгое время, но тогда накладывается это самое время на обдумывание, да и алгоритмов таких не слишком много, а нам важна средняя скорость). Тогда затраты на проект упадут примерно в 30-40 раз (таким суперам и платить надо больше), но все равно останется 100 человеко-лет, которые коллективом из 5 человек растянутся на
Итог расчётов можно выразить просто: действительно большую систему переписать руками, конечно, можно, но стоимость и сроки — абсолютно нереальные.
Сроки, в теории, можно сократить, но нужно не забывать, что чем больше коллектив разработчиков, работающих над одним и тем же кодом (а у старых систем зачастую очень плохо с модульностью), тем ниже эффективность каждого конкретного разработчика. Теряется много времени на согласование. И здесь рост производительности коллектива от количества разработчиков не линейный, а скорее логарифмический.
Что же делать?
Что же делать? Выходов из ситуации, конечно, есть несколько.
Для некоторых компаний подойдёт переход на готовые решения, благо их хватает — тут и Аксапта, и 1С: Предприятие, и Галактика, и многое другое.
Кому-то вообще хватит правильной настройки SharePoint + Office 365, например.
Но что же делать тем, у кого системы выходят за рамки стандартных?
Ниже будет приведено несколько вариантов решений.
Глубокая настройка готовых решений с переносом участков кода
В принципе, на рынке сейчас хватает компаний-интеграторов, которые могу выполнить настройку готовой коробочной системы под нужды клиента. Оставим за кадром то, что некоторые коробочные решения очень плохо живут с большим объемом данных/количеством транзакций. Рассмотрим только тот факт, что если старая система имеет большой объем, в нем много нестандартных «фишек», или же людей, которые в ней ориентируются и смогут чётко выделить небольшие участки кода, которые отвечают за эти самые фичи нет — мы скатываемся почти к случаю переписывания «ручками». Точно так же надо искать код, переносить его и интегрировать с готовой системой.
Настройка готовых решений по ТЗ
Еще есть некоторое количество предприятий, которые смогут составить грамотное ТЗ по дополнительным функциям, выбрать подходящую платформу. Тогда они смогут относительно малой кровью и своими (или интеграторскими/аутсорсерскими) силами доработать подходящую «коробочную» платформу под свои нужды, но количество таких компаний мало — не везде есть действительно грамотные постановщики задач и ТЗписатели.
А остальные?
Рассмотрим самый частый вариант:
- У предприятия есть большая система, которая работает в предприятии много лет, для системы имеются исходники;
- Из изначальных разработчиков системы никого не осталось, либо оставшиеся саботируют процесс переноса системы, так как перестанут быть «незаменимыми»;
- Система не ложится «легко и быстро» на функции готовых коробочных решений;
- В системе имеется огромный набор данных, которые необходимо сохранить;
- У системы есть большое количество пользователей, которые привыкли к старому внешнему виду системы и расположению элементов Gui;
- В компании нет толпы мега-супер-разработчиков, которые могли бы писать код по
1000хотя бы 100 строк в сутки в процессе переноса кода с платформы на платформуза едузаразумныесмешные для лубого программиста деньги.
Выглядит очень грустно. Таких предприятий и систем много, а решений вроде бы нет- всё вышеперечисленное не подходит:
- Переписать руками — долго и очень дорого;
- Готовое решение — быстро, приемлемо по цене, но можно потерять старые данные (или часть) и часть функционала, интерфейс, скорее всего, будет непривычен пользователям;
- Адаптированное готовое решение — либо получаем все проблемы первого варианта при адаптации/настройке/дописывании, либо же скатываемся ко второму решению.
На самом деле, как я с удивлением узнал в 2009 году, решение есть, оно придумано в далеком (сейчас) 2000 году и заключается оно в автоматической миграции данных и исходных текстов приложения. И да, вопреки мнению большинства, это решение вполне рабочее и несёт ОГРОМНУЮ выгоду предприятию, которое на него идёт.
Автоматическая миграция
Автоматическая миграция — это достаточно сложная в плане изначальной разработки, но очень быстрая и качественная для конечного потребителя услуга.
Рассмотрим детальнее.
Миграция данных
Здесь всё более-менее прости и больших нареканий не вызывает — почти всегда данные, предназначенные для старых систем, можно перенести на современные платформы (Oracle, MS SQL, в экзотических случаях — на post-SQL БД).
Для многих связок существуют готовые решения (например, MS SQL Data Transformation Wizard, Borland DataPump и т.д.) в случае, когда решение сложнее обычного. Можно адаптировать то, что есть, либо написать небольшое pump-приложение, которое перенесет данные. Думаю, что особо на этом пункте останавливаться не нужно.
Миграция кода
Вот этот пункт как раз и вызывает основной скепсис в IT-сообществе. Правда чаще всего возражения носят вид:
- «Если бы это было возможным, я бы об этом знал и вообще сам бы умел» — здесь можно только вспомнить байку про Колумба и яйцо;
- «Да я быстрее сам перепишу это руками» — перечитываем пункт про переписывание и особенно — стоимость и сроки работ.
На самом, деле почти все возражения сводятся к вышеперечисленным.
Итак, как это работает?
Все очень просто — исходный текст, на старой платформе, транслируется в текст на новой платформе. В некоторых случаях дописывается миграционная библиотека.
Выглядит просто? Да.
Тогда заглянем поглубже.
На самом деле, разработка такого транслятора, зачастую, сложнее, чем разработка классического транслятора из ЯП в машинный код. Первая часть работы — разбор и анализ кода. По сути, ровно такой же, как и при обычной трансляции, а вот дальше все сложнее. Языки программирования — они разные, конструкции одного не всегда легко ложатся на конструкции другого и эта задача тоже решается сложно.
Первые конверторы просто модифицировали исходный код через RegExp'ы, что оставляло очень большой простор для ручной работы. Нынешнее поколение конвертеров выполняет полноценную трансляцию исходного кода в новый исходный код.
Так как данная публикация не несет прямой рекламной информации — ссылок и прочего не будет. Это именно информация для размышления для тех, у кого стоит задача переноса большой системы на современную платформу.
UPD
В комментариях резонно указали на ошибки в вычислениях — они помечены теперь как
UPD2
В ответ на множество комментариев (особенное спасибо господам vladsharikov, lair, berez за конструктивные вопросы и уточнения), на этой неделе будет написана вторая статья — там будут приведены примеры сконвертированного кода.
UPD3
Вот вторая статья, с примерами конвертации кода и GUI
aalebedev
30 строк кода в день это бред.
Самому приходилось:
— за неделю переписывать сайт на PHP на ASP.NET, было около 1700 строк (да пхп-стайл получился, но такой заказ был)
— за ночь, переписывать 200-300 строк когда на Dephi на C# (ночь перед зачетом)
Конечно, на выходе был не супер крутой код, но получали, то что требовалось.
Да нужно хорошее знание 2-х языков, и это эквивалентно, переводу с английского на французский.
А теперь интересно послушать кто и за сколько переписал что-то? А то без примеров взято 30 строк в день.
vladsharikov
Возможно, автор это не озвучил, но код должен быть таким, чтобы его могла поддерживать группа разработчиков, а не 1 разработчик. Так же важно, чтобы в этом коде могли разобраться будущие разработчики. Речь о модульность и тд (простейшее). Подходы будут другими, архитектура другая, код будет написать сложнее.
Если писать код, чтобы лишь бы заработало, так, конечно, будет легче. Поддерживать позже такой код будет сложнее, особенно людям, которые его впервые увидят.
lair
Автор очень много чего не озвучил. Например, есть ли в исходном продукте тесты, и если да, то какие — а от этого, заметим, зависит очень много.
HackerDelphi Автор
Начну как еврей с вопроса-на-вопрос: «а много Вы видели систем, разработанных лет этак 20 назад на FoxPro / Delphi, в которых бы реально были тесты?!»
А если серьёзно — речь идёт о монстрах, миллионы строк кода, написанных по принципу «ген. директор в 17:45 захотел новый отчёт — к 10:00 должно работать» — обычно тут не до тестов.
Кроме того, в те годы особо и не было тестовых движков, да и про Test Driven Development и Unit Testing никто особо и не слышал…
lair
Вы так говорите, будто мигрируемые системы ограничиваются написанными 20 лет назад. Но даже если предположить, что мы мигрируем такую систему, нам все равно надо явно ответить на два вопроса: тесты есть? а нужны?
Потому что если ответы «нет»-«нет», то не понятно, как верифицировать результат миграции. А если ответы «нет»-«да», то основные усилия уйдут не на миграцию, а на написание тестов.
HackerDelphi Автор
Ответ чуть другой.
Тестов, обычно, нет.
Сдается по простому алгоритму: а процессе миграции некоторое количество особенно продвинутых пользователей описывает набор use-cases, которые постоянно используются в системе (на систему в 1 000 000 строк на FoxPro их оказалось около 70).
После миграции проверяется, что все use-cases отрабатывают на одинаковых данных одинаково.
К сожалению, на предприятиях действительно много систем, которые не имеют документации, автор которых давно ушёл (а порой — и умер), тестов нет, есть только огромный объем исходных текстов и огромные же объемы действительно ценных данных.
lair
Прохождение сценариев использование делается автоматически или вручную? Если автоматически, то на какой доле данных?
(в случае 70 UC — не быстрее ли с нуля написать?)
HackerDelphi Автор
прохождение сценариев делается, обычно, вручную.
А с нуля написать не так просто — из реального опыта: 60 сценариев суммарно занимали около 50 часов на прохождение. там весьма сложные алгоритмы, описаний которых нет, а суммарно в сценариях, по примерным прикидкам, использовалось порядка 70% когда приложения. Часть сценариев в процессе прохождения требовали больше 100 пользовательских действий типа «выбрать строку, нажать кнопку, выбрать элемент комбо бокса, и т.д.» и требовали работы в более, чем 10 формах. Это был ад — у нас специально выделеный человек все время проекта (полгода) спера собирал use cases, а потом их тестировал.
К тому же, иногда бывает еще один фактор сложности — человее, который единственный знает старую систему может просто отказаться помогать ее переписывать, так как перестанет быть незаменимым.
Про охват данных — мы тестировали тот проект на копии боевой базы. Объем бэкапа — 500 Гб, развернутая база — около 750 Гб.
lair
… и все равно вы делали это вручную.
Какой реальный процент данных вы проверяли за эти 50 часов?
HackerDelphi Автор
Да, реальные use cases проходились вручную — затраты на написание инструмента или покупку готового + его настройку были бы выше, чем зарплата того человека, который их выполнял.
Про данные — судя по изменениям, use cases охватывали около 85% данных на чтение и 100% данных за месяц/квартал (в зависимости от конкретного use case) на запись.
В целом, на запись охватывалось около 25-30% данных всей БД (база за два года — заказчики «устаревшие» данные убирали в архив средствами MS SQL).
lair
Т.е. вы хотите сказать, что ручное прохождение 60 UC, занимающее 50 часов, затрагивало 25-30% от 750Гб?
HackerDelphi Автор
Я вот только не могу понять — это много или мало?
основные данные на запись — это всяческие промежуточные данные для отчётов, сводные прайсы, сводные отчёты и подобное.
Больше половины объёма БД занимают справочники, проводки и приходно/расходные операции. Именно этим обусловлен высокий процент покрытия БД на чтение и относительно невысокий на запись.
Результаты примерные — так докладывал наш тестер (для сравнения использовался, если ничего не путаю, dbCompare). Для мониторинга чтения — что-то настраивали в SQL Profiler.
lair
Я хочу сказать, что я не очень верю. Слишком большой объем.
HackerDelphi Автор
Это FoxPro и люди, которые на нем писали либо со времен DOS'а, либо со времён Windows 95.
Там очень часто для «быстрой» выдачи отчётов используют генерацию гигантских таблиц со сводными данными.
Единственное светлое место в том приложении заключалось в том, что достаточно большой пласт таких «сводных» обновлений они вынесли в SP, а на той стороне был достаточно шустрый сервер, который всё съедал быстро.
P.S. Из смешного
, если бы не хотелось плакать. Когда мы первый раз подняли эту базу у себя (на виртуальной машине) — нам «немного» поплохело при первом же запуске и попытке работать. В результате собрали для первичного тестирования машинку с 32 Гб памяти и зеркалом на SATA-3 — тогда хоть немного быстрее зашуршало чтение данных, ну и гигабитная сеть здесь решала, как выяснилось — перекачка данных в 500-600 МБ для обработки на клиент — вполне себе регулярная задача была (я в одном из комментариев уже описывал).HackerDelphi Автор
Вы абсолютно правы!
Цель миграции не только в том, чтобы перенести код на другую платформу (хотя и это — тоже цель).
Цель в том, чтобы:
Так что «писать абы как» тут не подойдёт.
P.S. Ну и как, опять-таки, я объяснял в другом комментарии — речь идет о миллионах (минимум — сотни тысяч, где первая цифра больше пятёрки) строк — там невозможно сохранить высокую скорость написания кода. Даже если писать код по ТЗ с нуля.
lair
Как вы можете утверждать, что все алгоритмы сохранены точно, без подробного тестирования?
HackerDelphi Автор
Для такой уверенности у нас было 3 основания:
1. конвертация делалась 1-в-1, порядлк выполнения операций было видно глазами, более того, в исходниках на новой платформе мы в комментариях оставляли копию изначального кода старого приложения — можно было сравнить визуально.
2. для различных частных мест (сложная выборка из БД, сложный расчет и т.п.) мы писали тесты, которые создавали клон данных, прогоняли тест и далше сравнивали результирующие данные с эталоном.
3. все очень сложные алгоритмы прохдили через «пошаговое» тестирование, то есть: выполняем шаг в старой системе — берем данные, выполняем шаг в новой системе — сравниваем. особо «интересные» места вытаскивались в тесты прошлого раздела. Такое пошаговое тестирование — это, конечно, долго, но пройдя сложные use case таким макаром по паре/тройке раз мы получади очень качественный охват кода тестами.
P.S. в конце проекта у нас был второй тестовый проект (не просто unit test'ы, которые можно регулярно запускать, а длинные тесты, суммарно часа на полтора-два), так в нём было порядка 350 тестов. Всё это давало гарантию одинаковости алгоритмов.
lair
«Система писалась по требованиям 1-в-1, порядок выполнения операций было видно глазами, более того, в исходниках мы в комментариях оставляли копию требований — можно было сравнить визуально.»
HackerDelphi Автор
Если переписывать что-то с небольшим общим объемом — да, можно лопатить и 1000+ строк в сутки.
Но здесь мы вернёмся к описанию задачи:
30 строк в день — это средняя скорость. сюда включается и тестирование, и отлов багов, и корректировка отличий в работе плавающих вычислений (например иногда в Delphi и C# немного по-разному происходит окургление), иногда — надо переделывать работу с данными.
Про данные приведу отдельный пример:
в FoxPro при обработке больших (действительно больших) объемов данных принято делать так:
без реализации РЕАЛЬНО быстрой работы с каким-либо локальным хранилищем таблиц, поспорить в скорости выполнения данной задачи с FoxPro почти не реально — надо думать над переписыванием алгоритма, либо искать способ быстрой работы с локальными данными.
За скорость мы платим отсутствием транзакций, но FoxPo' шникам не привыкать
vlivyur
С FoxPro на C# тоже с такой же скоростью смигрируете? Желательно чтоб и формы продолжали так же работать (это, наверно, самое простое будет).
HackerDelphi Автор
Как раз для FoxPro у нас, пожалуй, самый продвиеутый инструмент. Формы 1-в-1, алгоритмы — тоже.
Самое забавное — даже раскраски в ячейках таблиц пашут адекватно.
P.S. забыл написать. FoxPro мы перетаскиваем в C# + WPF + MVVM. Получается интересно. Ну и скинов для контролов мы в какой-то момент делали 3 или 4, с подменой «на лету», а также — поддержку Zoom'а (чем и хорош WPF)
berez
А можно какой-нибудь примерчик такой миграции? Чтобы можно было, так сказать, в более практичесом ключе понять, как это должно работать.
Мне вот приходилось переносить небольшие (несколько тысяч строк кода) древние поделия на другую платформу — так там такое встречалось, что до сих пор волосья дыбом по всему организму. Правда, там и платформы были совсем разные (С++ и XML/XPath/Java), так что автоматическая трансляция, как мне кажется, вообще невозможна.
HackerDelphi Автор
Какой именно пример?
Если нужен пример куска кода — могу кинуть, если скриншоты GUI — это чуть подольше — пара дней нужна (надо добраться до тех мест, где это всё есть).
На самом деле, я могу «родить» пример переноса кода прямо сейчас — тут же подход такой — при разработке конвертера мы определяем, как именно какие конструкции в какие будут переводиться, дополнительно решаем, какие типы из старой платформы будут подменяться на типы в новой (даже для custom типов, зачастую) Соответственно строится и mapping методов/полей/свойств.
С одной стороны — всё просто, с другой — сложно.
P.S. Утром постараюсь выложить примеры кода прямо в статью через UPD.
P.P.S. Про сложность переноса — согласен, порой получается очень, так скажем,
berez
Ну, вам виднее, какой из примеров попоказательнее выбрать. Я как-то затрудняюсь ответить.
Поясню суть моих затруднений: дело в том, что у вас в статье, похоже, речь идет в основном о миграции комплекса, написанного на одном языке программирования (FoxPro?). Мне же обычно встречались «комплексы», слепленные из сотен разнообразных утилит, скриптов и прокладок. Языков программирования там использовалось минимум десяток всяких разных, причем для многих утилит за давностью лет не сохранилось никаких исходников (или сохранились, но далеко не самой последней версии, что еще хуже). Немалая часть всей системы — это сложная конструкция из подпорок и костылей, компенсирующая одни глюки за счет внесения других, чуть менее фатальных. Поэтому для меня автоматическая конвертация кода всей системы с сохранением его функционала — это что-то фантастическое.
Хорошо бы увидеть примеры кода (небольшие) — оригинал и результат конвертирования, с пояснениями, где там были самые грабельные места. Еще интересно, как вам удалось сконвертировать фокспрошные формы и отчеты в сишарп. Только учтите, что я фокспро последний раз тыкал палочкой лет десять назад (да и то еще версию под ДОС), поэтому никаких тонкостей языка уже не помню (думаю, как и многие другие хабровчане).
erp_shnik
Очень интересная математика. Сначала вы пишете, что 10 разработчиков за 13 лет написали это приложение. Затем в обратную сторону у вас получается 11 000 человеко лет…
HackerDelphi Автор
Как я уже ответил ниже — ошибка в вычислениях где-то произошла — на самом деле 1 300 человеко лет.
Сейчас исправлю в статье.
asis
Извините, но вы в расчетах, чисто математически ошиблись примерно на порядок для случая тридцати строк.
Ну сами подумайте, написание системы потребовало 130 человеко-лет, при средней скорости 200-300 строк кода в день на написание, а переделка, даже при скорости в десять раз меньше — уже 11 тысяч человеко-лет.
HackerDelphi Автор
Упс, спасибо за комментарий — пересчитал — где-то ошибся при подсчётах.
там 1 300, однако… Сейчас поправлю всю арифметику, но цифры всё равно очень большие выходят.
На самом деле — те программисты писали больше — это были реально ОЧЕНЬ хорошие работники и пахали они «за совесть» — порядка 12/14 часов в сутки стабильно, суммарно, по прикидкам, они написали 15-16 млн. строк кода, просто часть кода писалась «поверх» другого — исправления в связи с изменениями законодательства и требований заказчика — всё это время система активно эксплуатировалась.
Еще раз спасибо за исправление — сейчас допишу в статье.
vedenin1980
Ну, так не бывает.
1) Переписывать имея уже готовую реализацию всегда проще, если осталась старая документация на разработку, очень много времени уходит на проектирование и отброс неверных решений,
2) Новые языки программирования, новые IDE содержат кучу штук резко ускоряющих разработку,
3) Совершенно неправильно считать что строчки будут переписываться одна в одну, на самом деле при правильном дизайне, архитектуре и прямых руках программистов тысячи строчек старого проекта могут превратиться в десяток нового (для того и существуют плюшки нового языка),
4) Скорость может быть как 10 строчка в неделю, так и 30000 строк за 10 минут, сгенирить тысячу классов entity по текущей структуре базы можно чисто автоматически, да и всякие DTO объекты IDE генерит очень быстро, так что 300 строк кода в день это что-то вроде средней температуре по больнице,
5) Совершенно не учитывается сколько потом потребуется времени на рефакторинг и сопровождение мигрированного кода, вполне может быть для серьезного расширения придется сначала сделать рефакторинг с примерно теми же трудозатратами что переписать с нуля,
vedenin1980
Вспоминаю свою первую систему на Visual fox-pro, да вроде бы миллионы строк кода, но по факту мигрировать её гиблое дело, сплошной спагети стаил, не ооп программирование и велосипеды, велосипеды. На самом деле, проще взять юз.кейсы, снимки экранов и отчетов и за несколько месяцев сделать нормальную систему с нормальным дизайном и архитектурой, взяв за ТЗ функционал старой системы. Автоматических перенос магическим образом исправит дизайн и заплатки старого кода, поэтому получится тот же FoxPro со всеми его косяками, но как бы формально C#/Java, но со всеми проблемами сопровождения и расширения FoxPro.
На самом деле в таких системах из милионов строк кода почти всегда реально ценно меньше 1%, так как там огромное кол-во кода написано для работы с xml/json, экспорта в Excel, работы с архивами, работы с базами данными и все это решает буквально парой строчек кода на java/C#: перегнать json в объект и обратно => 1 строчка при подключении Gson, обеспечить работу с любыми архивами => 1 строчка при подключении апач компрес и т.д.
Хранимые процедуры на уровне базы данных делают все это без особого труда, да и все возможных nosql хранилищ с легким api тоже полно.
HackerDelphi Автор
Вопрос в том, что программисты FoxPro редко даже на их «комплексную БД» переходят, а уж про nosql и речи нет.
Про конкретно тот проект, который мы переводили (да и тот, что я приводил в качестве примера в начале статьи) это совсем неверно. В проекте 2001 года действительно нужного кода было больше 60% — он эксплуатировался до тех пор, пока предприятие, для которого велась разработка, не решило себе купить SAP R3… Купили, потратили $20 млн ТОЛЬКО на настройку… а оно не заработало. А вот новый (сменившийся за 4 месяца до решения о переходе на R3) начальник отдела автоматизации купил себе квартиру в центре Москвы и, вроде как еще какую-то недвижимость в Европе. Неплохо для новоиспечённого начальника отдела автоматизации компании, расположенной за 6 000 км от Москвы, да?
Про экспорт в Excel — Visual FoxPro сам умеет таблицы в Excel «выкидывать»… или отчёты — точно не помню, помню только, что умеет и мы это в миграционной библиотеке реализовали.
Проект на Visual, опять-таки был, видимо, изначально очень неплохо спроектирован — там используется ровно одно место для общения с MS SQL (функция, которая, с помощью макросов, исполняет SQL запрос и возвращает результат, а в случае ошибки — реализует отображение нормального окошка с текстом ошибки). Так что спагетти кода там было не так много.
vedenin1980
Ну может в вашем случае это и так, но по факту обычно смена кузова у гробатого запорожца на мерседес без смены внутренностей (перенос кода FoxPro, которые вообще не знает о ОПП если не брать в расчет компоненты, на С#/Java) ни к чем хорошему не приведет.
Да, у вас формально стал C#, но вы уверены что такой псевдоООП, псевдо C# проект можно будет адекватно развивать и сопровождать? Он уже запущен и нормально развивается или пока в стадии переноса? Просто я бы такое решения не взялся развивать и сопровождать, это по сути один сплошной технический долг на тысячу человеколет, который будущая команда будет разгребать.
HackerDelphi Автор
Конечно, FoxPro for DOS про ООП ничего не знал, а вот в Visual FoxPro ООП есть, притом вполне себе используется в действительно серьезных проектах.
Насчет вопроса запуска/сопровождения — да, запущен, вполне внятно сопровождается.
На текущий момент заказчик думает о привлечении нас на второй этап работ — глубокий рефакторинг приложения, избавление от макросов, замена алгоритмов «притащи мне 600 Мб данных на клиент — я буду вычислять группировки локально» и тому подобного.
При использовании C# подобные вещи гораздо проще отследить.
Более того, наша библиотека в отладочном режиме собирает статистику по использованию локальных таблиц, их очистке/переписке и многому другому, что позволяет легко вычислить где, кто и зачем их создает и унести проблемный код либо в хранимую процедуру, либо переписать запрос на группирующий сразу.
Клиенты получили очень много плюшек и довольны.
vlivyur
Для таблиц copy to type xls. С отчётами вроде вообще ничего сделать нельзя.
HackerDelphi Автор
Ага, спасибо!