Краткое вступление

Я собрал ниже 20 навыков, технологий и соображений по выбору между ними. Выбор правильных инструментов стал одной из наших самых больших проблем - экосистема Node.js созрела и предлагает привлекательные возможности практически во всех областях. Ваниль или TypeScript? Ава, Мокко или Шутка? Express, Fastify или Koa? а может Nest? должен ли я включать модули ES6 в свой следующий проект или придерживаться старого доброго «требования»? Смешение и сопоставление всего этого требует глубокого понимания последствий. Этот богатый набор инструментов и парадигм также побуждает вас на цыпочках отправиться на неизведанную территорию. Я надеюсь, что следующие пункты вдохновят вас на то, чтобы обогатить свой инструментарий и разнообразить себя.

Меня зовут Йони Голдберг, я независимый консультант Node.js, соавтор лучших практик Node.js и лучших практик тестирования JavaScript. Я работаю с клиентами из США и Европы над планированием, тестированием и усилением защиты их приложений.

Следуйте за мной: Твиттер, Блог, Информационный бюллетень, Мастерская тестирования

📗 Хотите довести свои навыки тестирования до предела? Рассмотрите возможность посещения моего всеобъемлющего курса Тестирование Node.js и JavaScript от А до Я

Проверено и улучшено Бруно Шойфлером

1. Обдуманно используйте возможности TypeScript.

TypeScript стремительно развивается: потрясающая диаграмма здесь, показывающая увеличение PR TypeScript в 5 раз, устраняет любые сомнения, исследования говорят, что он предотвращает ошибки, и сообщество в восторге. Хотя некоторые все еще сомневаются в этом (посмотрите этот замечательный и аргументированный пост Эрика Эллиота), очевидно, что TypeScript победил. Что теперь? Если вы внимательно посмотрите на шумиху, TypeScript фактически предлагает два взаимоисключающих предложения: безопасность типов (включая улучшенную документацию и intellisense) и расширенные конструкции дизайна. Многие команды используют TypeScript для повышения безопасности типов, но непреднамеренно, без какого-либо надлежащего планирования, также используют его причудливые функции - генерации, абстрактные классы, интерфейсы, пространства имен и т. Д. Эти команды меняют свой стиль дизайна с ванильного JavaScript на фантастический ООП непреднамеренно из-за закона инструментов - когнитивной предвзятости, которая предполагает использование имеющихся инструментов, независимо от того, являются ли они правильным выбором для миссии или нет. Другими словами, если абстрактный класс существует в наборе инструментов, разработчики будут использовать его. Если вы предпочитаете вышеупомянутые методы кодирования - это справедливо, продолжайте. Просто не меняйте код и стиль дизайна по неправильным причинам.

Примеры:

  • Выведение типов может помочь уменьшить многословие TypeScript и сделать его более похожим на ванильный JavaScript.
  • Псевдонимы типов - это альтернативный простой и более компактный способ определения конструкций (по сравнению с интерфейсами).
  • Используете TypeScript для инкапсуляции? Модификаторы доступа скоро появятся в vanilla JS

2. Модернизируйте свой набор инструментов для тестирования. Ava и Jest меняют правила игры

В области тестирования происходят большие события. Согласно недавнему обзору состояния js, удовлетворенность разработчиков инструментами тестирования возрастает больше, чем любой другой предметной областью. В тестовых бегунах происходит революция, а старые добрые ветераны Мокко и Жасмин проигрывают новым искушенным детям в городках Джест и Ава. Благодаря современному подходу, который они привносят, можно больше тестировать, исследовать больше и находить больше ошибок. Почему?

  1. Скорость - современные исполнители тестов работают быстрее благодаря модели выполнения нескольких процессов. Они также применяют расширенные оптимизации, такие как изучение статистики тестов с течением времени и приоритизация медленных тестов, запускаемых первыми. Речь идет не только о средствах запуска тестов, но и о других инструментах, которые также повышают скорость тестирования: поддельная база данных в памяти позволяет тестировать с помощью БД без участия ввода-вывода, некоторые пакеты npm предлагают локальную версию популярных облачных сервисов и версию в памяти. Назову несколько примеров.
  2. Великолепный опыт разработчиков - современные средства запуска тестов и инструменты предназначены для сопровождения процесса кодирования и предоставления ценной информации. Например, если тест не пройден, Jest и Ava не просто сообщат об ошибке, а извлекут соответствующий код из тестируемого модуля. Благодаря этому разработчики получают более богатый контекст, что приводит к более быстрому разрешению

