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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Как правило, это будет включать в себя несколько крупных кусков:

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

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

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

Комментарий Jim Denver

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

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

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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

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

Answer 11

This является вариацией Варианта 3:

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

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

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

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

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

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

Answer 12

Что об использовании одного из сторонних приложений, которые принимают COBOL и преобразовать его в C#, как:

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

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

Answer 13

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

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

Answer 14

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

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

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

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

Answer 15

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

Answer 16

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

Answer 17

Я сделал миграцию старой системы на новую (хотя она была значительно ниже).

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

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

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

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

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