Система интересная, но она не учитывает занятость. Один человек с тремя навыками не сможет делать три задачи одновременно, а трое людей смогут. Поэтому недостаточно иметь, условно, аналитика с навыками девопса, это вам никак не поможет параллельно делать аналитику и деплоить, потому что человек будет занят чем-то одним.
В целом же, если говорить о России, у бизнесов просто денег нет в современной ситуации, так что вакансии не закрываются в первую очередь не по вине плохих процессов.
Кажется как будто рынок полон бэкендерами с экспертизой по куберу, RabbitMQ/Kafka, умеющими отлично в PG, docker, пишущими отличный код, <вставить свою экспертизу>, ...
Конечно, полон, ведь ИИ в резюме им пишет именно так :)
Так и в описанных мной ситуациях те, кто это всё проектировал и писал, уверены, что у них по красоте :)
Профессионалы инфоцыганщиной обычно не занимаются
Понятно. Книги пишут только посредственные графоманы, поэтому хорошей профессиональной литературы не существует. Клепманн тоже не профессионал, раз книгу написал. И вообще, кому нужны эти тупые книги? Комментаторы на Хабре лучше знают.
Кажется, ежегодно на Хабре возникает всплеск обсуждений в духе: "Вы всё делали неправильно, общепринятые подходы это говно, их авторы дураки, а я сейчас расскажу вам, как надо". И хоть кто-нибудь из критиков Мартина выпустил бы книжку-бестселлер с феноменальным разрушением старых подходов, но что-то дальше комментариев в интернете дело так и не дошло.
А потом приходишь на работу в любой энтерпрайз, а там легаси-процедурщина с зацеплением, протечками, отсутствием моделирования, и погружение нового разработчика в домен занимает почему-то два года.
Так а что нужно делать на Го по вашему мнению в сложном домене? Анемичные модели и процедурный код? Чтобы каждый сервис имел 20 зависимостей, а инвариант любой сущности можно было сломать где угодно?
Кубер это чисто техническая тулза. Сложная, да, но не с доменной точки зрения. Модели в среднестатистическом электронном документообороте будут по поведению и машине состояний в разы сложнее, чем модели в кубере.
В том то и дело, что ООП это буквально высокоуровневая надстройка над средствами менеджмента данных, которая позволяет заниматься бизнес-моделированием и немного забить на техническую часть (то, как именно данные хранятся и передаются). Есть задачи, где ООП удобен, и в бизнесе таких задач полно. Зачем нести туда не-ООП язык? Ради моды?
Появление альтернативных прочтений какого-то подхода не делает автоматически всё остальное устаревшим. Придумали, как совместить функциональщину с DDD, это круто, и наверняка находит свои места применения. Но всерьёз говорить о полной замене классического подхода это примерно то же самое, что считать, будто с появлением грузовых автомобилей больше не нужны легковые. Просто конкретно вы, как я понимаю, противник ООП, имеете право, но превращать отрицание ООП в максиму всё-таки не стоит.
А вообще, приходите на какую-нибудь крупную конференцию с докладом DDD made functional. Во-первых, тема интересная, и многие с удовольствием послушают и поучаствуют в обсуждении. Во-вторых, защитите свои продвинутые архитектурные и технологические знания и утрёте нос закостенелым адептам старья вроде меня. В-третьих, там сразу и на софт-скиллы посмотрим )
Так это не в мигрантах дело. Просто бизесы стали тащить Го в энтерпрайз со сложным доменом, ну потому что все ведь пишут на Го, значит и нам надо. И Авито переходит с C# на Go, переписывая тот бизнес, для которого был выбран C#. Результат понятен, но это же не разработчики решили так делать.
Ну это какое-то зумерское изобретение вы описываете. "Нео-DDD" для разработки в функциональном стиле. Вот у Ханонова книга 2022 года по DDD вполне опирается на Эванса.
C# самый DDDшный язык, там очень много средств, которые будто специально сделаны для чистой архитектуры и развитого ООП-моделирования (тот же уровень доступа internalили всякие ковариантные/контрвариантные дженерики).
Что касается Go, то определённая дисциплина от разработчика будет нужна, конечно. Но не сказал бы, что прям принципиально невозможно, и, если берёшь Go, нужна обязательно анемичная процедурщина с высоким зацеплением.
В целом всё по делу, но я бы сказал, что у вас сейчас юзкейс почти буквально делает только orders.Save. В моей практике на уровне Application всегда объявляли DTO для запроса и ответа. Соответственно на вход в юзкейс приходит десериализованный createOrderRequest, а все маппинги и вызовы фабрик как раз в юзкейсе.
Получается, что мощные модели ИИ теперь что-то вроде ядерного оружия. Ими можно нанести много ущерба, но ресурсы на их создание есть только у крупных объединений людей типа мегакорпораций и государств. Впрочем, конкретно с ИИ всем миром скинулись американцам на главенство в этой сфере, но, как и с ядеркой, до какого-то уровня эта технология распространится, и будет «ИИ-сдерживание».
Есть ещё один интересный DD в контексте использования ИИ: а именно DDD. В одной компании, где я работал, была часть кода в виде неструктурированного легаси, и с ней ИИ справлялся очень плохо. Плохо находил ошибки, плохо рефакторил, плохо добавлял фичи. Стали части проекта переписывать на DDD, и оказалось что такой энциклопедически правильный формат, прям как по книжкам, ИИ тащит очень круто.
Обсуждали это с коллегами и пришли к такому выводу: помимо просто в целом более понятной структуры кода (которая и для людей понятнее), конкретно ИИ воспринимает код как текст, и поэтому хорошие названия функций и переменных из подходов Мартина и Эванса дают заметное преимущество. Если человек в целом неплохо видит суть функции или алгоритма даже с однобуквенными названиями, то для LLM-ки функция которая называется GetValidUserDataByRaw(rawUserData) уже сама по себе содержит сильно больше информации, чем просто какое-нибудь GetData(userData)
Риск-менеджмент
Процессно в моём личном опыте в больших компаниях самая серьёзная проблема вот какая: менеджеры и без того годами игнорили техдолг и архитектуру, прося говнокодить задачи побыстрее. Но раньше у разработчиков была защита в виде того, что быстро сделанные задачи (без архитектуры и в спешке) слишком часто оказывались критически неработоспособными. А сейчас для бизнеса ИИ выглядит как волшебная таблетка: работает и ладно, чего вы лезете со своим проектированием? Уволить половину программистов и архитектора.
разбираться с кодом нет мотивации
Проблема другая: джунов перестали нанимать. Разбираться с кодом нет не мотивации, а смысла — раньше вход в профессию был понятный, сейчас нет. Если джуны не нужны, а мидлом ты без реальной практики не станешь, то лучше поискать другую профессию. И вот эту проблему особо никто не взялся решать. Если через 20-30 лет программисты ещё останутся нужны, нас ждёт исчезновение эйджизма в отрасли, потому что нанимать можно будет только стариков :)
Обошел и вопрос информационного зазеркалья, когда из каждого утюга вещают совсем не то, что видишь своими глазами.
Но это то точно проблема, которой если не сотни, то десятки лет :)
Опять какая-то инофоцыганская пропаганда. То есть раньше без ИИ люди не могли насочинять себе резюме?
Вообще не понял, как сюда прикручено инфоцыганство. Но да, раньше многие люди не могли сделать красивое резюме с хорошей структурой и грамотным текстом. Просто по той причине, что многие не умеют структурировано и грамотно писать, либо ленятся. А сейчас считайте все стали уметь.
Система интересная, но она не учитывает занятость. Один человек с тремя навыками не сможет делать три задачи одновременно, а трое людей смогут. Поэтому недостаточно иметь, условно, аналитика с навыками девопса, это вам никак не поможет параллельно делать аналитику и деплоить, потому что человек будет занят чем-то одним.
В целом же, если говорить о России, у бизнесов просто денег нет в современной ситуации, так что вакансии не закрываются в первую очередь не по вине плохих процессов.
Конечно, полон, ведь ИИ в резюме им пишет именно так :)
Так и в описанных мной ситуациях те, кто это всё проектировал и писал, уверены, что у них по красоте :)
Понятно. Книги пишут только посредственные графоманы, поэтому хорошей профессиональной литературы не существует. Клепманн тоже не профессионал, раз книгу написал. И вообще, кому нужны эти тупые книги? Комментаторы на Хабре лучше знают.
Срачики! Иногда даже не политические
Хз, девочки станут меньше покупать на вб из-за этого? Мне кажется нет. Будут просто постоянно туда-сюда включать впн.
Не ехать в отпуск? )
Кажется, ежегодно на Хабре возникает всплеск обсуждений в духе: "Вы всё делали неправильно, общепринятые подходы это говно, их авторы дураки, а я сейчас расскажу вам, как надо". И хоть кто-нибудь из критиков Мартина выпустил бы книжку-бестселлер с феноменальным разрушением старых подходов, но что-то дальше комментариев в интернете дело так и не дошло.
А потом приходишь на работу в любой энтерпрайз, а там легаси-процедурщина с зацеплением, протечками, отсутствием моделирования, и погружение нового разработчика в домен занимает почему-то два года.
DotNext, там очень любят DDD, и есть отдельное направление по F#. Кажется, попадание на обоим пунктам.
Так а что нужно делать на Го по вашему мнению в сложном домене? Анемичные модели и процедурный код? Чтобы каждый сервис имел 20 зависимостей, а инвариант любой сущности можно было сломать где угодно?
Кубер это чисто техническая тулза. Сложная, да, но не с доменной точки зрения. Модели в среднестатистическом электронном документообороте будут по поведению и машине состояний в разы сложнее, чем модели в кубере.
В том то и дело, что ООП это буквально высокоуровневая надстройка над средствами менеджмента данных, которая позволяет заниматься бизнес-моделированием и немного забить на техническую часть (то, как именно данные хранятся и передаются). Есть задачи, где ООП удобен, и в бизнесе таких задач полно. Зачем нести туда не-ООП язык? Ради моды?
Я уже апнулся до архитектора, спасибо.
Появление альтернативных прочтений какого-то подхода не делает автоматически всё остальное устаревшим. Придумали, как совместить функциональщину с DDD, это круто, и наверняка находит свои места применения. Но всерьёз говорить о полной замене классического подхода это примерно то же самое, что считать, будто с появлением грузовых автомобилей больше не нужны легковые. Просто конкретно вы, как я понимаю, противник ООП, имеете право, но превращать отрицание ООП в максиму всё-таки не стоит.
А вообще, приходите на какую-нибудь крупную конференцию с докладом DDD made functional. Во-первых, тема интересная, и многие с удовольствием послушают и поучаствуют в обсуждении. Во-вторых, защитите свои продвинутые архитектурные и технологические знания и утрёте нос закостенелым адептам старья вроде меня. В-третьих, там сразу и на софт-скиллы посмотрим )
На C# тоже всегда делал интерфейсы в слое приложения.
Так это не в мигрантах дело. Просто бизесы стали тащить Го в энтерпрайз со сложным доменом, ну потому что все ведь пишут на Го, значит и нам надо. И Авито переходит с C# на Go, переписывая тот бизнес, для которого был выбран C#. Результат понятен, но это же не разработчики решили так делать.
Транспилятор над однопоточным языком, у которого в базе вообще нет адекватного ООП, выше, чем хардкорные ООП энтерпрайз языки.
В целом понятно, вы описываете пригодность для какого-то любимого вами определённого вида переосмысления DDD, но статья всё-таки про классический.
Ну это какое-то зумерское изобретение вы описываете. "Нео-DDD" для разработки в функциональном стиле. Вот у Ханонова книга 2022 года по DDD вполне опирается на Эванса.
C# самый DDDшный язык, там очень много средств, которые будто специально сделаны для чистой архитектуры и развитого ООП-моделирования (тот же уровень доступа
internalили всякие ковариантные/контрвариантные дженерики).Что касается Go, то определённая дисциплина от разработчика будет нужна, конечно. Но не сказал бы, что прям принципиально невозможно, и, если берёшь Go, нужна обязательно анемичная процедурщина с высоким зацеплением.
В целом всё по делу, но я бы сказал, что у вас сейчас юзкейс почти буквально делает только
orders.Save. В моей практике на уровне Application всегда объявляли DTO для запроса и ответа. Соответственно на вход в юзкейс приходит десериализованныйcreateOrderRequest, а все маппинги и вызовы фабрик как раз в юзкейсе.Сейчас хэндлер толстоват, имхо.
Получается, что мощные модели ИИ теперь что-то вроде ядерного оружия. Ими можно нанести много ущерба, но ресурсы на их создание есть только у крупных объединений людей типа мегакорпораций и государств. Впрочем, конкретно с ИИ всем миром скинулись американцам на главенство в этой сфере, но, как и с ядеркой, до какого-то уровня эта технология распространится, и будет «ИИ-сдерживание».
Есть ещё один интересный DD в контексте использования ИИ: а именно DDD. В одной компании, где я работал, была часть кода в виде неструктурированного легаси, и с ней ИИ справлялся очень плохо. Плохо находил ошибки, плохо рефакторил, плохо добавлял фичи. Стали части проекта переписывать на DDD, и оказалось что такой энциклопедически правильный формат, прям как по книжкам, ИИ тащит очень круто.
Обсуждали это с коллегами и пришли к такому выводу: помимо просто в целом более понятной структуры кода (которая и для людей понятнее), конкретно ИИ воспринимает код как текст, и поэтому хорошие названия функций и переменных из подходов Мартина и Эванса дают заметное преимущество. Если человек в целом неплохо видит суть функции или алгоритма даже с однобуквенными названиями, то для LLM-ки функция которая называется
GetValidUserDataByRaw(rawUserData)уже сама по себе содержит сильно больше информации, чем просто какое-нибудьGetData(userData)Процессно в моём личном опыте в больших компаниях самая серьёзная проблема вот какая: менеджеры и без того годами игнорили техдолг и архитектуру, прося говнокодить задачи побыстрее. Но раньше у разработчиков была защита в виде того, что быстро сделанные задачи (без архитектуры и в спешке) слишком часто оказывались критически неработоспособными. А сейчас для бизнеса ИИ выглядит как волшебная таблетка: работает и ладно, чего вы лезете со своим проектированием? Уволить половину программистов и архитектора.
Проблема другая: джунов перестали нанимать. Разбираться с кодом нет не мотивации, а смысла — раньше вход в профессию был понятный, сейчас нет. Если джуны не нужны, а мидлом ты без реальной практики не станешь, то лучше поискать другую профессию. И вот эту проблему особо никто не взялся решать. Если через 20-30 лет программисты ещё останутся нужны, нас ждёт исчезновение эйджизма в отрасли, потому что нанимать можно будет только стариков :)
Но это то точно проблема, которой если не сотни, то десятки лет :)
Вообще не понял, как сюда прикручено инфоцыганство. Но да, раньше многие люди не могли сделать красивое резюме с хорошей структурой и грамотным текстом. Просто по той причине, что многие не умеют структурировано и грамотно писать, либо ленятся. А сейчас считайте все стали уметь.
Точно ИИ, но видимо с дорисовкой в фотошопе. Уж надписи ИИ так хорошо не умеет пока.