Некоторые из традиционных инструментов были разработаны для CI или для периодического выполнения тестов. В случаях, когда команды развертываются один раз в день, обнаруживать ошибку через 4 часа недостаточно. Современные инструменты позволяют запускать тесты, в том числе тесты компонентов с БД, постоянно даже во время кодирования. Этот подход позволяет раньше тестировать больше уровней и вариантов использования, и он называется «сдвиг влево» - подробнее об этом ниже.

Примеры:

  • AVA и Jest - новые искушенные дети города.
  • Mongodb-memory server отлично подходит для тестирования с сервером MongoDB - он устанавливает, создает и настраивает локальный и настоящий Mongo с движком в памяти.
  • Cypress превращает тестирование E2E, в том числе тесты, связанные с API серверной части, приятным опытом.
  • Aws-sdk-mock подделывает многие сервисы AWS

3. Спланируйте стратегию использования модулей ES6. Видишь ли, это немного сложно

Долгожданные модули ES6 были не помечены недавно, так что у вас может возникнуть соблазн сразу же их использовать. Они открывают широкие возможности для Node Land, такие как современный синтаксис для импорта модулей, совместимость с синтаксисом внешнего интерфейса (важно для сопровождающего пакета, которому необходимо поддерживать как среду выполнения Node, так и браузер) и разрешение асинхронных модулей, открывающее двери для async-await и лучше дерево трясется. Прохладный. Однако есть некоторые последствия, о которых следует знать, прежде чем переходить на универсал ESM: еще не все поддерживающие функции реализованы. Например, пока неясно, как библиотеки тестовых двойников, такие как Sinon и Jest, могут имитировать такие модули, чтобы ваш вагончик мог разбиться дымом на обочине дороги.

Учитывая все эти соображения, какова ваша стратегия: прыгнуть прямо в воду ESM и работать над проблемами? или использовать ESM с babel / TS в качестве подстраховки? может быть, продолжать использовать золотой старый общий js «require», но избегать несовместимого синтаксиса, такого как использование __filename, __dirname, разрешение JSON и других? здесь нет строгих ответов, но, по крайней мере, мы стремимся задавать правильные вопросы

Спасибо Гилу Тайару за эти замечательные идеи.

Примеры:

4. Познакомьтесь с новейшими функциями JavaScript, которые скоро станут зелеными.

Я не большой поклонник погони за каждой новой языковой функцией, иногда эти блестящие игрушки работают против простоты кода и проясняют. Однако время от времени появляются некоторые действительно ценные функции Javascript, поэтому стоит посмотреть список Предложение TC39 и node.green, чтобы определить привлекательные новые функции, которые подходят вашему стилю кодирования.

Примеры:

  • Необязательная цепочка находится на этапе 4 и является частью Node.js 13.3 за флажком. Этот будет очень популярным. Некоторым нравится, другим нет
  • Частные методы и поля находятся на этапе 3 (активные предложения), поэтому, если вы выбираете TypeScript только для инкапсуляции - теперь есть еще один вариант на выбор.
  • Нулевое объединение (этап 4) наконец положит конец нашей неприятной привычке проверять наличие нулей и неопределенных значений с помощью синтаксиса! VariableName (который также включает ноль и, следовательно, подвержен ошибкам)
  • Promise.any - это последнее издание семейства обещаний. {Something}, в отличие от всех остальных (обещание.all, обещание.settleAll, обещание.раса), оно будет прервано, если какое-либо обещание разрешится или отклонится. Это один из последних гвоздей в крышку гроба вспомогательных библиотек Promises, таких как async и BlueBird.

5. Экспериментируйте с архитектурой за пределами вашей зоны комфорта. Обратите внимание, как GraphQL разрушает традиционные модели

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

Убедитесь, что вы знакомы с многоуровневыми архитектурами, такими как n-tiers, DDD, Hexagonal / Onion / Clean. Они выглядят очень по-разному, но их основной принцип схож - изоляция домена (то есть базовой схемы данных и бизнес-логики) от окружающих технологий (например, API, БД). Познакомьтесь также с архитектурами стилей потоковой передачи, популярность которых растет. Затем потратьте некоторое время на архитектуру, управляемую данными, которая в настоящее время лучше всего реализуется с помощью фреймворков GraphQL.

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

