Файловая структура проекта

Node Hero: Глава 7

Перевод книги Node Hero от RisingStack. Переведено с разрешения правообладателей.

Оглавление

Большинство Node.js-фреймворков не имеют фиксированной структуры каталогов и может быть непросто с самого начала проекта придерживаться правильной структуры. В этой главе вы узнаете, как правильно структурировать проект на Node.js, чтобы избежать сложностей, когда ваши приложения начнут расти.

5 основных правил структурирования проектов

Существует множество возможных способов организации Node.js-проектов и каждый из известных методов имеет свои плюсы и минусы. Однако, по нашему опыту, разработчики всегда хотят добиться одного и того же: чистоты кода и возможности легко добавлять новые функции.

В последние годы у нас в RisingStack была возможность создавать эффективные Node.js-приложения различного размера и мы получили много информации о том, что нужно, и что не нужно делать, когда занимаешься структурированием проекта.

Мы сформулировали пять простых правил, которые мы применяем во время разработки на Node.js. Если вы будете им следовать, ваши проекты будут в порядке.

Правило 1: Организуйте ваши файлы вокруг функций, а не ролей

Представьте, что у вас есть следующая структура каталогов:

// Неправильно
.
├── controllers
| ├── product.js
| └── user.js
├── models
| ├── product.js
| └── user.js
├── views
| ├── product.hbs
| └── user.hbs

Проблемы с этим подходом:

  • Чтобы понять, как работает страница product, вам нужно открыть три разных каталога с большим количеством переключений контекста
  • В конечном итоге вы пишете длинные пути при подключении модулей: require(‘../../controllers/user.js’)

Вместо этого вы можете структурировать Node.js-приложения вокруг функций продукта / страниц / компонентов. Это облегчает понимание:

// Правильно
.
├── product
| ├── index.js
| ├── product.js
| └── product.hbs
├── user
| ├── index.js
| ├── user.js
| └── user.hbs

Правило 2: Не помещайте логику в файлы index.js

Используйте эти файлы только для экспорта, например:

// product/index.js
var product = require('./product')
module.exports = {
create: product.create
}

Правило 3: Поместите тестовые файлы рядом с реализацией

Тесты предназначены не только для проверки того, генерирует ли модуль ожидаемый результат, они также документируют ваши модули (вы узнаете больше о написании тестов в следующих главах). Из-за этого легче понять код приложения, когда тестовые файлы находятся рядом с реализацией.

Поместите ваши дополнительные тестовые файлы в отдельную папку test, чтобы избежать путаницы.

.
├── test
| └── setup.spec.js
├── product
| ├── index.js
| ├── product.js
| ├── product.spec.js
| └── product.hbs
├── user
| ├── index.js
| ├── user.js
| ├── user.spec.js
| └── user.hbs

Правило 4: Используйте директорию config

Для хранения файлов конфигурации используйте каталог config.

├── config
| ├── index.js
| └── server.js
├── product
| ├── index.js
| ├── product.js
| ├── product.spec.js
| └── product.hbs

Правило 5: Положите свои большие npm-скрипты в каталог scripts

Создайте отдельный каталог для ваших дополнительных скриптов в package.json.

.
├── scripts
| ├── syncDb.sh
| └── provision.sh
├── product
| ├── index.js
| ├── product.js
| ├── product.spec.js
| └── product.hbs


Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.

Глава на GitHub

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.