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

Я работаю с NodeJS последние 3 года в той или иной форме. Либо как часть стека полиглотов, использующего в основном Java, Scala и NodeJS, а также работающего с полным стеком сверху донизу NodeJS и JavaScript.

Я думаю, что JavaScript и, в частности, NodeJS отправляет вас в путешествие, если вы посвятили большую часть своей инженерной карьеры преимущественно типизированным языкам, таким как Java или Scala. Вы быстро переключаетесь между сильными эмоциями и мыслями в духе если бы у меня были типы, этого бы не произошло или я бы хотел, чтобы у меня были типы, этот рефакторинг был бы безопаснее. >» и что добавляет это свойство, кто, что, где мутирует мой объект!. Но также и более позитивные заметки о том, насколько простыми и чистыми могут быть вещи, а также общее ощущение от меня, особенно с введением многих функций ES6 в node 4.4 возможность писать компактный, чистый, выразительный код очень достижима и очень быстро развивается.

С введением полного стека javascript и возможностью не переключать контекст между языками нельзя недооценивать. Устранение необходимости менять парадигму или языковую конструкцию следует рассматривать только как положительное явление, которое повышает производительность и гибкость команды.

Другие языки, с которыми я работал, также страдали от проблем, которые демонстрируют тот факт, что ни один язык не совершенен. Опыт показывает, что у чрезмерно спроектированного корпоративного проекта Java и Scala также будет столько же проблем, что и у NodeJS, но они будут страдать от них по-разному.

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

Поскольку инженеры-программисты и предприятия решают проблемы, требующие создания веб-приложений, теперь их можно решать с помощью множества различных инструментов, включая NodeJS. Затем это приводит меня к ряду моментов, которые я всегда старался бы поощрять, когда берусь за проект NodeJS и JavaScript приличного размера, посмотрите, что вы думаете.

