user

Авторизация

Добро пожаловать!

Регистрация

Undefined666

Кодинг

Как писать поддерживаемый код JavaScript в 2023 году — Web или Node.js

js

 Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. —Мартин Фаулер

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

 Отказ от ответственности: эта статья лучше всего подходит для разработчиков JS (веб-сайтов или Node.js) со средним опытом. Я предполагаю, что у вас уже есть солидный опыт написания JS.

Используйте TypeScript везде

 Не бойтесь TypeScript. Для любого достаточно опытного разработчика JavaScript достаточно официального 5-минутного руководства «TypeScript для программистов JavaScript» , чтобы начать писать TypeScript уже сегодня.

 Если вы используете IDE или редактор с автозаполнением, предложениями, встроенной документацией и т. д., вы можете попробовать The TypeScript™. Рассмотрим эти 2 примера без какого-либо контекста:

 Проблемы с этим подходом должны быть сразу очевидны для вас. Что getPosts возвращает? Что делать, если вам нужно переключиться с axios на fetch? Что делать, если вы хотите добавить функцию для создания поста — как вы определяете структуру data в объекте? Теперь взгляните на тот же код в TypeScript:

 Ключевое отличие — прозрачность . Вы можете понять код сейчас, и ваш редактор или tsc поможет вам с этим. Теперь, когда вы вызываете версию TS getPosts, вы получите полезную информацию.

getPosts

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

Хорошо изучите свой JavaScript и фреймворки

 Человек хорош ровно настолько, насколько хороши его инструменты. — Эммерт Вольф

 Чтобы стать отличным JS-разработчиком, вам нужно понимать асинхронный JavaScript, функции генератора, функциональные и объектно-ориентированные парадигмы, область видимости, производительность и многое другое. К сожалению, большинству JS-разработчиков не хватает более глубокого понимания асинхронного JavaScript , который является основной функцией современных приложений (вспомните Promises и async/await).

 Вот что вы можете начать делать сегодня, не узнав ничего нового.

  1. Работайте с документацией — будь то Next.js, Webpack, React, TypeScript или любой другой инструмент. Например, в React есть много хуков, которые большинство из нас никогда не использовало. Не торопитесь, когда вы разрабатываете основную функцию или настраиваете проект, и углубитесь в документацию ваших инструментов.
  2. Тестируйте производительность кода с помощью профилировщиков, отладчиков, измерений времени и расширенных тестов — почему бы не добавить 100 000 строк данных в таблицу React? Прежде чем выпускать основную функцию , постарайтесь добиться хорошей читабельности, а также производительности . Протестируйте наихудший сценарий, чтобы увидеть, не является ли ваш код узким местом в производительности.
  3. Не полагайтесь во всем на NPM — большинство простейших библиотек легко реализовать самостоятельно. Избавьте себя от необходимости обновлять пакеты, тестировать совместимость и мучиться с небольшим количеством дополнительного кода.
  4. Если вы используете библиотеку без документации, прочтите исходный код . При желании вы можете использовать хорошо документированные и более популярные библиотеки.
  5. Проанализируйте влияние размера пакета . Вам не нужно импортировать всю библиотеку lodash для одного _.omit вызова. Загрузка огромного пакета значительно замедляет первоначальную загрузку вашего приложения.

Форматирование и стиль кода

js

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

  1. Используйте ESLint и Prettier вместе, и вы сможете сосредоточиться на том, что делает ваш код. Представьте себе, что автоматический тест CI больше никогда не будет провален из-за отсутствия запятой в конце. Кроме того, используя удивительные значения по умолчанию Prettier, вы можете раз и навсегда покончить с аргументами в стиле кода.
  2. Используйте описательные имена для переменных . Вам нужно понять, что это такое, просто прочитав название. Рассмотрим buttonDomElem vs el— что легче понять? Или loading против isUserDataLoading. Ставьте перед булевыми переменными глагол вроде isor has и не бойтесь более длинных имен переменных. IDE предложит название, и vim пользователи быстро скопируют его.
  3. Используйте интервалы. Если вы используете prettier, он будет соединять многострочные разрывы. Большой. Но те однострочные разрывы, которые вы хотите использовать, остаются нетронутыми — даже внутри одной функции или объявления объекта, если это помогает удобочитаемости.

Комментарии в коде и встроенной документации

