Комментарии 25
Компании, руководители в которых не контролируют создание документации и bus factor должны страдать.я бы сказал «компании, руководители в которых не закладывают ресурс на разгребание технического долга».
Обычно переписывать пласты старого кода сложно даже не из-за отсутсвующей документации или устаревшего языка/диалекта, а потому что в таких кодобазах костыли друг друга подпирают, и прочитать код становится решительно невозможно.
Обычно переписывать пласты старого кода сложно даже не из-за отсутсвующей документации или устаревшего языка/диалекта, а потому что в таких кодобазах костыли друг друга подпирают, и прочитать код становится решительно невозможно.
Тогда новичок если даже и выучит cobol не сможет поддерживать старую кодовую базу, это нужно джуниора годами обучать что да как работает в этой системе, модуль за модулем и только после этого подпускать что то править и модифицировать. Без всего этого одна неосторожная правка кода может положить всю систему или появится такой баг что на его отлов уйдут месяцы.
«организации продолжают использовать старые технологии для своих критически важных приложений, поскольку они стабильны и надежны»
Стабильность, надёжность и отсутствие необходимости в непрерывных обновлениях — настоящая ценность. И это логично: все доказанные теоремы невозможно отменить, и нет необходимости доказывать их вновь. Программный код — это вывод из устройства вещей. Почему с ним должно быть иначе? Ан нет — переделывают и переделывают, пока система эволюционирует. Значит проблема в том, как строят эти выводы, и почему они так сильно зависят от эволюции системы. Либо недостаточная декомпозиция, либо игнорирование устройства вещей в части возможностей комбинирования составляющих.
Зачем организациям использовать старые мейнфреймы?
Программа, написанная на питоне на современном смартфоне будет работать на порядки производительнее программ на коболе на старых мейнфреймах.
А про надежность — это все херня. Наймите специалистов, обеспечьте их всем необходимым, правильно постройте процесс и они построят вам более быструю, недорогую в обслуживании, отказоустойчивую и масштабируемую систему, которая будет лучше таковой на мейнфрейме, о будущем вымирании которых было известно уже в 90х годах.
Ну и если вдруг спецов по старым технологиям не станет, компания очень быстро решит эту проблему, при желании.
Преимущество мейнфреймов только одно — они уже работают.
— обратная совместимость со старой системой на период перехода
— «период перехода» затягивается на продолжительное время, так как всё равно нужно изучить поведение старой системы и воспроизвести его, а это нельзя сделать только читая код
— В лучшем случае (при замене частей приложения) требуется обеспечить взаимодействие между старыми и новыми частями (которые нужно покрыть большим количеством тестов и которые будут удивлять необычными случаями раз в X дней) со всякими мониторингами, тестами, метриками, доп. поддержкой, фоллбеками в случае чего, корректировкой релизного цикла и прочими прелестями
— В худшем — перевести **всех до единого** пользователей на новую версию системы
И в том и в том случае возникает длительный период поддержки двух систем, который, увы, дороже более чем в два раза
А про надежность — это все херня.
Если вы пишете TODO-лист — да. Если вы пишете софт, от которого зависят жизни людей/килотонны денег/управление ядерным реактором — то лучше с таким подходом даже не смотреть в эту сторону.
Не смешите вы... Молодые специалисты своими глупостями только смех вызывают. У нас тоже таких систем хватает - типа экспресса железно-дорожного...
Да чего про мэйнфреймы говорить.... Вы на новые версии большей части коммерческого софта посмотрите и сравните с версиями для WinXP 20-летней давности по скорости, удобству работы, РАЗМЕРАМ (не трогая переход 32/64), относительному приросту функционала......
Выводы будут очень печальные.
А теперь представьте, ложка для супа будет закачивать суп вам в рот со скоростью 10000 циклов в минуту. Через сколько останетесь без зубов? И зачем наращивать скорость там, где всё равно самым медленным звеном остаётся человек? А эргономическая оптимизация - про это в 100% юных софтописателей, а судя по софту - и большинство ИТ-фирм, и вообще и не слышало. Им бы только свистоперделки свои туда всунуть, согласованные с заказчиком под коньячок с откатиком или распиликом.
В 90-е годы хотя бы понимали, что ПК с софтом - ЭТО ИНСТРУМЕНТ для конкретной задачи, выполняемой ЧЕЛОВЕКОМ, прекрасно понимали саму задачу, пути её решения, и писали софт, почти всегда находя оригинальные технические решения для обхода ограничений архитектуры тех лет....А сейчас понты, рисование воздушных замков перед не совсем опытными заказчиками, напихивание софта всяким ГУАНО - не справится i3 - справится Ryzen5950X или i9, не хватит 16 ГБ - купят 32; напихиванием всяческих левых библиотек —— по сути просто развод лохов в ИТ, не считая проблем от появления куч электронного мусора просто по воле криворуких программеров (типа XP, W7 etc).
Говоря про старый и современный софт — если это перевести в более понятные материи, то в 80-90-е молоток бы сделали максимально простым и функциональным - из железа, дерева, с клином для крепления рукоятки, с простым круглым или четырёхгранным бойком.
Сегодня начали бы, что боёк должен быть из какого-нибудь титана, с сердечником утяжелителем, украшенный сверху красивыми декорациями гравировкой или электроэрозионкой, какой-нибудь фигурной формы, типа просчитанной на супер-пупер нейросети, ручка из карбона или слоновой кости, украшенная не хуже эфесов старого ХО, с каким-нибудь хитрым креплением бойка — ну прям творение Церетели на выставку, а не гвозди забивать, и с ценой, как у самолёта.....
Еще один момент — замена всего комплекса оборудования на новое с переобучением персонала - огромные финансовые и трудовые затраты. Давайте переложим их на ЗП программистов — пусть до полного окупания и устаканивания они вместо 200-300 тыс, будут получать 20-30, а разница будет компенсировать затраты. И окажется, что все ТИПА ПРЕИМУЩЕСТВА нового софта никогда не окупятся, либо к тому времени, как окупятся - надо новое писать по этой же причине.
Если у организации уже есть работающий комплекс ПО, который выполняет свои бизнес-функции с приемлемой скоростью, надежностью и стоимостью эксплуатации, то какой смысл бизнесу вкладываться в переписывание этого комплекса?
При этом никаких гарантий что новое решение будет лучше (по критичным для бизнеса параметрам) никто как правило не дает. Затраты на переписывание и миграцию могут составлять очень внушительные суммы, которые, в случае неудачи, придется просто «списать».
Специалисты, которые смогут глубоко разобраться в существующей «старой» системе и ее взаимосвязях, так, чтобы переписать ее на новую платформу и обеспечить «безболезненную» миграцию — тоже будут стоить очень и очень недешево.
Поэтому в теории «наймите специалистов и они сделают вам хорошо» — работает. В реальности — этих специалистов еще нужно найти и суметь привлечь на конкретный проект, сумев вложиться в какой-то разумный бюджет и сроки.
Не могут переписать просто из-за того, что отрасль деградировала: раньше винда занимала диск на 700 Мб, теперь нужны гигабайты и десятки гигабайт, плюс принудительные обновления для оперативного устранения косяков набранных по расово-половым квотам. Для критичных применений такое неприемлемо.
Я участвую в переделке системы на мейнфрейме с кодом на Коболе на современные микросервисы на Котлине.
Код написан 25 лет назад, никто толком не понимает как он работает. Например, есть 70+ одинаковых job-ов, которые отличаются только одним числовым параметром... Почему сделали так? Тайна покрытая мраком, но никто даже не хочет это дело отрефакторить на одну джобу + файл с параметрами, так как все боятся трогать, типа работает - не трогай.
В коде джобов повсеместно встрчаются проверки условий для которых уже нет значений в базе DB2 и никто их не рефакторит по той же причине.
Логика этих джобов весьма запутанная и построенная на пакетном принципе типа в час Х запускается первая джоба, выгружает файл, в час Х+N минут запускается следующая, которая его фильтрует и сортирует и порождает новый файл, и так далее...
Причем для обработки засасываюся таблицы с сотнями милллионов строк, а по итогу после всех фильтраций и обработок на выходе получается файл в нескольо тысяч строк.
Мы когда пару джобов переписали с мейнфрема на Кафку + No SQL базу, оказалось что по факту там несколько тысяч обновлений в день и современные микросервисы это процессят моментально.
И все это движется медленно и печально, так как расковырять и понять код на Коболе местами затруднительно, зачастую джобы в несколько сот строк на коболе превращаются в десяток строк на котлине (после выкидывания всех археологический отложений)...
И мы еще только в начале пути, потом будет весьма нетривиальная задача сверить работу новой и старой систем...
На мой взгляд всем у кого системы на Коболе, с него надо уходить на современные технологи.
Может где то и есть "башни из слоновй кости" в которых написаны идеальные джобы на Коболе которые еще 50 лет будут "выполнять свои бизнес-функции"... но то что я вижу в реальности - это груды костылей, индусский код и отстуствие понимания как это все работает.
Беда в том, что ваши современные микросервисы через 25 лет будут выглядеть так же жутко - их будут поддерживать, потихоньку менять, в итоге вырастет монстр. Так оно всегда бывает в живых больших системах - меняются требования, меняются процессы, системы подстраиваются, в итоге каша. Это не потому, что кто-то идиот (хотя и это бывает), это потому, что жизнь - штука сложная, а все такие системы - это модели жизни организации, притом в динамике десятилетий.
Если система простая и понятная, она либо только что написана, либо никому не нужна.
Это одна из проблем давно существующей системы (вне зависимости от платформы и технологий), в которой давно (никогда?) не проводился рефакторинг и для которой утеряно понимание как эта система устроена и для чего нужны те или иные сущности в ней.
Если давно существующая система превратилась в «магический черный ящик» и не осталось специалистов понимающих как она устроена и работает — то эту систему придется заменять и попутно восстанавливать знания о том как она работает (или должна работать).
Точно также через 10-50 лет созданная сегодня по самым «современным технологиям» система может превратиться в точно такой же «магический черный ящик» с археологическими наслоениями кода, кучей костылей, отсутствующими специалистами и отсутствующей/устаревшей документацией об устройстве системы.
Я не защищаю конкретно Кобол, я не фанат этого языка и ничего сложнее «Hello world» я на нем не писал. Возможно, от самого языка пора отказываться, но по другим причинам, а не просто потому что «не модно».
Очередное подтверждение того, что, каким-бы очевидным и читаемым код ни был для создателя и команды, комментарии жизненно необходимы, а "самодокументирубщийся" код не поддерживаем при смене людей.
Например, есть 70+ одинаковых job-ов, которые отличаются только одним числовым параметром… Почему сделали так? Тайна покрытая мраком
А в чём тайна-то? Все операторы систем так делают. Никто не возьмёт на себя ответственность за изменения в «чёрном ящике». Долепить сбоку — пожалуйста. Вы и сами об этом дальше пишете.
Чтобы такого не случилось, у заказчика будет staging, testing, команда (внутри или внешняя), которая будет вести все доработки и тестирования?
Вообще есть уверенность, что после перехода на версию, условно, 1.0 со старой системы (то есть объявления новой системы production) внедрение версии 1.01 не потребует визы всего руководства компании и не застрянет на этом навсегда? Версию 1.0 принять легко — с «эталонной» системой на Коболе расчёты сошлись, значит всё правильно. А когда систему на Коболе отключат, кто и как поручится за правильность версии 1.01?
Я это к тому, что при условии цены ошибки в миллионы, дело, как правило, не в языке программирования и микросервисах.
Микросервисы они гораздо меньше чем джобы на мейнфрейме и их проще изменять независимо друг от друга (вплоть до переписывания на другом языке).
И да, на мейнфрейме толком нету стеджинга, есть дев и прод.
А на микросервисах будет и дев и стейджинг и прод, что позволит вносить изменения более безопасно.
Ну и найти спеца на Котлин/Джаву попроще чем на Кобол.
Но все это не исключает "человеческий" фактор и есть нехилый шанс, что все опять пойдет по тем же рельсам - "дописывания костылей сбоку".
Время покажет.
Микросервисы они гораздо меньше чем джобы на мейнфрейме и их проще изменять независимо друг от друга (вплоть до переписывания на другом языке).
Мне кажется, что для того, чтобы это было правдой в 100% случаев нужен 100% идеальный код, которого не бывает. Как можно гарантировать (кроме «мамой клянусь!»), что ни при каких обстоятельствах изменения в одном микросервисе и, как следствие, другой pattern взаимодействия с соседними микросервисами, никогда не вызовет проблемы у соседей? А если нет гарантии, то эксплуатации всё равно, какая там архитектура.
Обобщая, как мне кажется, современный подход к массовому производству кода допускает, что новая версия может «глючить». Ну часть пользователей пару минут не смогла посмотреть фотографии котиков, пока откатывали на предыдущую версию, неприятно, но терпимо. Когда же речь идёт о критических бизнесах, то это превращается в «ну у части пользователей пропало пару миллионов со счетов, а части пользователей теперь банк должен миллиард». В таких приложениях главное — не последний tech stack, а процессы менеджмента изменений, вокруг которых, по хорошему, и должна строится система, а не наоборот. То есть если для того, чтобы в случае ошибки иметь лучший rollback plan нужно использовать не любимую или «хайповую» технологию, а эту «гадость» из «этих ваших энтерпрайзов», то нужно её и использовать и вокруг неё строить систему.
Джоб на мейнфреме (ОС z/OS) вполне может быть очень простым.
Минимальный джоб — это буквально две строки в JCL. Первая — заголовок JOB, вторая — STEP, который вызывает программу или скрипт (процедуру в терминах JCL).
Если джоб «наворотили» и он состоит из 50+ шагов со сложными условиями и зависимостями — это вполне себе повод для рефакторинга, как и любой другой код (например скрипт на Shell). Хотя, могут быть случаи когда это обосновано.
То что на конкретном «мейнфрейме» нет стейджинг-систем — это опять же проблема не «мейнфрейма», а организации процесса внедрения и эксплуатации. Сам «мейнфрейм», как и любой другой сервер, ну никак этому не мешает.
Спеца на Котлин/Джаву проще найти «сейчас», сложно сказать как оно будет через N-лет. Я не к тому что Кобол вдруг станет популярнее, я к тому что Котлин/Джава тоже могут потерять популярность и специалистов по этим языкам станет меньше.
Недавно учавствовал в написании ТЗ для одной сложной промышленной системы. Заказчики потребовали что бы мы добавили требование о том что срок службы системы должен составлять 60 лет. На мой вопрос кто будет через 60 лет с этим старьем работать никто не смог ответить.
На моё предложение что придерживать актуальность системы следует на этапе ТЗ определить модернизацию системы каждые 10 -15 лет. Мне сказали что денег на это не закладывали.
Нет ничего более постоянного, чем временное. Заказчик возможно прозорлив, вон вояджеры и их софт работают в космической тьме уже 44 года.
Исследование: компании столкнулись с проблемой передачи опыта в старых технологиях новым работникам