Распространенные запахи, советы и предупреждения

  • Внедрение хороших шаблонов на раннем этапе является ключевым — разбейте свой код, не оставляйте этот экспресс-маршрут с методом из 150 строк — рефакторинг, чистый код обязателен!
  • Всегда следует соблюдать постоянное использование TDD или, по крайней мере, теста сначала и во время захода на посадку. Некоторые могут не согласиться, но инструменты покрытия особенно полезны при проверке ветвей, в идеале — при отказе сборки, если она падает ниже порогового значения или значения предыдущей сборки. При использовании JS у вас есть полный и отличный набор инструментов тестирования, охватывающих различные стили и подходы тестирования, поэтому TDD всегда должен быть возможен.

  • В связи с отсутствием необходимости в сортировочных библиотеках, которые есть в других языках, таких как JAXB и встроенных в Spray, а также в отсутствии типов, принудительное использование точек входа в ваши службы и из них является обязательным. проверка схемы — например, Схема JSON, например, ajv ИЛИ joi средство проверки объектов json. Строго и строго применять объекты и структуры полезной нагрузки — совместно использовать эти библиотеки между вашим стеком и, возможно, компанией, вы должны быть уверены, что межсервисные переговоры, контракты и конструкции общих данных надежны.
  • В связи с вышеизложенным, я думаю, что строгое следование подходу порты и адаптеры (Гексагональная архитектура/DZone) к разработке приложений javascript и nodejs полезно, помогая уменьшить объем спагетти кода. а также повышение тестируемости и ремонтопригодности. Это можно сказать о большинстве, однако я думаю, что скорость того, как быстро приложение NodeJS может стать громоздким, означает, что это необходимо применять на ранней стадии.
  • Всегда используйте строгие и защитные инструменты линтинга, которые не смогут выполнить сборку, если будут обнаружены ошибки, например. eslint — это современный и многофункциональный инструмент для анализа. В некоторых моментах может потребоваться подавление ошибок линтинга, но это заставит вас задуматься и, возможно, изменить тактику.
  • Несмотря на то, что он не навязывает какую-либо структуру пакета, используйте его и развивайте по мере необходимости — он также имеет преимущества выделения дублирования и других шаблонов, которые затем можно очистить, отточить и реорганизовать с течением времени. Избегайте пакета catch all common/utils/helpers!
  • Не стоит недооценивать, как быстро большая и сложная часть JS может стать очень сложной для понимания, особенно из-за того, насколько она динамична — если это так, переоцените используемый шаблон и подумайте о рефакторинге.
  • Великолепие Node заключается в небольших легковесных, асинхронных, не сохраняющих состояния (насколько это возможно) процессах/функциях — не самых простых для достижения и спорных моментов, самая сложная часть этого — решить, где нарезать логику и где разделить домены. & обеспокоенность. Также подумайте о подобных библиотеках, небольших легких и целенаправленных фрагментах кода, которые можно комбинировать друг с другом и легко использовать совместно, даже между пользовательским интерфейсом и серверной частью.
  • Являетесь ли вы стеком типа обещание или обратный вызов… выберите метод асинхронной работы и придерживайтесь его во всем стеке. Я лично считаю, что промисы создают более чистый код, с которым легче работать, хотя в некоторых случаях они заставляют вас прыгать через несколько обручей, и обратный вызов может быть проще. Однако таких случаев гораздо меньше, чем когда можно попасть в ад обратного звонка.
  • Вам действительно нужна система сборки…? Я не уверен, что вам всегда нужна система сборки ворчание/глоток/брокколи, которая просто добавляет еще одну вещь для управления и обслуживания вместе с вашим постоянно растущим стеком NodeJS и многофункциональным пользовательским интерфейсом.
  • Используйте открытый исходный код — очевидно, вы не сможете использовать каждую библиотеку из-за лицензии, но не исключайте открытый исходный код — есть огромный талант разработчиков JS с открытым исходным кодом и их ретроспективных библиотек. Их стоит проверить, прежде чем приступать к написанию и поддержке другой библиотеки. (См. тестовую среду deride.js, которую мы активно использовали с большим успехом)
  • Внесите свой вклад в экосистему, если это возможно — если вы найдете ошибку в используемой вами библиотеке с открытым исходным кодом — исправьте ее и отправьте — в 9/10 случаях автор будет доволен и благодарен, исправляя ошибку для всех.
  • Будьте последовательны в отношении используемых вами шаблонов — Node не навязывает вам какие-либо определенные шаблоны, однако, если вы столкнулись с добавлением функции, и вы можете либо добавить новый шаблон, либо следовать существующему — следуйте ему и будьте строги в этом. Это улучшит производительность команды, а также упростит рефакторинг общности в будущем. Если был введен неверный паттерн — не делайте форк сразу, если он не является на 100% необходимым — поставьте тикет на его рефакторинг после добавления функции, которая требуется бизнесу — поддерживайте бизнес в рабочем состоянии ваша сторона.
  • JS имеет такой широкий спектр удобных для разработчиков и ориентированных на разработчиков инструментов. Многие из которых, на мой взгляд, намного проще и приятнее, чем некоторые инструменты Java/Scala — используйте их.
  • Используйте .editorconfig — использование .editorconfig поможет уменьшить шум в запросах на вытягивание и позволит вам сосредоточиться на изменениях, а не на форматировании.
  • Будьте явными с параметрами и сигнатурами методов — задавайте вопросы, которые кажутся неправильными — правильно ли это, могу ли я быть более явным, отражает ли это намерение, должен ли я использовать events, другой шаблон, неизменяемость, композиция, jsdoc?
  • Наконец, но, возможно, самое важное, узел — это однопоточная структура, основанная на цикле событий и не подходящая для длительных блокирующих процессов. Если выявится это требование, используйте для этого другие инструменты или языки, внедрите кэширование, организацию очередей, обработку событий, кластеризируйте свои приложения для масштабирования — не используйте их вслепую, когда это может оказаться неправильным.

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

Заканчивать

Я чувствую, что NodeJS может быть мощным, быстрым и очень приятным для работы фреймворком, однако он также приносит с собой свои проблемы и причуды. В некоторые дни я боролся с отсутствием типов, а в другие дни смирился с этим. Я думаю, что этот язык лучше всего использовать, если вы держите вещи маленькими, простыми и изолированными, которые, честно говоря, могут и должны применяться к большинству. Использование шаблонов для разделения абстракций, небольших модулей для разделения и изоляции кода, фабрик для сокрытия создания и внедрения с помощью таких инструментов, как rewire и deride, чтобы помочь в тестировании вашего кода. Сильная зависимость от тестов TDD и BDD, чтобы всегда прикрывать свою спину.

Если бы завтра я начал проект JS с нуля, мне пришлось бы рассмотреть некоторые из популярных в последнее время языков, таких как TypeScript. Используя его с Angular2, нельзя недооценивать такие функции, как проверка типов, автозаполнение, навигация и рефакторинг. Только время покажет, полностью ли мир JavaScript примет TypeScript или он будет только сторонником NG2.

Однако я бы с самого начала стремился использовать транспилятор, такой как babal,особенно для фронтенд-проектов — это позволяет вам разрабатывать с использованием новейшего набора ES6. /ES7 и преобразовать их в требуемую версию, даже поддерживая их запуск в IE8. Еще одна вещь, которую я хотел бы рассмотреть, это возможность использования async/await вместо промисов и обратных вызовов, функции ES7, которую я еще не использовал в гневе.

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

Ссылки