Я с вами согласен! Но поди загрузи в голову такой крупный проект. Я почитал документацию в проекте, в ней есть проблема (я не критикую, заранее скажу, что у вас очень продвинутый воркфлоу работы со спеками для агентов) - документация расчитана на агентов.
Так как я тоже пишу с агентами в большой enterprise проекте, у меня накопился опыт перехода по всему градиенту от на 100% с ИИ до на 100% руками. Документация, написанная ИИ для ИИ отличается своей "ссылочностью". То есть она в описании отсылает к признакам за границей спецификации, перекрестным упоминаниям. Вот небольшая цитата из https://github.com/nv-lang/nova/blob/main/spec/decisions/05-memory.md
Никаких ~T, ~&T, ~weak префиксов. Программист пишет логику, GC делает остальное. Никаких &T / mut &T borrow — передача объекта = передача указателя в managed heap, copy/move не нужны.
Типичный артефакт создания документации через чат с агентом. Он пишет не только то что делать нужно, а то что не нужно. В сумме получилась не модель памяти, а облако тегов, отсылок, сравнений, часть из которых шум, резко снижающий уровень конкретики.
Это хорошо для LLM - эдакой болтливой базы данных, но плохо для человека, который физически не сможет по этой документации собрать целостную картину понимания и перейти к кодингу. Люди пишут для себя документацию иначе. По текущей доке разработчик поймет вашу задумку, как применять, но не как разрабатывать.
Я желаю вашему проекту удачи и с удовольствием почитаю новые статьи о вашем опыте!
На мой взгляд, проблема не в том на каком масштабе ломаются агенты, а где сломается процесс если агентов вдруг не станет. Если единственный способ поддержки и разработки агенты - это вечный пет проект. В таком случае, перестают быть важны выкрутасы со спеками, просто будем ждать ту модель, чей вендор даст гарантии качества.
Несмотря на здравомысле подхода, принятие его компаниями скорее исключение, чем правило. На практике он чаще используется самими программистами, которые к нему приходят опытным путем, в то время как руководители пытаются формлировать метрики, а-ля, "сколько кода мы теперь производим с ИИ", "с какой скоростью мы теперь отстреливаем фичи". В остальном, как я говорил в статье, если пушить даже хорошо зарекомендованные подходы работы с ИИ, получается обратный результат.
Я вам больше скажу: ИИ код писал, ревьюил, подходы и процессы придумывал, на грабли наступал, опыт получал, в команду внедрял, скилы создавал, на гитхаб выкладывал, потом статью на хабр написал и ИИ-агентом редактировал, но… был вычислен, теперь всё клоду под хвост ))
Спасибо большое! Обязательно попробуйте скилы, всем кому давал на пробу, тащатся от процесса, когда агент заставляет реально думать, что вы собираетесь сделать и отвечать на сложные вопросы, не пряча их за простотой "волшебной" генерации.
А я на этом дерьме написал проект на 100К строк. Миддлвару использовал только для CSP. Она там вообще чисто чтоб было, а проку ноль. Rest маршруты тупо декорировал функциями с логированием, авторизацией и прочими делами. А вот с тем, как код пересекает границу сервер-клиент я дофига проблем словил. Так что второй раз пожалуй ни для чего серьезного я nextjs не возьму
Вы рассуждаете по ООП-шному и как будто хотите склеить два разноплановых подхода ООП-шными принципами.
Я примерно понимаю на чем стоит ваша аргументация, поправьте если я неправ, что применение FoodMenuClient.live() дефолтным значением аргумента плохо тем, что о существовании live имплементации становится известно модулю (не классу) и он начинает от нее зависеть. В этом нет никакой проблемы, так как в сниппетах кода из статьи конечно же не полный production-grade пример как скомпоновать зависимости. Полная картина может быть несколько сложнее, но принцип тот же. В ней не используются классовые View, Presenter, Interactor или что там еще можно придумать в качестве ООП-like архитектуры.
Любая высокоабстрактная ООП архитектура в итоге заканчивается классами с реализацией, но создает неповоротливость, большое кол-во бойлерплейта. В функциональном мире, созданию абстракций отводится меньше значения так как атомарность логики компенсирует связность, не требует сложных подходов к подмене имплементаций, инъекции зависимостей и тд. То есть формально передача зависимости аргументом функции это тоже DI, но инъекция через аннотацию всё таки на другой стороне архитектурного спектра.
При таком проектировании, всё исходит из идеи, что View - функция от State (что и представляет собой Compose). А State - кусочек иммутабельных данных без логики. Логика с зависимостями от компонентов с версткой отделяется созданием двухэтажных компонент: FoodMenuLogicComposable + FoodMenuLayoutComposable. К этому прилагается тонкая View модель реагирующая на события и обрабатывающая их в Клиентах. Вот и вся архитектура. Под клиентами может быть масса других частей: кеши, база, неворкинг и тд и тп скрытых под своими клиентами. Компонуются плюс-минус тем же способом по принципу фрактала - множество треугольничков имеют похожую форму, но в составной объект может принимать любые формы. То есть при необходимости перекомпоновки под новые требования атомарные компоненты перекомпонуются на раз-два.
Суть DI заключается в разрыве прямой связи между реализациями сущностей, что достигается прокидыванием зависимостей в объект извне самого объекта.
Разрыв связи, о котором вы пытаетесь сказать это Dependency Inversion. Суть его в том, чтобы изменить направление зависимости: Получатель зависимости зависит от ее абстракции, а не реализации.
Инъекция зависимости к этому не имеет отношения. В примере зависимость закрыта своим интерфейсом и создается за пределами объекта-приемника, с масштабируемостью тут никаких проблем нет. А вот создавать единый граф и протягивать его сквозь приложение - подход действительно плохой, по той же причине, по которой андроидеры ругаются на глобальные объекты предлагаемые SDK.
Чтобы понять и верно построить архитектуру в принципах, о которых говорит автор, нужно придерживаться нескольких правил: модуляризация всего, зависимости без состояния, дробление функционала сложных зависимостей на атомарные подзависимости в высококомпозируемых функциях, использование статического инстанцирования (все объекты, какие возможно в рамках здравого смысла, а таких должен быть минимум, создаются на статическими при старте приложения).
Большие кодовые базы UI (~1,5 млн строк) прекрасно живут с этим подходом. Попробуйте! Уверен, вам понравится простота, от которой поначалу будет казаться, что где-то должен быть подвох.
Это дискуссионный вопрос. Я с вами согласен, фишинг - проблема. Но фишинг - это мимикрия под то, чему вы доверяете. Вариации дизайна точно не пытаются пользователя обмануть. Если вы посмотрите на формы входа различных сервисов, вы заметите что кнопки входа через Google, Яндекс и других провайдеров соответствуют мягким гайдлайнам (тот же Яндекс предлагает варианты на выбор), но стилизованы под дизайн продукта. Мы же не говорим о проблеме фишинга авторизации гугла.
У телеги есть прописанные гайдлайны, все что не по ним это уже от лукавого
Честно говоря, не видел чтобы у телеги были какие-то ясные гайдлайны на этот счет, поделитесь ссылкой где они прописаны.
их надо уважать даже если кнопка не вписывается в ваш интерфейс
так никто не делает, просто потому что тут нечего уважать. Много iOS приложений строго следует Apple Human Interface Guidelines? Или на Андроиде все под копирку используют Material Design? Конечно нет. Если кнопка синяя с фирменным самолетиком телеграма с надписью «Войти с Telegram», этого достаточно, чтобы юзер идентифицировал функцию кнопки. А опасность фишинга меньшая из тех, что я привел в статье.
Я с вами согласен! Но поди загрузи в голову такой крупный проект. Я почитал документацию в проекте, в ней есть проблема (я не критикую, заранее скажу, что у вас очень продвинутый воркфлоу работы со спеками для агентов) - документация расчитана на агентов.
Так как я тоже пишу с агентами в большой enterprise проекте, у меня накопился опыт перехода по всему градиенту от на 100% с ИИ до на 100% руками. Документация, написанная ИИ для ИИ отличается своей "ссылочностью". То есть она в описании отсылает к признакам за границей спецификации, перекрестным упоминаниям. Вот небольшая цитата из https://github.com/nv-lang/nova/blob/main/spec/decisions/05-memory.md
Типичный артефакт создания документации через чат с агентом. Он пишет не только то что делать нужно, а то что не нужно. В сумме получилась не модель памяти, а облако тегов, отсылок, сравнений, часть из которых шум, резко снижающий уровень конкретики.
Это хорошо для LLM - эдакой болтливой базы данных, но плохо для человека, который физически не сможет по этой документации собрать целостную картину понимания и перейти к кодингу. Люди пишут для себя документацию иначе. По текущей доке разработчик поймет вашу задумку, как применять, но не как разрабатывать.
Я желаю вашему проекту удачи и с удовольствием почитаю новые статьи о вашем опыте!
Поддержал лайком! Удачи!
На мой взгляд, проблема не в том на каком масштабе ломаются агенты, а где сломается процесс если агентов вдруг не станет. Если единственный способ поддержки и разработки агенты - это вечный пет проект. В таком случае, перестают быть важны выкрутасы со спеками, просто будем ждать ту модель, чей вендор даст гарантии качества.
👏 крутая работа! Любо-дорого смотреть на такие красивые решения. Хотя последние пару лет на Swift не пишу (но скучаю), кайфую от его выразительности.
Вы проделали большую работу, но озвученная проблема кажется уже была решена тем же образом https://www.textasticapp.com
Крепкий фундамент есть, дальше можно было бы подумать над позиционированием.
Несмотря на здравомысле подхода, принятие его компаниями скорее исключение, чем правило. На практике он чаще используется самими программистами, которые к нему приходят опытным путем, в то время как руководители пытаются формлировать метрики, а-ля, "сколько кода мы теперь производим с ИИ", "с какой скоростью мы теперь отстреливаем фичи". В остальном, как я говорил в статье, если пушить даже хорошо зарекомендованные подходы работы с ИИ, получается обратный результат.
Я вам больше скажу: ИИ код писал, ревьюил, подходы и процессы придумывал, на грабли наступал, опыт получал, в команду внедрял, скилы создавал, на гитхаб выкладывал, потом статью на хабр написал и ИИ-агентом редактировал, но… был вычислен, теперь всё клоду под хвост ))
Спасибо большое! Обязательно попробуйте скилы, всем кому давал на пробу, тащатся от процесса, когда агент заставляет реально думать, что вы собираетесь сделать и отвечать на сложные вопросы, не пряча их за простотой "волшебной" генерации.
…охапка дров и плов готов!
А я на этом дерьме написал проект на 100К строк. Миддлвару использовал только для CSP. Она там вообще чисто чтоб было, а проку ноль. Rest маршруты тупо декорировал функциями с логированием, авторизацией и прочими делами. А вот с тем, как код пересекает границу сервер-клиент я дофига проблем словил. Так что второй раз пожалуй ни для чего серьезного я nextjs не возьму
Вы рассуждаете по ООП-шному и как будто хотите склеить два разноплановых подхода ООП-шными принципами.
Я примерно понимаю на чем стоит ваша аргументация, поправьте если я неправ, что применение
FoodMenuClient.live()дефолтным значением аргумента плохо тем, что о существовании live имплементации становится известно модулю (не классу) и он начинает от нее зависеть. В этом нет никакой проблемы, так как в сниппетах кода из статьи конечно же не полный production-grade пример как скомпоновать зависимости. Полная картина может быть несколько сложнее, но принцип тот же. В ней не используются классовые View, Presenter, Interactor или что там еще можно придумать в качестве ООП-like архитектуры.Любая высокоабстрактная ООП архитектура в итоге заканчивается классами с реализацией, но создает неповоротливость, большое кол-во бойлерплейта. В функциональном мире, созданию абстракций отводится меньше значения так как атомарность логики компенсирует связность, не требует сложных подходов к подмене имплементаций, инъекции зависимостей и тд. То есть формально передача зависимости аргументом функции это тоже DI, но инъекция через аннотацию всё таки на другой стороне архитектурного спектра.
При таком проектировании, всё исходит из идеи, что View - функция от State (что и представляет собой Compose). А State - кусочек иммутабельных данных без логики.
Логика с зависимостями от компонентов с версткой отделяется созданием двухэтажных компонент: FoodMenuLogicComposable + FoodMenuLayoutComposable. К этому прилагается тонкая View модель реагирующая на события и обрабатывающая их в Клиентах. Вот и вся архитектура. Под клиентами может быть масса других частей: кеши, база, неворкинг и тд и тп скрытых под своими клиентами. Компонуются плюс-минус тем же способом по принципу фрактала - множество треугольничков имеют похожую форму, но в составной объект может принимать любые формы. То есть при необходимости перекомпоновки под новые требования атомарные компоненты перекомпонуются на раз-два.
Разрыв связи, о котором вы пытаетесь сказать это Dependency Inversion. Суть его в том, чтобы изменить направление зависимости: Получатель зависимости зависит от ее абстракции, а не реализации.
Инъекция зависимости к этому не имеет отношения. В примере зависимость закрыта своим интерфейсом и создается за пределами объекта-приемника, с масштабируемостью тут никаких проблем нет. А вот создавать единый граф и протягивать его сквозь приложение - подход действительно плохой, по той же причине, по которой андроидеры ругаются на глобальные объекты предлагаемые SDK.
Чтобы понять и верно построить архитектуру в принципах, о которых говорит автор, нужно придерживаться нескольких правил: модуляризация всего, зависимости без состояния, дробление функционала сложных зависимостей на атомарные подзависимости в высококомпозируемых функциях, использование статического инстанцирования (все объекты, какие возможно в рамках здравого смысла, а таких должен быть минимум, создаются на статическими при старте приложения).
Большие кодовые базы UI (~1,5 млн строк) прекрасно живут с этим подходом. Попробуйте! Уверен, вам понравится простота, от которой поначалу будет казаться, что где-то должен быть подвох.
Это дискуссионный вопрос. Я с вами согласен, фишинг - проблема. Но фишинг - это мимикрия под то, чему вы доверяете. Вариации дизайна точно не пытаются пользователя обмануть. Если вы посмотрите на формы входа различных сервисов, вы заметите что кнопки входа через Google, Яндекс и других провайдеров соответствуют мягким гайдлайнам (тот же Яндекс предлагает варианты на выбор), но стилизованы под дизайн продукта. Мы же не говорим о проблеме фишинга авторизации гугла.
Честно говоря, не видел чтобы у телеги были какие-то ясные гайдлайны на этот счет, поделитесь ссылкой где они прописаны.
так никто не делает, просто потому что тут нечего уважать. Много iOS приложений строго следует Apple Human Interface Guidelines? Или на Андроиде все под копирку используют Material Design? Конечно нет. Если кнопка синяя с фирменным самолетиком телеграма с надписью «Войти с Telegram», этого достаточно, чтобы юзер идентифицировал функцию кнопки. А опасность фишинга меньшая из тех, что я привел в статье.
Хехе, передам дизайнеру ) к счастью, преимущества собственного дизайна в том, что его можно менять )