Про Cobol тут обсуждали... личный опыт..

koldoblin — 06.12.2023

https://peremogi.livejournal.com/69141689.html?view=comments#t1968400313
На счёт — взять и автоматически перевести Cobol на Java.. Ну вот у вас новый код на Java. Миллион корявых строк.

Шаг один выполнен. Ура! Считайте это экспериментальным прототипом.

Но мы говорим о серьёзной организации. Поэтому осталось ещё несколько небольших таких шагов.
Тут мой личный опыт в одной финансовой компании.

Шаг два. У любого финансового продукта должны быть определены требования к функциональности. Есть такой продукт DOORS. Всё что делает ваш продукт, должно быть там определено. Каждая формула и алгоритм, которым программа пользуется. Фактически это тоже самое, что и код, но на английском языке, и всё разбито на кусочки и пронумеровано.

Есть сомнение, что у старого продукта такое есть. Ну значит нужно создать. Т.е. взять старый код и начать переводить на английский язык. После чего пользователь, т.е. какой-то финансист на жирной зарплате должен это утвердить. Тут вообще засада. В зависимости от продукта, это может быть том на тысячу страниц.  И вас могут послать с этой книжкой нафиг.
Ну некогда и зачем мне этим заниматься. Давайте ещё раз поищем дедушку со знанием языка.

Шаг три. Необходимо провести код Review. Каждая строчка нового кода должна быть прочитана программистом сравнена с оригиналом, и он должен подтвердить, код делает то, что нужно. Нигде не произошло печальной ошибки. И 33 тыс не превратятся в минус 233. Кто-то обязан взять эту ответственность на себя. Если вы думаете, что программист что-то пишет, и банкомат начинает сразу деньги выдавать, используя этот код, то мягко говоря ошибаетесь. Код перечитывает несколько человек. Речь ведь о деньгах. Опять же весьма нереальная задача с гигантским объёмом строк.

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

Шаг пять. Cпециалист по кибер-безопасности прогонит код через свой софт и глаза. И возможно осчастливит вас ещё тем, что вот здесь и ещё тут и тут 100 раз возможна атака Man-in-the-middle. И от переполнение жёсткого диска во время DDOS атаки было бы неплохо что-то придумать. Ну да, ну да, раньше и без этого работало. А теперь раз мы об этом знаем, то уже нельзя. А ещё у вас в log-file пишется секретная информация о продукте и Java-stack намекает на то, какими библиотеками вы пользуетесь. Так тоже нельзя. А без исправлений не подпишу.

Шаг шесть. Тестирование. Тут вообще засада.
В нашей ситуации тестерам придётся пройтись по всем требованиям (шаг 2) и проверить на то, что новый код полностью соответствует. На этапе тестирования к ошибкам относятся с терпением. Тестеры и разработчики из близких отделов. Туда, сюда, обратно, всё исправили.

Шаг семь. QA — гарантия качества. Тоже самое, что и тестирование, но проводит другой изолированный от разработчиков отдел. И тут если что-то ломается, это плохо. Все такой ситуации опасаются.

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

Шаг девять. Подготовка к установке. Пишется план обновления. Каждый шаг в подробности и в виде красивой таблички, с именами участников, временем, сколько займёт и когда шаг будет выполнен.
Всё это проводят вечером после окончания работы большенством сотрудников.
План утверждается начальством, отделами безопасности, отделом администраторов серверов и тп.

Шаг десять. Вечер. Собираются проджект менеджеры. Авторы изменений. Зрители. Был у нас классный мужик. Он приносил всякое пиво, чтобы отметить окончание. Но в начале...
Суть в том, что в процесс завязано очень много людей, чтобы избежать какой-нибудь криминальной подставы.

Звоним в отдел безопасности и объявляем, что сейчас начнётся процесс. Они отключают «сигнализацию» с тех участков, где будут проводить изменения.
Звоним в отдел администраторов и те следуя плану обновления начинают, копировать файлы, редактировать, всякое такое. У обычных сотрудников нет никакого способа добраться до этих серверов. Если администратор туда полезет в другое време, его поймают. На всех базах данных висит куча триггеров на обнавление записей. Они регистрируют все изменения, занося записи в другую базу данных. И там уже ничего не сотрёшь.
После обновления звоним пользователю. Он/она заходит к себе и делает первоначальную проверку того, что вроде всё работает. Если где-то, что-то не так, это очень неприятно, потому что нужно объяснять админу как и где что-то проверить. Например, уровни доступа к файлам, как их исправить. Бывало и такое.
Ну и наконец все по очереди закрываются. Безопасники восстанавливают свои звоночки.
Всё хорошо, пьём пиво!

Оставить комментарий

Популярные посты:

• Архив