Перевод статьи «10 Things You Will Eventually Learn About JavaScript Projects», автор – The Cat with a Dragon Tattoo («Кошка с татуировкой дракона»).
JavaScript это приключение. Думаю, никто с этим не поспорит, если, как я, проведет десяток лет за аматорской и профессиональной разработкой в разных сферах.
Мы, программисты, обладаем большой свободой выбора, гибкостью и пространством для творчества в том, что касается фронтенд-проектов. Но такая работа требует знаний, умения планировать и ответственности.
Поработав с проектами на jQuery, require.js, Angulars, React, ExtJs и прочих, я насмотрелась вещей, невозможных для современного фронтенда. Наверное, всем доводилось видеть подобное в той или иной мере.
Но есть определенные шаблоны действий, позволяющие как-то управляться даже с ужасно организованными проектами. В этой статье я составила список того, что может вам пригодиться в этом смысле. Конечно, мой список не объективен, но я думаю, что многие разработчики, давно пребывающие в этой сфере, согласятся с его пунктами. Эти шаблоны обеспечивают стойкую основу для проекта, созданного командой любого размера, с применением любого фреймворка и любой методологии. Благодаря этим шаблонам можно существенно уменьшить необходимость документирования и рефакторинга.
Мне бы хотелось, чтобы вы почерпнули из моей статьи что-то интересное и применили при создании невероятных вещей!
1. Разделяй и властвуй
На этот принцип многие не обращают внимания, хотя слышали о нем, пожалуй, все. CommonJS, Webpack, и Node позволяют нам разбивать код на множество разных файлов. Но зачем это нужно?
Последовательность. Разделение проекта на отдельные файлы заметно облегчает поиск и управление зависимостями. А если давать файлам имена, обозначающие их единственное действие, то работа с ними становится интуитивной и не требует значительного напряжения мозгов при перемещению по архитектуре проекта.
Менеджмент. Создание отдельных файлов позволяет быстро перемещать их и способствует уменьшению связанности системы. Когда ваша вспомогательная функция нужна в другом месте в том же приложении, можно просто создать директорию /shared и перетащить туда нужный файл – это сделает его доступным для других частей вашего кода.
2. Делайте все обескураживающе очевидным
Отнеситесь серьезно к выбору подходящих имен для каждой переменной, функции и файлу. Выбирайте так, будто речь идет о выборе имени для вашего ребенка. Назвав переменную «х», вы сэкономите себе 0, секунды сегодня, но через месяц у вас уйдет пара дней на то, чтобы понять, что этот «х» значит. А когда дойдет до рефакторинга, то понадобятся все 4 дня. Продумывайте все наперед и не бойтесь давать длинные имена.
Избегайте хаков и прочих вещей, написав которые вы начинаете думать о немедленном поступлении в MIT. Ваше решение, конечно, может быть хитроумным и сложным. Но вряд ли ваш коллега поблагодарит вас за такую изворотливость, если ему когда-нибудь придется провести много времени, силясь понять, что к чему в вашем коде. Направьте свои усилия на то, чтобы сделать все простым и не требующим дополнительной документации или комментирования.
3. Замените магические числа и строки
Здесь действует тот же принцип, что и при выборе имен: как бы этого ни хотелось, но не используйте магические числа и строки в своем коде. Не важно, насколько маленьким и обычным кажется значение – все равно поместите его в переменную с осмысленным именем и поместите наверх области видимости.
Чаще всего любое значение, заданное в коде явно, будет использоваться повторно где-нибудь еще. Если вы сразу поместите его в переменную, это уменьшит дублирование кода, облегчит отладку и придаст этому значению осмысленность.
4. Боритесь со вложенностью
Если длина строк вашего кода превышает 120 символов вправо, а весь код длиннее 500 строк вниз, если ваши if-предложения уходят на 3 уровня вглубь, – постарайтесь разделить их.
Со сложностью условий можно совладать, разбив код в глубоко вложенных if-предложениях на отдельные функции, Promises и Observables. При использовании большого количества асинхронных вызовов поможет async/await – благодаря этому код станет проще..
5. Уделяйте внимание конфигам
Создайте отдельный конфигурационный файл для глобальных значений, API endpoints, feature toggles и сторонних учетных данных, если используете из в своем приложении.
Есть много пакетов для помощи управления конфигами – и в интернете, и в node – например, config. На каком-то этапе ваше приложение будет доступно как на сервере, так и локально, для разработки. Создать конфиг-файл гораздо проще на раннем этапе. Благодаря этому вы сможете оценить, поведение окружения, необходимость учетных данных и доступность функций.
6. Фреймворки – к вашим услугам
Очень часто доводится видеть, как тот или иной фреймворк используется только потому что разработчик с ним знаком, или потому что он популярен в данное время.
Подумайте, есть ли необходимость в фреймворке для вашего проекта, и если да, то в каком именно. Уделите время обдумыванию этого вопроса. Помните, что конечному пользователю совершенно все равно, насколько популярен на Github использованный вами фреймворк.
Исходя из собственного опыта, я бы распределила фреймворки и библиотеки таким образом:
- React – для полного контроля над архитектурой и сборкой. Но только для веб-приложений, созданных на компонентной основе. Разработка в экосистеме React требует времени и тщательного планирования наперед. Все это окупится, но только если вы знаете, что делаете.
- Angular / VueJS / Ember – для быстрого и надежного создания веб-приложений. Но вместо архитектуры у вас будет большой черный ящик. Эти фреймворки многое делают за вас, отметая необходимость (и возможность) планирования архитектуры. Также их строгая структура более благожелательна к ошибкам, чем свобода React.
- jQuery / lodash / и все похожие на них – если вам нужно быстро создать веб-страницу и при этом сберечь несколько kB. Эти библиотеки заметно уменьшают количество времени, необходимого для разработки. Однако работа с ними требует осторожности, поскольку они позволяют вам писать даже неподдерживаемый код. Поэтому используйте их как вспомогательные средства, а не как основу.
- Vanilla / отсутствие фреймворка – подходит как для веб-страниц, так и для веб-приложений. Применимо, когда вы готовы потратить много времени на разработку и планирование. Чистый JavaScript это отличный вариант, если ваш проект делает что-то экспериментальное – представляет WebGL, Workers, глубокие оптимизации или браузерные анимации. В итоге вы можете прийти к созданию собственного фреймворка. Благодаря транспиляторам это также может быть лучшей и более легкой альтернативой jQuery.
Считайте этот список ориентировочным и уделите время, чтобы определить, какой фреймворк будет самым подходящим для вашего проекта (и нужен ли он вообще).
7. Пишите тесты (если речь не о прототипе)
Юнит-тесты. «Дымовые» и сквозные тесты. Санитарное тестирование. Если только ваш проект не прототип, который в любом случае будет вскоре переписан, – пишите тесты. Чем сложнее будет становиться ваша кодовая база, тем тяжелее будет ее поддерживать и контролировать, а тесты будут делать это вместо вас.
Когда спустя некоторое время вы обнаружите баг, скажите себе спасибо за то, что писали тесты. Потому что иначе вы бы не заметили, сколько всего тихо сломалось при добавлении нового функционала.
8. Пользуйтесь системами контроля версий
Используйте git или любую другую систему с самой первой написанной строчки кода. Размеры и важность проекта при этом не имеют значения. Делайте коммиты ежедневно, используйте ветвление, научитесь мержить, решать конфликты и откатываться до предыдущих коммитов. Оставляйте осмысленные комментарии к коммитам.
Система контроля версий дает возможность перемещаться во времени, сохранять сломанное, просматривать сделанные в прошлом изменения.
Если вы почерпнете из этой статьи только одну вещь, то пусть это будет необходимость изучения основ контроля версий и ежедневное его использование. Почему? Потому что даже если вы наплевали на все остальное и что-то вдруг пошло не так, то система контроля версий позволит вам это исправить, а без нее придется начинать все сначала.
9. Управляйте состоянием ответственно
Найдите шаблон / библиотеку для управления состоянием и вцепитесь в нее так, будто от этого зависит ваша жизнь.
У фронтенд-разработчиков обычно только две серьезные задачи – отображение данных и хранение данных. Со временем становится все тяжелее поддерживать данные в синхронном состоянии. Ведь так удобно игнорировать это дело, аж пока ваш проект несколько месяцев спустя не станет неподдерживаемым.
Хранение данных, т. е., управление состоянием, это непростая задача. То, что клиент видит на экране, и то, что хранится в базах данных на сервере, обычно должно быть синхронизировано. Для нас главное – не добавлять в нашу JavaScript-структуру излишней сложности между отображаемыми и хранимыми данными. Компоненты должны доставлять одни и те же наборы данных, синхронизируя изменения, внесенные пользователем, и реагируя на любые изменения на сервере. Как с этим справиться?
- Что касается React, то тут есть множество решений, поскольку это очень открытая экосистема. Redux для Flux-архитектуры, Mobx – для архитектуры на основе Observables. У каждого варианта свои достоинства и недостатки. Поэтому, прежде чем воспользоваться библиотекой (любой), убедитесь, что знаете и понимаете ее.
- Angular, Ember и VueJS имеют собственные встроенные решения для управления состоянием, в основе которых лежит идея Observables. Хотя особой нужды в них нет, но для этой цели есть еще и дополнительные библиотеки, такие как ngRx, Akita и Vuex.
- Для любого другого фреймворка, а также для Vanilla JavaScript, можно использовать Redux, Mobx или ваше собственное решение. Главное – сделать так, чтобы у всего приложения был один и тот же источник истины.
10. Критически относитесь к трендам
Наконец, прислушивайтесь к сообществу и учитесь у него, однако относитесь критически ко всему, что читаете. К каждому комментарию, каждому лонгриду на Medium, написанному кошкой (отсылка к нику автора этой статьи, – прим. перев.), каждому отклику на ваш код. Будьте открыты для новых идей, поскольку в сфере фронтенда они появляются довольно шустро. Но не гонитесь за трендами ради их новизны и популярности: это погубило многие проекты.
Проект, написанный на более старом, полностью сформировавшемся фреймворке зачастую намного лучше и стабильнее, чем проект, написанный одновременно на двух фреймворках (поскольку появился новый). Хотя новинки способны несколько улучшить производительность, последовательность все-таки важнее. Держитесь своего первоначального выбора, чтобы сохранить возможность с легкостью поддерживать код, и меняйте что-то только в случае необходимости.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]