Именно аналоги. Pattern — шаблон. Но Паттерн звучит умнее и многозначительнее.
Поверьте, знаю много людей, которые собаку съели на проектировании. Но от всех этих «паттернов» их корежит. И обратное — люди, щеголяющие умными «паттернами», но которых очень легко поставить в тупик любым нестандартным вопросом, не укладывающимся в схему — в ответ начинается поток «умных слов», лишенный какой-либо конкретики.
Спасибо, не надо :-) Я начинал когда еще нортона не было и работали только в командой строке, так что документацию читаю свободно.
Но использовать заимствования там, где есть русские аналоги считаю дурным тоном. И еще более дурным тоном считаю напичкивание речи «умными словами». Как правило, такие люди сами затрудняются пояснить что именно они хотели сказать.
Работая программистом много много лет ничего не ответил бы на эти вопросы.
Аналогично.
Паттерны когда-то читал но все забыл, потому что не помогали.
Паттерны — это вообще что? Переведите на русский. Вообще, когда человек начинает сыпать заимствованиями, у меня лично сразу возникает сомнение в его компетентности.
Хочется ответить в стиле
Высочайшие достижения нейтронной мегалоплазмы! Ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания…
Ну вот у нас есть программы стажировок. Студентов старших курсов берут стажерами на 20 часов в неделю на полгода. На полставки.
Потом, если возникает взаимный интерес, человека приглашают в штат уже готовым специалистом.
Но у нас специфика — разработчиков, знающих RPG и AS/400 в России крайне мало. Так что в любом случае приходится готовить. Так что любой при приеме на работу первые три месяца проходит обучение — сначала тестовые задачи, потом несложные боевые (или околобоевые — допустим кому-то надо что-то вспомогательное сделать — дают).
Написать на листочке простенькую программу на коболе, постоянно заглядывая в учебник несложно.
А вот ту же программу собрать и запустить на, к примеру, сервере AS/400 общаясь с ним через эмулятор терминала IBM5250 — это уже посложнее будет. Еще сложнее будет понять что делают эти несколько тысяч строк на коболе и почему они работают не так быстро как хочется.
S/360-370 это ведь то, из чего вырос современный IBM z?
Сейчас имею удовольствие работать с их параллельной веткой — линейкой S/36-38 AS/400, ныне IBM i. Тоже ни на что не похожая платформа. Со множеством особенностей в которые надо вникнуть чтобы писать надежно и эфективно.
Для любителей «освоить за вечер» простенький тест — зарегистрироваться на PUB400 — получите 300мб дискового пространства и две личных библиотеки. TN5250 можно бесплатно скачать с сайта IBM (Access i Client Solution — целый пакет). Установив и настроив его (это совсем просто, фактически, когда есть логин и пароль к серверу там просто надо создать конфигурацию введя адрес сервера, остальное оно само сделает).
После этого попробуйте написать, собрать и запустить под отладчиком Hello Word на любом из доступных в ILE языков — COBOL, RPG, CL, C/C++.
Все средства от редактора до компилятора и отладчика там есть. Прям в составе ОС.
Дальше можно попробовать создать простенькую табличку с хотя бы одним индексом и простенький интерфейс для добавление, редактирования записей и вывода их на печать.
Гарантирую много интересных открытий на этом пути :-)
Кстати, да. Последние года три для AS/400 пишу — архизанятная система. Чем глубже в нее влажу, те больше нравится. Но не суть.
Суть в том, что там огромное количество сущностей, абсолютно чуждых миру винтов и никсов. Аналогов которым нет ни там ни там. А сущности эти часто основополагающие — без их понимания (не знания, а именно понимания) можно на ровном месте наплодить изрядное количество багов, часть из которых далеко не всегда проявятся в тесте.
Честно говоря, из своего опыта, я даже не уверен что проблема там в коболе как таковом. Это может быть что-то платформенное.
Но чтобы решить эту проблему нужно переписать часть кода. Который на коболе.
Ну вот как пример из нашей практики. В режиме пиковой нагрузки одна из таблиц значительно разрослась и, совершенно неожиданно, время на аллокацию дополнительного простраства при добавлении новых записей подскочило в 100 раз (в сто раз!!!) что привело к существенному замедлению всей работы. И это в условиях пика!
Чтобы система вообще не встала сопровождение было вынужденно отключить один из модулей (временно, до выяснения проблемы). В результате в течении пары часов не проходили расчеты по пластиковым картам. В масштабах страны, между прочим.
Ситуацию поправили сначала временным решением, потом внесли изменения в код.
Вполне возможно, что там ситуация ну если не подобная, то носит схожий характер — надо где-то что-то переписать более оптимально. Но на коболе. Который для этого желательно знать не по краткому курсу, а на опыте реального использования.
Честно говоря, для меня все зависит от человека. Вот не так двано. Два новых разработчика. Один… Ну полный ноль. Только после института, да еще и не профильный (т.е. техническое, но не информатика). Второй доучивается, но вроде как какой-то опыт разработки имеет.
На собеседовании первого взяли со вздохом — нужно было человека. Взяли стажером, на подставки.
Второй произвел впечатление — берем-берем-берем.
Первый — чистый лист. поначалу даже алгоритмического мышления нет. Первые учебные задачи с ним разжевывали до азов. Но. Все что ему хоть раз сказали, все откладывается в голове. В результате стремительный прогресс, через три месяца безоговорочно в штат (хотя стажировка на полгода была). Сейчас чуть больше полугода прошло — уже вполне самостоятельный разработчик. Вдумчивый, аккуратный, основательный.
А со вторым… Все еще вопросы. Есть какая-то лихость — быстро слабать и скинуть. В результате сплошные возвраты на доработку. Все еще нужно кодревью делать и опекать.
Так что все от человека… Я скорее буду просто разговаривать, без замороченых тестов. Мне лично это больше даст чем формальное тестирование. Ибо завалить можно практически любого — ну вот скажите мне, чем опасна группа активации *CALLER в программе, создающей временную таблицу в QTEMP :-)
И тонкости поведения локальных, глобальных, статических переменных и файловых дескрипторов с разных типа групп активации (*NEW, *CALLER, именованых).
Это вопросы, которые для меня актуальны. Ибо там есть неочевидные тонкости, которые могут приводить к падению программы. А для большинства тут это просто набор слов.
Так что еще раз — нормальный человек с правильным устройством мозгов. Остальное на месте впитает. Было бы куда.
Ну трудно от студента требовать чтобы он на уровне подсознания в голове держал столько разных разностей. Понятно, что с опытом некоторые вещи становятся очевидными, но не сходу.
В данноом случе «обновить что-то» не получится. Там все на коболе. Ну или 80-90%. А тут речь о том что «почему бы не переписать это на нормальном языке». Так вот переписывать придется все.
И не стоит думать что служба по учету безработных сильно проще банковского ПО. Уверен, что не проще. И не меньше по объему обрабатываемых данных. И ее нельзя вот так взять и остановить «подождите пока перепишем».
И требования по надежности там не меньше.
Так что мой пост просто как пример того, что просто так системы такого масштаба не переписываются. Очень затратно.
И тут речь ведь не о том, что оно не работает. А о том, что оно не справляется с пиковой нагрузкой. Т.е. требуется не просто переписать, требуется оптимизировать. А это само по себе непростая задача. Обычно сначала проводится аудит (у нас для этого вызывают спецом из IBM). Аудиторы проводят нагрузочные исследования, выявляют наиболее ресурсоемкие участки кода, а потом уже разработчики морщат мозг на тем как это можно сделать эффективнее.
Сам иногда такими вещами занимаюсь — у нас целый список задач на оптимизацию в беклоге висит, как время от текучки чуть освободилось, берем в работу.
Вчитайтесь внимательно — там требуется оптимизация работающей системы. А оптимизация требует достаточно глубокого знания языка и платформы на которой система работает (в рамках привычной мне AS/400 это к примеру понимание что быстрее и ресурсоэффективнее *DTAARA или *USRSPC, *DTAQ или *USRQ или как избежать лишнего переоткрытия файлов путем кеширования файловых дескрипторов — на RPG, на котором написан код, к примеру, это так просто не решить, надо писать на C + RECIO, а это уже знание двух языков + некоторое понимание внутренностией AS/400). А это уже не «хороший программист, освоивший язык за один день».
Что можно освоить — я знаю. Проходил через это. Но вот получить опыт, пригодный для решения задач по оптимизации нужно время. Это именно опыт работы с конкретной системой.
Так вот, там был абзац в конце, который сюда не попал:
К числу причин, по которым организации не спешат отказываться от COBOL и переходить программы, созданные при помощи актуальных языков программирования – это дороговизна обновления. На своем примере это доказал Банк содружества Австралии, решившийся на полную замену всех приложений, написанных на COBOL.
Представители банка сообщили, что переход на новое ПО занял пять лет – он проходил в период с 2012 по 2017 гг. Размер затрат на это крупномасштабное мероприятие известен – апдейт обошелся банку почти в $750 млн.
Вот вам масштабы. Можете сравнить это с тем, с чем сталкивались Вы.
Как разработчик в банке могу вам сказать что подобная операция потребует
1. Немалого количества человеко-часов работы аналитиков для проработки FSD.
2. Огромного количества человеко-часов работы разработчиков для реализации всего этого в коде — количество строк кода, работающего на банковских серверах я лично затрудняюсь оценить количественно даже примерно, а качественно оцениваю как очень-очень-очень дофига.
3. Опять аналитики — любое, самое минимальное изменение в коде требует ретеста. Тестирование ПО проходит в несколько этапов — компонентное (соответствие кода требованиям FSD), бизнес (соответствие FSD+реализации заданию на разработку от бизнеса), интеграционное (непротиворечивость различных компонентов системы друг другу, отсутствие конфликтов и паразитных влияний), нагрузочное (потребление ресурсов и поведение в условиях пиковых нагрузок).
Ну и последнее — внедрение. Банк штука такая — его невозможно становить даже на час «подождите, мы тут ПО обновляем». Так что все это должно внедряться или путем постепенной замены элементов действующей системы или включением параллельной системы, получением подтверждения что она на 100% повторяет работу старой, незаметным для пользователя переключением на нее и потом вывода из эксплуатации новой старой системы.
Это огромная нагрузка на сопровождение и поддержку.
В общем, масштаб затрат (времени, денег, ресурсов) ту колоссальный. И просто так на это никто не подпишется. Это не отдельный сайт, который можно положить на час-два-три и кроме недовольства пользователей ничего не будет.
Ну не знаю… Может быть, конечно, но мне не кажется что таких позиций будет много и они будут хорошо оплачиваться.
В моем понимании человек, способный писать хороший код, не требующи постоянного кодревью, — это уже скрее мидл. А джун ближе к печатной машинке с голосовым управлением.
Ну вроде как у тех, кто к этой кухне близок, есть предположения как это могло быть сделано. Часть уязвимостей уже прикрыли, ведется поиск более радикальных решений по улучшению безопасности.
Поверьте, знаю много людей, которые собаку съели на проектировании. Но от всех этих «паттернов» их корежит. И обратное — люди, щеголяющие умными «паттернами», но которых очень легко поставить в тупик любым нестандартным вопросом, не укладывающимся в схему — в ответ начинается поток «умных слов», лишенный какой-либо конкретики.
Но использовать заимствования там, где есть русские аналоги считаю дурным тоном. И еще более дурным тоном считаю напичкивание речи «умными словами». Как правило, такие люди сами затрудняются пояснить что именно они хотели сказать.
Аналогично.
Паттерны — это вообще что? Переведите на русский. Вообще, когда человек начинает сыпать заимствованиями, у меня лично сразу возникает сомнение в его компетентности.
Хочется ответить в стиле
(с)
Ну и далее по тексту…
Потом, если возникает взаимный интерес, человека приглашают в штат уже готовым специалистом.
Но у нас специфика — разработчиков, знающих RPG и AS/400 в России крайне мало. Так что в любом случае приходится готовить. Так что любой при приеме на работу первые три месяца проходит обучение — сначала тестовые задачи, потом несложные боевые (или околобоевые — допустим кому-то надо что-то вспомогательное сделать — дают).
А вот ту же программу собрать и запустить на, к примеру, сервере AS/400 общаясь с ним через эмулятор терминала IBM5250 — это уже посложнее будет. Еще сложнее будет понять что делают эти несколько тысяч строк на коболе и почему они работают не так быстро как хочется.
Сейчас имею удовольствие работать с их параллельной веткой — линейкой S/36-38 AS/400, ныне IBM i. Тоже ни на что не похожая платформа. Со множеством особенностей в которые надо вникнуть чтобы писать надежно и эфективно.
Для любителей «освоить за вечер» простенький тест — зарегистрироваться на PUB400 — получите 300мб дискового пространства и две личных библиотеки. TN5250 можно бесплатно скачать с сайта IBM (Access i Client Solution — целый пакет). Установив и настроив его (это совсем просто, фактически, когда есть логин и пароль к серверу там просто надо создать конфигурацию введя адрес сервера, остальное оно само сделает).
После этого попробуйте написать, собрать и запустить под отладчиком Hello Word на любом из доступных в ILE языков — COBOL, RPG, CL, C/C++.
Все средства от редактора до компилятора и отладчика там есть. Прям в составе ОС.
Дальше можно попробовать создать простенькую табличку с хотя бы одним индексом и простенький интерфейс для добавление, редактирования записей и вывода их на печать.
Гарантирую много интересных открытий на этом пути :-)
Суть в том, что там огромное количество сущностей, абсолютно чуждых миру винтов и никсов. Аналогов которым нет ни там ни там. А сущности эти часто основополагающие — без их понимания (не знания, а именно понимания) можно на ровном месте наплодить изрядное количество багов, часть из которых далеко не всегда проявятся в тесте.
Но чтобы решить эту проблему нужно переписать часть кода. Который на коболе.
Ну вот как пример из нашей практики. В режиме пиковой нагрузки одна из таблиц значительно разрослась и, совершенно неожиданно, время на аллокацию дополнительного простраства при добавлении новых записей подскочило в 100 раз (в сто раз!!!) что привело к существенному замедлению всей работы. И это в условиях пика!
Чтобы система вообще не встала сопровождение было вынужденно отключить один из модулей (временно, до выяснения проблемы). В результате в течении пары часов не проходили расчеты по пластиковым картам. В масштабах страны, между прочим.
Ситуацию поправили сначала временным решением, потом внесли изменения в код.
Вполне возможно, что там ситуация ну если не подобная, то носит схожий характер — надо где-то что-то переписать более оптимально. Но на коболе. Который для этого желательно знать не по краткому курсу, а на опыте реального использования.
На собеседовании первого взяли со вздохом — нужно было человека. Взяли стажером, на подставки.
Второй произвел впечатление — берем-берем-берем.
Первый — чистый лист. поначалу даже алгоритмического мышления нет. Первые учебные задачи с ним разжевывали до азов. Но. Все что ему хоть раз сказали, все откладывается в голове. В результате стремительный прогресс, через три месяца безоговорочно в штат (хотя стажировка на полгода была). Сейчас чуть больше полугода прошло — уже вполне самостоятельный разработчик. Вдумчивый, аккуратный, основательный.
А со вторым… Все еще вопросы. Есть какая-то лихость — быстро слабать и скинуть. В результате сплошные возвраты на доработку. Все еще нужно кодревью делать и опекать.
Так что все от человека… Я скорее буду просто разговаривать, без замороченых тестов. Мне лично это больше даст чем формальное тестирование. Ибо завалить можно практически любого — ну вот скажите мне, чем опасна группа активации *CALLER в программе, создающей временную таблицу в QTEMP :-)
И тонкости поведения локальных, глобальных, статических переменных и файловых дескрипторов с разных типа групп активации (*NEW, *CALLER, именованых).
Это вопросы, которые для меня актуальны. Ибо там есть неочевидные тонкости, которые могут приводить к падению программы. А для большинства тут это просто набор слов.
Так что еще раз — нормальный человек с правильным устройством мозгов. Остальное на месте впитает. Было бы куда.
Ну трудно от студента требовать чтобы он на уровне подсознания в голове держал столько разных разностей. Понятно, что с опытом некоторые вещи становятся очевидными, но не сходу.
И не стоит думать что служба по учету безработных сильно проще банковского ПО. Уверен, что не проще. И не меньше по объему обрабатываемых данных. И ее нельзя вот так взять и остановить «подождите пока перепишем».
И требования по надежности там не меньше.
Так что мой пост просто как пример того, что просто так системы такого масштаба не переписываются. Очень затратно.
И тут речь ведь не о том, что оно не работает. А о том, что оно не справляется с пиковой нагрузкой. Т.е. требуется не просто переписать, требуется оптимизировать. А это само по себе непростая задача. Обычно сначала проводится аудит (у нас для этого вызывают спецом из IBM). Аудиторы проводят нагрузочные исследования, выявляют наиболее ресурсоемкие участки кода, а потом уже разработчики морщат мозг на тем как это можно сделать эффективнее.
Сам иногда такими вещами занимаюсь — у нас целый список задач на оптимизацию в беклоге висит, как время от текучки чуть освободилось, берем в работу.
Что можно освоить — я знаю. Проходил через это. Но вот получить опыт, пригодный для решения задач по оптимизации нужно время. Это именно опыт работы с конкретной системой.
Один из аспектов описывался тут:
habr.com/ru/company/ruvds/blog/467251
habr.com/ru/company/ruvds/blog/467253
Из современных (по крайней мере развивающихся ныне) языков наиболее близок RPG.
Статья эта — перепечатка, давно уже по сети гуляет. Я в первый раз столкнулся с ней на CNews — www.cnews.ru/news/top/2020-04-07_ssha_izza_koronavirusa_ponadobilis
Так вот, там был абзац в конце, который сюда не попал:
Вот вам масштабы. Можете сравнить это с тем, с чем сталкивались Вы.
Как разработчик в банке могу вам сказать что подобная операция потребует
1. Немалого количества человеко-часов работы аналитиков для проработки FSD.
2. Огромного количества человеко-часов работы разработчиков для реализации всего этого в коде — количество строк кода, работающего на банковских серверах я лично затрудняюсь оценить количественно даже примерно, а качественно оцениваю как очень-очень-очень дофига.
3. Опять аналитики — любое, самое минимальное изменение в коде требует ретеста. Тестирование ПО проходит в несколько этапов — компонентное (соответствие кода требованиям FSD), бизнес (соответствие FSD+реализации заданию на разработку от бизнеса), интеграционное (непротиворечивость различных компонентов системы друг другу, отсутствие конфликтов и паразитных влияний), нагрузочное (потребление ресурсов и поведение в условиях пиковых нагрузок).
Ну и последнее — внедрение. Банк штука такая — его невозможно становить даже на час «подождите, мы тут ПО обновляем». Так что все это должно внедряться или путем постепенной замены элементов действующей системы или включением параллельной системы, получением подтверждения что она на 100% повторяет работу старой, незаметным для пользователя переключением на нее и потом вывода из эксплуатации новой старой системы.
Это огромная нагрузка на сопровождение и поддержку.
В общем, масштаб затрат (времени, денег, ресурсов) ту колоссальный. И просто так на это никто не подпишется. Это не отдельный сайт, который можно положить на час-два-три и кроме недовольства пользователей ничего не будет.
Может быть потому что у самого уже давно привычка объявлять локальные переменные большого размера типа d2 как static.
Ну а вообще-то размер стека настравивается опциями линкера
В моем понимании человек, способный писать хороший код, не требующи постоянного кодревью, — это уже скрее мидл. А джун ближе к печатной машинке с голосовым управлением.