Примеры:

  • Это видео Dev Mastery о чистой архитектуре - настоящая жемчужина. Он также включает стартовый пример dev-mastery comments-api.
  • Node-api-cabinplate - отличный стартер с мышлением DDD.
  • Prisma server позволяет запускать приложения без бэкэнда, управляемые данными.
  • Apollo server - это среда на основе GraphQL для создания приложений, основанных на схемах Graph.
  • Express-graphql приносит пользу GraphQL, не заставляя выходить из удобной среды Express.

6. Узнайте о победителе «Оскара 2019» - Nest.js.

Спустя годы экспресс-жизни нам понадобится небольшое гнездо (js). При таком потрясающем росте это просто невозможно игнорировать. Я бы сказал, что Nest.js - самое замечательное, что случилось с Node.js в 2018/2019 годах - впервые у нас есть полноценная консенсусная среда, такая как Java Spring и Python Django. До 2018 года командам без сильных дизайнерских навыков приходилось проектировать свои серверные части, проводить время за сантехникой и изобретать колесо. Как человек, который участвует в ~ 15 проектах каждый год, поверьте мне, я видел так много типов колес. Очень много. Мой друг и коллега Гил Тайар забавно приспособил принцип Анны Карениной к программному обеспечению: Все счастливые проекты похожи; каждый неудачный проект несчастлив по-своему .

В отличие от Express & co., Nest.js предлагает полноценную инфраструктуру с включенными батареями (например, обрабатывает уровень доступа к данным, проверку и т. Д.). Его стиль дизайна очень «вдохновлен» Angular - самоуверенным, основан на TypeScript и воплощает в себе тяжелые конструкции модульности. Тем не менее, он по-прежнему предлагает большую гибкость при выборе подфреймворков. Учитывая все эти плюсы, я не сомневаюсь, что команды, делающие свои первые шаги с Node.js, будут двигаться намного быстрее с Nest.js, а не с минималистичным подходом Express.

При всем своем величии он не безупречный. Можно сомневаться, соответствует ли модульный подход Angular, который был разработан, чтобы облегчить боль огромной кодовой базы внешнего интерфейса, потребностям серверной части? Разве мы не перескочили от минимального Express к огромному и столь самоуверенному фреймворку? нужны ли все эти тяжелые модульные функции в мире небольших микросервисов? или эквивалент, разве это не продвижение монолитов («Я легко могу обработать 30 000 LOC в моей кодовой базе»)?

По крайней мере, теперь у нас есть возможность выбирать.

Примеры:

7. Применяйте методы постепенного развертывания, такие как отметка функций, канарейка или затенение трафика.

Вы слышали об эпическом Cloudflare d owntime, когда разработчик, который хотел поэкспериментировать с какой-то функцией в производственной среде, отключил большую часть Интернета? Ничто не повысит вашу уверенность и скорость, чем знание того, что ваш механизм развертывания улавливает ошибки раньше ваших пользователей. Эту магию обеспечит куча техник. Каждый из них достигает этого по-своему, но общая идея одна - предоставить следующую версию ограниченной группе пользователей и измерить, насколько она стабильна. Следуя этому подходу, мы фактически отделяем фазу развертывания от фазы релиза. Некоторые говорят, что это так же важно, как как тестирование, я предлагаю, чем все, что измеряет наш конвейер, является ТЕСТом.

Что это за техники? Канарейка - самая известная и простая. Он настраивает маршрутизацию, поэтому следующая версия развертывается и обслуживается группе пользователей, начиная с того, что пользователи с большей вероятностью будут терпеть ошибки (например, офисный сотрудник, неплательщики), и по мере роста доверия она обслуживает все больше и больше пользователей. Это может показаться сложным, но такие фреймворки, как istio для K8S и AWS serverless, берут на себя большую часть тяжелой работы. Следующая техника, пометка функций, более эффективна, но также требует, чтобы ваша рука испачкалась. По сути, он предлагает обернуть код функции с критериями условий, которые говорят, какие пользователи должны получить преимущества от этой новой функции. Обычно он также поставляется с панелью управления, на которой менеджеры по продукту могут включать и выключать функции. Это позволяет нетехническим пользователям участвовать в вечеринке, а также поддерживать более тонкие расширенные критерии. Например, с помощью флагов вы можете активировать некоторую экспериментальную функцию только для пользователей из определенного города, на конкретном экземпляре компьютера с определенным браузером. Еще один супер-интересный метод, на который стоит обратить внимание, - это слежение за трафиком, о котором я оставлю вам читать.

