Сюрреализм на JavaScript. Советы по разработке на NodeJS

По совету 4. Надо исключение хотя бы в консоль вывести, или в лог-файл — иначе отладка модулей превращается в какой-то ужас, когда ничего не работает — и причина не видна.

По совету №4 — в продакшене достаточно запускать приложение через forever или passenger, которые в случае падения переподнимут его. Более того, при тестировании удобнее и нагляднее будет если приложение упадет. Для логирования можно использовать сторонние модули, например, тот же Winston позволяет отлавливать исключения и продолжать работу приложения (не убивая его).

По приватным и публичным методам — это лишь соглашение, но никто не защитит от прямого вызова этих методов. Удобнее обернуть модуль в анонимную функцию, а в ней все публичные методы определить в объекте и его возвратить.

var module = (function() {
    var privateMethod = function() {
        // определение метода
    };

    return {
        publicMethod: function() {
            return privateMethod();
        }
    };
})();

По совету номер 6. В своем случае я использую стандартную систему модулей Node.js подгружая json

// config.json
{
    "param1": "value1",
    "param2": "value2"
}

// app.js

var config = require('./config.json');

config.param1 // value1

Совет 8. Почему бы не использовать существующие решения async и Q (кому что нравится)?

Вообще мне в сообществе node.js нравится тот факт, что на каждую задачу можно найти готовый модуль, решающий ее, не изобретая велосипедов (велотренажеры не в счет)

Поздравляю с успешным завершением этого в общем-то непростого предприятия :) Хотелось бы узнать подробности, например: сколько времени, финансов и прочих ресурсов нужно, чтобы издать что-то подобное?

А почему нельзя обойтись для первого совета просто конкатенацией строк? Читабельность запроса будет такой же. А вообще, разве в NodeJS нет никаких queryBuilder?

Любопытно… Интересно узнать, сколько времени и ресурсов надо, чтобы издать что-то подобное?

Обложку оформили — супер =)

Насчёт совета № 4 предостерегаю: употребление try…catch должно быть необыкновенно осторожным, потому что оно приводит к деоптимизации функций на движке V8 — а значит, и в Node.js.

Простой обёртке (которая внутри себя только вызывает другой метод) деоптимизация сильно не навредит. Но если внутри try…catch расположить нечто более сложное, то неизбежны проблемы со скоростью.

По 8 совету, использую замечательную библиотеку bluebird, обещания рулят!

Совет 1. SQL запросы лучше хранить отформатированными
Совет 2. Жизнь становится проще, когда API различных компонентов принимает на вход любой формат

Общий совет, подойдёт к любому ЯП.

Совет 3. Разукрасьте консоль и отформатируйте вывод информации

Как только Вы наиграетесь с консолью и начнёте весь лог укладывать в БД, Вы откатитесь к первоначальному нечитаемому логу. Решение более сложное. В development окружении сойдёт консоль, в production — уже нужно прибивать любую раскраску.

Совет 4. Оборачивайте все API в try/catch

Не используйте throw в runtime и не нужно ничего оборачивать. Используйте принятый стандарт записи callback-функции. function callback(err, result).

Совет 5. Собирайте запросы в конфиги
Совет 6. Выносите все в конфиги

Общий совет, подойдёт к любому ЯП.

Совет 7. Работа с файлами и Модуль Social Link для СЕО

Не понятно при чём здесь node.js вообще. Но вот следующее, я бы охарактеризовал как вредный совет:

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

Вы нарушаете саму идеологию асинхронного ввода/вывода, за что Вам будет больно.

