Переписать устаревший код

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

Мы считаем, что у нас есть четыре варианта:

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

Что вы считаете лучшим вариантом для нас и почему?

ОТВЕТЫ

Ответ 1

admeddly, проблема связана с коболом, который делает любой ответ конкретным для ваших нужд, если вы сказали "у нас есть старое приложение VB" или старое приложение C, тогда вариант №3 всегда правильный путь.

Я работал в 3 компаниях, которые решили пойти на вариант №2. 2 пошел спать, пытаясь заплатить за новую систему, только получая доход от старого, третий пришел очень близко.

Другим фактором для opetion # 3 является то, что вы получаете все старые исправления, которые вы делали на протяжении многих лет. Каждый переписывать всегда вводит все больше и больше ошибок, отчасти потому, что вы захотите быстро сделать переписывание, отчасти потому, что вы будете писать его на новом незнакомом языке, а отчасти потому, что у всех новых кодов есть ошибки.

Рефакторинг и замените логические фрагменты старого приложения, в конце концов у вас будет красивый блестящий новый. Начните с GUI, чтобы получить самый безопасный подход к новому. Кроме того, к тому времени, когда вы закончите переписывать приложение во что-то новое, что-то еще более новое станет самым крутым, и ваше новое приложение будет устаревшим, и вы снова опубликуете тот же вопрос!

Ответ 2

Это вариант Варианта 3:

Microfocus предоставляет инструмент под названием Enterprise Server, который позволяет COBOL взаимодействовать с веб-службами.

Если у вас есть программа COBOL A, а другая программа COBOL B и A вызывает B через секцию интерфейса, инструмент позволяет вам открыть раздел интерфейса B в качестве веб-службы.

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

Конечно, поскольку у B теперь есть веб-служба, любой другой тип программы (командная строка, приложение Windows, Java, ASP и т.д.) теперь также может вызвать его.

Используя этот подход, вы можете "откусить по краям", чтобы переместить графический интерфейс в современный подход на основе браузера, используя что-то вроде ASP, все еще используя бизнес-движок COBOL.

И как только у вас есть приличный набор веб-сервисов, они могут быть использованы для любой новой разработки, которая обеспечивает способ перехода от COBOL в долгосрочной перспективе.

Ответ 3

Будьте осторожны, пытаясь полностью переписать. Есть много примеров того, что это будет сложно для многих компаний-разработчиков программного обеспечения. Netscape является основным примером

Ответ 4

Соблюдайте правило 80/20. Сядьте с клиентом и напишите спецификации для 20% приложения, которое получает 80% от использования. Напишите это в современной системе. Затем либо сохраните старую систему для сокращения количества специальных случаев, либо пошагите ее, как только вы создадите новую систему.

Не пытайтесь переписать старый код на 100%. Это просто глупо. В лучшем случае вы имеете полный порт устаревшей системы. В худшем случае вы сжигаете много времени и денег, чтобы иметь неудачную новую систему, и вы все еще придерживаетесь старой системы.

Используйте время и усилия, чтобы улучшить систему, а не просто ее переносить. После переноса наиболее важных частей используйте время, чтобы пересмотреть особые случаи.

Ответ 5

Варианты № 2 и № 3 - ваш лучший выбор. Если ваше приложение COBOL хранит данные в SQL DB или каком-либо другом нормальном формате, к которому вы можете легко получить доступ с современного языка, который является самым дешевым/простым решением.

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

Поддержание COBOL в долгосрочной перспективе будет только усложняться. Чем дольше вы ждете, тем сложнее будет.

Ответ 6

Мигрировать приложение постепенно?

Есть ли способ связать другой код с COBOL и постепенно переписывать компоненты по мере того, как происходят изменения? Вы никогда не сможете избавиться от всего этого, но действительно ли это имеет значение?

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

Не предполагайте, что компетентный программист не сможет узнать COBOL, если возникнет такая необходимость - один язык программирования очень похож на другой. Если вы нанимаете кого-то компетентного (скажем) на С++ или Java, они смогут узнать COBOL.

Ответ 7

Я сам перевел старую систему на новую (хотя она была в гораздо более низком масштабе).

Мы довольно успешно использовали подход "постепенной замены" (№ 2) для системы клиент/сервер (небольшая, написанная в письменном виде система отчетности). Мы на самом деле сделали это с помощью твиста, используя "проксирующий" подход:

  • Сначала мы реализовали новый сервер, который предлагал весь интерфейс функциональности/вызова старого сервера, но внутренне просто делегировал все на старый сервер, который продолжался.
  • Затем все клиенты были переключены на новую систему; это было относительно безболезненно, поскольку новая система была по существу просто оберткой.
  • Наконец, мы постепенно переписывали новый сервер для реализации функциональности, не обращаясь к старой системе.

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

