Путешествие, которое мы называем JavaScript, полно сюрпризов. Такие разработчики, как мы с вами, у всех разный опыт, но все же все мы приходим к одним и тем же истинам.
Одна самая универсальная правда, о которой я могу думать:
«Мы все хотим меньше сосать».
Если вы пишете код на JavaScript больше года или двух, большинство из нас работает там, где:
- мы написали несколько веб-приложений / сайтов
- знакомы с Vue, React или Angular
- кажется, что мы мало что можем сделать с JavaScript
- неплохо справляются с отладкой с помощью консоли разработчика Chrome
- достаточно уверены в навыках JavaScript в целом
Тем не менее мы знаем, что еще многое можно улучшить.
Посмотрим правде в глаза, мы можем быстро смоделировать любой компонент и поэкспериментировать с ним в браузере. Но прежде чем вы это узнаете, более 50% нашего времени тратится на отладку того, что мы сделали вчера… 😕
Люди говорят
Хорошо, люди говорят: «Вам просто нужно написать им тесты!»
Но это легче сказать, чем сделать, особенно, если ваши приложения в основном состоят из компонентов, с которыми вы кодируете. ваш фреймворк. Кроме того, хотя у нас есть некоторые преимущества от центрального государственного управления, имитировать состояние всего вашего магазина утомительно. В то время как другие действия асинхронны и их еще сложнее протестировать ...
Хорошо, люди говорят: «Сейчас 2019 год, а вы все еще не используете TypeScript?»
И хотя иногда это звучит привлекательно, опять же, с чего нам начать. Нам пришлось бы пройти через обручи, полагаться на некоторые плагины машинописного текста для нашей платформы и рефакторинг более 50% кода для каждого отдельного компонента ...
Идеалистическая дорожная карта разработчика 🗺
Это действительно крутая дорожная карта разработчика, которая описывает путь, который прошли большинство из нас, фронтенд-разработчиков, даже если мы не знали об этом.
Однако я лично пишу JavaScript более 3 лет и должен сказать:
Этот план намного более идеалистичен, чем реальная жизнь.
Особенно, когда вы дойдете до частей, которые говорят «Тестирование ваших приложений, PWA, набор текста, SSR…». Конечно, мы можем делать все это, потому что в наши дни это просто выполнение одной команды в нашем фреймворке. CLI, верно? Но, эй, обычно не проходит много времени с тех пор, как вы обнаруживаете ошибку после того, как фреймворк сотворил свое волшебство, и их часто даже труднее отлаживать ...
Я имею в виду, действительно ли мы настолько уверены, что можем называть себя хорошими разработчиками из-за возможностей, которые нам дают наши фреймворки? Разве мы не чаще всего пытаемся «просто заставить все работать», в то время как мы (втайне) не до конца понимаем, как все вообще работают?
Если ты был там, позволь мне сказать тебе кое-что интересное: мы все были там, дружище. Мы слишком глубоко засунули руки в фреймворк. 🍪
Сделать шаг назад
Позвольте мне поделиться некоторыми советами, которые мне бы хотелось, чтобы кто-нибудь сказал мне, когда я был в вашем возрасте JavaScript. Я скажу вам кое-что, что мне нужно было выяснить на себе, что позволило мне лично сильно вырасти.
Вспомните, насколько увлекательным и простым был JavaScript, когда мы только изучали, что такое функция. Функция - это один из основных строительных блоков, но на самом деле это самый мощный инструмент, который у нас есть.
Если вы хотите писать лучший код с меньшим количеством ошибок, самый большой совет, который я могу вам дать:
«Модулируйте свой JavaScript»
Да, это цитата… Я это сказал.
Но я уверен, что так делал любой другой разработчик в один прекрасный день своей жизни. 😀
В любом случае, я пытаюсь сказать, что если вы напишете небольшой модульный код - функции, которые просто принимают одни параметры и возвращают что-то еще - все станет намного проще.
Не беспокойтесь о добавлении тестов в свой фреймворк. Не беспокойтесь о переписывании вашего приложения на TypeScript. Слишком сложно делать это от одного дня к другому.
Просто начните с небольшого написания небольших модульных функций.
Дай мне детские шажки 🔰
Это очень просто
- Посмотрите код вашего последнего приложения, которое вы создаете, и найдите самую длинную функцию или действие, которое вы написали.
- Если он изменяет значения вне самой функции, делайте это только в самом низу этой функции.
- Теперь извлеките фактическую логику в отдельный файл и получите ее:
- взять параметры
- не полагаться ни на что, кроме принимаемых параметров
- изменить только эти параметры
- только возвращать параметры и ничего не менять вне функции - В исходной функции вы можете вызвать извлеченную функцию, получить результаты, а затем обновить любые значения, которые вы хотите обновить.
Это всего лишь один пример извлечения логики из вашего приложения, и у него есть бесчисленное множество преимуществ, которые заставят вас писать более качественный код.
Когда вы извлекли функцию, ее намного проще протестировать, убедиться, что она хорошо работает, независимо от того, что вы на нее бросаете, и, черт возьми, может быть, даже применить некоторую проверку типов для этих параметров? 😄
Когда вы извлекли некоторую логику из своего кода в отдельную функцию, вы, по сути, написали свой самый первый модуль! Добро пожаловать в модульный JavaScript! И поверьте мне, здесь только начинается самое интересное !!
Удачи вам во всех приключениях, связанных с JavaScript! 🎉
Также смотрите мой другой пост на
С уважением,
- Лука Бан (github)
PS: На данный момент, если вы хотите узнать больше о модульном JavaScript, ознакомьтесь с этим сообщением Синдре Сорхуса: Маленькие сфокусированные модули
