Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
30 строк кода в день это бред.
Самому приходилось:
— за неделю переписывать сайт на PHP на ASP.NET, было около 1700 строк (да пхп-стайл получился, но такой заказ был)
— за ночь, переписывать 200-300 строк когда на Dephi на C# (ночь перед зачетом)
Конечно, на выходе был не супер крутой код, но получали, то что требовалось.
Да нужно хорошее знание 2-х языков, и это эквивалентно, переводу с английского на французский.
А теперь интересно послушать кто и за сколько переписал что-то? А то без примеров взято 30 строк в день.
Самому приходилось:
— за неделю переписывать сайт на PHP на ASP.NET, было около 1700 строк (да пхп-стайл получился, но такой заказ был)
— за ночь, переписывать 200-300 строк когда на Dephi на C# (ночь перед зачетом)
Конечно, на выходе был не супер крутой код, но получали, то что требовалось.
Да нужно хорошее знание 2-х языков, и это эквивалентно, переводу с английского на французский.
А теперь интересно послушать кто и за сколько переписал что-то? А то без примеров взято 30 строк в день.
Возможно, автор это не озвучил, но код должен быть таким, чтобы его могла поддерживать группа разработчиков, а не 1 разработчик. Так же важно, чтобы в этом коде могли разобраться будущие разработчики. Речь о модульность и тд (простейшее). Подходы будут другими, архитектура другая, код будет написать сложнее.
Если писать код, чтобы лишь бы заработало, так, конечно, будет легче. Поддерживать позже такой код будет сложнее, особенно людям, которые его впервые увидят.
Если писать код, чтобы лишь бы заработало, так, конечно, будет легче. Поддерживать позже такой код будет сложнее, особенно людям, которые его впервые увидят.
Автор очень много чего не озвучил. Например, есть ли в исходном продукте тесты, и если да, то какие — а от этого, заметим, зависит очень много.
Начну как еврей с вопроса-на-вопрос: «а много Вы видели систем, разработанных лет этак 20 назад на FoxPro / Delphi, в которых бы реально были тесты?!»
А если серьёзно — речь идёт о монстрах, миллионы строк кода, написанных по принципу «ген. директор в 17:45 захотел новый отчёт — к 10:00 должно работать» — обычно тут не до тестов.
Кроме того, в те годы особо и не было тестовых движков, да и про Test Driven Development и Unit Testing никто особо и не слышал…
А если серьёзно — речь идёт о монстрах, миллионы строк кода, написанных по принципу «ген. директор в 17:45 захотел новый отчёт — к 10:00 должно работать» — обычно тут не до тестов.
Кроме того, в те годы особо и не было тестовых движков, да и про Test Driven Development и Unit Testing никто особо и не слышал…
Вы так говорите, будто мигрируемые системы ограничиваются написанными 20 лет назад. Но даже если предположить, что мы мигрируем такую систему, нам все равно надо явно ответить на два вопроса: тесты есть? а нужны?
Потому что если ответы «нет»-«нет», то не понятно, как верифицировать результат миграции. А если ответы «нет»-«да», то основные усилия уйдут не на миграцию, а на написание тестов.
Потому что если ответы «нет»-«нет», то не понятно, как верифицировать результат миграции. А если ответы «нет»-«да», то основные усилия уйдут не на миграцию, а на написание тестов.
Ответ чуть другой.
Тестов, обычно, нет.
Сдается по простому алгоритму: а процессе миграции некоторое количество особенно продвинутых пользователей описывает набор use-cases, которые постоянно используются в системе (на систему в 1 000 000 строк на FoxPro их оказалось около 70).
После миграции проверяется, что все use-cases отрабатывают на одинаковых данных одинаково.
К сожалению, на предприятиях действительно много систем, которые не имеют документации, автор которых давно ушёл (а порой — и умер), тестов нет, есть только огромный объем исходных текстов и огромные же объемы действительно ценных данных.
Тестов, обычно, нет.
Сдается по простому алгоритму: а процессе миграции некоторое количество особенно продвинутых пользователей описывает набор use-cases, которые постоянно используются в системе (на систему в 1 000 000 строк на FoxPro их оказалось около 70).
После миграции проверяется, что все use-cases отрабатывают на одинаковых данных одинаково.
К сожалению, на предприятиях действительно много систем, которые не имеют документации, автор которых давно ушёл (а порой — и умер), тестов нет, есть только огромный объем исходных текстов и огромные же объемы действительно ценных данных.
Прохождение сценариев использование делается автоматически или вручную? Если автоматически, то на какой доле данных?
(в случае 70 UC — не быстрее ли с нуля написать?)
(в случае 70 UC — не быстрее ли с нуля написать?)
прохождение сценариев делается, обычно, вручную.
А с нуля написать не так просто — из реального опыта: 60 сценариев суммарно занимали около 50 часов на прохождение. там весьма сложные алгоритмы, описаний которых нет, а суммарно в сценариях, по примерным прикидкам, использовалось порядка 70% когда приложения. Часть сценариев в процессе прохождения требовали больше 100 пользовательских действий типа «выбрать строку, нажать кнопку, выбрать элемент комбо бокса, и т.д.» и требовали работы в более, чем 10 формах. Это был ад — у нас специально выделеный человек все время проекта (полгода) спера собирал use cases, а потом их тестировал.
К тому же, иногда бывает еще один фактор сложности — человее, который единственный знает старую систему может просто отказаться помогать ее переписывать, так как перестанет быть незаменимым.
Про охват данных — мы тестировали тот проект на копии боевой базы. Объем бэкапа — 500 Гб, развернутая база — около 750 Гб.
А с нуля написать не так просто — из реального опыта: 60 сценариев суммарно занимали около 50 часов на прохождение. там весьма сложные алгоритмы, описаний которых нет, а суммарно в сценариях, по примерным прикидкам, использовалось порядка 70% когда приложения. Часть сценариев в процессе прохождения требовали больше 100 пользовательских действий типа «выбрать строку, нажать кнопку, выбрать элемент комбо бокса, и т.д.» и требовали работы в более, чем 10 формах. Это был ад — у нас специально выделеный человек все время проекта (полгода) спера собирал use cases, а потом их тестировал.
К тому же, иногда бывает еще один фактор сложности — человее, который единственный знает старую систему может просто отказаться помогать ее переписывать, так как перестанет быть незаменимым.
Про охват данных — мы тестировали тот проект на копии боевой базы. Объем бэкапа — 500 Гб, развернутая база — около 750 Гб.
60 сценариев суммарно занимали около 50 часов на прохождение. [...] Часть сценариев в процессе прохождения требовали больше 100 пользовательских действий типа «выбрать строку, нажать кнопку, выбрать элемент комбо бокса, и т.д.» и требовали работы в более, чем 10 формах.
… и все равно вы делали это вручную.
Какой реальный процент данных вы проверяли за эти 50 часов?
Да, реальные use cases проходились вручную — затраты на написание инструмента или покупку готового + его настройку были бы выше, чем зарплата того человека, который их выполнял.
Про данные — судя по изменениям, use cases охватывали около 85% данных на чтение и 100% данных за месяц/квартал (в зависимости от конкретного use case) на запись.
В целом, на запись охватывалось около 25-30% данных всей БД (база за два года — заказчики «устаревшие» данные убирали в архив средствами MS SQL).
Про данные — судя по изменениям, use cases охватывали около 85% данных на чтение и 100% данных за месяц/квартал (в зависимости от конкретного use case) на запись.
В целом, на запись охватывалось около 25-30% данных всей БД (база за два года — заказчики «устаревшие» данные убирали в архив средствами MS SQL).
Т.е. вы хотите сказать, что ручное прохождение 60 UC, занимающее 50 часов, затрагивало 25-30% от 750Гб?
Я вот только не могу понять — это много или мало?
основные данные на запись — это всяческие промежуточные данные для отчётов, сводные прайсы, сводные отчёты и подобное.
Больше половины объёма БД занимают справочники, проводки и приходно/расходные операции. Именно этим обусловлен высокий процент покрытия БД на чтение и относительно невысокий на запись.
Результаты примерные — так докладывал наш тестер (для сравнения использовался, если ничего не путаю, dbCompare). Для мониторинга чтения — что-то настраивали в SQL Profiler.
основные данные на запись — это всяческие промежуточные данные для отчётов, сводные прайсы, сводные отчёты и подобное.
Больше половины объёма БД занимают справочники, проводки и приходно/расходные операции. Именно этим обусловлен высокий процент покрытия БД на чтение и относительно невысокий на запись.
Результаты примерные — так докладывал наш тестер (для сравнения использовался, если ничего не путаю, dbCompare). Для мониторинга чтения — что-то настраивали в SQL Profiler.
Я хочу сказать, что я не очень верю. Слишком большой объем.
Это FoxPro и люди, которые на нем писали либо со времен DOS'а, либо со времён Windows 95.
Там очень часто для «быстрой» выдачи отчётов используют генерацию гигантских таблиц со сводными данными.
Единственное светлое место в том приложении заключалось в том, что достаточно большой пласт таких «сводных» обновлений они вынесли в SP, а на той стороне был достаточно шустрый сервер, который всё съедал быстро.
P.S. Из смешного, если бы не хотелось плакать. Когда мы первый раз подняли эту базу у себя (на виртуальной машине) — нам «немного» поплохело при первом же запуске и попытке работать. В результате собрали для первичного тестирования машинку с 32 Гб памяти и зеркалом на SATA-3 — тогда хоть немного быстрее зашуршало чтение данных, ну и гигабитная сеть здесь решала, как выяснилось — перекачка данных в 500-600 МБ для обработки на клиент — вполне себе регулярная задача была (я в одном из комментариев уже описывал).
Там очень часто для «быстрой» выдачи отчётов используют генерацию гигантских таблиц со сводными данными.
Единственное светлое место в том приложении заключалось в том, что достаточно большой пласт таких «сводных» обновлений они вынесли в SP, а на той стороне был достаточно шустрый сервер, который всё съедал быстро.
P.S. Из смешного
Вы абсолютно правы!
Цель миграции не только в том, чтобы перенести код на другую платформу (хотя и это — тоже цель).
Цель в том, чтобы:
Так что «писать абы как» тут не подойдёт.
P.S. Ну и как, опять-таки, я объяснял в другом комментарии — речь идет о миллионах (минимум — сотни тысяч, где первая цифра больше пятёрки) строк — там невозможно сохранить высокую скорость написания кода. Даже если писать код по ТЗ с нуля.
Цель миграции не только в том, чтобы перенести код на другую платформу (хотя и это — тоже цель).
Цель в том, чтобы:
- перенести приложение «прозрачно для тётушек со склада» (обычно — 4-8 классов образования — увы), то есть сохранить внешний вид и функционал,
- перенести код, оставив его хоть в какой-то мере похожим на тот, что был раньше (облегчить сотрудникам IT отдела переход с проекта на проект),
- оставить ВСЕ фичи (ну и баги, конечно) старой версии, все алгоритмы, которые годами нарабатывались (ниже есть пример одного из мест, где алгоритм нужно, конечно, менять, но подобные задачи тоже можно, порой, обработать автоматом или же, по крайней мере, отметить подобные места — слишком «типичный» вид)
- по возможности подготовить приложение к рефакторингу в процессе переноса.
Так что «писать абы как» тут не подойдёт.
P.S. Ну и как, опять-таки, я объяснял в другом комментарии — речь идет о миллионах (минимум — сотни тысяч, где первая цифра больше пятёрки) строк — там невозможно сохранить высокую скорость написания кода. Даже если писать код по ТЗ с нуля.
Как вы можете утверждать, что все алгоритмы сохранены точно, без подробного тестирования?
Для такой уверенности у нас было 3 основания:
1. конвертация делалась 1-в-1, порядлк выполнения операций было видно глазами, более того, в исходниках на новой платформе мы в комментариях оставляли копию изначального кода старого приложения — можно было сравнить визуально.
2. для различных частных мест (сложная выборка из БД, сложный расчет и т.п.) мы писали тесты, которые создавали клон данных, прогоняли тест и далше сравнивали результирующие данные с эталоном.
3. все очень сложные алгоритмы прохдили через «пошаговое» тестирование, то есть: выполняем шаг в старой системе — берем данные, выполняем шаг в новой системе — сравниваем. особо «интересные» места вытаскивались в тесты прошлого раздела. Такое пошаговое тестирование — это, конечно, долго, но пройдя сложные use case таким макаром по паре/тройке раз мы получади очень качественный охват кода тестами.
P.S. в конце проекта у нас был второй тестовый проект (не просто unit test'ы, которые можно регулярно запускать, а длинные тесты, суммарно часа на полтора-два), так в нём было порядка 350 тестов. Всё это давало гарантию одинаковости алгоритмов.
1. конвертация делалась 1-в-1, порядлк выполнения операций было видно глазами, более того, в исходниках на новой платформе мы в комментариях оставляли копию изначального кода старого приложения — можно было сравнить визуально.
2. для различных частных мест (сложная выборка из БД, сложный расчет и т.п.) мы писали тесты, которые создавали клон данных, прогоняли тест и далше сравнивали результирующие данные с эталоном.
3. все очень сложные алгоритмы прохдили через «пошаговое» тестирование, то есть: выполняем шаг в старой системе — берем данные, выполняем шаг в новой системе — сравниваем. особо «интересные» места вытаскивались в тесты прошлого раздела. Такое пошаговое тестирование — это, конечно, долго, но пройдя сложные use case таким макаром по паре/тройке раз мы получади очень качественный охват кода тестами.
P.S. в конце проекта у нас был второй тестовый проект (не просто unit test'ы, которые можно регулярно запускать, а длинные тесты, суммарно часа на полтора-два), так в нём было порядка 350 тестов. Всё это давало гарантию одинаковости алгоритмов.
Если переписывать что-то с небольшим общим объемом — да, можно лопатить и 1000+ строк в сутки.
Но здесь мы вернёмся к описанию задачи:
30 строк в день — это средняя скорость. сюда включается и тестирование, и отлов багов, и корректировка отличий в работе плавающих вычислений (например иногда в Delphi и C# немного по-разному происходит окургление), иногда — надо переделывать работу с данными.
Про данные приведу отдельный пример:
в FoxPro при обработке больших (действительно больших) объемов данных принято делать так:
без реализации РЕАЛЬНО быстрой работы с каким-либо локальным хранилищем таблиц, поспорить в скорости выполнения данной задачи с FoxPro почти не реально — надо думать над переписыванием алгоритма, либо искать способ быстрой работы с локальными данными.
В общем, есть множество дополнительных задач, которые приходится так или иначе решать. Отсюда средняя скорость 30 строк в сутки… которая более-менее реалистична для действительно хороших разработчиков. Для тех, кто обычно сидит в IT отделах старых компаний, имеющих подобный софт — это очень высокая скорость.
P.S. А расчет с 300 строк/сутки тоже не убеждает?
Но здесь мы вернёмся к описанию задачи:
- в проектах, обычно, миллионы строк кода.
- В расчетах в сроки переписывания не включены отдельно, как можно заметить, ни отладка, ни тестирование, ни все остальное — это тоже очень большие расходы времени, которые стоят денег
30 строк в день — это средняя скорость. сюда включается и тестирование, и отлов багов, и корректировка отличий в работе плавающих вычислений (например иногда в Delphi и C# немного по-разному происходит окургление), иногда — надо переделывать работу с данными.
Про данные приведу отдельный пример:
в FoxPro при обработке больших (действительно больших) объемов данных принято делать так:
- выдергиваем данные из SQL Server'а через хранимую процедуру (которую лучше не трогать — упадет) в локальную таблицу DBF (например — 250-300 тысяч строк, я лично встречал и пару миллионов).
- Обрабатываем таблицу (проходя по каждой записи и выполняя над ней какие-либо действия),
- Группируем локальную таблицу, сохраняя сгруппированный результат в другой локальной таблице.
- Создаем relation типа master->detail, где главная таблица — таблица с группировками
- открываем форму, в которой отображаются все эти данные.
без реализации РЕАЛЬНО быстрой работы с каким-либо локальным хранилищем таблиц, поспорить в скорости выполнения данной задачи с FoxPro почти не реально — надо думать над переписыванием алгоритма, либо искать способ быстрой работы с локальными данными.
Кстати, про скорость локальных хранилищ
Работа с DBF файлами FoxPro — самый быстрый способ работать с таблицами, имеющими строгую структуру, возможность иметь до 231 записей, поддержку индексов, мемо полей и многого другого.
За скорость мы платим отсутствием транзакций, но FoxPo' шникам не привыкать
За скорость мы платим отсутствием транзакций, но FoxPo' шникам не привыкать
В общем, есть множество дополнительных задач, которые приходится так или иначе решать. Отсюда средняя скорость 30 строк в сутки… которая более-менее реалистична для действительно хороших разработчиков. Для тех, кто обычно сидит в IT отделах старых компаний, имеющих подобный софт — это очень высокая скорость.
P.S. А расчет с 300 строк/сутки тоже не убеждает?
С FoxPro на C# тоже с такой же скоростью смигрируете? Желательно чтоб и формы продолжали так же работать (это, наверно, самое простое будет).
Как раз для FoxPro у нас, пожалуй, самый продвиеутый инструмент. Формы 1-в-1, алгоритмы — тоже.
Самое забавное — даже раскраски в ячейках таблиц пашут адекватно.
P.S. забыл написать. FoxPro мы перетаскиваем в C# + WPF + MVVM. Получается интересно. Ну и скинов для контролов мы в какой-то момент делали 3 или 4, с подменой «на лету», а также — поддержку Zoom'а (чем и хорош WPF)
Самое забавное — даже раскраски в ячейках таблиц пашут адекватно.
P.S. забыл написать. FoxPro мы перетаскиваем в C# + WPF + MVVM. Получается интересно. Ну и скинов для контролов мы в какой-то момент делали 3 или 4, с подменой «на лету», а также — поддержку Zoom'а (чем и хорош WPF)
Все очень просто — исходный текст, на старой платформе, транслируется в текст на новой платформе. В некоторых случаях дописывается миграционная библиотека.
А можно какой-нибудь примерчик такой миграции? Чтобы можно было, так сказать, в более практичесом ключе понять, как это должно работать.
Мне вот приходилось переносить небольшие (несколько тысяч строк кода) древние поделия на другую платформу — так там такое встречалось, что до сих пор волосья дыбом по всему организму. Правда, там и платформы были совсем разные (С++ и XML/XPath/Java), так что автоматическая трансляция, как мне кажется, вообще невозможна.
Какой именно пример?
Если нужен пример куска кода — могу кинуть, если скриншоты GUI — это чуть подольше — пара дней нужна (надо добраться до тех мест, где это всё есть).
На самом деле, я могу «родить» пример переноса кода прямо сейчас — тут же подход такой — при разработке конвертера мы определяем, как именно какие конструкции в какие будут переводиться, дополнительно решаем, какие типы из старой платформы будут подменяться на типы в новой (даже для custom типов, зачастую) Соответственно строится и mapping методов/полей/свойств.
С одной стороны — всё просто, с другой — сложно.
P.S. Утром постараюсь выложить примеры кода прямо в статью через UPD.
P.P.S. Про сложность переноса — согласен, порой получается очень, так скажем,
Если нужен пример куска кода — могу кинуть, если скриншоты GUI — это чуть подольше — пара дней нужна (надо добраться до тех мест, где это всё есть).
На самом деле, я могу «родить» пример переноса кода прямо сейчас — тут же подход такой — при разработке конвертера мы определяем, как именно какие конструкции в какие будут переводиться, дополнительно решаем, какие типы из старой платформы будут подменяться на типы в новой (даже для custom типов, зачастую) Соответственно строится и mapping методов/полей/свойств.
С одной стороны — всё просто, с другой — сложно.
P.S. Утром постараюсь выложить примеры кода прямо в статью через UPD.
P.P.S. Про сложность переноса — согласен, порой получается очень, так скажем,
нетривиально
. Интереса для, если не сталкивались, попробуйте прочитать про области видимости переменных в FoxPro. Конкретно — области видимости для переменных, созданных через конструкции Public, Private и Local. И попробуйте себе представить, как это должно выглядеть в C#. Мы данную проблему решили — у нас получилось, в своё время, разработать 100% автоматический переводчик из Visual FoxPro 9 в C#. Именно 100% автоматики (а причина простая — у FoxPro есть развёртывание макросов + есть функция Eval().
Какой именно пример?
Ну, вам виднее, какой из примеров попоказательнее выбрать. Я как-то затрудняюсь ответить.
Поясню суть моих затруднений: дело в том, что у вас в статье, похоже, речь идет в основном о миграции комплекса, написанного на одном языке программирования (FoxPro?). Мне же обычно встречались «комплексы», слепленные из сотен разнообразных утилит, скриптов и прокладок. Языков программирования там использовалось минимум десяток всяких разных, причем для многих утилит за давностью лет не сохранилось никаких исходников (или сохранились, но далеко не самой последней версии, что еще хуже). Немалая часть всей системы — это сложная конструкция из подпорок и костылей, компенсирующая одни глюки за счет внесения других, чуть менее фатальных. Поэтому для меня автоматическая конвертация кода всей системы с сохранением его функционала — это что-то фантастическое.
Хорошо бы увидеть примеры кода (небольшие) — оригинал и результат конвертирования, с пояснениями, где там были самые грабельные места. Еще интересно, как вам удалось сконвертировать фокспрошные формы и отчеты в сишарп. Только учтите, что я фокспро последний раз тыкал палочкой лет десять назад (да и то еще версию под ДОС), поэтому никаких тонкостей языка уже не помню (думаю, как и многие другие хабровчане).
Очень интересная математика. Сначала вы пишете, что 10 разработчиков за 13 лет написали это приложение. Затем в обратную сторону у вас получается 11 000 человеко лет…
Извините, но вы в расчетах, чисто математически ошиблись примерно на порядок для случая тридцати строк.
Ну сами подумайте, написание системы потребовало 130 человеко-лет, при средней скорости 200-300 строк кода в день на написание, а переделка, даже при скорости в десять раз меньше — уже 11 тысяч человеко-лет.
Ну сами подумайте, написание системы потребовало 130 человеко-лет, при средней скорости 200-300 строк кода в день на написание, а переделка, даже при скорости в десять раз меньше — уже 11 тысяч человеко-лет.
Упс, спасибо за комментарий — пересчитал — где-то ошибся при подсчётах.
там 1 300, однако… Сейчас поправлю всю арифметику, но цифры всё равно очень большие выходят.
На самом деле — те программисты писали больше — это были реально ОЧЕНЬ хорошие работники и пахали они «за совесть» — порядка 12/14 часов в сутки стабильно, суммарно, по прикидкам, они написали 15-16 млн. строк кода, просто часть кода писалась «поверх» другого — исправления в связи с изменениями законодательства и требований заказчика — всё это время система активно эксплуатировалась.
Еще раз спасибо за исправление — сейчас допишу в статье.
там 1 300, однако… Сейчас поправлю всю арифметику, но цифры всё равно очень большие выходят.
На самом деле — те программисты писали больше — это были реально ОЧЕНЬ хорошие работники и пахали они «за совесть» — порядка 12/14 часов в сутки стабильно, суммарно, по прикидкам, они написали 15-16 млн. строк кода, просто часть кода писалась «поверх» другого — исправления в связи с изменениями законодательства и требований заказчика — всё это время система активно эксплуатировалась.
Еще раз спасибо за исправление — сейчас допишу в статье.
Ну, так не бывает.
1) Переписывать имея уже готовую реализацию всегда проще, если осталась старая документация на разработку, очень много времени уходит на проектирование и отброс неверных решений,
2) Новые языки программирования, новые IDE содержат кучу штук резко ускоряющих разработку,
3) Совершенно неправильно считать что строчки будут переписываться одна в одну, на самом деле при правильном дизайне, архитектуре и прямых руках программистов тысячи строчек старого проекта могут превратиться в десяток нового (для того и существуют плюшки нового языка),
4) Скорость может быть как 10 строчка в неделю, так и 30000 строк за 10 минут, сгенирить тысячу классов entity по текущей структуре базы можно чисто автоматически, да и всякие DTO объекты IDE генерит очень быстро, так что 300 строк кода в день это что-то вроде средней температуре по больнице,
5) Совершенно не учитывается сколько потом потребуется времени на рефакторинг и сопровождение мигрированного кода, вполне может быть для серьезного расширения придется сначала сделать рефакторинг с примерно теми же трудозатратами что переписать с нуля,
1) Переписывать имея уже готовую реализацию всегда проще, если осталась старая документация на разработку, очень много времени уходит на проектирование и отброс неверных решений,
2) Новые языки программирования, новые IDE содержат кучу штук резко ускоряющих разработку,
3) Совершенно неправильно считать что строчки будут переписываться одна в одну, на самом деле при правильном дизайне, архитектуре и прямых руках программистов тысячи строчек старого проекта могут превратиться в десяток нового (для того и существуют плюшки нового языка),
4) Скорость может быть как 10 строчка в неделю, так и 30000 строк за 10 минут, сгенирить тысячу классов entity по текущей структуре базы можно чисто автоматически, да и всякие DTO объекты IDE генерит очень быстро, так что 300 строк кода в день это что-то вроде средней температуре по больнице,
5) Совершенно не учитывается сколько потом потребуется времени на рефакторинг и сопровождение мигрированного кода, вполне может быть для серьезного расширения придется сначала сделать рефакторинг с примерно теми же трудозатратами что переписать с нуля,
Вспоминаю свою первую систему на Visual fox-pro, да вроде бы миллионы строк кода, но по факту мигрировать её гиблое дело, сплошной спагети стаил, не ооп программирование и велосипеды, велосипеды. На самом деле, проще взять юз.кейсы, снимки экранов и отчетов и за несколько месяцев сделать нормальную систему с нормальным дизайном и архитектурой, взяв за ТЗ функционал старой системы. Автоматических перенос магическим образом исправит дизайн и заплатки старого кода, поэтому получится тот же FoxPro со всеми его косяками, но как бы формально C#/Java, но со всеми проблемами сопровождения и расширения FoxPro.
На самом деле в таких системах из милионов строк кода почти всегда реально ценно меньше 1%, так как там огромное кол-во кода написано для работы с xml/json, экспорта в Excel, работы с архивами, работы с базами данными и все это решает буквально парой строчек кода на java/C#: перегнать json в объект и обратно => 1 строчка при подключении Gson, обеспечить работу с любыми архивами => 1 строчка при подключении апач компрес и т.д.
Хранимые процедуры на уровне базы данных делают все это без особого труда, да и все возможных nosql хранилищ с легким api тоже полно.
На самом деле в таких системах из милионов строк кода почти всегда реально ценно меньше 1%, так как там огромное кол-во кода написано для работы с xml/json, экспорта в Excel, работы с архивами, работы с базами данными и все это решает буквально парой строчек кода на java/C#: перегнать json в объект и обратно => 1 строчка при подключении Gson, обеспечить работу с любыми архивами => 1 строчка при подключении апач компрес и т.д.
в FoxPro при обработке больших (действительно больших) объемов данных принято делать так:
Хранимые процедуры на уровне базы данных делают все это без особого труда, да и все возможных nosql хранилищ с легким api тоже полно.
Хранимые процедуры на уровне базы данных делают все это без особого труда, да и все возможных nosql хранилищ с легким api тоже полно
Вопрос в том, что программисты FoxPro редко даже на их «комплексную БД» переходят, а уж про nosql и речи нет.
там огромное кол-во кода написано для работы с xml/json, экспорта в Excel, работы с архивами, работы с базами данными
Про конкретно тот проект, который мы переводили (да и тот, что я приводил в качестве примера в начале статьи) это совсем неверно. В проекте 2001 года действительно нужного кода было больше 60% — он эксплуатировался до тех пор, пока предприятие, для которого велась разработка, не решило себе купить SAP R3… Купили, потратили $20 млн ТОЛЬКО на настройку… а оно не заработало. А вот новый (сменившийся за 4 месяца до решения о переходе на R3) начальник отдела автоматизации купил себе квартиру в центре Москвы и, вроде как еще какую-то недвижимость в Европе. Неплохо для новоиспечённого начальника отдела автоматизации компании, расположенной за 6 000 км от Москвы, да?
Про экспорт в Excel — Visual FoxPro сам умеет таблицы в Excel «выкидывать»… или отчёты — точно не помню, помню только, что умеет и мы это в миграционной библиотеке реализовали.
Проект на Visual, опять-таки был, видимо, изначально очень неплохо спроектирован — там используется ровно одно место для общения с MS SQL (функция, которая, с помощью макросов, исполняет SQL запрос и возвращает результат, а в случае ошибки — реализует отображение нормального окошка с текстом ошибки). Так что спагетти кода там было не так много.
Ну может в вашем случае это и так, но по факту обычно смена кузова у гробатого запорожца на мерседес без смены внутренностей (перенос кода FoxPro, которые вообще не знает о ОПП если не брать в расчет компоненты, на С#/Java) ни к чем хорошему не приведет.
Да, у вас формально стал C#, но вы уверены что такой псевдоООП, псевдо C# проект можно будет адекватно развивать и сопровождать? Он уже запущен и нормально развивается или пока в стадии переноса? Просто я бы такое решения не взялся развивать и сопровождать, это по сути один сплошной технический долг на тысячу человеколет, который будущая команда будет разгребать.
Да, у вас формально стал C#, но вы уверены что такой псевдоООП, псевдо C# проект можно будет адекватно развивать и сопровождать? Он уже запущен и нормально развивается или пока в стадии переноса? Просто я бы такое решения не взялся развивать и сопровождать, это по сути один сплошной технический долг на тысячу человеколет, который будущая команда будет разгребать.
Конечно, FoxPro for DOS про ООП ничего не знал, а вот в Visual FoxPro ООП есть, притом вполне себе используется в действительно серьезных проектах.
Насчет вопроса запуска/сопровождения — да, запущен, вполне внятно сопровождается.
На текущий момент заказчик думает о привлечении нас на второй этап работ — глубокий рефакторинг приложения, избавление от макросов, замена алгоритмов «притащи мне 600 Мб данных на клиент — я буду вычислять группировки локально» и тому подобного.
При использовании C# подобные вещи гораздо проще отследить.
Более того, наша библиотека в отладочном режиме собирает статистику по использованию локальных таблиц, их очистке/переписке и многому другому, что позволяет легко вычислить где, кто и зачем их создает и унести проблемный код либо в хранимую процедуру, либо переписать запрос на группирующий сразу.
Клиенты получили очень много плюшек и довольны.
Насчет вопроса запуска/сопровождения — да, запущен, вполне внятно сопровождается.
На текущий момент заказчик думает о привлечении нас на второй этап работ — глубокий рефакторинг приложения, избавление от макросов, замена алгоритмов «притащи мне 600 Мб данных на клиент — я буду вычислять группировки локально» и тому подобного.
При использовании C# подобные вещи гораздо проще отследить.
Более того, наша библиотека в отладочном режиме собирает статистику по использованию локальных таблиц, их очистке/переписке и многому другому, что позволяет легко вычислить где, кто и зачем их создает и унести проблемный код либо в хранимую процедуру, либо переписать запрос на группирующий сразу.
Клиенты получили очень много плюшек и довольны.
Для таблиц copy to type xls. С отчётами вроде вообще ничего сделать нельзя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция приложений — мифы и реальность