Понятно, сами выдумали понятие свалки и у вас разумеется всё идеально. У всех свалка, а у вас структура и нейминг и несвалочный шаренный код.
выделение в отдельный реп с точки зрения борьбы со свалками особого профита не несет.
Действительно, была тысяча папок, стало 30 папок. Было 10тыс файлов, стало 100 файлов. Вообще тоже самая. Такая же свалка. Запуск проект был 5 минут, стал 4 секунды. Ты был заложником легаси архитектуры и легаси подхода, а теперь можно писать микрофронт по красоте. Но кому это всё нужно, даже не знаю.
Я не смогу вам доказать, что все эти абстракции вполне конкретные и помогают.
Абстракции на то и абстракции, они не могут быть конкретными априори. Поэтому когда мы опускаемся на уровень решения конкретных задач, то там уже нет абстракций.
Мой полет мыслей: 1) Форма входа на сайт содержащая поля логина и пароля - это конкретика. И сразу все легко да?
2) Задача, добавить на эту форму входа капчу - это конкретика, тоже сразу все понятно.
А теперь ваш полет мыслей: 1) Слой авторизации. Что конкретно в него входит, что именно имеется ввиду? Почему Х в него входит, а Y не входит?
2) Задача, добавить капчу в слое авторизации. Куда конкретно ее добавить? Только на вход? Только на регистрацию? Или туда и туда?
Поэтому то, что вы говорите я не понимаю и другие тоже, вы скрываете конкретику намеренно. Только вы знаете что вы подразумеваете по слоем авторизации или под слоем товара например. Больше никто. Когда называешь вещи своими именами, то всё для всех становится предельно понятно и просто с первого раза. Не надо 10 раз задавать уточняющие вопросы и гадать на кофейной гуще, а что же конкретно он имеет ввиду.
Если вы рассматриваете микрофронты как адекватное решение которое приносит бенефиты на большой проект, то почему вы так сильно выступаете против разбиения не домены?
Микрофронт как относительно самодостаточное отдельное маленькое приложение это не тоже самое что огромный монолит который пытается это имитировать. У каждого микрофронта могут быть свои архитектурные особенности и подходы, что дает свободу, гибкость и развитие. Главное что каждый отдельный микрофронт может обслуживать только один разработчик, чем больше людей пишут в одну и ту же репу параллельно, тем хуже. Каждый человек ас на проекте пока он 100 процентный хозяин кода, и он работает максимально эффективно и комфортно, а когда это нарушается, то падает эффективность и комфорт. И я не то чтобы против разбиения не домены как таковые, просто это вводит дополнительные ограничения и неудобства, я как раз прежде всего против ограничений и неудобств.
Вы усложняете все и накладываете оверхед по умолчанию на все сценарии и весь процесс разработки, ради того, чтобы потенциально выиграть 10-15% времени для одной задачи из ста и то не факт, что такой кейс настанет, а я выстраиваю архитектуру чтобы выигрывать в 99 реальных задачах из 100. Суммарно экономия времени, ресурсов и усилий на разработку в классической архитектуре намного больше, т.к. в ней нет нужны специально усложнять простые вещи. Вот и все. Keep It Simple и всё будет шикарно, каким бы сложным и большим не был бы проект. Тем более далеко далеко не все проекты реально настолько большие и сложные, это больше исключения, чем правила. Другой вопрос если их намеренно переусложнить введя кучу слоев абстракций, то да, простой проект станет сложным. Когда оперируешь конкретными вещами, а не абстрактными, то всё просто на самом деле.
Покажите мне проект с 5+ лет жизни и затронутый больше 10 разработчиками с классической архитектурой и кучей бизнес-логики, который легко поддерживать и масштабировать
Я работал на таких проектах, но их основная сложность не в том, что в них классическая архитектура или ddd или fsd или что угодно, а в том, что в них сложная и большая бизнес логика. А сложную и большую бизнес логику нельзя упростить если на то не будет согласие бизнеса. А следовательно, реальная сложность обуславливается не структурой файлов и папок и тем, мыслим мы доменами или конкретными вещами. Всё что мы можем, дополнительно не усложнять и не усугублять без того сложную бизнес логику дополнительными слоями абстракций. Тем самым выигрывая время и нервы.
Ну и кстати если рассуждать про абстрактный огромный проект, где есть "мусорка", то этот проект должен быть разбит на микрофронты, причем заранее, до появление этой самой "мусорки". И тут уже бац и все эти драматизированные проблемы файлов и папок опять улетучиваются сразу)
все верно, когда их становится в "куче" много, их начинают групировать в этой куче. Более того, как правило это приводит и к тому что в других "кучах" так же возникает необходимость групировки.в итоге у нас /orderSpecified повторяется в нескольких разделах. И самое веселое когда в одном разделе это уже сгрупированно, а в другом нет, и там начинают групировку. Это часто приводит к тому , что появляются расхождения.
И где проблема? Все сгруппировано. Все логично и все понятно.
Вы выдумали сценарий где проект пишут джуны или вообще неадекваты. Если все сводится к неадекватам, то нет разницы что и как, проект будет мертвым, без вариантов.
Плюс вы фантазируете со сложность поиска. Во первых есть ctrl + f, во вторых, вы знаете где нужный вам компонент находится на странице, допустим вам надо пофиксить сворачивающийся блок на странице товара, он идет сразу после блока описание, зашли в src/pages/orderDetails/index.tsx и вот вы увидили нужный вам компонент в JSX'e, ctrl+click по нему и вуаля, вы уже в этом компоненте, 30 секунды и все дела. Дальше уже пофиксили и дело сделано.
Если не драматизировать вещи, которые являются нашей работой, то оказывается что все легко и просто и проблем то и нет в общем-то. Просто бери да делай. И палки в колеса себе не вставляй и не усложняй простые вещи на ровном месте.
Конечно в глобальное, это состояние которое могут использовать все кому надо из разных мест. Но опять же, оно глобальное, но вполне себе конкретное и называется конкретно.
И как я понимаю компоненты отвечающие за его отображение так же уходят в глобальную папку components?
Его могут использовать все кому надо. Вcе страницы, лейауты, общие компоненты, локальные копоненты внутри страницы и т.п. src/compoentns src/layouts src/pages Вообще все кто захочет, ограничений и запретов нет и в этом огромный плюс и удобство.
import { orderState } from 'globalState/orderState';
Допустим у вас тысяча страниц и 10 из них использует одну и туже функцию или компонент который завязан на бизнес. Где вы его разместите в данной структуре?
Общий компонент в src/components или никто не запрещает в src/compoents/orderSpecified/{компоненты} если они все сгруппированы по какому-то признаку и при этом используются в разных местах. Так же можно и src/components/formFields/{компоненты для форм}
Общие функции в src/heplers или src/utils как больше нравится называть. Если они шарят какое-то общее состояние глобальное, то оно лежит в src/globalState например src/globalState/orderState
Вы может не понимаете смысл классики? С чего вы вообще решили что там нет вложенностей? Что там нет разбиения на логические уровни?
Ваш пример с useOrderItems, только хуки не использованы, вместо них MobX ибо я например адекватный человек.
src/
pages/
OrdersPage/
index.tsx // Тут UI
state.ts // Тут локальное состояние для этой страницы
styles.module.scss // Стили для этой страницы
Всё лежит друг с другом, это обычная классика. Уже 100 раз приводил эту структуру. В чем тут проблема? Не понимаю. Хоть тысяча таких страниц, пожалуйста, легко.
Про выгоду разработки от бизнесового домена. Легче менять какую-то бизнесовую логику и есть чёткое разграничение между ui и бизнес-логикой. Постановки чаще всего летят от аналитиков, а не от дизайнеров.
Так и не увидел никакой выгоды. Крайне не убедительные слова не подкрепленные ни одним конкретным примером который можно проверить/воспроизвести. Более того, даже не понятно с чем вы сравниваете? Почему вы решили, что объект вашего сравнения это какая-то мешанина где вся логика описана внутри div'a или как там вы себе представляете как обычно люди пишут код?
Луковая архитектура, ddd - также предлагают бизнесовый домен делать независимым от всего, ядром архитектуры.
Всё равно не вижу плюсов, только минусы из-за введения лишних абстракций и ограничений. И строить архитектуру приложения вот так, без привязки к удобству/простоте/легкости/понятности написания кода это конечно жесть. Во главе угла должны быть KISS и YAGNI прежде всего.
Всё равно хоть убей не понимаю каким образом классическая архитектура может быть хуже? Ни одного реального аспекта нет, кроме выдумок. То, что классика все всём лучше, это да, тут всё однозначно, она понятна всем и каждому на интуитивном уровне .
Вы вот не трогали fsd получается у вас меньше опыта?
Как раз таки наоборот) Из-за опыта мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет. Ну и касаемо самом FSD я видел его на 2х проектах в которых приходилось вносить доработки, это конечно было фрик шоу) Вполне ожидаемое фрик шоу, другого я и не ждал, ибо и так все понятно если просто взглянуть на эту мертворожденную концепцию) Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы FSD приносил удобство по сравнению с классикой, я бы сразу же перевел все свои проекты на FSD и новые начинал с FSD. Или же если бы redux был удобнее чем mobx, я бы сразу выкинул mobx и перешел на redux. И т.п.
Простой пример из жизни, для большинства людей которые видят коровью лепешку на дороге достаточно просто ее видеть, чтобы понять что она не вкусная и вонючая) Для этого нет нужны к ней походить, пробовать ее на вкус и тд) Или когда ты видишь кипящую воду(она вся такая бурлит) нет смысла совать в нее руку и проверять температуру, ты уже знаешь что это кипяток. Вот и тут такой же принцип.
Можно себе сэкономить уйму времени и нервов, избежав такого рода экспериментов. Просто посмотри что перед тобой, проведи мысленный эксперимент и вуаля.
У меня в отличии от вас позиция не предвзятая и не фанатичная, а просто вытекает из фактов и простых принципов. Всё сугубо ради удобства и выгоды с точки зрения трудозатрат. Зачем мне на проекте применять подход Y, если с ним я в 2 раза больше времени трачу на реализацию таких же задач, как тратил бы если бы использовал подход X.
Например в 2016 году я считал что typescript это оверхед, с 2012 по 2016 ни разу TS не юзал, но в уже 2017 я пересмотрел свою позицию и с тех пор typescript only. До появления async/await в Node.js ноду я тоже не рассматривал в серьез как инструмент для написания бэка. Но JS эволюционировал, стал значительно круче и вуаля, в 2018 я уже писал бэкенд на Node.js с удовольствием.
Я вот такой как у вас реализации вообще не встречал с components в страницах.
Чем меньше опыта(в разрезе кол-ва проектов), тем меньше шанс что вы видели тот или иной подход.
Самое плохое в этом всём что работая в команде надо руководствоваться хоть какой то архитектурой и документацией
Есть вещи не нуждающиеся в документации. Ибо они и так предельно ясны.
function sum(a: number, b: number) {
retrun a + b;
}
Это нуждается в документации? Нет, тут всё говорит за себя. Более того, никто не запрещает на классику написать документацию. Это супер быстро и супер просто. pages - для страниц layuots - для лейтаутов components - для общих компонентов вложенная папка components - для локальных компонентов, которые необходимы исключительно этой странице/компоненту/лейауту и т.п.
Ну и так далее. Всё же элементарно. А вы опять какую-то смуту наводите, якобы тут что-то сложное, не понятное, бардак и т.п. Ну бред же.
Руководствуясь здравым смыслом у вас крокозябра получитсья.
Ахах. Ясно.
Если вы не понимаете вы спросите что не понимаете, а лучше перечитайте доку доклад какой-нибудь послушайте.
Так вы называйте вещи конкретно своими именами, не называйте стакан объектом, не называйте стул объектом по крупнее. Просто говорите стакан и стул.
Понятно, сами выдумали понятие свалки и у вас разумеется всё идеально. У всех свалка, а у вас структура и нейминг и несвалочный шаренный код.
Действительно, была тысяча папок, стало 30 папок. Было 10тыс файлов, стало 100 файлов. Вообще тоже самая. Такая же свалка. Запуск проект был 5 минут, стал 4 секунды. Ты был заложником легаси архитектуры и легаси подхода, а теперь можно писать микрофронт по красоте. Но кому это всё нужно, даже не знаю.
Тогда какие претензии к "свалкам" если вы их сами создаете и поощряете?
Большой проект = свалка
Небольшой проект = свалки быть не может.
Это не микрофронты, это монорепа с костылями.
Микрофронты = 1 микрофронт - отдельный репозиторий
Большой проект, в смысле реально прям большой = свалка. Поэтому микрофронты и свалки нет.
О какой конкретно сложности вы говорите? Для вас что, сложно когда Button может дергать что-то из глобального стора?
В точку!)
Абстракции на то и абстракции, они не могут быть конкретными априори. Поэтому когда мы опускаемся на уровень решения конкретных задач, то там уже нет абстракций.
Мой полет мыслей:
1) Форма входа на сайт содержащая поля логина и пароля - это конкретика. И сразу все легко да?
2) Задача, добавить на эту форму входа капчу - это конкретика, тоже сразу все понятно.
А теперь ваш полет мыслей:
1) Слой авторизации. Что конкретно в него входит, что именно имеется ввиду? Почему Х в него входит, а Y не входит?
2) Задача, добавить капчу в слое авторизации. Куда конкретно ее добавить? Только на вход? Только на регистрацию? Или туда и туда?
Поэтому то, что вы говорите я не понимаю и другие тоже, вы скрываете конкретику намеренно. Только вы знаете что вы подразумеваете по слоем авторизации или под слоем товара например. Больше никто. Когда называешь вещи своими именами, то всё для всех становится предельно понятно и просто с первого раза. Не надо 10 раз задавать уточняющие вопросы и гадать на кофейной гуще, а что же конкретно он имеет ввиду.
Микрофронт как относительно самодостаточное отдельное маленькое приложение это не тоже самое что огромный монолит который пытается это имитировать. У каждого микрофронта могут быть свои архитектурные особенности и подходы, что дает свободу, гибкость и развитие. Главное что каждый отдельный микрофронт может обслуживать только один разработчик, чем больше людей пишут в одну и ту же репу параллельно, тем хуже. Каждый человек ас на проекте пока он 100 процентный хозяин кода, и он работает максимально эффективно и комфортно, а когда это нарушается, то падает эффективность и комфорт. И я не то чтобы против разбиения не домены как таковые, просто это вводит дополнительные ограничения и неудобства, я как раз прежде всего против ограничений и неудобств.
Вы усложняете все и накладываете оверхед по умолчанию на все сценарии и весь процесс разработки, ради того, чтобы потенциально выиграть 10-15% времени для одной задачи из ста и то не факт, что такой кейс настанет, а я выстраиваю архитектуру чтобы выигрывать в 99 реальных задачах из 100. Суммарно экономия времени, ресурсов и усилий на разработку в классической архитектуре намного больше, т.к. в ней нет нужны специально усложнять простые вещи. Вот и все. Keep It Simple и всё будет шикарно, каким бы сложным и большим не был бы проект. Тем более далеко далеко не все проекты реально настолько большие и сложные, это больше исключения, чем правила. Другой вопрос если их намеренно переусложнить введя кучу слоев абстракций, то да, простой проект станет сложным. Когда оперируешь конкретными вещами, а не абстрактными, то всё просто на самом деле.
Я работал на таких проектах, но их основная сложность не в том, что в них классическая архитектура или ddd или fsd или что угодно, а в том, что в них сложная и большая бизнес логика. А сложную и большую бизнес логику нельзя упростить если на то не будет согласие бизнеса. А следовательно, реальная сложность обуславливается не структурой файлов и папок и тем, мыслим мы доменами или конкретными вещами. Всё что мы можем, дополнительно не усложнять и не усугублять без того сложную бизнес логику дополнительными слоями абстракций. Тем самым выигрывая время и нервы.
Ну и кстати если рассуждать про абстрактный огромный проект, где есть "мусорка", то этот проект должен быть разбит на микрофронты, причем заранее, до появление этой самой "мусорки". И тут уже бац и все эти драматизированные проблемы файлов и папок опять улетучиваются сразу)
И где проблема? Все сгруппировано. Все логично и все понятно.
Вы выдумали сценарий где проект пишут джуны или вообще неадекваты. Если все сводится к неадекватам, то нет разницы что и как, проект будет мертвым, без вариантов.
Плюс вы фантазируете со сложность поиска. Во первых есть ctrl + f, во вторых, вы знаете где нужный вам компонент находится на странице, допустим вам надо пофиксить сворачивающийся блок на странице товара, он идет сразу после блока описание, зашли в
src/pages/orderDetails/index.tsxи вот вы увидили нужный вам компонент в JSX'e, ctrl+click по нему и вуаля, вы уже в этом компоненте, 30 секунды и все дела. Дальше уже пофиксили и дело сделано.Если не драматизировать вещи, которые являются нашей работой, то оказывается что все легко и просто и проблем то и нет в общем-то. Просто бери да делай. И палки в колеса себе не вставляй и не усложняй простые вещи на ровном месте.
Конечно в глобальное, это состояние которое могут использовать все кому надо из разных мест. Но опять же, оно глобальное, но вполне себе конкретное и называется конкретно.
Его могут использовать все кому надо.
Вcе страницы, лейауты, общие компоненты, локальные копоненты внутри страницы и т.п.
src/compoentnssrc/layoutssrc/pagesВообще все кто захочет, ограничений и запретов нет и в этом огромный плюс и удобство.
И вперед
Общий компонент в
src/componentsили никто не запрещает вsrc/compoents/orderSpecified/{компоненты}если они все сгруппированы по какому-то признаку и при этом используются в разных местах. Так же можно и
src/components/formFields/{компоненты для форм}Общие функции в
src/heplersилиsrc/utilsкак больше нравится называть.Если они шарят какое-то общее состояние глобальное, то оно лежит в
src/globalStateнапримерsrc/globalState/orderStateВот
Где в упрощенном виде orderState:
Откуда вы взяли кучу? Откуда вы взяли свалку? Где тут куча? Где тут свалка?
Всё разбито на логические уровни.
Вы может не понимаете смысл классики? С чего вы вообще решили что там нет вложенностей? Что там нет разбиения на логические уровни?
Ваш пример с useOrderItems, только хуки не использованы, вместо них MobX ибо я например адекватный человек.
Всё лежит друг с другом, это обычная классика. Уже 100 раз приводил эту структуру. В чем тут проблема? Не понимаю. Хоть тысяча таких страниц, пожалуйста, легко.
Так и не увидел никакой выгоды. Крайне не убедительные слова не подкрепленные ни одним конкретным примером который можно проверить/воспроизвести. Более того, даже не понятно с чем вы сравниваете? Почему вы решили, что объект вашего сравнения это какая-то мешанина где вся логика описана внутри div'a или как там вы себе представляете как обычно люди пишут код?
Всё равно не вижу плюсов, только минусы из-за введения лишних абстракций и ограничений. И строить архитектуру приложения вот так, без привязки к удобству/простоте/легкости/понятности написания кода это конечно жесть. Во главе угла должны быть KISS и YAGNI прежде всего.
Всё равно хоть убей не понимаю каким образом классическая архитектура может быть хуже? Ни одного реального аспекта нет, кроме выдумок. То, что классика все всём лучше, это да, тут всё однозначно, она понятна всем и каждому на интуитивном уровне .
@NikitaLikosovтак как классика этому мешает?
Как раз таки наоборот) Из-за опыта мне достаточно провести мысленный эксперимент чтобы увидеть сразу к чему приведет использование FSD или использование Effector и т.п. Чтобы понять, оно будет лучше чем Х или нет. Ну и касаемо самом FSD я видел его на 2х проектах в которых приходилось вносить доработки, это конечно было фрик шоу) Вполне ожидаемое фрик шоу, другого я и не ждал, ибо и так все понятно если просто взглянуть на эту мертворожденную концепцию)
Я же не извращенец или фанатик, я ленивый человек и если что-то добавляет удобства, я обязательно это использую. Если бы FSD приносил удобство по сравнению с классикой, я бы сразу же перевел все свои проекты на FSD и новые начинал с FSD. Или же если бы redux был удобнее чем mobx, я бы сразу выкинул mobx и перешел на redux. И т.п.
Простой пример из жизни, для большинства людей которые видят коровью лепешку на дороге достаточно просто ее видеть, чтобы понять что она не вкусная и вонючая) Для этого нет нужны к ней походить, пробовать ее на вкус и тд)
Или когда ты видишь кипящую воду(она вся такая бурлит) нет смысла совать в нее руку и проверять температуру, ты уже знаешь что это кипяток.
Вот и тут такой же принцип.
Можно себе сэкономить уйму времени и нервов, избежав такого рода экспериментов. Просто посмотри что перед тобой, проведи мысленный эксперимент и вуаля.
У меня в отличии от вас позиция не предвзятая и не фанатичная, а просто вытекает из фактов и простых принципов. Всё сугубо ради удобства и выгоды с точки зрения трудозатрат. Зачем мне на проекте применять подход Y, если с ним я в 2 раза больше времени трачу на реализацию таких же задач, как тратил бы если бы использовал подход X.
Например в 2016 году я считал что typescript это оверхед, с 2012 по 2016 ни разу TS не юзал, но в уже 2017 я пересмотрел свою позицию и с тех пор typescript only. До появления async/await в Node.js ноду я тоже не рассматривал в серьез как инструмент для написания бэка. Но JS эволюционировал, стал значительно круче и вуаля, в 2018 я уже писал бэкенд на Node.js с удовольствием.
Чем меньше опыта(в разрезе кол-ва проектов), тем меньше шанс что вы видели тот или иной подход.
Есть вещи не нуждающиеся в документации. Ибо они и так предельно ясны.
Это нуждается в документации? Нет, тут всё говорит за себя.
Более того, никто не запрещает на классику написать документацию. Это супер быстро и супер просто.
pages- для страницlayuots- для лейтаутовcomponents- для общих компонентоввложенная папка
components- для локальных компонентов, которые необходимы исключительно этой странице/компоненту/лейауту и т.п.Ну и так далее. Всё же элементарно. А вы опять какую-то смуту наводите, якобы тут что-то сложное, не понятное, бардак и т.п. Ну бред же.
Ахах. Ясно.
Так вы называйте вещи конкретно своими именами, не называйте стакан объектом, не называйте стул объектом по крупнее. Просто говорите стакан и стул.