Вот почему для синьоров это действительно помощник а джунам лучше не подходить пока не подрастут. Налабать mvp за вечер конечно можно, но все же продукт для рынка это не mvp для инвесторов
Как по мне, пример с код ревьбю невалиден - это работа skill и субагент здесь ни к чему. Для код ревью нет необходимости в контексте, если вы в процессе ревью добавляете новые правила, все ложится в скилл
Если честно, не читал, но заголовок удивил, а в чем отличие доменной модели в случае микросервисов и монолита? Почему она вообще зависит от того как вы диплоити свое приложение?
Ради смеха дал задание клоду, парни вы до сих пор глазами смотрите, пора заканчивать
Правильный ответ — Е. Всё перечисленное. Все пять пунктов (А, Б, В, Г, Д) — реальные проблемы в этом черновике. Разберу по порядку, почему каждая ломает проект.
А. Циклическая зависимость common-dto ↔ common-events
common-dto зависит от common-events, а common-events зависит от common-dto. Maven при reactor-сборке такое просто не разрулит — упадёт с ошибкой «The projects in the reactor contain a cyclic reference». Логически тоже бессмыслица: DTO должны быть листовым модулем без зависимостей на доменные события, а события могут использовать DTO (но не наоборот). Лечится разделением: события зависят от DTO, точка.
Б. Захардкоженные версии в дочерних pom
В user-service явно прописано <version>3.5.14</version> для spring-boot-starter-web, в модулях libs — <version>1.0.0</version> для внутренних зависимостей. При обновлении Spring Boot придётся идти по всем пяти сервисам руками. Версии должны жить в <dependencyManagement> родителя, а дочерние pom’ы указывают только groupId/artifactId.
В. spring-boot-maven-plugin в модуле libs
Это и есть причина «No main manifest attribute». Плагин пытается собрать executable jar и ищет главный класс, а в библиотеке его нет. spring-boot-maven-plugin должен подключаться только в сервисах, никогда в общих библиотеках. Иначе библиотеку ещё и нельзя нормально использовать как зависимость — fat jar для этого не годится.
Г. Нет <dependencyManagement> в корневом pom
Прямое следствие пункта Б. Без секции управления зависимостями каждый модуль сам решает, какую версию подтянуть, и через полгода получаешь разъезжающиеся версии Jackson, Spring, валидаторов. BOM Spring Boot (spring-boot-dependencies) надо импортировать через <dependencyManagement> с <scope>import</scope>, а свои внутренние модули прописать туда же с одной версией.
Д. Корневой pom смешивает роли агрегатора и родителя
Это менее очевидная, но архитектурно важная ошибка. Сейчас platform/pom.xml одновременно:
наследует spring-boot-starter-parent (родитель)
содержит <modules> (агрегатор)
от него наследуется user-service
Из-за этого все сервисы автоматически получают конфигурацию spring-boot-starter-parent, включая spring-boot-maven-plugin, и библиотеки тоже наследуют её через цепочку. Правильнее разделить: отдельный platform-parent (только <dependencyManagement>, <pluginManagement>, properties — никаких <modules>) и отдельный platform-aggregator (только <modules>, без наследников). Сервисы наследуются от parent, агрегатор просто запускает reactor-сборку.
Бонусом, чего ещё не хватает в этом черновике, но что обычно сразу прикручивают: maven-enforcer-plugin для запрета захардкоженных версий и дубликатов, flatten-maven-plugin если будете публиковать модули, и единый property вроде <revision> для версионирования всего монорепы одной строкой.
Я использую Claude и я в шоке, он пишет код и код работает, но пишет хреново, а если попросить его пофиксить баг в каком нибудь легаси, то здесь затык, лучше этого не делать. Наверное поэтому одного вайбкодинга недостаточно, для mvp - вполне, но не для прода, здесь пока у людей есть шансы
У меня с одним и тем же ВПН на телефоне работает, на планшете нет, так что думаю там посложнее проблема. Причем пару дней Джемини и на планшете работала
А на проще через впн с ним работать, по крайней мере я использую его в проектах прямо из IDE, так можно ему кодовую базу скормить и интерактивно править если будут рекомендации
Т. Е. Парни нахирачили мемори ликов и вместо чтобы их чинить перезапускают jvm - хитро :) но не ново, первый гард которого я помню был в борландовской бд, уж не помню как она называлась
Не знаю как насчёт вайбкодинга, у меня была мысль попробовать, но как то со временем никак, но есть опыт немного другого плана, но мне кажется очень похоже, даёшь задание, смотришь на результат, поправляешь и новая итерации и так пока не получится то чо хочется,. Так вот я хотел составить брошюру по своей новой машине, читать 300 с лишним страниц не хотелось, а что то действительно нужно можно пропустить если читать по диагонали. Так вот есть gemini pro, кормил ей pdf ник и попросил сделать конспект где будут перечилины действия как сделать, ссылка на картинку если есть и английская цитата из брошюры. Казалось просто, но ничего не получилось, я так и не добился конспект по всей брошюре, а потом она перешла на украинский. Так что мне кажется тоже будет и с вайбкодингом, попробую как нибудь если время будет, а пока юнит тесты пусть пишет, с этим пока вроде норм
кесарю кесарево, java - это энтерпрайз, там она хороша и никакой раст там не нужен. Попробуйте налабать на расте какой нибудь банковский проект и сравните насколько позже вы выкатите mvp по сравнению с java
Могу сказать из своего опыта чего не может ии - предложить другое решение проблемы, он будет предлагать решения пытаясь поправить конкретную проблему, но не подумает что можно сделать тоже самое, но другим способом.
Может надо было распилить монолит для начала? И на самом деле интересно какая предметная область? Если телеком, ну может быть в каких то случаях rust, но для обычного энтерпрайза мне кажется перебор
Вот почему для синьоров это действительно помощник а джунам лучше не подходить пока не подрастут. Налабать mvp за вечер конечно можно, но все же продукт для рынка это не mvp для инвесторов
Воо
Как по мне, пример с код ревьбю невалиден - это работа skill и субагент здесь ни к чему. Для код ревью нет необходимости в контексте, если вы в процессе ревью добавляете новые правила, все ложится в скилл
Если честно, не читал, но заголовок удивил, а в чем отличие доменной модели в случае микросервисов и монолита? Почему она вообще зависит от того как вы диплоити свое приложение?
Ради смеха дал задание клоду, парни вы до сих пор глазами смотрите, пора заканчивать
Правильный ответ — Е. Всё перечисленное. Все пять пунктов (А, Б, В, Г, Д) — реальные проблемы в этом черновике. Разберу по порядку, почему каждая ломает проект.
А. Циклическая зависимость common-dto ↔ common-events
common-dtoзависит отcommon-events, аcommon-eventsзависит отcommon-dto. Maven при reactor-сборке такое просто не разрулит — упадёт с ошибкой «The projects in the reactor contain a cyclic reference». Логически тоже бессмыслица: DTO должны быть листовым модулем без зависимостей на доменные события, а события могут использовать DTO (но не наоборот). Лечится разделением: события зависят от DTO, точка.Б. Захардкоженные версии в дочерних pom
В
user-serviceявно прописано<version>3.5.14</version>дляspring-boot-starter-web, в модулях libs —<version>1.0.0</version>для внутренних зависимостей. При обновлении Spring Boot придётся идти по всем пяти сервисам руками. Версии должны жить в<dependencyManagement>родителя, а дочерние pom’ы указывают толькоgroupId/artifactId.В. spring-boot-maven-plugin в модуле libs
Это и есть причина «No main manifest attribute». Плагин пытается собрать executable jar и ищет главный класс, а в библиотеке его нет.
spring-boot-maven-pluginдолжен подключаться только в сервисах, никогда в общих библиотеках. Иначе библиотеку ещё и нельзя нормально использовать как зависимость — fat jar для этого не годится.Г. Нет
<dependencyManagement>в корневом pomПрямое следствие пункта Б. Без секции управления зависимостями каждый модуль сам решает, какую версию подтянуть, и через полгода получаешь разъезжающиеся версии Jackson, Spring, валидаторов. BOM Spring Boot (
spring-boot-dependencies) надо импортировать через<dependencyManagement>с<scope>import</scope>, а свои внутренние модули прописать туда же с одной версией.Д. Корневой pom смешивает роли агрегатора и родителя
Это менее очевидная, но архитектурно важная ошибка. Сейчас
platform/pom.xmlодновременно:наследует
spring-boot-starter-parent(родитель)содержит
<modules>(агрегатор)от него наследуется
user-serviceИз-за этого все сервисы автоматически получают конфигурацию spring-boot-starter-parent, включая
spring-boot-maven-plugin, и библиотеки тоже наследуют её через цепочку. Правильнее разделить: отдельныйplatform-parent(только<dependencyManagement>,<pluginManagement>, properties — никаких<modules>) и отдельныйplatform-aggregator(только<modules>, без наследников). Сервисы наследуются от parent, агрегатор просто запускает reactor-сборку.Бонусом, чего ещё не хватает в этом черновике, но что обычно сразу прикручивают:
maven-enforcer-pluginдля запрета захардкоженных версий и дубликатов,flatten-maven-pluginесли будете публиковать модули, и единый property вроде<revision>для версионирования всего монорепы одной строкой.Я использую Claude и я в шоке, он пишет код и код работает, но пишет хреново, а если попросить его пофиксить баг в каком нибудь легаси, то здесь затык, лучше этого не делать. Наверное поэтому одного вайбкодинга недостаточно, для mvp - вполне, но не для прода, здесь пока у людей есть шансы
У меня с одним и тем же ВПН на телефоне работает, на планшете нет, так что думаю там посложнее проблема. Причем пару дней Джемини и на планшете работала
Синхронизацию команд, когда чтобы решить ночной критический баг на проде вам нужно разбудить 5 тимлидов соседних команд.
Я только не понял чем здесь поможет монолит, те-же 5 команд будут пилить тот-же код только он будет называться модуль а не сервис
А на проще через впн с ним работать, по крайней мере я использую его в проектах прямо из IDE, так можно ему кодовую базу скормить и интерактивно править если будут рекомендации
Какими мы все красивыми в молодости были :)
Т. Е. Парни нахирачили мемори ликов и вместо чтобы их чинить перезапускают jvm - хитро :) но не ново, первый гард которого я помню был в борландовской бд, уж не помню как она называлась
Я бы вспомнил философиия java, книга с которой я начал изучать язык
Не знаю как насчёт вайбкодинга, у меня была мысль попробовать, но как то со временем никак, но есть опыт немного другого плана, но мне кажется очень похоже, даёшь задание, смотришь на результат, поправляешь и новая итерации и так пока не получится то чо хочется,. Так вот я хотел составить брошюру по своей новой машине, читать 300 с лишним страниц не хотелось, а что то действительно нужно можно пропустить если читать по диагонали. Так вот есть gemini pro, кормил ей pdf ник и попросил сделать конспект где будут перечилины действия как сделать, ссылка на картинку если есть и английская цитата из брошюры. Казалось просто, но ничего не получилось, я так и не добился конспект по всей брошюре, а потом она перешла на украинский. Так что мне кажется тоже будет и с вайбкодингом, попробую как нибудь если время будет, а пока юнит тесты пусть пишет, с этим пока вроде норм
Во-во
кесарю кесарево, java - это энтерпрайз, там она хороша и никакой раст там не нужен. Попробуйте налабать на расте какой нибудь банковский проект и сравните насколько позже вы выкатите mvp по сравнению с java
Могу сказать из своего опыта чего не может ии - предложить другое решение проблемы, он будет предлагать решения пытаясь поправить конкретную проблему, но не подумает что можно сделать тоже самое, но другим способом.
Ну прям страшно за будущее программеров :)
Может надо было распилить монолит для начала? И на самом деле интересно какая предметная область? Если телеком, ну может быть в каких то случаях rust, но для обычного энтерпрайза мне кажется перебор
В РФ она не будет работать, только через впн, хотя я не вижу для себя необходимости покупать ultimate версию, community вполне достаточно
А в андроид нет поддержки FFM API? Начиная с 17 java уже не надо париться с jni
Нобелевская премия по экономике не существует, банкиры обиделись что их Нобель обделили и придумали свою премию, но назвали её Нобелевской