Приключения в модернизации: стратегия + пример преобразования COBOL в Java

«Re-платформа? Это как починить мои ботинки?

Re-Platform иногда называют лифт-и-сдвиг. По своей сути, ре-платформа переносит, то есть переводит один язык кода на другой. В качестве стратегии модернизации это означает преобразование старых языков кода в новые.

Мейнфреймы по-прежнему распространены на некоторых крупных предприятиях по множеству причин, и из-за этого все еще существуют более старые базы кода, такие как COBOL. Причины отказа от этих старых кодовых баз и мэйнфреймов обычно заключаются в следующем:

• Проблемы с ресурсами (как уже упоминалось выше): программистов на мэйнфреймах становится мало, и эти языковые наборы не охватываются современными учебными программами. Труднее привлечь новых разработчиков, особенно когда нормой становятся быстрые изменения и постоянно расширяющийся выбор технологий. Меньшее количество сотрудников готовы работать над тем, что некоторые считают устаревшей технологией.
• Мейнфреймы могут быть большими затратами для предприятий любого размера, при этом единственным вариантом роста является вертикальное масштабирование, которое иногда обходится слишком дорого.
  Стратегии аварийного восстановления и обеспечения высокой доступности, характерные для большинства современных архитектур, могут быть слишком дорогостоящими для мэйнфреймов.
• Новые шаблоны программирования не могут быть легко использованы в процедурных языковых конструкциях (ООП, Функциональное программирование, Реактивное программирование и т. Д.), Что ограничивает возможности.
• Изменение в SDLC — то есть переход от водопада к гибкому процессу, чтобы оставаться конкурентоспособным.

Итак, чтобы сделать длинную историю бесконечной — что мы на самом деле имеем в виду, когда говорим «Переплатформирование»?

Это процесс, в котором старые базы кода анализируются для определения грамматики или шаблонов в базе кода.

Как только дерево грамматики или набор шаблонов кода определены, исходная база кода (например, COBOL) запускается через одно- или многошаговое программное обеспечение компилятора-компилятора для преобразования унаследованного кода в желаемое конечное состояние — обычно Java, C # или более новый языковой эквивалент.

С точки зрения бизнеса это может быть очень привлекательным. Вместо того, чтобы укомплектовывать команды владельцев продуктов и разработчиков, чтобы постепенно переписывать каждый из унаследованных кусков кода на новом языке — этот метод обещает выполнить всю тяжелую работу с парой нажатий кнопки. Звучит здорово!

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

Перевод кода не обязательно исправляет технический долг!

В некоторых случаях эти унаследованные кодовые базы могут существовать более 20 лет. Это потенциально 20+ лет плохих или специфичных для мэйнфреймов решений, встроенных в ваш код.

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

Код может выглядеть хуже, чем на мэйнфрейме!

Выполнение кода через этот процесс может иногда выглядеть так, как будто его выбросили через дробилку древесины. Некоторые конструкции и поведения мэйнфреймов и унаследованных кодов плохо или вовсе не переводятся в более новые кодовые базы. (Например: в недавнем клиенте мы нашли пример, где в одной базе кода математическая операция x / 0 вернула 0!)

Даже если код конвертируется и выглядит хорошо, это не значит, что он всегда будет работать!

Простой перевод на другой язык не гарантирует выполнения — первоначальный успешный перевод обычно означает отсутствие синтаксических ошибок.

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

Бег! = Выполнение

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

Сложность, скорее всего, не будет уменьшена этим процессом!

Во время этого процесса вы, скорее всего, переходите от чего-то, что обрабатывает всю его сложность в процессе (и в некоторых случаях с небольшими или нулевыми штрафами ввода / вывода), к чему-то менее щедрому с его ресурсами.

Перемещение этих кодовых баз на более новые языки, как правило, предполагает некоторое разделение задач:

• уровень доступа к данным, противоположный встроенным операторам SQL
• потенциальные новые хранилища реляционных данных в отличие от хранилищ данных на основе файлов
• Уровень представления в отличие от кода пользовательского интерфейса, запеченного прямо в
• слой сервисной / бизнес-логики как собственный слой

Может потребоваться некоторая дополнительная инфраструктура для обработки вещей, которые мэйнфрейм делал бесплатно

Например, обмен сообщениями, управление контейнером или виртуальной машиной, очереди, интеграция AD / LDAP / OAuth и т. Д.

Так что теперь вы, вероятно, чувствуете, что только что вошли в фармацевтическую рекламу, где я сказал:

«Эта крошечная таблетка решит все ваши боли в спине и желтые проблемы с ногтями на ногах. Потенциальные побочные эффекты могут включать рвоту, кровотечение из глаз и / или ушей, временную потерю зрения, спонтанное облысение и болезненную чувствительность к букве «А» ».

Однако это может быть успешное путешествие, если вы сосредоточитесь на следующем:

1. Если у вас большая кодовая база на унаследованных языках / языках мэйнфреймов, этот процесс может очень быстро перевести вашу кодовую базу в более современную кодовую базу.
2. С этого момента — ваши команды разработчиков будут гораздо в большей степени способны обновлять приложения в желаемом конечном состоянии, просто благодаря тому факту, что теперь они могут читать код.

Если вы выбираете процесс, который может использовать грамматическое дерево для первоначального преобразования …

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

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

Synhole Tree Transformer Keyhole и его собственный анализатор грамматики COBOL основаны на грамматике и созданы именно для этого!

Это может быть жизнеспособным вариантом, чтобы получить вас в поэтапной реализации …

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

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

Это позволяет организации принимать более целенаправленные решения относительно того, что действительно важно для бизнеса.

Предоставляет ценную информацию и анализ бизнес-логики, применяемой в вашей кодовой базе.

В некоторых случаях бизнес-логика может быть такой же старой, как база кода, и больше не применяется. Большинство клиентов находят в этом большую ценность и заканчивают тем, что сокращают свою кодовую базу для преобразования на 10-25% только за счет анализа.

Возможность представить DevOps как часть конверсии.

В зависимости от желаемого конечного состояния кода, возможность представить DevOps как часть преобразования может быть полезной за пределами процесса преобразования. Иногда «необходимость» выдержать какой-либо инструментарий или внедрить новый процесс заканчивается как возможность внедрить передовой опыт, не проходя столько бюрократических проволочек или шлюзов.

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

Этот процесс может быть краткосрочным бюджетным выигрышем.

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

Общая стоимость разработки для перевода кода в это преобразованное состояние обычно меньше, чем переписывает команда вручную.

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

Суть этой стратегии:

Если вы убедитесь, что понимаете, что на самом деле может делать процесс, и выбрали надежный инструмент, основанный на грамматике (например, Keyhole Syntax Tree Transformer и наш анализатор — просто говорите), вы сможете достичь очень предсказуемого результата, который позволит вам сэкономить средства и время. выигрывает.

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

«Давай уже перенастроим!»

Чтобы начать этот пример, мы собираемся начать с образца бита COBOL, который был преобразован в синтаксическое дерево JSON нашим проприетарным парсером грамматики. Программа COBOL просто читает хранилище данных DB2 и возвращает список сотрудников. Мы не будем показывать фактическое преобразование COBOL в JSON — вместо этого мы начнем с уже преобразованной программы COBOL.

В заключении