Совет 8. Без callback`ов жизнь проще

Тоже в раздел вредных советов. Используйте callback`и. Не нравится, или говнокод получается — вас спасут promise`ы. Или не пишите на javascript, найдите другой язык… без колбеков.

Итого:
4 общих совета по программированию вообще. Даже не знаю зачем они, это приходит с опытом;
1 совет так себе, буду считать, что полезный (про консоль). Вреда от него не будет;
1 бессмысленный совет использовать try catch в асинхронном потоке исполнения ( скорее вредный );
2 совета вредных для javascript в принципе. (синхронная работа с вводом/выводом и боязнь коллбеков);

Очень много как велосипедов, так и вредных советов.

Логи — см. пост habrahabr.ru/post/209436/. Раскраска по уровню важности — бесполезна при последующем анализе лог-файла.Нужны тэги, такие же, как и для модулей. И не забывайте, что для ошибок в unix-way надо использовать stderr.

Конфиги — куча их готовых, см. например, minimist

Глушить экзепшены — сказали выше

Отказ от асинхронности — сказали выше

Последовательное выполнение — сказали выше (async или promises).

Пол года назад я подумал: «А может книгу написать?», и таки написал.

А вот это действительно очень круто! :) Респект.

По совету 8. Я бы вам посоветовал для этих целей посмотреть на стримы — весь прогрессивный мир их уже давно использует. Порой это даже более удобная высокоуровневая замена промисам.

Зачем вы вводите людей в заблуждение по поводу дебага nodejs?
Во-первых: nodejs умеет работать в режиме дебага из консоли.
Во-вторых: существует node-inspector который превращает хром в девтолзу для nodejs
В-третьих: В WebStorm встроена хорошая поддержка дебга, со всеми плюшками.

Блок try catch мало того что вреден для оптимизация и производительности, так он еще практически бесполезен в среде nodejs т.к. сможет отловить только синхронный код. 99.9% кода nodejs работают в асинхронном режиме, и вот их хоть тройным слоем try catch оберните, а ошибку не словите.

Без callback`ов может и проще, но это не дает вам права советовать применять синхронные функции вместо них. Хотите синхронности пишите на пхп, хотите синхронности в javascript пишите на javascript, но не давайте своих вредных советов. Для решения проблемы вложенности придумано уже много паттернов и библиотек. Самое простое и самое удобное это Promise. Они позволяют избавиться от Большего кол-ва проблем связанного с callback`ами, в том числе большая вложенность и отлова ошибок. Вскоре Promise станет частью языка, а знание их станет таким же обязательным знанию и пониманию. Про генераторы я просто помолчу.

В целом, книгу не читал, читать не собираюсь и если там уровень такой же как и в статье, то не советую ее читать, особенно новичкам.

/зануда on
Я так и не понял зачем главному исполнительному директору нужен модуль Social Link…

И не все советы полезны, некоторые даже вредны! Особенно меня коробит то, что вы призываете отказываться от коллбеков — главной фишки асинхронности! Это не правильно. Таких вещей не нужно бояться, к ним нужно привыкать и искать как работать с ними так, чтобы было удобнее.

Книга супер! И стиль, и картинки. Интересный материал. Спасибо!

Советы так себе, скажу вам.

• Тяжелые sql запросы следует хранить в отдельных *.sql файлах. И вообще, ребята, давно уже надо использовать es6, а там есть замечательные шаблонные литералы — и пишите себе мультилайн строки без всяких массивных хаков.
  
• Это вредный совет. Если функция должна принимать на вход sql query string, так чего это мы должны разрешать какой-то array, тем более если учесть, что первый пункт отпадает. Всегда желательно что бы функция была как можно конкретнее.
  
• Для дебага в консоли сойдёт, но тут ещё можно добавить группировки и различны уровни логов, как глобальные, так и групповые.
  
• В ноде большинство вызовов асинхронные, какие здесь могут быть try..catch? Если инстанс падает из-за ошибки — это баг, ошибка должна логироваться, а какой нибудь процесс-менеджер должен подымать процесс.
  
• Как и с первым пунктом, конфигурация не относится к коду и не должна там находиться. И вместо json лучше используйте yml, например.
  
• Подходит лишь для баш скриптов.
  
• Сколько можно уже мусолить тему callback-ов. Сколько же ненавистников есть, хотя ничего сложного в них нет. А совет с интервал какой-то смешной. Если уж хотите по одному файлу обрабатывать, так нужно использовать очередь, а не какой-то хак с секундным подёргиванием.
  

Вставлю свои пять копеек про try-catch, не мало уже прокомментировали, но как-то забыли про домены, которые рекомендованы быть заменой для отлова, исправления реалтайм ошибок. Кто не понимает особенностей работы try-catch и калбэков будет удивлен, почему ошибки не ловятся. Это скорее антисовет

А есть там что-нибудь про архитектуру crud-приложений (соц. сети и т.п.)?

Уже половину прочёл.
Читается хорошо — я её открываю как сказку перед сном. Какие-то моменты читал в «Графика на JavaScript», а некоторые знал до этого, но всё равно почему-то интересно читать.
Книга довольно сложная, не для новичков, из-за использованного словарного запаса, оборотов, резкого перехода от поверхностного описания в существенные детали.
Но, повторюсь, читаю как сказку на ночь, интересно!

Стал бы я её покупать? Нет, как-то не хочется. Не вижу её ценности, если открою через пол года.