Я действительно спустился в серверную комнату, чтобы лично закрыть старый сервер, когда все было перенесено. Это было весело: -).

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

Ответ 8

Я бы сохранил старый код и добавил к нему новые функции, используя некоторые из отличных материалов из Microfocus/AcuCOBOL. Вы можете делать приложения с графическим интерфейсом и называть компоненты .NET и Java прямо из вашего "старого" кода.

Зачем ломать back-end, если он работает для вас? Сохранение рабочей базы и замена усталого front-end - это решение, в котором работает компания, которую я работаю.

Итак, я думаю, что мой выбор будет вариантом № 3, потому что там есть решение.

Ответ 9

Недостаточно данных для определения правильного курса.

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

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

Тем не менее, ответ многих технологов будет # 1, а многие деловые люди ответят на # 4. Не зная ничего, кроме того, что было представлено, я бы подтолкнул команду к глубокому расследованию № 3, поскольку это, вероятно, самый низкий риск. # 1 имеет проверенную репутацию неудачи, а # 2 - это только № 1 с меньшим количеством ресурсов. # 4, вероятно, не является долговременным решением, ЕСЛИ ВЫ НЕ ПОЗВОЛИТЬ эту линейку продуктов в ближайшей/среднесрочной перспективе.

Ответ 10

Честно говоря, помог "переносить" приложение из ColdFusion 5 в PHP на ColdFusion 8, я бы сказал, иди с №1. Оставьте старое приложение на месте и заморозьте разработку. Познакомьтесь с клиентом и выясните, какие новые функции есть, в дополнение к тому, как работает или работает старая система, и должен подготовить документ с хорошими требованиями. Это просто оставляет детали конструкции и дизайна, которые затем вы сможете разумно выбрать лучший язык и платформу для вашего приложения.

Где я работаю сейчас, мы фактически поддерживаем старое приложение CF при создании заменяющего .NET-приложения. Можете ли вы представить код, который ребятам .NET придется писать после завершения базового приложения? Поэтому я рекомендую замораживать разработку.

Ответ 11

Я твердо убежден в том, что вы обновляете устаревшие приложения до новейших технологий (к большому разочарованию менеджера). Это всегда должно быть поэтапным подходом и предприниматься только в случае необходимости. Постарайтесь, чтобы устаревшее приложение работало и обслуживало его, но создавайте его небольшую часть в новой технологии и со временем вытесняете старый код и заменяете его новым кодом. Я всегда убеждаюсь, что в первую очередь приоритет их в выгоде/стоимости для бизнеса.

Если приложение слишком плотно соткано, вам кажется, что вам нужно нанять некоторых скриптов COBOL, чтобы помочь вытащить изолированные службы, чтобы вы могли лишить их, когда будете готовы.

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

Ответ 12

Другим решением может быть:

Перевести код на современный язык по вашему выбору.

Как правило, это связано с несколькими большими кусками:

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

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

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

Комментарий Джима Денвера

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

Я не могу сказать, как сильно это будет. Это проще, если код, из которого вы начинаете, является регулярным. Но в любом случае вы получите "COBOL, написанный в $LANG". Это только отправная точка для инкрементных переписываний до тех пор, пока не будет исправлен кошмар обслуживания.

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

Ответ 13

Я бы сохранил старое приложение, но потом, я программист cobol....

Ответ 14

Как насчет использования одного из сторонних приложений, которые принимают cobol и конвертируют его в С#, например:

http://www.softwaremining.com/index.jsp

Или портировать его на COBOL.net, это должно быть проще, тогда все, что вы добавляете, может быть в одном из других языков .net.

Ответ 15

Прекрасная вещь о COBOL заключается в том, что требования к данным указаны там, наверху кода. Это также помогает тому, чтобы COBOL был разработан для написания с использованием (относительно) простого БИЗНЕС-английского языка (TXTSPKers не должны применяться).

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

Ответ 16

Компания, которую я знаю, боролась с одним и тем же вопросом в течение многих лет; в конечном итоге они отбросили приложение COBOL и переключились на SAP. Это был огромный проект, который занял несколько лет, но все получилось хорошо.

Ответ 17

Если вы используете OpenVMS, BridgeWorks может помочь вам создать веб-приложение с использованием старого кода с небольшими изменениями.