Найкраща структура файлів для вашого проєкту!
Давайте поговоримо про те, чому цей заголовок є приманкою. Чому не існує жодної “найкращої” або “найгіршої” файлової архітектури та чому не варто довірятися статтям, що рекомендують конкретну структуру.
“Як я структурую мій проект React”, “Архітектура CSS”, “Як створити сучасну front-end архітектуру” та багато подібних статей, які я читала, виглядають приблизно однаково. Автор багато розповідає про свій багаторічний досвід, про кількість проєктів, на яких він використовує свою архітектуру, та про те, як краще стало жити з усіма цими файлами та папками. Як можна не повірити цій людині?
Кожна така стаття змушує мене сумувати. Але не тому, що автор помиляється і його папки не зручні, а тому, що це глибоко суб’єктивне, неважливе питання, яке викликає бурю невдоволення та суперечок.
Як ви використовуєте своє IDE?
Можливо, це найважливіше питання у темі “ідеальна структура папок”. Особисто я люблю використовувати дерево вкладень у бічній панелі або посилання на залежності. Але ви можете віддавати перевагу швидкому пошуку за ім’ям файлу, посиланням у хлібних крихтах, пошуку ключових слів, назв функцій/компонентів або просто тримаєте всі необхідні файли відкритими. Саме це різноманіття варіантів руйнує будь-яку, навіть найбільш зручну архітектуру — ніколи не буде зручно всім.
Наприклад, я не люблю велику вкладеність, оскільки відкривати чотири теки в бічній панелі, щоб дістатися до index.js, це біль. Коли я використовую посилання на залежності, це стає простіше. Пошук за ім’ям файлу також не пов’язаний з архітектурою, але я так і не звикла ним користуватися.
Це тільки здається, що /components/forms/login/components — це найкраща вкладеність для всіх і для всього.
Повірте, комусь це точно буде не зручно.
Так само як і одна єдина тека components, яка викличе запитання у більшості розробників. Це що, просто все туди складати? І навіть якщо це ціла сторінка? І навіть якщо це маленький компонент? Розв’язання таких питань і роздумів на тему “як покращити цю занадто просту архітектуру” може забрати досить багато часу, енергії та віри у світле майбутнє.
На скільки сильно ви любите дотримуватися правил?
Давайте будемо чесними, я люблю коли все по правилах і все розкладено по поличкам, але тільки за умови, що це мої правила.
Чим більше обмежень та умов, тим важче працювати з проєктом, бо потрібно все запам’ятати, не забути та головне — використовувати.
Стилістичні правила, які прописані в тексті (або ще гірше — проголошені усно) та контролюються іншими розробниками під час рев’ю коду, є незручними та можуть викликати конфлікти. Тому я визначила для себе таку стратегію:
Все, що не покрите автоматичною перевіркою коду, не є важливим.
Звичайно, це не стосується рев’ю алгоритмів, абстракцій, потоку даних, для яких і має проводитися рев’ю. Це також не означає, що проєкт можна перетворювати на смітник та писати кожен новий компонент по-новому. Але існує велика різниця між автоматичними перевірками стилістики та ручним контролем будь-якої дії розробників.
Повірте, в моїх особистих проєктах я маю сотню правил найменування файлів та папок, але в великому проєкті з великою командою я буду створювати файли точно так само, як їх створювали до мене.
Звичайно, можна переконати команду все переписати “правильно”, але спочатку дайте відповіді на запитання:
- Скільки часу вам на це знадобиться?
- Наскільки складно вашій команді буде перейти на нову архітектуру та звикнути до неї?
- Чи маєте ви достатньо терпіння, щоб стежити за цим переходом та контролювати порушення ваших правил?
- Яку користь принесуть ваші зміни?
- Якщо ви залишите проєкт, скільки часу ваша архітектура протримається без вас?
Відповіді допоможуть вам усвідомити всю важливість вашого рішення.
Великі зміни та нові правила легко впроваджуються лише в особисті проєкти. Коли мова йде про команду з декількох людей, складність змін зростає у кілька разів, і потрібно вміти не лише казати, що правильно, але й нести відповідальність за своє рішення.
Як справи з вашим абстрактним мисленням?
Коли ми бачимо складну структуру, наш мозок намагається її декомпозувати та виділити закономірності в повторюваних елементах. Так легше сприймати інформацію. Тому, програмуючи, ми мислимо абстракціями.
На жаль, розробники дуже люблять створювати абстракції, керуючись лише принципом DRY. І це доволі непогано характеризує рівень абстрактного мислення сучасних фахівців.
Якщо два компоненти схожі між собою, це не означає, що вони повинні бути в одній папці.
Наприклад,
створимо папку для сторінки входу — login, всі компоненти покладемо туди.
Але що робити з випливаючим діалогом, в якому також є форма входу?
Покласти його в ту ж папку?
Але ж діалог не знаходиться на цій сторінці, він підключений в шапці на всіх інших сторінках.
Покласти його в папку modals, де знаходяться інші випливаючі вікна?
Але як тоді зручніше перевикористовувати форму?
Винести форму в папку forms, де лежать всі форми?
Але тоді руйнується цілісність папок сторінок та компонентів…
Як бачите, дірява абстракція створює більше питань, ніж приносить користі.
Абстракції це складно, а хороші абстракції — практично недосяжна розкіш у сучасних зростаючих і постійно змінюючихся проєктах. Тому найкраща порада — спрощуйте, повторюйтесь, менше групуйте все, що потрапляє вам під руку, у більшості випадків це зайве додаткове навантаження, яке ускладнює ваш проєкт.
Інакше вам, так само як і мені, буде соромно за всі ті папки forms і modals, utils і services, components/common структури та інші рішення “на майбутнє”, з якими тепер хтось продовжує страждати або в кращому випадку не користується.
А замість висновку, спробуйте пригадати всі “найкращі правила” для структури проєкту, які ви використовували протягом усього свого досвіду роботи. Я впевнена, що їх буде кілька: розділяти HTML, CSS, JS за різними папками; розділяти компоненти та все, що до них відноситься, за папками; розділяти за папками “розумні”/“дурні” компоненти, сторінки, інтерфейси. Це лише частина мого списку. А який він у вас?
На мою думку, правила, які постійно змінюються, не можуть бути правилами. Тому не варто слідувати їм бездумно, на хвилі гайпу. В той же час не варто створювати стандартні папки utils, components та подібні, просто за звичкою. Фокусуйтеся на тому, що ви робите та для чого, чому певне рішення зручне для вашого проєкту, чи навпаки, не працює саме для вас.
Це і є основою для гарної архітектури проєкту.
Дякую за те, що дочитали!
Побачимось наступного разу! 🤹🏻♀️
