Разработка лучших разработчиков Node.js

Разработка лучших разработчиков Node.js

В последние несколько месяцев у нас наблюдается огромный рост отдела NodeJS в Wolox, по этой причине мы прошли много тренингов по API Express.js. В результате мы начали замечать, что были некоторые повторяющиеся проблемы, из-за которых у слушателей больше головной боли, чем у остальных.

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

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

Асинхронность

Одним из больших преимуществ использования NodeJS является возможность естественной работы с асинхронным выполнением кода, но это также одна из наиболее неприятных проблем, когда вы знакомитесь с Node.js и любым JS-фреймворком. Будь то обратные вызовы, обещания или async / await, всегда возникают проблемы с пониманием того, как они работают, как их использовать, что на самом деле происходит и почему мой код ведет себя не так, как я ожидал.

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

Тестирование

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

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

Вот почему очень важно объяснить и прояснить, что является настоящей причиной проведения тестов, и охватить все ожидаемое поведение, а не только его половину.

Коды состояния HTTP

Когда мы разрабатываем API, мы должны следить за декларативностью наших ответов конечной точки, поскольку это будет все, что клиент, будь то интерфейс, другой API или какой-либо другой сервис, может узнать, что произошло с его запросом. Для этого у нас есть очень хороший, а иногда и плохо используемый инструмент в кодах состояния HTTP.

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

Я думаю, что очень важно объяснить и убедиться, что разницу между каждым классом кодов статуса он хорошо усвоил. Я имею в виду, чтобы понять, что 2xx используется для успешных случаев, 4xx для сбоев, вызванных какой-либо ошибкой клиента и 5xx для сбоев, вызванных какой-либо ошибкой сервера. Затем, если вы хотите объяснить или обсудить, какой код состояния использовать в каждом конкретном случае, мне лично было бы очень интересно, но приятно иметь. Тем более, что это обычно становится немного утомительным и бесполезным, поскольку у каждого есть свое видение вариантов использования для каждого конкретного кода состояния в соответствии с каждым вкусом и знаниями о данном случае. Тем не менее, если вы хотите узнать немного больше о том, как выбрать код состояния HTTP, мы рекомендуем следующую статью и следующую документацию.

Отладка

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

Прежде всего, мы настоятельно рекомендуем им использовать Postman или аналогичные программы, чтобы иметь возможность быстро и просто делать HTTP-запросы к API. Кстати, они могут хранить там запросы, чтобы потом довольно легко и быстро использовать их повторно.

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

Кроме того, мы разработали интерактивную консоль Node.js, которая загружает весь проект (что-то вроде консоли rails), так что вы можете играть вместе со всем уже реализованным без необходимости выполнять полный цикл запроса. Например, если вы хотите попробовать какую-то новую функцию модели пользователя, вы можете напрямую использовать модель пользователя в консоли и вызвать функцию.

И последнее, но не менее важное: мы показываем и поощряем использование инструментов отладки, таких как chrome devtools, отладчик кода Visual Studio или любой другой вариант, который вам нравится больше всего. Используя их, вы можете воспроизвести некоторую ошибку и с помощью отладчика проверить все значения переменных и то, что происходит, до того, как ошибки возникнут. Если вы хотите начать использовать какой-либо инструмент отладки, я рекомендую вам следующее видео о том, как использовать chrome devtools.

Структура Стандарт

Здесь, в Wolox, мы разработали bootstrap Express.js, чтобы иметь возможность легко и быстро запускать проекты, включая базовую структуру папок и некоторые инструменты и конфигурации, общие для подавляющего большинства наших проектов.

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

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

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

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

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

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

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