Коли поруч зібрано приблизно 5–7 файлів.

Лише коли більше 100 файлів.

Введення вкладеності ніколи не виправдане.

Приблизно яка кількість файлів поруч робить доцільним введення додаткового рівня вкладеності?

Перевірка знань базових архітектурних принципів організації файлової структури та іменування в сучасному фронтенді.

Організувати код так, щоб файли та сутності було легко швидко знаходити.

Завжди зберігати кожну функцію в окремому файлі.

Максимально заглиблювати структуру папок для чіткої класифікації.

Автоматично видаляти дублікати файлів при збірці.

Що означає принцип «Locate» при організації проєкту?

Іменування з префіксом util-.

Ім'я файлу з великої літери (PascalCase).

Додавання суфіксу .service до імені файлу.

Використання тільки числових імен файлів.

Яка конвенція іменування зазвичай вказує на те, що файл містить компонент у React чи Vue?

Коли файли належать до абсолютно різних доменів.

Коли кожен хелпер експортує по десятку несумісних інтерфейсів.

Коли утиліти тісно пов’язані між собою і утворюють єдину логічну сутність.

Завжди: менше файлів — краще.

Коли має сенс поміщати кілька пов’язаних хелперів в один файл замість розділення на багато файлів?

Старатися уникати дублювання коду, але не за рахунок порушення інших важливих принципів.

Категорично забороняти будь-яке дублювання за будь-яких умов.

Завжди дублювати код двічі для надійності.

Переносити всю логіку в утиліти, навіть якщо це ускладнює структуру.

Який зміст зазвичай вкладають у формулювання «Try to be DRY» щодо організації коду?

Тому що index.ts завжди містить лише конфігурацію.

Тому що кожен index.ts автоматично приховує свій вміст від IDE.

Тому що однакові імена в різних вкладеннях ускладнюють швидке визначення, який саме файл відкрито.

Тому що index.ts не підтримує експорти за замовчуванням.

Чому наявність великої кількості файлів з іменем index.ts ускладнює навігацію по проєкту?

Сліпо застосовувати їх без адаптації до проєкту.

Змінювати принципи на основі особистих уподобань кожного розробника.

Ігнорувати їх, якщо проєкт малий.

Перетворювати їх у конкретні правила та інструкції, адаптовані до потреб проєкту.

Як найкраще використовувати високорівневі архітектурні принципи при розробці конкретного проєкту?

Перенести всі файли в один великий файл для простоти.

Створювати нові вкладені папки для кожної дрібної функції.

Уникати зайвої глибини папок, зберігаючи оглядовість коду.

Зменшити кількість рядків у кожному файлі до мінімуму.

Що мається на увазі під принципом «Flatten» (уплощення структури)?

Питання 5 з 8