Просмотр кода страницы 10 привычек довольного node.js разработчика

К концу 2015 года в распоряжении JavaScript разработчиков образовалось огромное количество инструментов. В этой экосистеме легко потеряться, поэтому успешные команды следуют выработанным правилам, которые позволяют не терять время и сохранять здоровье проектов. Под катом перевод статьи 2016 года от команды Heroku, в которой они рассказывают о десяти привычках веб разработчиков, у которых все работает и ничего не болит. Скорее всего 80% написанного вы уже знаете – тем интереснее вам будет прочитать об оставшихся двух приемах!


'''1. Начинайте новый проект командой npm init'''

Эта команда сразу создаст правильный package.json, основываясь на имени директории проекта и ваших ответах на вопросы визарда:

 $ mkdir my-awesome-app
 $ cd my-awesome-app
 $ npm init --yes


Использование флага --yes позволяет не отвечать на вопросы визарда, а в поле engines получившегося package.json можно сразу установить нужную версию ноды (node -v):

 "engines": {
   "node": "4.2.1"
 }


'''2. Используйте «умный» .npmrc'''

По умолчанию npm не записывает установленные зависимости в package.json (а за зависимостями надо следить всегда!).

Если вы воспользуетесь флагом --save для автоматического обновления package.json, то npm сохранит имя зависимости с префиксом ^. Семантическое версионирование ставит ваши зависимости под угрозу, так как при чистой инсталляции в проект могут установиться другие версии зависимостей, и кто знает, какие в них могут быть баги и проблемы. Такой способ хорош во время разработки, но не в продакшне. Одно из решений – сохранять точную версию зависимости:

 $ npm install foobar --save --save-exact


А еще лучше – поменять глобальные настройки npm в ~/.npmrc, чтобы все происходило автоматически:

 $ npm config set save=true
 $ npm config set save-exact=true
 $ cat ~/.npmrc


При такой конфигурации установка зависимостей сохранит точную версию и ваш проект никогда не настигнет жуткий “version drift”!

Если вы предпочитаете последние версии зависимостей во время разработки, плюс заморозку для прода, то вы можете воспользоваться функцией shrinkwrap. Такая конфигурация потребует несколько больше усилий, но позволит более гибко подойти к версионированию зависимостей.

'''3. Не упустите уходящий поезд ES6'''

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

 let user = users.find(u => u.id === ID);
 console.log(`Hello, ${ user.name }!`);


'''4. Придерживайтесь нижнего регистра'''

Некоторые языки рекомендуют именовать файлы так же, как классы. Например, файл, имплементирующий MyClass, предлагается называть MyClass.js. Не делайте так в node. Используйте нижний регистр:

 let MyClass = require('my-class');


Node.js это редкий пример линуксовой программы с великолепной поддержкой кроссплатформенности. Несмотря на то, что OSX и Windows будут считать файлы myclass.js и MyClass.js одним и тем же файлом, Linux так считать не будет. Если вы хотите писать кросс-платформенный код, вам необходимо именовать файлы в том же регистре, который вы используете для require.

Самый простой пусть сделать все правильно – это использовать нижний регистр, то есть my-class.js (примечание переводчика: или my_class.js, что все-таки популярнее среди программистов, нежели css нотация).
'''
5. Кластеризируйте ваше приложение'''

Так как процесс node ограничен одним ядром и полутора гигабайтами оперативной памяти, деплой некластеризованного приложения на мощный сервер является тратой полезных ресурсов впустую. Чтобы использовать несколько ядер и много памяти, добавьте в свое приложение поддержку кластеризации. Даже если сейчас вы запускаете приложение на одноядерной vps с гигом памяти, добавление кластеризации будет хорошим заделом на будущее.

Лучший способ найти оптимальное количество процессов это, конечно, тестирование. Но для начала подойдет значение по умолчанию, предлагаемое платформой. Ну и адекватный fallback, конечно же:

 const CONCURRENCY = process.env.WEB_CONCURRENCY || 1;


Использование кластеризации позволяет не изобретать велосипед для управления потоками. Если вам нравится разделение по файлам на “master” и “worker”, то попробуйте forky. Если же вы предпочитаете единую точку входа, то throng.

'''6. Следите за переменными окружения'''

Используйте переменные окружения вместо конфиг файлов. Для этого установите node-foreman:

 $ npm install --save --save-exact foreman


Затем создайте Procfile, чтобы указать тип приложения:

 web: bin/web
 worker: bin/worker


И установите альяс для запуска:

 "scripts": {
   "start": "nf start"
 }


Теперь, чтобы изменить настойки окружения, достаточно создать (и добавить в .gitignore) файл с именем .env, который будет автоматически загружен node-foreman:

 DATABASE_URL='postgres://localhost/foobar'
 HTTP_TIMEOUT=10000


