Типичный сценарий для современного IT: - берем общий термин или идею (FSD, или там Immutable State) - делаем как-получится реализацию (feature-sliced.design, или там Redux) - пиарим люто бешенно - у людей создаётся ассоциация FSD=feature-sliced.design, Immutable State = Redux - люди начинают считать изначальную идею - плохой, хотя плохая была - реализация
FSD как идея, в том же реакте живёт прям от входа: компоненты лежат в папочке со своими хуками, CSS, и логикой. И отлично это работает. И по-инерции, народ пишет так не только компоненты. В общем, многие проекты на React (особенно без Redux) - они уже Feature-Sliced.
Но нет - пришли люди с папочками, линтерами, и красивым веб-сайтом. Решили научить жить правильно. И вот - пошла справедливая контр-реакция. Но направленная теперь - против самой идеи.
И вот, на полном серьезе людям предлагают переходить на Layered Architecture. Как на беке, да. Где, если что, вообще за все годы не научились делать большие проекты. Где с этими нашими слоями, всю дорогу не получалось ничего кроме лапши. И где единственный способ как-то себе запретить делать лапшу - прям физически разнести код по репозиториям. Это называется "микросервисы", и "микросервисы" переводится как "мы так и не научились разложить код по папочкам".
Не надо тащить эту ошибку на фронт. Я вот сейчас наоборот пытаюсь эти идеи забирать в бек. Чем плоха монорепа, где у тебя те внутри сервисы, взаимодействующие друг с другом через понятные API? Разве это хуже, чем один гигантский DataLayer на сотни таблиц, и бизнес-логика - ходящая рандомно в любую часть БД?
Всё очень сильно зависит от приложения. Я вот тоже пишу уже лет 18 бизнес-приложения, и какой-то прям отделяемой бизнес-логики на фронте - толком и не видел. Логика самого UI - да, бывает прям очень навороченной, всякие там WYSIWYG-билдеры, редактируемые диаграммы Ганта, и т.п. Но вот чтобы прям какую-то сложную функцию про бизнес, не привязанную к UI выделить - это скорее редкость. Это на беке всё обычно.
Но я представляю бизнес-логики может быть много. У всех по-разному. У кого-то там API ходит в 50 микросервисов, постоянно бек просит переделать, и надо слой абстракции. Джависты любят нафигачить по REST своих GET/POST/PUT, и там даже для странички данные достать - уже на пол-страницы кода. А у кого-то - какой-нибудь один стабильный GraphQL, всё что хочешь достаётся одним запросом, и куда удобнее запросы эти класть рядом с компонентом.
Из-за того, что у всех разное - рассуждения о том, какие именно должны быть папки прям в каждом приложении - скорее вообще губительны. Я видел классные, понятные, проекты, где рядом лежат папки с визуальными компонентами, хелперами про бизнес, и т.п - у любителей FSD волосы на жопе зашевелятся, но всё понятно и круто. И видел проекты где лид любит вот эти все папочки, и там пока что-то поймешь - через 10 слоёв надо пройти, менять что-то страшно, а разобраться что где - нереально.
Работает понимание где код разбивать на модули, приёмы как это делать, здоровый перфекционизм, и трудолюбие чтобы постоянно что-то рефачить.
Разделение на слои - это по-факту декомпозиция "для галочки". Ну типа всё красиво разложено по папочкам, в папочках - файлы с похожим содержимым. Но это не дает каких-то прям сильных плюшек. Каждое изменение затрагивает кучу файлов, которые непонятно кто еще использует. Тестировать - непонятно как, получаются дебильные тесты в стиле "если позвали API и fetch отдал объект X, то API отдал объект X".
"Вертикальное" разделение - когда в каждой папочке-подсистеме какой-то понятный кусок функционала, с выставленным API - делать сложнее, но оно даёт плюшки. Можно какие-то вещи делать не выходя из этой папочки (если её API не меняется). На чанки приложение лучше разбивается. И - если вообще всё идеально - что-то можно выносить в библиотеки и использовать в нескольких приложениях. А может даже даже будет просто распилить приложение на два.
Ошибка FSD - это чрезмерно настаивать каких видов нужно делать папочки-модули, и как они должны быть связаны. Ну типа различать features и widgets. Можно ведь делить как угодно, оставляя саму идею.
По-факту, в реальных приложениях часто микс обоих подходов. Общие компоненты - почти всегда выделены как модули, правда не всегда следят чтобы API был нормальный. Какие-нибудь react hooks - сваливают в общую папку по принципу "это же хуки" - и те что общие, и те что нужны одной страничке.
В общем, мысль в том, что думать надо чуть выше абстракциями. Ну, что каждая папочка - это модуль, от него должна быть какая-то польза (проще взять его, чем написать прям по месту), хороший API. И поменьше придумывать синтетические ограничения себе, в стиле "давайте заранее придумаем какие у нас папочки будут, и что будет в них".
Так я и предлагаю не к интернету прикручивать, а к тому же Консультанту. Дать ей тот же API для поиска, и пусть ищет себе по ключевым, векторным, или историю изменений смотрит.
Мысль тут в том, что вместо того, чтобы делать убер-поиск по векторам, дать те же инструменты что человеку. Оно нормально этим умеет пользоваться. И что удобно человеку - ей тоже норм.
Я, в целом, думаю что всем, кто делает LLM-based продукты, надо присмотреться к Cursor, и как им пользуются. Там же типа «собери инфу про то-то, сложи в файлик», «теперь вот эти файлики посмотри и сделай то-то», «теперь проанализируй что мы делали - и сделай себе инструкцию на будущее». Т.е. там нет попытки сделать магию - чтобы один промпт пишешь и оно само. Там дают инструмент, чтобы вести ее по шагам, и каждый шаг контроллировать.
Мне думается, что с LLM только этот путь более-менее и работает - когда ты командуешь, разбиваешь на подзадачи, и проверяешь каждый шаг. Да, он требует научиться этим пользоваться. Но, видимо, придется всем учиться.
А как юристы это всё до LLM искали и обрабатывали? Я тут смотрю на RAG-подход (пытаться найти сразу всё нужное по тексту), и агентный (дать инструменты поиска и анализа через MCP - и пусть сама ищет). И во многих случаях второе работает лучше, хоть и жрет больше токенов.
Т.е. может лучше давать ей поиск, инструмент чтобы доставать историю с дельтами, ходить по ссылкам, доставать выжимки документов? Ну т.е. API от того же UI юридической какой-то БД, и пусть оно само ковыряется?
В Cursor том же именно так делают, а они вроде фишку секут.
Если не надо было бы инфоповод и хайпануть, могли бы вместо этого хитрого протокола, просто REST API с OpenAPI-спекой подключать.
С этой новой прекрасной идеей, ждём новую версию протокола, где для Tool можно схему ответа указать. А то там сейчас тупо текст, и как модель сможет написать код, который как-то результат обработает - не ясно.
Конкретно эту я давал офлайн решать, ребятам из учебки - там это было уместно.
Для онлайн "при зрителях" - она прям слишком сложная. У меня для собесов задачи прям супер-простые, в т.ч. чтобы не парализовало. Уровня дописать полу-готовый ToDo List на React, или вынуть суммы из трех связанных таблиц на .NET.
Но задачи все - с кучей точек где что-то дописать, спросить, обсудить.
Как-то на каком-то похожем сайте решал задачки давно.
И там была задачка - дано сколько-то «рук» в покере - надо посчитать когда левая бьет правую комбинацию.
И мне она так понравилась, что я её давал как тестовую потом.
Прикол в том, что это не сложная какая-то муть про o(n), это максимально близко к тому, что приходится писать в бизнес-приложениях: куча странных условий друг на друге. И написать это красиво и понятно - надо прям уметь.
Разработчикам то может и нравится. Вот понравится ли бизнесу 5х оценки на добавление одного атрибута к продукту, и потом еще неделя т.к. «ой не в тот сервис положили, надо рефакторинг и миграцию данных.
Почему разработчики протестуют? Да потому что нам на этом потом «писать». Сколько я видел проектов, где какая-нибудь Camunda приделывается с идеей «мы сейчас BA посадим самих процессы строить». А заканчивается всегда тем, что всё это пилят те же разработчики, в 5 раз дольше, и которым еще доплачивать надо за вредность.
DSL, любой - визуальный или нет, почти всегда плохая идея. По той же причине, что и «давайте все перепишем» - почти никогда не работает. Если хочется поднять уровень абстракции надо строить поверх готового - идти в eDSL, или вообще делать обычные библиотеки.
Мне кажется, пора кому-то написать C#: The Good Parts :) Или сделать какой-нибудь C-бемоль.
Они идут очень долгой дорожкой от деревянности и многословности джавы к минимализму. Но там так много всего мешается, что не получается ни просто, ни реально минималистично.
Но у C# есть прям крутая фишка - там можно делать зубодробильные мета-штуки, и прям рядом писать на них тупой понятный код. Можно делать большие и сложные аппы, с серьезными абстракциями, в 10 средних бойцов, и одного крутого лида. Все другое такое не тянет.
Когда заморачиваются - картинку на cdn включают, типа «вас слишком многа», чтобы часть трафика убрать, и хоть для кого-то работать. Когда все подвисает - это как раз когда не подумали, и дали завалить всё и всем.
Там есть очередь же. Настраиваешь чтобы у тебя запросы не запускались в обработку больше, скажем, 10 одновременно. Остальные ждут в очереди сколько скажешь. И дальше крутишь ручки на перф-тесте. Обычно надо чтобы уперлось в CPU базы. Если под недонагружен по cpu, а база еще дышит - можно побольше в параллель навалить.
База, от того что ей в параллель надо кучу запросов вертеть, быстрее не работает - у нее тоже не бесконечное количество процов. Ей быстрее последовательно все делать плюс-минус по очереди.
Ну и исключается гонка за коннектами, сотни запросов ждущих блокировки и коннекты к БД. Все что система не переварит - видно по растущей очереди.
Вместо самодельных очередей, надо вешать rate limiter на входе. Он поставит http-запросы в очередь, и пустит в параллель сколько скажешь.
Тогда, если разные куски когда будут бороться за коннекты, не получится что у тебя куча запросов ждет освободившегося коннекта чтобы завершится, а новые все прилетают - и тоже получают шанс сожрать коннект.
Я такую структуру папок называю «джунской». Вроде все разложено по типам объектов, порядочек. По факту - все со всем повязано, а если что-то надо в одной фиче поправить - надо пол проекта перелопатить. И все завязано на все в мясо.
У меня примерно такой первый ПК был, p90 250мб винт, 8 метров оперативы, s3 trio. Писал на Watcom C с ассемблерными вставками. Было прикольно: честное плоское адресное пространство наконец, после 16 бит real mode с всратыми сегментами этими. С другой стороны, чуть что - в перезагрузку. И дебаггера никакого (или может не разобрался). Ощущения, близкие к спектруму.
Мы микрофронты грузим тупо через стандартный import(). Зачем нужно Single SPA - я так и не понял.
А реакт и UI kit общие, или каждый свой грузит?
Типичный сценарий для современного IT:
- берем общий термин или идею (FSD, или там Immutable State)
- делаем как-получится реализацию (feature-sliced.design, или там Redux)
- пиарим люто бешенно
- у людей создаётся ассоциация FSD=feature-sliced.design, Immutable State = Redux
- люди начинают считать изначальную идею - плохой, хотя плохая была - реализация
FSD как идея, в том же реакте живёт прям от входа: компоненты лежат в папочке со своими хуками, CSS, и логикой. И отлично это работает. И по-инерции, народ пишет так не только компоненты. В общем, многие проекты на React (особенно без Redux) - они уже Feature-Sliced.
Но нет - пришли люди с папочками, линтерами, и красивым веб-сайтом. Решили научить жить правильно. И вот - пошла справедливая контр-реакция. Но направленная теперь - против самой идеи.
И вот, на полном серьезе людям предлагают переходить на Layered Architecture. Как на беке, да. Где, если что, вообще за все годы не научились делать большие проекты. Где с этими нашими слоями, всю дорогу не получалось ничего кроме лапши. И где единственный способ как-то себе запретить делать лапшу - прям физически разнести код по репозиториям. Это называется "микросервисы", и "микросервисы" переводится как "мы так и не научились разложить код по папочкам".
Не надо тащить эту ошибку на фронт. Я вот сейчас наоборот пытаюсь эти идеи забирать в бек. Чем плоха монорепа, где у тебя те внутри сервисы, взаимодействующие друг с другом через понятные API? Разве это хуже, чем один гигантский DataLayer на сотни таблиц, и бизнес-логика - ходящая рандомно в любую часть БД?
Всё очень сильно зависит от приложения. Я вот тоже пишу уже лет 18 бизнес-приложения, и какой-то прям отделяемой бизнес-логики на фронте - толком и не видел. Логика самого UI - да, бывает прям очень навороченной, всякие там WYSIWYG-билдеры, редактируемые диаграммы Ганта, и т.п. Но вот чтобы прям какую-то сложную функцию про бизнес, не привязанную к UI выделить - это скорее редкость. Это на беке всё обычно.
Но я представляю бизнес-логики может быть много. У всех по-разному. У кого-то там API ходит в 50 микросервисов, постоянно бек просит переделать, и надо слой абстракции. Джависты любят нафигачить по REST своих GET/POST/PUT, и там даже для странички данные достать - уже на пол-страницы кода. А у кого-то - какой-нибудь один стабильный GraphQL, всё что хочешь достаётся одним запросом, и куда удобнее запросы эти класть рядом с компонентом.
Из-за того, что у всех разное - рассуждения о том, какие именно должны быть папки прям в каждом приложении - скорее вообще губительны. Я видел классные, понятные, проекты, где рядом лежат папки с визуальными компонентами, хелперами про бизнес, и т.п - у любителей FSD волосы на жопе зашевелятся, но всё понятно и круто. И видел проекты где лид любит вот эти все папочки, и там пока что-то поймешь - через 10 слоёв надо пройти, менять что-то страшно, а разобраться что где - нереально.
Работает понимание где код разбивать на модули, приёмы как это делать, здоровый перфекционизм, и трудолюбие чтобы постоянно что-то рефачить.
Разделение на слои - это по-факту декомпозиция "для галочки". Ну типа всё красиво разложено по папочкам, в папочках - файлы с похожим содержимым. Но это не дает каких-то прям сильных плюшек. Каждое изменение затрагивает кучу файлов, которые непонятно кто еще использует. Тестировать - непонятно как, получаются дебильные тесты в стиле "если позвали API и fetch отдал объект X, то API отдал объект X".
"Вертикальное" разделение - когда в каждой папочке-подсистеме какой-то понятный кусок функционала, с выставленным API - делать сложнее, но оно даёт плюшки. Можно какие-то вещи делать не выходя из этой папочки (если её API не меняется). На чанки приложение лучше разбивается. И - если вообще всё идеально - что-то можно выносить в библиотеки и использовать в нескольких приложениях. А может даже даже будет просто распилить приложение на два.
Ошибка FSD - это чрезмерно настаивать каких видов нужно делать папочки-модули, и как они должны быть связаны. Ну типа различать features и widgets. Можно ведь делить как угодно, оставляя саму идею.
По-факту, в реальных приложениях часто микс обоих подходов. Общие компоненты - почти всегда выделены как модули, правда не всегда следят чтобы API был нормальный. Какие-нибудь react hooks - сваливают в общую папку по принципу "это же хуки" - и те что общие, и те что нужны одной страничке.
В общем, мысль в том, что думать надо чуть выше абстракциями. Ну, что каждая папочка - это модуль, от него должна быть какая-то польза (проще взять его, чем написать прям по месту), хороший API. И поменьше придумывать синтетические ограничения себе, в стиле "давайте заранее придумаем какие у нас папочки будут, и что будет в них".
Так я и предлагаю не к интернету прикручивать, а к тому же Консультанту. Дать ей тот же API для поиска, и пусть ищет себе по ключевым, векторным, или историю изменений смотрит.
Мысль тут в том, что вместо того, чтобы делать убер-поиск по векторам, дать те же инструменты что человеку. Оно нормально этим умеет пользоваться. И что удобно человеку - ей тоже норм.
Я, в целом, думаю что всем, кто делает LLM-based продукты, надо присмотреться к Cursor, и как им пользуются. Там же типа «собери инфу про то-то, сложи в файлик», «теперь вот эти файлики посмотри и сделай то-то», «теперь проанализируй что мы делали - и сделай себе инструкцию на будущее». Т.е. там нет попытки сделать магию - чтобы один промпт пишешь и оно само. Там дают инструмент, чтобы вести ее по шагам, и каждый шаг контроллировать.
Мне думается, что с LLM только этот путь более-менее и работает - когда ты командуешь, разбиваешь на подзадачи, и проверяешь каждый шаг. Да, он требует научиться этим пользоваться. Но, видимо, придется всем учиться.
А как юристы это всё до LLM искали и обрабатывали? Я тут смотрю на RAG-подход (пытаться найти сразу всё нужное по тексту), и агентный (дать инструменты поиска и анализа через MCP - и пусть сама ищет). И во многих случаях второе работает лучше, хоть и жрет больше токенов.
Т.е. может лучше давать ей поиск, инструмент чтобы доставать историю с дельтами, ходить по ссылкам, доставать выжимки документов? Ну т.е. API от того же UI юридической какой-то БД, и пусть оно само ковыряется?
В Cursor том же именно так делают, а они вроде фишку секут.
Если не надо было бы инфоповод и хайпануть, могли бы вместо этого хитрого протокола, просто REST API с OpenAPI-спекой подключать.
С этой новой прекрасной идеей, ждём новую версию протокола, где для Tool можно схему ответа указать. А то там сейчас тупо текст, и как модель сможет написать код, который как-то результат обработает - не ясно.
Конкретно эту я давал офлайн решать, ребятам из учебки - там это было уместно.
Для онлайн "при зрителях" - она прям слишком сложная. У меня для собесов задачи прям супер-простые, в т.ч. чтобы не парализовало. Уровня дописать полу-готовый ToDo List на React, или вынуть суммы из трех связанных таблиц на .NET.
Но задачи все - с кучей точек где что-то дописать, спросить, обсудить.
Вот она: https://projecteuler.net/problem=54
Как-то на каком-то похожем сайте решал задачки давно.
И там была задачка - дано сколько-то «рук» в покере - надо посчитать когда левая бьет правую комбинацию.
И мне она так понравилась, что я её давал как тестовую потом.
Прикол в том, что это не сложная какая-то муть про o(n), это максимально близко к тому, что приходится писать в бизнес-приложениях: куча странных условий друг на друге. И написать это красиво и понятно - надо прям уметь.
Такие задачки на leetcode попадаются?
Разработчикам то может и нравится. Вот понравится ли бизнесу 5х оценки на добавление одного атрибута к продукту, и потом еще неделя т.к. «ой не в тот сервис положили, надо рефакторинг и миграцию данных.
Да Entity Framework тот же.
Почему разработчики протестуют? Да потому что нам на этом потом «писать». Сколько я видел проектов, где какая-нибудь Camunda приделывается с идеей «мы сейчас BA посадим самих процессы строить». А заканчивается всегда тем, что всё это пилят те же разработчики, в 5 раз дольше, и которым еще доплачивать надо за вредность.
DSL, любой - визуальный или нет, почти всегда плохая идея. По той же причине, что и «давайте все перепишем» - почти никогда не работает. Если хочется поднять уровень абстракции надо строить поверх готового - идти в eDSL, или вообще делать обычные библиотеки.
Мне кажется, пора кому-то написать C#: The Good Parts :) Или сделать какой-нибудь C-бемоль.
Они идут очень долгой дорожкой от деревянности и многословности джавы к минимализму. Но там так много всего мешается, что не получается ни просто, ни реально минималистично.
Но у C# есть прям крутая фишка - там можно делать зубодробильные мета-штуки, и прям рядом писать на них тупой понятный код. Можно делать большие и сложные аппы, с серьезными абстракциями, в 10 средних бойцов, и одного крутого лида. Все другое такое не тянет.
Если так хочется разделить - делаешь хук к компоненту в отдельном файле, делов то.
К реакту можно много где домотаться, но статья - вообще мимо. Человек хочет ангуляр просто.
Когда заморачиваются - картинку на cdn включают, типа «вас слишком многа», чтобы часть трафика убрать, и хоть для кого-то работать. Когда все подвисает - это как раз когда не подумали, и дали завалить всё и всем.
Там есть очередь же. Настраиваешь чтобы у тебя запросы не запускались в обработку больше, скажем, 10 одновременно. Остальные ждут в очереди сколько скажешь. И дальше крутишь ручки на перф-тесте. Обычно надо чтобы уперлось в CPU базы. Если под недонагружен по cpu, а база еще дышит - можно побольше в параллель навалить.
База, от того что ей в параллель надо кучу запросов вертеть, быстрее не работает - у нее тоже не бесконечное количество процов. Ей быстрее последовательно все делать плюс-минус по очереди.
Ну и исключается гонка за коннектами, сотни запросов ждущих блокировки и коннекты к БД. Все что система не переварит - видно по растущей очереди.
Вместо самодельных очередей, надо вешать rate limiter на входе. Он поставит http-запросы в очередь, и пустит в параллель сколько скажешь.
Тогда, если разные куски когда будут бороться за коннекты, не получится что у тебя куча запросов ждет освободившегося коннекта чтобы завершится, а новые все прилетают - и тоже получают шанс сожрать коннект.
Я такую структуру папок называю «джунской». Вроде все разложено по типам объектов, порядочек. По факту - все со всем повязано, а если что-то надо в одной фиче поправить - надо пол проекта перелопатить. И все завязано на все в мясо.
У меня примерно такой первый ПК был, p90 250мб винт, 8 метров оперативы, s3 trio. Писал на Watcom C с ассемблерными вставками. Было прикольно: честное плоское адресное пространство наконец, после 16 бит real mode с всратыми сегментами этими. С другой стороны, чуть что - в перезагрузку. И дебаггера никакого (или может не разобрался). Ощущения, близкие к спектруму.