Ценность этих методов огромна: в отличие от тестирования кода, которое требует постоянных больших усилий, настройка маршрутизаторов для канареечного развертывания происходит только один раз (!), А также «тестирует» ваш код в реалистичной производственной среде. Узнайте об этом увлекательном мире и внедрите одну из этих техник в свой конвейер.

Примеры:

  • Fflip - это минималистичная и бесплатная функция отметки для Node.js.
  • Unleash - это многофункциональная функция, включающая панель инструментов для разработчиков продукта.
  • легко испортить свой код, пометив функции, сначала прочтите некоторые лучшие практики
  • Kubernetes istio значительно упрощает настройку канареечного развертывания.
  • С AWS serverless настроить канарейку очень просто
  • Введение в слежку за трафиком

8. Сдвиньте тестирование влево - проверяйте больше и раньше.

Концепция сдвига влево выдвигает разумное утверждение - чем позже обнаружена ошибка, тем дороже ее исправить. Рассмотрим случай, когда вы обнаруживаете проблему с производительностью поздно в промежуточной среде, после короткого анализа выясняется, что необходимо изменить фундаментальную модель данных БД - это, вероятно, повлечет за собой значительные изменения кода. Некоторые исследователи утверждают, что это может стоить в 640 раз дороже, если ошибка обнаруживается слишком поздно в производственной среде. Проще говоря, традиционная модель, в которой разработчик сосредоточен только на модульном тестировании, а через несколько недель QA выполняет реалистичный E2E, а расширенные тесты являются медленными и дорогостоящими. Эта хорошо известная диаграмма благополучно подводит нас к этому моменту.

Тестируйте больше вещей раньше, рано обнаруживайте ошибки. Как воплотить эту идею в реальные задачи развития? запускать разнообразный набор тестов как часть каждой фиксации и даже во время кодирования: тесты компонентов / API с реальной (в памяти?) БД, точно так же, как вы запускаете модульные тесты, тесты с реалистичным производственным вводом с использованием специальных библиотек на основе свойств, применение безопасности сканеры, запускайте нагрузочные тесты производительности и многое другое. См. Ниже список с десятками тестов, которые можно запустить по конвейеру.

Примеры:

  • Пакет быстрой проверки npm для тестирования на основе свойств позволяет вызывать ваши модули / API с множеством входных перестановок.
  • Проверьте наш фреймворк и инструменты для сканирования docker-контейнеров на наличие CVE, таких как snyk, Trivy, Quay.
  • Настройка вашей реальной БД для работы в памяти без ввода-вывода сделает практичным запускать тесты api / component мгновенно, почти как модульные тесты: вот как вы настроили бы PostgreSQL (вот готовый к использованию -use dockerized version), mongodb-memory server установит и настроит локальный и настоящий Mongo с движком в памяти.

9. Сдвиньте свое тестирование вправо - тестируйте в / с продукцией.

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

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

Примеры:

10. Будьте готовы использовать свой новый карманный нож async - рабочие потоки

Самый популярный вопрос на собеседовании по Node.js может скоро исчезнуть: «действительно ли Node.js однопоточен?». Начиная с версии 11.7, мы приветствуем нового члена семьи в наборе инструментов async - рабочий поток. Этот инструмент, в отличие от любого другого, может устранить очень болезненные слепые пятна в Node. Если 100% запросов загружают процессор, никакие веб-фреймворки, в том числе Go и Java, не помогут приручить этого зверя. Однако более популярна рабочая нагрузка, когда только 1–10% запросов захватывают ЦП на длительное время - большинство фреймворков, не относящихся к Node, предотвращают это автоматически (поток на запрос). Node.js не может - при обслуживании 1000 запросов в секунду достаточно, чтобы 1 требовал загрузки ЦП, чтобы пострадали все остальные 999. От этой боли не было лекарства, дочерний процесс, например, слишком медленный, чтобы раскручиваться, и не может делиться памятью. Хорошие новости, теперь это можно изменить: рабочие потоки могут запускать выделенный цикл обработки событий, поэтому основной цикл будет оставаться быстрым.

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

Примеры:

