Раньше писали более верхнеуровневую спецификацию, которая оставляла разработчику достаточно много свободы для реализации. Ну например раньше точно не было границ транзакций или описания агрегатов. Теперь часть спецификации пишет разработчик. Так как не каждый аналитик тянет эти детали пока что. В целом конечно граница между аналитиком и разработчиком размывается. А ну и может быть забыл упомянуть вся специкация лежит в том же репозитории и публикуется на doc-as-code платформе. Достаточно удобно получается.
Да на что вы столько тратите? Пользую codex за 20$ и мне хватает. Да периодически в лимиты утыкаюсь, но использую это время как раз чтобы подумать, что нагенерила модель и пишу замечания и будущий рефакторинг. Опять же часть приходится делать самому в любом случае, так как не все задачи хорошо вайбкодятся.
Так а в чем проблема просто на тред пулах это сделать было? Каждый запрос на "отдельный поток" отдаёте и получаете тоже самое. На небольшом кол-ве запросов кол-во тредов будет небольшим. Там даже vt не требуются. Если нагрузки нет какой смысл использовать webflux?
Может тогда прям в статье это отразить? Просто видел проект на работе на webflux на 10 rps. Весь в граблях и костылях. Смотреть на это просто больно. И я кажется знаю почему там взяли webflux, приложение ходило в 3 сервиса по http параллельно.
Сравнениюе на самом деле не совсем корректное. Применимость, сложность разработки/поддержки, входа разная у синхронного и асинхронного кода. Поэтому может и нет смысла их сравнивать. Синхронный уместно применять в сложных сервисах, где есть бизнес логика. Если бизнес логики практически нет, но есть потребность выжать максимум из железа, то логично будет применить асинхронный подход. Но тут опять же стоит несколько раз подумать будет ли эта экономия на ресурсах оправдана при возросшей сложности.
А так в целом и так понятно что event loop в лоб всегда будет быстрее работать чем vt.
Нет разбора кейса где взаимодействует несколько aggregate root. Не всегда бизнес кейсы ложатся в один aggregate root. Иначе довольно простой кейс перевод денег превращает в корень все счета. Мы обычно используем доменные сервисы для таких кейсов в пакете domain. В целом описано хорошо в Learning Domain-Driven Design.
А тут похоже уже деваться некуда. Придётся приспасабливаться. Иначе отстать можно так что в лоу перформеры запишут.
Сейчас пробуем на работе такой подход. Пишем по сути очень подробную спеку в которой раскладываем модель, все инварианты поведения. Механизмы взаимодействия компонентов. И дальше уже по этой спеке генерим код. На выходе будет спека, код, тесты по спеке. Проект с одной стороны небольшой, с другой домен и бизнес правила достаточно сложные.
Ну в компании могут поднять свою модель тот же qwen. Железо конечно дорогое, но не космических денег стоит.
Так же есть вариант с корпоративным проксированием и затиранием секретов перед запросом в модель.
Ну и опять же чтобы воспользоваться секретом его нужно ещё достать оттуда и потом как то получить сетевой доступ до инфраструктуры где он используется.
Помню когда то мне предлагали возглавить альфатим в неткрекере. Команду которая будет тушить пожары за джунами студентами. Мне тогда уже эта идея не понравилась. Делать правки в сложном домене в котором не работаешь очень сложно и рискованно. За тобой уже никто не проревюит. Поэтому как мне кажется эта идея провальна. Разработка будет буксовать и останавливаться слишком часто. А выиграют в итоге те кто сохранит экспертизу в командах и не поддастся сиюминутному желанию срезать косты. Поэтому на мой взгляд пока не будет создан ии который думает примерно как человек, может в голове крутить абстракции, а не просто по предыдущему тексту выводить следующий, идея эта о обречена на провал.
Ну я привел просто пример. Не все проблемы решаются общеизвестными практиками. Очень часто проблемы специфичные для твоего кейса и нужно подумать чтобы их решить. А не просто известное решение подставить. Собственно решение багов ту да же. И каким образом это можно только спекой решить мне не понятно. Нужен качественно иной ии, для таких задач. И скорее всего это не llm. Но вот проверить спеку на логичность, сделать процесс разработки проще вполне такой инструмент может. Идея в целом мне нравится.
А теперь давайте представим ситуацию. Спеку создали всё ок. Но llm сгенерила код с проблемой n+1. Через какое-то время заметили что всё тормозит. Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать? Идея всё таки кажется утопичной в плане генерации по этой спеке кода.
Но в целом как инструмент спецификации может быть интересно. Идея ввести универсальный язык, и попросить llm следить чтобы спека была непротиворечива. Это прямо топ идея. Опять же просто просить проверять на соответствие спеку и код, может быть очень полезным. Поэтому думаю в целом может получится очень хороший инструмент
Да программировать не нужно учиться, лол. Первый затык в claude который будет ходить по кругу и выдумывать все более нелепые решения для проблемы несовместимости библиотеки и что дальше?
Да есть у меня и подписка платная и codex настроен. И опыт у меня есть 15 лет. И позиция у меня техлид/тимлид. Поэтому в состоянии оценить этот шлак который модель выдаёт на мои запросы. Понятно что если ей всё разжевать объяснить и показать пример как делать, она сделает. Да только смысл то какой от этого? Мне уже реально надоедает сидеть нянчиться с ней. Времени уходит часто больше на работу с ней чем без неё.
Одного не могу понять. Как увеличение 1 2 1 и уменьшение вследствие этого количества времени на выполнение работы может что то улучшить в работе компании. Я сам тимлмд и стараюсь сократить коммуникации чтобы дать людям спокойно сделать свою работу и это работает)
Ну так а чего не заставить тех агентов хотя-бы написать это нормальное по?) Или это всё байки?) Я честно говоря немного разочаровался в ии. Ничего вразумиткльного даже самые последние модели на рабочих проектах показать не могут. Да какие то простые проекты могут написать, но чуть посложнее проект и толку от них 0.
Раньше писали более верхнеуровневую спецификацию, которая оставляла разработчику достаточно много свободы для реализации. Ну например раньше точно не было границ транзакций или описания агрегатов. Теперь часть спецификации пишет разработчик. Так как не каждый аналитик тянет эти детали пока что. В целом конечно граница между аналитиком и разработчиком размывается. А ну и может быть забыл упомянуть вся специкация лежит в том же репозитории и публикуется на doc-as-code платформе. Достаточно удобно получается.
Так мой комментарий и относится к физику, он жалуется что у него половина дохода на нейронки уходит.
.
Да на что вы столько тратите? Пользую codex за 20$ и мне хватает. Да периодически в лимиты утыкаюсь, но использую это время как раз чтобы подумать, что нагенерила модель и пишу замечания и будущий рефакторинг. Опять же часть приходится делать самому в любом случае, так как не все задачи хорошо вайбкодятся.
Ну да с кем не бывало. Ну поэтому и нужно описывать кейсы применимости как мне кажется, чтобы из пушки по воробьям не стреляли
Так а в чем проблема просто на тред пулах это сделать было? Каждый запрос на "отдельный поток" отдаёте и получаете тоже самое. На небольшом кол-ве запросов кол-во тредов будет небольшим. Там даже vt не требуются. Если нагрузки нет какой смысл использовать webflux?
Может тогда прям в статье это отразить? Просто видел проект на работе на webflux на 10 rps. Весь в граблях и костылях. Смотреть на это просто больно. И я кажется знаю почему там взяли webflux, приложение ходило в 3 сервиса по http параллельно.
Но в целом статья хорошая, спасибо!
Сравнениюе на самом деле не совсем корректное. Применимость, сложность разработки/поддержки, входа разная у синхронного и асинхронного кода. Поэтому может и нет смысла их сравнивать. Синхронный уместно применять в сложных сервисах, где есть бизнес логика. Если бизнес логики практически нет, но есть потребность выжать максимум из железа, то логично будет применить асинхронный подход. Но тут опять же стоит несколько раз подумать будет ли эта экономия на ресурсах оправдана при возросшей сложности.
А так в целом и так понятно что event loop в лоб всегда будет быстрее работать чем vt.
Нет разбора кейса где взаимодействует несколько aggregate root. Не всегда бизнес кейсы ложатся в один aggregate root. Иначе довольно простой кейс перевод денег превращает в корень все счета. Мы обычно используем доменные сервисы для таких кейсов в пакете domain. В целом описано хорошо в Learning Domain-Driven Design.
А тут похоже уже деваться некуда. Придётся приспасабливаться. Иначе отстать можно так что в лоу перформеры запишут.
Сейчас пробуем на работе такой подход. Пишем по сути очень подробную спеку в которой раскладываем модель, все инварианты поведения. Механизмы взаимодействия компонентов. И дальше уже по этой спеке генерим код. На выходе будет спека, код, тесты по спеке. Проект с одной стороны небольшой, с другой домен и бизнес правила достаточно сложные.
Посмотрим как получится.
Ну в компании могут поднять свою модель тот же qwen. Железо конечно дорогое, но не космических денег стоит.
Так же есть вариант с корпоративным проксированием и затиранием секретов перед запросом в модель.
Ну и опять же чтобы воспользоваться секретом его нужно ещё достать оттуда и потом как то получить сетевой доступ до инфраструктуры где он используется.
Помню когда то мне предлагали возглавить альфатим в неткрекере. Команду которая будет тушить пожары за джунами студентами. Мне тогда уже эта идея не понравилась. Делать правки в сложном домене в котором не работаешь очень сложно и рискованно. За тобой уже никто не проревюит. Поэтому как мне кажется эта идея провальна. Разработка будет буксовать и останавливаться слишком часто. А выиграют в итоге те кто сохранит экспертизу в командах и не поддастся сиюминутному желанию срезать косты. Поэтому на мой взгляд пока не будет создан ии который думает примерно как человек, может в голове крутить абстракции, а не просто по предыдущему тексту выводить следующий, идея эта о обречена на провал.
Ну я привел просто пример. Не все проблемы решаются общеизвестными практиками. Очень часто проблемы специфичные для твоего кейса и нужно подумать чтобы их решить. А не просто известное решение подставить. Собственно решение багов ту да же. И каким образом это можно только спекой решить мне не понятно. Нужен качественно иной ии, для таких задач. И скорее всего это не llm. Но вот проверить спеку на логичность, сделать процесс разработки проще вполне такой инструмент может. Идея в целом мне нравится.
А теперь давайте представим ситуацию. Спеку создали всё ок. Но llm сгенерила код с проблемой n+1. Через какое-то время заметили что всё тормозит. Код при этом мы писать уже не умеем и вообще плохо понимаем что там под капотом работает. Дальше что делать? Идея всё таки кажется утопичной в плане генерации по этой спеке кода.
Но в целом как инструмент спецификации может быть интересно. Идея ввести универсальный язык, и попросить llm следить чтобы спека была непротиворечива. Это прямо топ идея. Опять же просто просить проверять на соответствие спеку и код, может быть очень полезным. Поэтому думаю в целом может получится очень хороший инструмент
Да программировать не нужно учиться, лол. Первый затык в claude который будет ходить по кругу и выдумывать все более нелепые решения для проблемы несовместимости библиотеки и что дальше?
А может перенайм после ковида? Там вон горбик такой неплохой
Да есть у меня и подписка платная и codex настроен. И опыт у меня есть 15 лет. И позиция у меня техлид/тимлид. Поэтому в состоянии оценить этот шлак который модель выдаёт на мои запросы. Понятно что если ей всё разжевать объяснить и показать пример как делать, она сделает. Да только смысл то какой от этого? Мне уже реально надоедает сидеть нянчиться с ней. Времени уходит часто больше на работу с ней чем без неё.
Одного не могу понять. Как увеличение 1 2 1 и уменьшение вследствие этого количества времени на выполнение работы может что то улучшить в работе компании. Я сам тимлмд и стараюсь сократить коммуникации чтобы дать людям спокойно сделать свою работу и это работает)
Ну так а чего не заставить тех агентов хотя-бы написать это нормальное по?) Или это всё байки?) Я честно говоря немного разочаровался в ии. Ничего вразумиткльного даже самые последние модели на рабочих проектах показать не могут. Да какие то простые проекты могут написать, но чуть посложнее проект и толку от них 0.
Ага вместо того чтобы написать вменяемое по, будем писать вокруг агентов чтобы они все это тыкали руками. Просто гениально