комментарий js

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

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

 Вы когда-нибудь видели setTimeout(someFn, 0) без каких-либо объяснений, почему это было отложено до конца цикла выполнения? Вы знаете, что он делает, но почему он вызывается в случайном месте, например, сопоставление цветов с аватарами пользователей в таблице? Здесь вдумчивый комментарий избавит вас от головной боли, связанной с повторным обнаружением уже исправленной ошибки.

Напишите содержательные и полезные тесты, где это применимо

 Если вам не нравится модульное тестирование вашего продукта, скорее всего, ваши клиенты тоже не захотят его тестировать. — Аноним

 Вы наверняка слышали о парадигме разработки через тестирование (TDD) . Чаще всего это разделяет разработчиков на два лагеря — одни поддерживают TDD, а другие презирают его.

 Я ни за, ни против TDD. Где-то это имеет смысл, а где-то — пустая трата ресурсов. Когда вы разрабатываете важную внутреннюю функцию на основе тщательной спецификации, вы получите выгоду от TDD. Но если вы создаете интерфейсное приложение панели мониторинга, использование TDD может значительно замедлить работу. Подумайте, перевешивают ли плюсы минусы.

тест js
  1. Модульное тестирование — это метод тестирования для большинства случаев использования. Модульное тестирование внешнего интерфейса позволяет оценить сложные компоненты, такие как макеты, модальные диалоговые окна, мастера, многоэтапные формы, проверенные на стороне клиента, и т. д. При разработке серверной части вы можете проверить, обрабатывают ли конечные точки хорошие и плохие случаи так, как вы ожидаете.
  2. Сквозное (E2E) тестирование — настоящий MVP тестов. Как только ваше фронтенд-приложение станет большим, имеет смысл создать тестовую базу данных и тестировать ваш фактический код в реальном браузере каждый раз, когда вы хотите предоставить его пользователям. Самый полный способ провести E2E-тестирование во внешнем интерфейсе — это думать как UX-инженер — разрабатывать свои пользовательские потоки или собирать эти данные из таких инструментов, как HotJar, и тестировать то, что делают ваши пользователи.

 Вы можете протестировать гораздо больше вещей, если хотите. Обычный тестовый сценарий в package.json в больших проектах может выглядеть так: «test»: «NODE_ENV=test eslint && tsc —noEmit && jest && cypress run».

 Больше тестов !== больше качества.

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

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

Используйте прототипы и/или MVP перед внедрением сложных функций

 Настройка прозрачного жизненного цикла проекта с четкими спецификациями и знанием того, когда будет выпущена каждая фаза, может дать вам много возможностей подумать над уже проделанной работой . Это здорово, потому что как только MVP «закончен», вы можете отвлечься от обычной работы и оценить результат. Это лучшее время для дополнительного тестирования производительности, незначительного рефакторинга или других улучшений.

 Очистка и рефакторинг мелких частей после каждой основной функции

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

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

 Используйте прототипы для тестирования функций и избегайте бесконечного рефакторинга.

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

Бонус: несколько дополнительных советов

  1. Задокументируйте инструкции по начальной настройке и развертыванию для каждого проекта, над которым вы работаете, включая требования и их версии, и опишите, какие шаги необходимо предпринять и в каком порядке. В идеале еще и почему.
  2. Структурируйте свое приложение вокруг установленной практики. Вы можете позаимствовать старые подходы MVC, попробовать разделить функции или объединить несколько подходов. Нет правильного или неправильного.
  3. Используйте лучшие инструменты , которые можно купить за деньги. Покупайте оборудование, которое вам понравится, украшайте свой офис и тратьте деньги, чтобы ваша работа приносила удовольствие. Ведь на работу вы будете тратить около трети своего дня.
  4. Не позволяйте себе устанавливать нереалистичные сроки. Если ваша рабочая среда токсична, не позволяйте одной работе убить ваше творчество и страсть. Вы всегда можете перейти на другую позицию.
  5. Выскажите свое мнение и начните обсуждение. Помните поговорку — «Глупых вопросов не бывает»? Так что продолжайте спрашивать и говорить. Вы можете значительно расширить свой кругозор, просто делая это.

 Вот и все, что касается этого исчерпывающего списка советов по написанию более удобного в сопровождении кода. Удачного кодирования!