11. Углубите свое понимание Docker и Kubernetes. Это сильно влияет на ваш код Node.js.

Шторм DevOps означает разные вещи для разных команд. Для некоторых это означает, что Dev выполняет также работу Ops (например, дежурит по вызову), для других это скорее рекомендация заранее спланировать производство. Как минимум, от разработчиков ожидается, что они будут разбираться в производственной среде, поскольку она сильно влияет на решения и шаблоны кодирования. В основном это решения, которые находятся на пересечении Dev и Ops.

Несколько примеров: это хорошо известная практика, чтобы гарантировать, что все исходящие запросы воспроизводятся при сбоях (шаблон автоматического выключателя), это можно сделать как на уровне инфраструктуры с помощью K8S Istio, так и в самом коде с использованием выделенных пакетов. Что бы вы предпочли и почему? интересный выбор, не правда ли? Давайте обсудим другие сценарии - K8S может убивать и перемещать поды, когда он посылает сигнал об уничтожении, веб-сервер может обрабатывать 2000 пользователей. Когда модуль просто выходит из строя, они быстро разозлятся 2000 пользователей, если вы не осуществите изящное и продуманное завершение работы. Что такое льготный период? ну, это требует некоторого обучения Kubernetes, не так ли? Иногда сигналы об уничтожении от K8S даже не доходят до вашего кода, если вы используете команду npm start, почему? для этого требуется некоторое понимание того, как управляются процессы и сигналы Docker (1-я ссылка ниже ответит на этот вопрос). Еще одна интересная проблема заключается в разрешении двух противоречащих друг другу вещей: как инструменты тестирования могут работать в контейнерах Docker во время конвейера, а затем удаляться перед производством? Последний интересный пример - настройка разрешенной памяти для каждого контейнера, учитывая, что v8 недавно перестала ограничивать размер кучи, который теперь будет расти по мере необходимости, это может повлиять на ограничения ресурсов K8S (общая передовая практика) - принять решение и согласовать Сторона Node.js со стороной K8S

все эти проблемы призывают вас глубже погрузиться в увлекательный мир кластеров Docker (или бессерверных, если хотите).

Примеры:

12. Безопасность: научитесь думать как злоумышленник, просматривая примеры уязвимого кода.

Если вы не можете думать как нападающий, вы не можете думать как защитник. В 2020 году вам не следует передавать оборонные работы сторонним компаниям или полагаться исключительно на статические сканеры безопасности: количество типов атак огромно (конвейер разработки и NPM - последние тенденции). Ключевым моментом является обучение разработчиков: внедрите ДНК безопасности в себя и свою команду и добавьте элементы безопасности ко всему. Полезный способ углубить понимание безопасности - рассмотреть примеры уязвимого кода и векторов атак. См. Ниже несколько примеров ссылок, которые могут сильно помочь

Примеры:

  • NodeGoat - это проект, который намеренно воплощает недостатки безопасности в образовательных целях. Не пропустите эту страницу с примерами атак
  • Прочтите мой список лучших практик безопасности Node.js, который содержит более 23 идей атак, включая примеры кода JavaScript.
  • Ежемесячно проводите собрание по анализу угроз, на котором команда пытается изучить дизайн приложения и предложить атаки. звучит скучно? не обязательно, если вы добавляете некоторую геймификацию и награждаете участников, которые находят эксплойт, или запускаете соревнование между синей командой, которая разрабатывает модуль, и командой чтения, которая пытается найти эксплойты

13. Выучите хотя бы одно: ELK или Prometheus.

Мониторинг - это важная установка, которая должна быть хорошо усилена и требует сотрудничества между Ops и Dev. Ни одно решение для мониторинга не может быть совершенным без участия разработчиков. Эти две популярные системы мониторинга, ELK и Prometheus, звучат как игрушки для системного администратора, но на самом деле разработчики могут многому научиться, настроив их. В любом случае обязательным действием для разработчиков является раскрытие метрик.

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

Примеры:

14. Используйте машинное обучение как продукт черного ящика.

