Как понял из статьи проблемы в следующем: Во-первых - есть много вариантов использования - различные DSL и RunTime. Во-вторых - ну как-то все привыкли к красивому UI который может просто все - только таская кубики! Иными словами если все решат - что XML DSL хорош и аналитикам, что бы перестраивать систему его будет хватать - то обязательно найдется крутой прораммист - который докажет что XML это прошлый век (или еще там что ) - что с Main Core нужно обязательно уйти на Quarkus ! А у аналитика не хватит квалификации разобраться с кучей XML. Я к чему - просто видет большую сложную low-code систему построеную на XML DSL и Main Core - в которой все работало. Крутых програмистов и аналитиков которые не понимали XML DSL туда просто не допускали. Первый раз с ней столкнулся в 2017 году - тогда организация федерального уровня с ней жила уже давно, ну и по последнем сведеньям живет с ней до сих пор и продолжает развивать. И все там работает. Аналитики используют готовые модули или заказывают новые и перестраивают конфирурации на XML DSL как им надо.
Еще год назад продублировал свои важные репы в GitVerse. Это должно было наступить - причем в любой из сторон. Хотя GitVerse не совсем сахар с одной только сберовской авторизацией куча проблем.
Проблема в том - что да код забываешь и не за 2 года - а значительно раньше. Помнишь логику или общий подход. Программисты меняются тоже не по своей воли. Они как правило ресурс. И если у всех их будет разный подход - то операции с ресурсами становится проблематичными. Но это не самое главное. У бизнеса ну просто часто меняются требования. Причем кардинально. А за 10 лет система может претерпеть такие изменения - на одной и той же команде!!!! В видео кодеках (где я работал) и играх ситуация другая. Там стандарты годами прорабатываются не менеджерами и специалистами и нарваться на какую-то дичь из-за которой приходится систему если не на 360 или 180 градусов переделывать - то 12 или 6 раз на 30 градусов практически не реально. Поймите чистый код - это не про скорость и потребление ресурсов - а просто методика по которой можно угнаться за дичью от бизнеса.
Не посадить макаку его подерживать - а обеспечить высокую скорость внесение исправлений, при минимуме проблем которое внесет это изменение. При этом код не должен в течение 10 лет его эксплуатации стать порталом в ад. К стати если посадить макаку - то она из понятного и структурированого кода тоже портал в ад быстро сделает. Я как понял это статься относится к
В индустрии разработки игр (а может софта и вообще) живёт очень удобная идея, которой многие оправдывают лишние слои логики и абстракции.
то есть там где на ради оптимизации готовы на траты времени и готовы жертвовать обслуживаемостью кода. Да там идеи дядюшки Боба несколько опасны.
PS Я не являюсь явным поборником идеалогии Clean Code - но она должна жить. Есть проекты, где ее использования (без излишнего фанатизма) приносит реальный результат. При этом я явно против тех, кто считает если ему удалось написать вычесление факториала в 1 строку, который только он понять может и на который от потратил пару человеко-месяцев рабочего времени - то остальные просто какие-то макаки.
На Go можно так же плохо код писать. Даже скажу точно - на Go плохо писать код значительно легче. А по поводу уменьшение производительности от наследования - судя по сравнению С и С++ - то да обычный С где-то в полтора раза быстрее С++ на GNU компиляторах по крайней мере. НО !!!! Попробуй вести большой проект на том же С и сразу захочится на С++ пересесть, потому что разрабатывать на С значительно сложнее.
Помню историю, которая до сих пор для меня как эталон. Декабрь 2021-го, Log4Shell. Полночь, дежурный канал разрывается, и первый вопрос, который задаёт половина команд по всему рынку, звучит не «как пропатчить», а «а у нас вообще есть этот Log4j?».
Вопрос а почему не использовали mvn dependency:tree?
На самом деле как не проектируй, все равно если 1) через пару лет прийдет кто-то кто скажет - не спроектировано не так - я переделаю 2) разработчик скажет - да все равно - а я вот так могу 3) менеджер скажет - что вы тут в облаках летаете с архитектурой надо быстрее.... все просто привратится в BigPieceOfMud и умрет.
Вернее для этого лучше использовать, как описано в разделе "Внутренний ID и публичный ID — разные контракты" данной статьи. И внутрений ID закрепить seq базы данных. А публичный ID генерировать самому. По мне это несколько логичнее получается.
ТУСУР - Факультет систем управлений - ВУЗ который с 1971 года выпускал специалистов по квалификации инженер-программист вынужден был в 2023 и 2024 годах на эту специальность обьявлять дополнительный набор. Ну зачем идти в ВУЗ учится от 4 до 6 лет - когда есть полугодичный курсы и такие хорошие менторы! (Это сарказм - не минусуйте).
Не "ГринАтом" (ГК "РосАтом") случаем? Хотя там чуть-чуть не так - ИИ нельзя! Не чего нельзя. Но не смотря на то - что работаеш со скорость на уровне "старослужащих" показывают на дверь....
Россия всегда отличалась фундаментальной подготовкой специалистов. Это наша культура. Начнем с того что детей в школе учили складывать/умножать/делить не на калькуляторе- а в столбик. Сейчас что бы работать с AI нужно знать основы.
От этой истории у меня полное ощущение, что в команду полную бездельников наняли нормального инженера. Особенно - код в неявной логике - в которой не кто разобраться немог! Или не хотел? Или началось - вон Ваня больше получает и значит ему нужнее - мы тупо посидим покурим в сторонке - он все сделает. Проблема не в звезде - а в команде - которая отказалась тянуться за звездой. Учитываю ситуацию - что звезду взяли по причине того - что модуль ДОЛЖЕН быть написан - то разгонять нужно команду.
Я в отличии от других не стал такого делать - просто тыкал пальцем тех-лиду во все косяки предшественников, которые поступали именно так - по этому меня просто выставили.
Вот в последнее время, кроме проблемы с ИИ я сталкиваюсь еще с проблемой полной некомпентецией некоторых коллег, которые они прикрывают уверенным высказыванием бредовых идей. А тут ИИ который хоть говорит разумно. Может проверить - задал вопрос "Как изменится производительность разработчика в первый и 10 год проекта, если не было контроля архитектуры на проекте и была частая смена разработчиков" - Google AI - получил развернутый ответ. А вот руководящий состав и кадровые специалисты ГК "ГринАтом" (это IT компания "РосАтом") уверено считают, что если при старте проекта за 3 месяца разработчик делал 30 задач средней сложности - то через 10-15 лет - при смене 6 или 7 внешних фирм разработчиков (ну через аукционны крупные дороботки делали - кто дешевле - то и кодит) и текучки (много комитов от уже не существуещих людей, я должен не только выполнить эту норму и перевыполнить. Так что не чего на ИИ тут жаловаться.
Если был проектный характер работ (к стати в нем манипуляторы и плодятся) - то 8 компаний с 2013 года - это норма. Даже если не считать, когда тебя взяли и просто перевели с одной компании в другую.
Как понял из статьи проблемы в следующем: Во-первых - есть много вариантов использования - различные DSL и RunTime. Во-вторых - ну как-то все привыкли к красивому UI который может просто все - только таская кубики! Иными словами если все решат - что XML DSL хорош и аналитикам, что бы перестраивать систему его будет хватать - то обязательно найдется крутой прораммист - который докажет что XML это прошлый век (или еще там что ) - что с Main Core нужно обязательно уйти на Quarkus ! А у аналитика не хватит квалификации разобраться с кучей XML. Я к чему - просто видет большую сложную low-code систему построеную на XML DSL и Main Core - в которой все работало. Крутых програмистов и аналитиков которые не понимали XML DSL туда просто не допускали. Первый раз с ней столкнулся в 2017 году - тогда организация федерального уровня с ней жила уже давно, ну и по последнем сведеньям живет с ней до сих пор и продолжает развивать. И все там работает. Аналитики используют готовые модули или заказывают новые и перестраивают конфирурации на XML DSL как им надо.
Еще год назад продублировал свои важные репы в GitVerse. Это должно было наступить - причем в любой из сторон. Хотя GitVerse не совсем сахар с одной только сберовской авторизацией куча проблем.
Проблема в том - что да код забываешь и не за 2 года - а значительно раньше. Помнишь логику или общий подход. Программисты меняются тоже не по своей воли. Они как правило ресурс. И если у всех их будет разный подход - то операции с ресурсами становится проблематичными. Но это не самое главное. У бизнеса ну просто часто меняются требования. Причем кардинально. А за 10 лет система может претерпеть такие изменения - на одной и той же команде!!!! В видео кодеках (где я работал) и играх ситуация другая. Там стандарты годами прорабатываются не менеджерами и специалистами и нарваться на какую-то дичь из-за которой приходится систему если не на 360 или 180 градусов переделывать - то 12 или 6 раз на 30 градусов практически не реально. Поймите чистый код - это не про скорость и потребление ресурсов - а просто методика по которой можно угнаться за дичью от бизнеса.
Не посадить макаку его подерживать - а обеспечить высокую скорость внесение исправлений, при минимуме проблем которое внесет это изменение. При этом код не должен в течение 10 лет его эксплуатации стать порталом в ад. К стати если посадить макаку - то она из понятного и структурированого кода тоже портал в ад быстро сделает. Я как понял это статься относится к
то есть там где на ради оптимизации готовы на траты времени и готовы жертвовать обслуживаемостью кода. Да там идеи дядюшки Боба несколько опасны.
PS Я не являюсь явным поборником идеалогии Clean Code - но она должна жить. Есть проекты, где ее использования (без излишнего фанатизма) приносит реальный результат. При этом я явно против тех, кто считает если ему удалось написать вычесление факториала в 1 строку, который только он понять может и на который от потратил пару человеко-месяцев рабочего времени - то остальные просто какие-то макаки.
На Go можно так же плохо код писать. Даже скажу точно - на Go плохо писать код значительно легче. А по поводу уменьшение производительности от наследования - судя по сравнению С и С++ - то да обычный С где-то в полтора раза быстрее С++ на GNU компиляторах по крайней мере. НО !!!! Попробуй вести большой проект на том же С и сразу захочится на С++ пересесть, потому что разрабатывать на С значительно сложнее.
Напиши аналог minio на Go и Java и тогда сравнивай. Оба сервиса должны быть написаны на коленке для обьективного сравнения.
Помню историю, которая до сих пор для меня как эталон. Декабрь 2021-го, Log4Shell. Полночь, дежурный канал разрывается, и первый вопрос, который задаёт половина команд по всему рынку, звучит не «как пропатчить», а «а у нас вообще есть этот Log4j?».
Вопрос а почему не использовали mvn dependency:tree?
На самом деле как не проектируй, все равно если 1) через пару лет прийдет кто-то кто скажет - не спроектировано не так - я переделаю 2) разработчик скажет - да все равно - а я вот так могу 3) менеджер скажет - что вы тут в облаках летаете с архитектурой надо быстрее.... все просто привратится в BigPieceOfMud и умрет.
Вернее для этого лучше использовать, как описано в разделе "Внутренний ID и публичный ID — разные контракты" данной статьи. И внутрений ID закрепить seq базы данных. А публичный ID генерировать самому. По мне это несколько логичнее получается.
Сколько нужно женщин, чот бы ребенок родился не через 9, а через 1 месяц?
ТУСУР - Факультет систем управлений - ВУЗ который с 1971 года выпускал специалистов по квалификации инженер-программист вынужден был в 2023 и 2024 годах на эту специальность обьявлять дополнительный набор. Ну зачем идти в ВУЗ учится от 4 до 6 лет - когда есть полугодичный курсы и такие хорошие менторы! (Это сарказм - не минусуйте).
Не "ГринАтом" (ГК "РосАтом") случаем? Хотя там чуть-чуть не так - ИИ нельзя! Не чего нельзя. Но не смотря на то - что работаеш со скорость на уровне "старослужащих" показывают на дверь....
Россия всегда отличалась фундаментальной подготовкой специалистов. Это наша культура. Начнем с того что детей в школе учили складывать/умножать/делить не на калькуляторе- а в столбик. Сейчас что бы работать с AI нужно знать основы.
От этой истории у меня полное ощущение, что в команду полную бездельников наняли нормального инженера. Особенно - код в неявной логике - в которой не кто разобраться немог! Или не хотел? Или началось - вон Ваня больше получает и значит ему нужнее - мы тупо посидим покурим в сторонке - он все сделает. Проблема не в звезде - а в команде - которая отказалась тянуться за звездой. Учитываю ситуацию - что звезду взяли по причине того - что модуль ДОЛЖЕН быть написан - то разгонять нужно команду.
Ну да автору надо было по идее в экономисты идти......
Похоже разумные менеджеры попались. Поняли, что это не саботаж - а просто попытки выполнить свою работу качественно.
Я в отличии от других не стал такого делать - просто тыкал пальцем тех-лиду во все косяки предшественников, которые поступали именно так - по этому меня просто выставили.
Вот в последнее время, кроме проблемы с ИИ я сталкиваюсь еще с проблемой полной некомпентецией некоторых коллег, которые они прикрывают уверенным высказыванием бредовых идей. А тут ИИ который хоть говорит разумно. Может проверить - задал вопрос "Как изменится производительность разработчика в первый и 10 год проекта, если не было контроля архитектуры на проекте и была частая смена разработчиков" - Google AI - получил развернутый ответ. А вот руководящий состав и кадровые специалисты ГК "ГринАтом" (это IT компания "РосАтом") уверено считают, что если при старте проекта за 3 месяца разработчик делал 30 задач средней сложности - то через 10-15 лет - при смене 6 или 7 внешних фирм разработчиков (ну через аукционны крупные дороботки делали - кто дешевле - то и кодит) и текучки (много комитов от уже не существуещих людей, я должен не только выполнить эту норму и перевыполнить. Так что не чего на ИИ тут жаловаться.
А почему нет 3 вопроса - Я участвовал в краже кода?
Если был проектный характер работ (к стати в нем манипуляторы и плодятся) - то 8 компаний с 2013 года - это норма. Даже если не считать, когда тебя взяли и просто перевели с одной компании в другую.