С такими настройками достаточно одной команды npm start, чтобы запустить web и worker процессы, а затем прменить к ним настройки в соответствии с переменными окружения. Это намного проще, чем 'config/abby-dev.js', 'config/brian-dev.js', 'config/qa1.js', 'config/qa2.js', 'config/prod.js', итд.

'''7. Избегайте мусора'''

Node.js (в лице движка V8) использует «ленивый» и «жадный» сборщик мусора. С лимитом по умолчанию в полтора гигабайта он часто ждет до последнего, прежде чем освободить не используемую память. Если у вас постепенно растет использованная память, это может быть не ее утечка, а вполне штатное поведение сборщика мусора node.

Для лучшего контроля за сборщиком мусора, в Procfile можно поместить команды для движка V8:

 web: node --optimize_for_size --max_old_space_size=920 --gc_interval=100 server.js


Это особенно важно, если ваше приложение запущено на машине с менее чем полутора гигами доступной памяти. Например, для контейнера с 512 мегабайтами памяти строка аргументов может выглядеть вот так:

 web: node --optimize_for_size --max_old_space_size=460 --gc_interval=100 server.js


'''8. Используйте хуки'''

“Lifecycle scripts” в node.js предоставляют широкие возможности для автоматизации. К примеру, если вам нужно что-нибудь запустить перед сборкой приложения, вы можете воспользоваться скриптом preinstall. Нужно собрать ассеты с помощью grunt, gulp, browserify или webpack? Используйте скрипт postinstall. Все эти скрипты можно задать прямо в package.json:

 "scripts": {
   "postinstall": "bower install && grunt build",
   "start": "nf start"
 }


И конечно вы можете использовать переменные окружения для управления скриптами:

 "postinstall": "if $BUILD_ASSETS; then npm run build-assets; fi",
 "build-assets": "bower install && grunt build"


Если скрипты стали слишком сложные – перенесите их в файлы:

 "postinstall": "scripts/postinstall.sh"


Важно: скрипты в package.json выполняются с ./node_modules/.bin автоматически добавленным в PATH, так что вы можете напрямую вызывать локально установленные npm пакеты, такие как webpack. Это позволяет вообще не устанавливать пакеты глобально.

'''9. Only git the important bits'''

Мне настолько понравился этот заголовок, что я оставил его без перевода. Красивая игра слов – «гитуйте только важные биты» = «добавляйте в git только то, что важно». Большинство приложений состоят из файлов двух типов: которые можно или нельзя сгенерировать автоматически. Когда вы используете систему контроля версий, избегайте добавлять в нее файлы, которые можно сгенерировать автоматически.

Например, у вашего приложения есть директория node_modules с установленными зависимостями. Да, есть люди, которые добавляют ее в систему контроля версий! Не надо так делать. Указание нужных версий зависимостей в package.json намного надежнее, так как npm install не очищает node_modules, и если там уже будут файлы из системы контроля версий, может случиться беда.

Также добавление генерируемых файлов производит много лишнего шума в логах и нотификациях вашего репозитория. Более того, некоторые зависимости требуют компиляции при установки, так что добавление установленной версии в репозиторий делает ваше приложение непортабельным и может привести к странным ошибкам.
По тем же причинам не стоит добавлять bower_components или скомпилированные grunt ассеты. Если в проекте директория node_modules уже добавлена в систему контроля версий, то ее всегда можно убрать, например, вот так:

 $ echo 'node_modules' >> .gitignore
 $ git rm -r --cached node_modules
 $ git commit -am 'ignore node_modules'


Также я обычно добавляю в игнор логи npm, чтобы не засорять код:

 $ echo 'npm-debug.log' >> .gitignore
 $ git commit -am 'ignore npm-debug'


Игнорируя эти менее важные файлы, вы уменьшаете размер репозитория, упрощаете коммиты и не получаете конфликтов слияния.

'''10. Упрощайте'''

Предсказания в айти – дело неблагодарное. Но я все-таки сделаю одно. Предсказываю, что для JavaScript 2016 год станет годом упрощения.
Все больше программистов упрощают архитектуру своих решений. На смену монолитных MVC решений приходит статический фронтенд, который так удобно раздавать через CDN, и Node.js бэкенд для динамических данных.

Мы также начали замечать, насколько сложные системы сборки усложняют наши проекты. На острие прогресса разработчики упрощают эти решения, в частности, используя npm скрипты вместо bower, gulp и grunt.

И, наконец, в 2016 году мы будем упрощать написанный нами код. В ряде случаев это будет отказ от лишних фичей, как показал Douglas Crockford в своих The Better Parts. Или, наоборот, упрощение придет от добавления новой функциональности. Такой, как мои любимые async и await. В ноде их пока нет, но всегда можно воспользоваться транспайлером, например BabelJS.

Попробуйте не соревноваться друг с другом в том, сколько новых технологий можно запихнуть в один проект, а сфокусироваться на упрощении вашей работы.

'''ИСТОЧНИК:'''
<hr>
* [https://habr.com/company/Voximplant/blog/277707/ 10 привычек довольного node.js разработчика]