Этот маркер предназначен для новичков в области машинного обучения (ML), которые работают с продуктами, которые не сильно зависят от ML. Если вы не один из них - смело переходите к следующему пункту. Так что вы, как и я, не имеете ни малейшего представления о машинном обучении, это справедливо, мы намеренно решили не накапливать опыт в этой области. Тем не менее, мы можем добиться большего, если просто поймем общие потребности и решения машинного обучения, чтобы использовать их, когда возникнет необходимость. Мир JavaScript ML созрел до такой степени, что существует множество стабильных библиотек, которые могут принести большую пользу без глубоких знаний о реализации. Если мы просто понимаем, ЧТО они делают (+ как настраивать) - мы получаем специальный молоток к нашему набору инструментов. Когда это может оказаться ценным? скажем, вы сидите на собрании, и менеджер по продукту упоминает что-то об организации данных (например, клиентов) в группы - предложите использовать кластерные алгоритмы. Подачи данных в адекватную библиотеку может быть достаточно для получения важных идей. Часто вам нужно получить больше знаний, чтобы правильно его настроить - это справедливо, наймите эксперта, станьте экспертом, по крайней мере, вы знали, с чего начать, и структурировали путь решения. Кто-нибудь теперь спрашивает, что можно порекомендовать пользователю? классифицировать вещи? Находите сходство между текстами? предсказывать? анализировать аудио или изображение? для каждого из них есть своя библиотека - вытаскивайте оружие в нужный момент

Очевидно, лучше вникнуть в детали и прочитать инструкции. Ни в коем случае я предлагаю неосторожное использование технологий. Однако я действительно предлагаю познакомиться с высшими уровнями лучше, чем ничего не знать, и это может создать мотивацию для продолжения исследования. Если я неправильно использовал вышеупомянутую таксономию машинного обучения - пожалуйста, поймите, я только начал свой путь к машинному обучению

Примеры:

  • Ml.js - швейцарский армейский нож инструментов машинного обучения
  • Brain.js специализируется на нейронных сетях, имеет отличную документацию и бесплатный видеокурс.
  • Natural переносит мир НЛП в страну узлов: сравнение текстов и сходства, анализ тональности, классификация текста и многое другое.

15. Сон ›7 часов в сутки. Это имеет гораздо большее значение, чем любая технология, которую вы используете и научно доказали, чтобы стать лучшим разработчиком.

Это от Хиллела Уэйна, и это один из лучших твитов, которые я встречал за последний год:

качество вашего сна и уровень стресса имеют гораздо большее значение, чем языки, которые вы используете, или методы, которым вы следуете. Ничто другое и близко не подходит: ни системы типов, ни TDD, ни формальные методы, ни НИЧЕГО.

Он полон примеров и исследований - я призываю вас побывать там и покопаться в этих жемчужинах мудрости.

Примеры:

16. Закройте Express, он устарел и не обслуживается должным образом. Fastify и Koa - отличные кандидаты в 2020 году

Вы не забыли обернуть все свои маршруты Express с помощью try-catch, затем перейти к методу next () и, наконец, вернуть пользователю соответствующий статус? Если нет, ваш процесс потерпит неудачу без следа. Если да, то вы просто отлично провели время, устанавливая простые детали, которые не добавляют ценности вашему бизнесу. Разве не для этого существуют фреймворки? Хотя Fastify и Koa не будут обрабатывать все пути ошибок (например, неперехваченные исключения), они решают эту проблему с помощью современного подхода, который требует меньше усилий. Оба они также изначально поддерживают асинхронные маршруты. Это всего лишь несколько примеров, когда современный и поддерживаемый фреймворк может вам помочь.

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

Тем не менее, большинство инструментов и документации сообщества полагаются на Express. Я надеюсь увидеть лидеров сообщества, разработчиков курсов, блогеров, создающих больше контента о его современных альтернативах.

Примеры:

17. Вернемся к этим спискам прошлого года - некоторые по-прежнему актуальны.

Я опубликовал похожий пост в 2019 году, и многие из пунктов кажутся важными и в 2020 году. Вот некоторые конкретные рекомендации:

Примеры:

18. Расширьте свой CI с помощью автоматизированных инструментов контроля качества.

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

