Работаю в финтехе. Можете мне не рассказывать про надежность процессинга, он слезы вызывает. По факту всем пофиг. Главное платежи не потерять, а пройдут на 20 минут позже, да и черт с ним.
Ну не знаю… У нас с этим сильно строго. И по надежности и по нагрузке.
Загрузка серверов мониторится постоянно, регулярно аудиты проводятся по потреблению ресурсов. Те задачи, что крутятся в фоне постоянно без нагрузочного тестирования вообще в бой не уходят.
И в промавтоматизации (точнее, близкой к ней области — система мониторинга инженерного оборудования заданий) работал долго. Там тоже все жестко было и по надежности и по таймингам. И все очень просто — плилетела посылка — не успел в таймаут уложиться — все, удаленная сторона считает что ты не получил. Идет перепосылка. После трех перепосылок считается что ты умер, разрыв сессии, реконнект и опять все сначала. Поставить систему колом можно на раз-два просто неоптимальным кодом.
А плохо работающую систему никто не купит, пойдут к конкурентам.
Э-э-э… Что есть CLR?
Там речь о CL — Command Language в AS/400. Системный язык, часть команд (полный референс порядка 2300 страниц в pdf) может использоваться в интерактиве в терминальной сессии, но можно и программы писать на нем (что характерно, программа на CL компилируется командой того же CL).
Согласен, что на собеседованиях часто просто тупо лупят по взятому откуда-то шаблону, абсолютно не задумываясь насколько этот шаблон применим к специфике работы в данной конторе.
Вообще, попасть на хорошее собеседование та еще удача, как я понял. И, опять же, иногда если не прошел через собеседование, то думаешь — вот и слава богу что не прошел. Не хочу я тут работать.
Один ответ на оба коммента.
Ситуации бывают разные. Одно дело, когда развлекательный сайт тормозит — ну тормозит и бог с ним по большому счету
А вот когда встает некое производство т.к. в системе уравления компоненты начинают по таймауту отваливаться из-за неоптимального в каком-то месте кода или у банка в период пиковой нагрузки из-за одного неоптимального модуля на несколько часов встает процессинг пластика по всей стране — это уже совсем другое дело. Тут уже бизнесу по карману бьет.
По большому счету опыт разработчика в том и есть, чтобы понимать, какой кусок кода можно сделать побыстрее, но чтобы работало, а какой надо вылизать до блеска котовых причиндалов чтобы не просто работало, но работало максимально быстро.
Насчет «большинства задач»… Ну не знаю… Сильно зависит от предметной области. Мне в этом смысле «везло» (или везло — тут как посмотреть). Долгое время работал в промавтоматизации — там постоянно сталкиваешься с жесткими таймаутами. Не уложился — тебя послали. Разрыв соединения, реконект, перепосылка пакета и все такое прочее. Посему — будь добр извернуться, но все необходимые действия уложить в отведенное время.
Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
И там тоже вопрос был в оптимизации одного модуля.
Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
Ниже правильно сказали — это разные люди. А еще ниже тоже правильно — хантеры получают плюсик за каждого, кого они доведут до собеседования.
Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
В нашем случае от этого два барьера — во-первых, в очень сомнительном случае предлагается не штат, а стажировка на полгода (20 часов в неделю, т.е. условно полставки). Часто такой вариант бывает интересен студентам старших курсов.
По результатам стажировки уже предлагается или переход в штат (возможно до окончания стажировки), или… Просто окончание стажировки за которой не последовало никаких предложений.
В любом случае, каждый новый сотрудник берется с испытательным сроком в три месяца. Зарплата на испытательном сроке полная, но плюшки типа ДМС и страхования НС не оформляются.
На испытательный срок ставятся конкретные цели. Фактически это срок обучения (напомню — платформа очень специфическая, готовых спецов по ней найти малореально). К концу срока человек уже должен уметь решать несложные (ну так скажем, типовые) боевые задачи (и иметь уже одну-две поставки, хотя бы на уровне бизнес тестирования).
По окончании срока оценка, там уже решается будет человек работать дальше здесь или нет.
Собственно говоря, я к тому, что «конвеерное тестирование» на собеседовании путем раздачи тестовых заданий решение очень простое (для HR), но в качестве фильтра далеко не самое лучшее.
Вот вам и ответ на вопрос «откуда берется только глючного тормозного софта, жрущего ресурсы как не в себя».
Один вчерашний студент почитал пару страниц stackoverflow и написал некий «продукт». Протестировал его в стиле «вроде сразу не упало — значит работает»
Другой вчерашний студент почитал пару страниц stackoverflow и настроил прод так что «вроде не падает».
Юниттесты? Не, не слышали — зачем это надо, оно и так работает, мамой клянусь!
Оптимизация? Да нафига время тратить — оно и так работает.
Нагрузочное тестирование? А что это такое? А зачем? Походу само понятно станет.
Тенденция такая, что с опытом и шаганием по лестнице, становится проще себя продать (знаешь то больше), но блин, боюсь я этого момента, если мне при след. резюме тест на какое-нибудь дерево или баблсорт подкинут — я сломаюсь.
Вот именно. Я могу рассказать про различные подходы обмена данными между процессами (от тривиальной многопоточки до гетерогенных распределенных систем), сейчас могу рассказать про некоторые аспекты эффективного кода под AS/400 (с учетом особенности работы групп активации, ресурсоемкости работы с USRSPC по сравнению с DTAARA) и т.п… Но вот тот же баблосорт реально не вспомню на память :-)
Согласен. Тут вопрос подхода. Но в нашем случае готового специалиста, знающего AS/400 и RPG найти малореально. Так что все равно готовить человека пока он сможет работать самостоятельно. Так что все равно первые три месяца — обучение. Обычно через полтора два месяца человек уже выходит на несложные боевые задачки (поначалу подбирается что-то небольшое).
Бывают и ошибки, конечно. Второй кандидат, тоже из недавних, на собеседовании полный восторг и радужные надежды, а сейчас вопросы — что с ним делать дальше. То ли попытаться найти подход, то ли распрощаться.
Тут общение через эмулятор терминала 5250, т.н. «зеленый экран».
Ценность… Очень цельная система. В нее встроено все — БД (DB2), компиляторы языков (CL, COBOL, RPG, C/C++). Очень нравится концепция ILE (Integrated Language Environment) — исполняемая программа может быть собрана из модулей, каждый из которых написан на разных языках. У нас широко используется RPG и C/C++. В рамках одной программы можно писать часть функций на RPG, часть на C/C++ и все это будет работать, главное правильно интерфейсы прописать.
Очень много концепций, которые просто не имеют аналогов в других системах. Те же группы активации в рамках процесса (JOB'а). Много не имеющих аналогов системных объектов типа DTAARA, USRSPC, DTAQUE, USRIDX и т.п.
Сситема изначально объектно-оринтированная. Т.е. основной постулат — «все есть объект». причем, заложено все это на самом глубинном уровне.
Ну и производительность… Тестовый сервер — это SMT8 процессор на 18 ядер, 1800Гб оперативки, два SSD дисковых массива 87 и 15 Тб.
На боевых серверах стоит 4 «книжки» по 4 12-ядерных SMT8 процессора (т.е. в сумме 192 ядра, каждое из которых работает в 8 потоков).
И при всем этом очень жесткие требования к оптимизации кода. Есть целый список «нефункциональных требований» как нужно делать и как делать нельзя. Ну и те задачи, что много работают в фоне, обязательно проходят нагрузочное (помимо компонентного, интеграционного и бизнес) тестирование. А там могут вернуть с замечениями типа:
Из PEX статистики работы XXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение YYY в программе ZZZ, т.е. парсинг статических выражений при подготовке SQL запроса,
Сократить данные русурсозатраты практически до нуля можно путем описания параметров sql запросов через SQL Descriptor Area (SQLDA).
Поскольку TTT один из наиболее активно используемых сервис модулей, необоснованное повышенное ресурсопотребление является малодопустимым. Просьба инициировать доработку ZZZ.
Т.е. решение некоторых задач требует некоторой изворотливости ума и придумывания хитрых алгоритмов Например, замена order by по неиндексированным полям в sql запросе на предварительное занесение результатов выборки в автосортируемый по нужному ключу массив может дать выигрыш по времени в 5-6 раз. Или разделение запроса на несколько частей с использованием высокоселективной предвыборки с использованием частотного словаря вместо агрегатной listagg в запросе как-то позволило сократить время работы процедуры с 3 сек до 150-200мсек :-)
Меня как-то HR из Я через L-In пыталась схантить. Объясняю что не ищу работу в настоящее время. Не отстает. «Ну хотя бы просто поговорить, может интересно станет...» Ну ладно, поговорить согласился, вдруг действительно интересно.
Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
Вот не поверите. Не так давно (менее полгугода назад) брали на работу человека. Опыта — ноль. Алгоритмическое мышление отсутствует напрочь. Но в разговоре за жизнь уловилась в нем некая целеустремленность и желание постичь глубины.
Взяли стажером на полгода. Через три месяца уже посовещались и перевели в штат. Ибо прогресс невообразимый. Первые задачи мы решали просто за него. Ну то есть разжевывали как и с какой строны браться, человек сидел и старательно ушами хлопал. Но потом вгрызался в тему и добивал до победного. И все, что ему хоть раз говорили, все оседало в голове, устаканивалось там и потом шло в дело. Сейчас уже вполне самостоятельный разработчик, коммуникативный, пройдет еще год и будет классным спецом в своей области.
Но на любом формальном тесте посыпался бы в том время. только в разговоре смогли потенциал разглядеть.
Вот именно такого плана у меня было собеседование в альфе. Но, во-первых, у меня был опыт в разработке 25+ лет, причем, на достаточно объемных проектах, причем, с нуля, с формирования архитектуры. Во-вторых, брали на бэкенд, причем, самый глубокий. Под разработку на платфрме IBM i которую в РФ знает очень ограниченное количество людей (и все они сосредоточены в альфе, райфе, росбанке и еще паре-тройке компаний). Т.е. интересовало не знание каких-то фреймворков, а способоность быстро и глубоко вникнуть в особенности платформы (а она очень особенная, с виндой и никсами общего очень и очень мало) и уметь писать эффективный код под высоконагруженные системы (сейчас это порядка 3млрд изменений бд в сутки и постоянно растет).
В общем, был разговор «за жизнь» с теми, с кем сейчас работаю без каких-либо синтетических тестов.
А потом 3 месяца испытательный срок, фактически обучение и проверка «сработаемся — не сработаемся».
Губится не только производительность. Губятся подходы к разработке.
Модный нынче тренд — фреймворки. Важно освоить очередной фреймворк, а что скрывается под ним никого не интересует.
В результате когда все это начинает тормозить, или давать не тот результат, которого ожидали, все списывается на фреймворк — «он так работает, мы с этим ничего не можем поделать».
Количество (в процентном соотношении) разработчиков, способных заглянуть по фреймворк, разобраться с особенностями API той платформы, под которую ведется разработка и использовать их для разработки высокопропроизводительной системы, стремительно падает.
Насколько крупна контора где вы работаете? И как часто вам приходитт на доработку сратый код, написанный кем-то другим?
За себя скажу — ведущий разработчик в альфа-банке. На бэкенде, причем, самом глубоком — команда ядровых функций АБС.
Как думаете, могу я тут сказать «а я выбираю дельфи»? Нет, не могу. Потому что ее тут нет. Вся АБС написана на RPG на платформе IBM i. И немного на С/С++ Ну еще часть на CL. И именно это определяет выбор инструмента.
И то, что я дорабатываю сегодня, во-первых, будет поддерживаться командой сопровождения, а потом попадет на доработку кому-то. Может мне, а может кому-то еще. Но все оно должно работать. Стабильно, надежно, эффективно и несмотря ни на что.
до этого работал в небольшой конторке (хотя проект был серьезный — система мониторинга инженерного оборудования зданий, строилось все это как распределенная гетерогенная система на микроядерной архитектуре — моя час была как раз разработка микроядра, которое обеспечивало связь всех остальных узлов системы — прмконтроллеров, интерфейсных клиентов между собой). Там да — я мог сам выбирать на чем писать, какие технологии использовать. И это был хороший опыт. Писал, кстати, на 6-м билдере.
Но там была одна ситуация, здесь совсем другой масштаб и совсем другие подходы.
Зависит от. Экономия ресурсов железа обеспечивает стабильность работы его при больших нагрузках. Игнор оптимизации чреват факапами в периоды пиковых нагрузок. Где-то на это плюют, а где-то это приводит к очень ощутимому ущербу, как репутационному, так и материальному.
Последний случай — сбой в работе Альфа Банка 27-го декабря. Но там все реально сложно было предсказать. Хотя можно, конечно… Технические подробности рассказать не могу, да и слишком сложно это объяснить тем, кто не в курсе как оно все работает. Так что поверьте на слово — проблема была именно в недостаточной оптимизации (и работы в этом направлении будут выполнены и выводы на будущее будут сделаны). Хотя здесь к этому вопросу подход более чем серьезный. Но именно вот этого момента не учли.
кобол тоже не уйдет до тех пор, пока работает написанное на нем огромной количество кода в финансовой сфере.
Но сравнивать его с дельфи некорректно поскольку кобол достаточно специализированный язык, заточенный на выполнение финансовых рассчетов. И тут он имеет свои преимущества, про что уже писалось
Тут отчасти маркетинг. Котлин дает большую прибыль даже при средней квалификации разработчика. Только и всего.
На самом деле, по достижении некоторого уровня и опыта перейти с одного языка на другой или с одной платформы на другую совсем не так сложно как кажется поначалу. Устрицы…
Ну не знаю… У нас с этим сильно строго. И по надежности и по нагрузке.
Загрузка серверов мониторится постоянно, регулярно аудиты проводятся по потреблению ресурсов. Те задачи, что крутятся в фоне постоянно без нагрузочного тестирования вообще в бой не уходят.
И в промавтоматизации (точнее, близкой к ней области — система мониторинга инженерного оборудования заданий) работал долго. Там тоже все жестко было и по надежности и по таймингам. И все очень просто — плилетела посылка — не успел в таймаут уложиться — все, удаленная сторона считает что ты не получил. Идет перепосылка. После трех перепосылок считается что ты умер, разрыв сессии, реконнект и опять все сначала. Поставить систему колом можно на раз-два просто неоптимальным кодом.
А плохо работающую систему никто не купит, пойдут к конкурентам.
Там речь о CL — Command Language в AS/400. Системный язык, часть команд (полный референс порядка 2300 страниц в pdf) может использоваться в интерактиве в терминальной сессии, но можно и программы писать на нем (что характерно, программа на CL компилируется командой того же CL).
Вообще, попасть на хорошее собеседование та еще удача, как я понял. И, опять же, иногда если не прошел через собеседование, то думаешь — вот и слава богу что не прошел. Не хочу я тут работать.
Было у меня такое один раз…
Ситуации бывают разные. Одно дело, когда развлекательный сайт тормозит — ну тормозит и бог с ним по большому счету
А вот когда встает некое производство т.к. в системе уравления компоненты начинают по таймауту отваливаться из-за неоптимального в каком-то месте кода или у банка в период пиковой нагрузки из-за одного неоптимального модуля на несколько часов встает процессинг пластика по всей стране — это уже совсем другое дело. Тут уже бизнесу по карману бьет.
По большому счету опыт разработчика в том и есть, чтобы понимать, какой кусок кода можно сделать побыстрее, но чтобы работало, а какой надо вылизать до блеска котовых причиндалов чтобы не просто работало, но работало максимально быстро.
Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
И там тоже вопрос был в оптимизации одного модуля.
Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
В нашем случае от этого два барьера — во-первых, в очень сомнительном случае предлагается не штат, а стажировка на полгода (20 часов в неделю, т.е. условно полставки). Часто такой вариант бывает интересен студентам старших курсов.
По результатам стажировки уже предлагается или переход в штат (возможно до окончания стажировки), или… Просто окончание стажировки за которой не последовало никаких предложений.
В любом случае, каждый новый сотрудник берется с испытательным сроком в три месяца. Зарплата на испытательном сроке полная, но плюшки типа ДМС и страхования НС не оформляются.
На испытательный срок ставятся конкретные цели. Фактически это срок обучения (напомню — платформа очень специфическая, готовых спецов по ней найти малореально). К концу срока человек уже должен уметь решать несложные (ну так скажем, типовые) боевые задачи (и иметь уже одну-две поставки, хотя бы на уровне бизнес тестирования).
По окончании срока оценка, там уже решается будет человек работать дальше здесь или нет.
Собственно говоря, я к тому, что «конвеерное тестирование» на собеседовании путем раздачи тестовых заданий решение очень простое (для HR), но в качестве фильтра далеко не самое лучшее.
Один вчерашний студент почитал пару страниц stackoverflow и написал некий «продукт». Протестировал его в стиле «вроде сразу не упало — значит работает»
Другой вчерашний студент почитал пару страниц stackoverflow и настроил прод так что «вроде не падает».
Юниттесты? Не, не слышали — зачем это надо, оно и так работает, мамой клянусь!
Оптимизация? Да нафига время тратить — оно и так работает.
Нагрузочное тестирование? А что это такое? А зачем? Походу само понятно станет.
Вот именно. Я могу рассказать про различные подходы обмена данными между процессами (от тривиальной многопоточки до гетерогенных распределенных систем), сейчас могу рассказать про некоторые аспекты эффективного кода под AS/400 (с учетом особенности работы групп активации, ресурсоемкости работы с USRSPC по сравнению с DTAARA) и т.п… Но вот тот же баблосорт реально не вспомню на память :-)
Бывают и ошибки, конечно. Второй кандидат, тоже из недавних, на собеседовании полный восторг и радужные надежды, а сейчас вопросы — что с ним делать дальше. То ли попытаться найти подход, то ли распрощаться.
Ценность… Очень цельная система. В нее встроено все — БД (DB2), компиляторы языков (CL, COBOL, RPG, C/C++). Очень нравится концепция ILE (Integrated Language Environment) — исполняемая программа может быть собрана из модулей, каждый из которых написан на разных языках. У нас широко используется RPG и C/C++. В рамках одной программы можно писать часть функций на RPG, часть на C/C++ и все это будет работать, главное правильно интерфейсы прописать.
Очень много концепций, которые просто не имеют аналогов в других системах. Те же группы активации в рамках процесса (JOB'а). Много не имеющих аналогов системных объектов типа DTAARA, USRSPC, DTAQUE, USRIDX и т.п.
Сситема изначально объектно-оринтированная. Т.е. основной постулат — «все есть объект». причем, заложено все это на самом глубинном уровне.
Ну и производительность… Тестовый сервер — это SMT8 процессор на 18 ядер, 1800Гб оперативки, два SSD дисковых массива 87 и 15 Тб.
На боевых серверах стоит 4 «книжки» по 4 12-ядерных SMT8 процессора (т.е. в сумме 192 ядра, каждое из которых работает в 8 потоков).
И при всем этом очень жесткие требования к оптимизации кода. Есть целый список «нефункциональных требований» как нужно делать и как делать нельзя. Ну и те задачи, что много работают в фоне, обязательно проходят нагрузочное (помимо компонентного, интеграционного и бизнес) тестирование. А там могут вернуть с замечениями типа:
Т.е. решение некоторых задач требует некоторой изворотливости ума и придумывания хитрых алгоритмов Например, замена order by по неиндексированным полям в sql запросе на предварительное занесение результатов выборки в автосортируемый по нужному ключу массив может дать выигрыш по времени в 5-6 раз. Или разделение запроса на несколько частей с использованием высокоселективной предвыборки с использованием частотного словаря вместо агрегатной listagg в запросе как-то позволило сократить время работы процедуры с 3 сек до 150-200мсек :-)
Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
Взяли стажером на полгода. Через три месяца уже посовещались и перевели в штат. Ибо прогресс невообразимый. Первые задачи мы решали просто за него. Ну то есть разжевывали как и с какой строны браться, человек сидел и старательно ушами хлопал. Но потом вгрызался в тему и добивал до победного. И все, что ему хоть раз говорили, все оседало в голове, устаканивалось там и потом шло в дело. Сейчас уже вполне самостоятельный разработчик, коммуникативный, пройдет еще год и будет классным спецом в своей области.
Но на любом формальном тесте посыпался бы в том время. только в разговоре смогли потенциал разглядеть.
В общем, был разговор «за жизнь» с теми, с кем сейчас работаю без каких-либо синтетических тестов.
А потом 3 месяца испытательный срок, фактически обучение и проверка «сработаемся — не сработаемся».
Модный нынче тренд — фреймворки. Важно освоить очередной фреймворк, а что скрывается под ним никого не интересует.
В результате когда все это начинает тормозить, или давать не тот результат, которого ожидали, все списывается на фреймворк — «он так работает, мы с этим ничего не можем поделать».
Количество (в процентном соотношении) разработчиков, способных заглянуть по фреймворк, разобраться с особенностями API той платформы, под которую ведется разработка и использовать их для разработки высокопропроизводительной системы, стремительно падает.
За себя скажу — ведущий разработчик в альфа-банке. На бэкенде, причем, самом глубоком — команда ядровых функций АБС.
Как думаете, могу я тут сказать «а я выбираю дельфи»? Нет, не могу. Потому что ее тут нет. Вся АБС написана на RPG на платформе IBM i. И немного на С/С++ Ну еще часть на CL. И именно это определяет выбор инструмента.
И то, что я дорабатываю сегодня, во-первых, будет поддерживаться командой сопровождения, а потом попадет на доработку кому-то. Может мне, а может кому-то еще. Но все оно должно работать. Стабильно, надежно, эффективно и несмотря ни на что.
до этого работал в небольшой конторке (хотя проект был серьезный — система мониторинга инженерного оборудования зданий, строилось все это как распределенная гетерогенная система на микроядерной архитектуре — моя час была как раз разработка микроядра, которое обеспечивало связь всех остальных узлов системы — прмконтроллеров, интерфейсных клиентов между собой). Там да — я мог сам выбирать на чем писать, какие технологии использовать. И это был хороший опыт. Писал, кстати, на 6-м билдере.
Но там была одна ситуация, здесь совсем другой масштаб и совсем другие подходы.
Последний случай — сбой в работе Альфа Банка 27-го декабря. Но там все реально сложно было предсказать. Хотя можно, конечно… Технические подробности рассказать не могу, да и слишком сложно это объяснить тем, кто не в курсе как оно все работает. Так что поверьте на слово — проблема была именно в недостаточной оптимизации (и работы в этом направлении будут выполнены и выводы на будущее будут сделаны). Хотя здесь к этому вопросу подход более чем серьезный. Но именно вот этого момента не учли.
Но сравнивать его с дельфи некорректно поскольку кобол достаточно специализированный язык, заточенный на выполнение финансовых рассчетов. И тут он имеет свои преимущества, про что уже писалось
https://habr.com/ru/company/ruvds/blog/467251/
https://habr.com/ru/company/ruvds/blog/467253/
В дельфе этого нет. Как нет и такого количества кода, который было бы так дорого заменить на что-то еще.
На самом деле, по достижении некоторого уровня и опыта перейти с одного языка на другой или с одной платформы на другую совсем не так сложно как кажется поначалу. Устрицы…