Перевод статьи Кошки с тату дракона (The Cat with a Dragon Tattoo): 10 Things You Will Eventually Learn About JavaScript Projects.
JavaScript — это приключение. После почти десятилетия как любительского, так и профессионального развития в различных отраслях, я считаю, что все согласятся с этим утверждением.
Фронтенд-проекты дают нам, программистам, большую свободу выбора, гибкость и много места для творчества, но взамен они также требуют немного знаний, планирования и ответственности.
Пройдя через проекты, использующие jQuery, require.js, Angular, React, ExtJS и, возможно дюжину других технологий, которые я, возможно не помню (или не хочу вспоминать) — я видел вещи, которые невозможно представить себе в современном мире фронтенд. И я думаю, многие с похожим встречались.
Но всегда существовали некоторые общие паттерны, которые позволяли организовывать работу, даже над самыми неорганизованными проектами. Ниже вы найдете список из 10 наиболее важных из них — исходя из моего личного опыта, они могут иметь субъективный характер, но я верю в то, что большая часть опытных разработчиков со мной согласится. Эти паттерны обеспечивают стабильный фундамент для проекта с любым фреймворком, методологией и размером команды — тем самым уменьшая потребность в документации, рефакторинге и количестве слез, пролитых разработчиками.
Я надеюсь, вы научитесь чему-то новому, найдете это полезным для себя и используете для создания чего-то потрясающего! 💪
Большинство из нас слышали об этом, но похоже многие недооценивают это правило. CommonJS, Webpack, и Node.js дают нам возможность разделять код на несколько файлов — но зачем?
Консистентность. Разделение проекта на файлы, которые экспортируют только одну сущность, значительно облегчают управление поиском и зависимостями по мере увеличения кодовой базы. Именование каждого файла, в зависимости от экспортируемой сущности, делает его интуитивно понятным и не заставляет задумываться при обходе архитектуры.
Управление. Разделяя код на модули, мы можем легко управлять ими, удалять и перемещать, при этом ничего не ломая. Когда ваша вспомогательная функция потребуется в другой части приложения, вы просто создаете каталог /shared и перемещаете её, это даст доступ к ней другим частям вашего кода.
Каждая переменная, каждая функция, каждый файл — потратьте время и назовите их так, как если бы вы называли вашего новорожденного ребенка. Вы можете сэкономить 0.3 секунды сегодня, назвав переменную — «x», но через месяц, вы потратите 2 дня пытаясь понять что это, а затем еще 4 на рефакторинг. Думайте заранее, и не бойтесь длинных имен.
Избегайте хаков и вещей, которые застанут вас врасплох, через определенный промежуток времени. Ваше решение может быть действительно крайне умным и сложным — и в будущем, вы или кто-то из вашей команды согласитесь с этим, а затем потратите уйму времени, дабы разобраться, что происходит в коде. Старайтесь делать код простым для восприятия, без необходимости документирования или оставления комментариев.
Подобно именованию — каким бы заманчивым оно ни было, не используйте «магические числа или строки» в своем коде. Несмотря на то, насколько то или иное значение кажется маловажным и не экстраординарным, всегда выделяйте для этого отдельную переменную со значимым именем в верхней части области видимости.
В большинстве случаев любое явное значение, которое вы вводите в код, будет повторно использовано в другом месте. Размещение таких значений в переменные, придает им смысл, уменьшает дублирование кода, и упрощает корректировку.
Если ваш код выходит за пределы 120 символов справа, более 500 строк вниз, или ваше if-условие уходит на 3 уровня в глубину — сделайте все возможное, чтобы разделить это.
Вы можете избавиться от излишней сложности условий, разделив код внутри глубоко вложенных условий if на отдельные функции, Promises, Observables. Если вы используете много асинхронных вызовов, async/await также может значительно упростить ваш код.
Если ваше приложение использует глобальные значения, конечные точки API, данные учетных записей — поместите их в отдельный конфигурационный файл.
Существует множество пакетов, которые помогают управлять файлами конфигураций, как в вебе, так и в Node.js, например config. Ваше приложение, может использоваться, как на сервере, так и локально в режиме разработки. Создание файла конфигурации на ранней стадии намного проще, чем на более поздних этапах разработки. Это позволит вам настроить поведение различных сред выполнения: какие учетные данные им следует использовать, какие функции доступны и т.д.
Очень часто вы встретите приложения которые используют фреймворки, так как они популярны в настоящее время.
Потратьте время, для того чтобы понять, нужен ли Вам фреймворк, и если да, то какой. Конечных пользователей мало заботит, что ваш сайт или приложение используют фреймворк со 100,000 звезд на GitHub. Исходя из моего опыта, я бы разделил фреймворки и библиотеки таким образом:
-
React: когда Вам нужен тотальный контроль над архитектурой и сборкой, но только для веб-приложений построенных на компонентах. Разработка React-косистемы требует много времени на планирование. Но оно того стоит, если вы знаете что делаете.
-
Angular / Vue.js / Ember: когда Вам нужно быстро создать надежное приложение, взамен вы получаете «большой черный ящик» вместо архитектуры. Эти фреймворки делают многое для вас — забирая при этом плюсы и минусы возможности планировать архитектуру проекта. Их строгая структура простит Вам больше ошибок, чем свобода мира React.
-
jQuery / lodash / или аналоги: когда вам нужно быстро создать страницу и сэкономить при этом несколько Кбайт. Они могу значительно сократить время разработки, но требуют внимания, так как код написанный с помощью них, сложно поддерживать — используйте их как помощников, а не как основу.
-
Vanilla / без фреймворка: можно использовать как для отдельных страниц, так и для веб-приложений, когда вы можете позволить себе потратить много времени на разработку и планирование. Чистый JavaScript — это хороший выбор, когда в вашем проекте создается что-то экспериментальное — WebGL, воркеры, углубленные оптимизации или браузерные анимации — в конечно итоге у вас получится ваш собственный фреймворк. Добавьте транспайлеры, и получите лучший и более легковесный аналог jQuery.
Используйте этот список в качестве предложения — потратьте время и выберите фреймворк, который будет лучшим образом подходить для вашего проекта.
Модульные тесты. Smoke-тесты. Тесты End-to-end. Sanity-тесты. Если вы пишите не прототип, который в ближайшее время будет переписан, пишите тесты. С увеличением сложности кодовой базы, её будет труднее поддерживать — тесты это сделают за вас.
Когда-нибудь в будущем, вы столкнетесь с ошибкой, посмотрите на безоблачное синее небо, и поблагодарите свое прошлое за написанные тесты — так как вы никогда бы не узнали, что сломалось, когда вы добавили новый функционал.
Независимо от того, является ли это прототипом, полноценным корпоративным веб-приложением, или совсем небольшим проектом — используйте git, или любую другую систему контроля версий, как только написали первую строку кода. Ежедневно делайте коммиты, используйте ветки, узнайте как правильно объединять изменения, разрешать конфликты и возвращаться к предыдущим коммитам. Добавляйте к коммитам осмысленные сообщения.
Система контроля версий, позволяет Вам путешествовать во времени, чинить сломанные функционал, видеть изменения внесенные в прошлом. Вы можете отказаться от других предложений в этой статье, но только не от изучения основ системы контроля версий и её ежедневного использования. Почему? Потому что, даже если вы игнорируете остальные и случайно ошибаетесь в пути, с системой контроля версий вы можете это исправить — без нее, вы обречены начинать все сначала.
Найдите паттерн или библиотеку для управления состоянием, и держитесь за неё так, как если бы ваша жизнь зависела от нее.
Как фронтенд-разработчики, мы обычно сталкиваемся с двумя серьезными проблемами — отображение данных и их хранение. С течением времени проект становится все сложнее поддерживать, это очень удобно игнорировать, до тех пор, пока через несколько месяцев, проект не становится абсолютно неподдерживаемым.
Хранение данных, то есть управление состоянием становится сложным. Наши приложения обычно должны синхронизировать, то что видит пользователь, c тем что хранит сервер в базе данных. Наша задача — не усложнять структуру JavaScript-кода, которая находится посередине этого процесса. Компоненты должны предоставлять один и тот же набор данных, синхронизировать все действия сделанные пользователем, и реагировать на любые изменения на сервере. Как мы можем решить эти задачи?
- Благодаря очень открытой экосистеме — существует множество решений для React. Redux для архитектуры Flux, MobX для архитектуры на основе наблюдаемых объектов (observables). У каждого из них есть свои плюсы и минусы — перед использованием обязательно изучите основы этих библиотек.
- Angular, Ember, и Vue.js имеют свои собственные встроенные решения для управления состоянием, основанные на идее наблюдаемых объектов. Но есть и дополнительные библиотеки, такие как ngRx, Akita и Vuex.
- Для всех остальных фреймворков и чистого JavaScript вы можете использовать тот же Redux и MobX, или использовать собственные решения для управления состоянием. Основная цель — сделать так, что бы все приложение имело единый источник правды — это может быть сервис, библиотека или обычная реализация наблюдаемых объектов.
В самом конце хотелось бы сказать, слушайте и учитесь у сообщества — но и сами изучайте то, о чем говорят многие: каждый комментарий, длинную статью на Medium, любую обратную связь связанную с вашим кодом. Будьте открытым для новых идей — благодаря этому фронтенд-экосистема остается динамичной — однако не пытайтесь следовать за всеобщим хайпом, только для того, чтобы за ним следовать — это привело уже многое количество проектов к забвению.
Проект, написанный на старом, зрелом фреймворке, часто намного лучше и стабильнее, чем проект, написанный на двух фреймворках сразу — только потому, что появился новый. В то время как новые тенденции могут немного улучшить производительность приложений и процесса разработки, это немного снижает согласованность. Придерживайтесь своего выбора, чтобы сохранить возможность поддержки кода.
Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.