Примеры:

  • Проверять Docker-контейнеры на наличие CVE с помощью таких инструментов, как snyk, Trivy, Quay.
  • Lockfile-lint будет обнаруживать попытки внедрения вредоносных зависимостей с помощью файла блокировки npm (например, редактировать URL-адрес зависимости в файле блокировки)
  • Swagger-express-validator обеспечит соответствие ваших маршрутов схеме swagger
  • Eslint-plugin-import - отличный линтер, который выполняет десятки проверок модуля и разрешения зависимостей. Например, он может предупреждать, когда import / require не находится в начале, запрещать изменяемый экспорт с var или let, discoverextraneous пакетами, которые не объявлены с package.json, и многое другое.
  • Commitlint будет принудительно выполнять семантические коммиты, которые затем могут привести к автоматическому семантическому управлению версиями микросервисов и пакетов.
  • Dependency-cruiser - это инструмент командной строки, позволяющий объявлять гибкие политики для разрешенных и запрещенных зависимостей. Используя это, вы можете создавать собственные правила, например, какие лицензии разрешены, разрешенные пути и многое другое.

19. Обогатите свое мышление, разнообразьте свой набор инструментов.

Мы часто окружаем себя любимыми технологиями и игнорируем альтернативы, основанные на предубеждениях. Вот несколько типичных предложений, которые я слышу в своей сети: «Функциональное программирование непрактично», «REST API мертв, TDD не для меня», «ORM - это зло», «TypeScript слишком многословен».

Это ложные дихотомии - это не бинарный вопрос, все эти парадигмы воплощают в себе множество разных идей, и тем не менее мы склонны выбирать все или игнорировать все. Например, каррирование и монады функционального программирования кажутся странными? Это справедливо, рассмотрим другие более распространенные идеи FP, такие как чистые функции. Игнорирование TypeScript из-за того, что ООП не в вашем стиле? возможно, использовать только его систему типов и придерживаться ванильных объектов и функций JS. Идеи и особенности Cherry-pick, а не пакет.

Как именно я планирую диверсифицировать свой стек в 2020 году? Я, вероятно, буду использовать Fastify для веб-слоя с смесью REST и GraphQL. Уровень доступа к данным будет представлять собой некоторую легкую ORM, но только для миграции и объединения соединений (без дихотомии, я выбираю правильные функции ORM для себя). Что касается БД, то я планирую использовать реляционную БД, смешанную с столбцами JSON. Мой стиль кодирования основан на простых и плоских ванильных объектах JavaScript, но я обычно смешиваю его с некоторыми классами, когда это необходимо, и сохраняю большинство своих функций в чистоте. Общий стиль архитектуры будет сосредоточен вокруг микросервисов, но, возможно, в монорепозитории - я не обязан выбирать все навороты микросервисов, верно? Что касается тестирования, я определенно хочу выполнить итерации рефакторинга в стиле TDD для своего кода, но не обязательно сначала кодировать тесты - я выбираю функции TDD, которые подходят моему стилю. Какой вид тестирования? в основном тесты компонентов (например, api), но смешайте это с модульным тестированием, чтобы охватить части с тяжелой логикой.

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

p.s. Я не выступаю за то, чтобы стать мастером слишком большого количества сделок. Собственно овладение некоторыми технологиями важно. Я хочу быть прагматичным и открытым для великих идей. Не будьте «этим парнем с отверткой», обогатите свое мышление, разнообразьте свой набор инструментов

20. Вдохновляйтесь этими 5 стартовыми проектами.

Начальные (шаблонные) проекты являются подлинным источником знаний - просто просмотрите код в течение 10–20 минут и получите множество идей, которые можно использовать. Я собрал здесь несколько качественных стартеров, каждый из которых предлагает уникальный подход, чтобы вы обогатили свое мышление новыми парадигмами.

Примеры:

  • Node-api-markerplate - отличная демонстрация DDD с прикладным уровнем, который демонстрирует организацию кода по функциям.
  • Dev-mastery comments-api - отличный перевод чистой архитектуры на Node.js, и он поставляется с этим супер объясняющим видео
  • Машинописец-стартер не научит вас никаким архитектурным концепциям, но будет прекрасной демонстрацией TypeScript, настроенной с использованием современных библиотек и отличной документации.
  • Nodejs-api-starter - это стартер для тех, кто ищет реальную реализацию GraphQL, включая ошибки и аутентификацию.
  • Bulletproof-nodejs - хорошо известный стартер, который использует трехуровневую структуру папок, которая является моим личным и рекомендуемым способом структурирования приложения Node.js.

📗 Понравился контент здесь и вы хотите пройти 10+ часовой курс по качеству и тестированию Node.js? Посетите мой онлайн-курс Тестирование Node.js и JavaScript от А до Я

Спасибо. Другие статьи, которые могут вам понравиться

⭐ Хотите еще? Подписывайтесь на меня в Twitter ⭐