Давайте поговорим о том, почему заголовок этой статьи — кликбейт. Почему нет лучшей или худшей файловой архитектуры и почему не стоит доверять статьям, предлагающим такую.
«Как я структурирую свой проект React», «Архитектура CSS», «Как создать современную архитектуру внешнего интерфейса» и множество подобных статей, которые я читал, выглядят почти одинаково. Авторы много рассказывают о своем многолетнем опыте, количестве проектов, где они используют свою архитектуру, и о том, как жизнь улучшилась со всеми этими файлами и папками. Ну как можно не верить этим людям?
Каждая такая статья меня огорчает. Но не потому, что авторы ошибаются и папки у них неудобные, а потому, что это весьма субъективный, маловажный вопрос, вызывающий бурю гнева и споров.
Как вы используете свою IDE?
Пожалуй, это самый важный вопрос в теме «идеальная структура папок». Лично мне нравится использовать дерево файлов на боковой панели или ссылки в зависимостях. Но вы можете предпочесть быстрый поиск по имени файла, навигационным ссылкам, поиск по ключевым словам, именам функций/компонентов или просто оставить все файлы открытыми. Это разнообразие вариантов губит любую, даже самую удобную архитектуру — она никогда не будет подходить всем.
Например, я не люблю глубокую вложенность, потому что открывать четыре папки в сайдбаре, чтобы добраться до заветного index.js, — мучение. Однако, когда я использую ссылки зависимостей, все становится проще. Поиск по имени файла также не зависит от структуры папок, но я к этому так и не привык.
Это только кажется, что /components/forms/login/components/ лучшая вложенность для всех и каждого.
Поверьте, кому-то это будет неудобно.
А также единственную папку /components, которая у большинства разработчиков вызовет вопросы: а туда просто все положить? А если это целая страница? И даже если это небольшой компонент? Мысли «как улучшить эту слишком простую архитектуру» могут отнять довольно много времени, сил и мотивации.
Насколько вам нравится следовать правилам?
Скажем честно, я люблю, когда все по правилам и в порядке, но только если это мои правила.
Чем больше ограничений и регламентов, тем сложнее работать с проектом, ведь нужно все запоминать, не забывать, а главное — использовать.
Правила, записанные в тексте (или, что еще хуже, просто произнесенные) и контролируемые товарищами по команде во время код-ревью, неудобны и провоцируют конфликты. Поэтому я придумал следующую стратегию:
Все, что не имеет автоматического код-ревью — не имеет значения.
Конечно, это не относится к обзору алгоритмов, абстракций и потока данных, который следует выполнять. Это также не значит, что команда может превратить проект в свалку и писать каждый новый компонент по-новому. Но есть большая разница между автоматической проверкой стиля и ручным управлением любыми действиями разработчика.
Поверьте, у меня в личных проектах сотни правил именования файлов и папок, но в большом проекте с большой командой я буду создавать файлы именно так, как они были созданы до меня.
Конечно, вы можете убедить свою команду переписать все «правильно», но сначала ответьте на эти вопросы:
- Сколько времени вы потратите на это?
- Насколько сложно будет вашей команде перейти на новую архитектуру и привыкнуть к ней?
- Хватит ли у вас терпения следить за этим переходом и контролировать нарушения ваших правил?
- Каковы преимущества ваших изменений?
- Как долго ваша архитектура проживет без вас, если вы покинете проект?
Ответы помогут вам осознать важность вашего решения.
Существенные изменения и новые правила легко внедряются только в личных проектах. Однако когда мы говорим о команде из нескольких человек, сложность изменений возрастает в несколько раз. Поэтому речь идет не о том, чтобы рассказать, как это сделать правильно, а о том, чтобы нести ответственность за свое решение.
А как насчет вашего абстрактного мышления?
Когда мы смотрим на сложную структуру, наш мозг пытается разложить ее на части и выявить закономерности повторяющихся элементов. Так легче воспринимать информацию. Поэтому при программировании мы используем абстракции.
К сожалению, разработчики очень любят создавать абстракции, руководствуясь только принципом СУХОЙ. А это многое говорит об уровне абстрактного мышления современных специалистов.
Тот факт, что два компонента похожи, не означает, что они должны находиться в одной папке.
Например,
давайте создадим папку для страницы входа — login и поместим туда все компоненты.
А как насчет всплывающего диалога, который также имеет форму входа?
Должен ли мы поместили его в ту же папку?
Но всплывающее окно не на этой странице. На всех остальных страницах она в шапке.
Стоит ли класть ее в папку modals со всеми остальными попапами?
Но как тогда лучше переиспользовать общую форму?
Перенести форму на папка forms со всеми остальными формами?
Но тогда целостность папок страниц и компонентов разваливается…
Как видите, дырявая абстракция создает больше вопросов, чем пользы.
Абстракции сложны, а хорошие абстракции — почти недостижимая роскошь в современных, быстрорастущих и постоянно меняющихся проектах. Поэтому лучший совет — упрощайте, повторяйте, не группируйте все, что вам мешает. В большинстве случаев это ненужное излишество, усложняющее ваш проект.
Иначе вам, как и мне, будет стыдно за все эти папки forms и modals, utils и services, структуры типа components/common и прочие решения «на будущее», так как кто-то продолжает страдать из-за тех или надеюсь, не использует их.
Вместо заключения вспомните все «лучшие правила» структуры проекта, которыми вы пользовались на протяжении всей своей карьеры. Уверен, их будет несколько: отдельные HTML, CSS, JS по разным папкам; разделите компоненты и все, что с ними связано, по папкам; разделяйте «умные»/«глупые» компоненты, страницы, интерфейсы в разные папки. Это только часть моего списка. А что у тебя?
На мой взгляд, правила, которые постоянно меняются, не могут быть правилами. Так что не стоит бездумно следовать за ними, движимые ажиотажем. В то же время не стоит по привычке создавать стандартные папки utils, components и им подобные. Вместо этого сосредоточьтесь на том, что вы делаете и почему. Почему любое решение удобно для вашего проекта или наоборот не работает для вас.
Ответы на эти вопросы — основа хорошей архитектуры проекта.
Спасибо, что дочитали!
Увидимся в следующий раз! 🤹🏻♀️
Солов’їною:
