Тендеры и лиды
Информация
Фронтенд не стоит на месте и развивается с бешеной скоростью. Новые инструменты, фреймворки и подходы появляются чуть ли не каждую неделю. Вот только независимо от выбранного стека, есть проверенные временем практики. Они помогают писать чистый, быстрый и удобный в поддержке код.
Такие базовые принципы создают основу для масштабируемых, поддерживаемых и эффективных решений, которые не теряют актуальности с течением времени. Понимание и применение лучших практик не только упрощают разработку, но и помогает коллегам быстрее влиться в проект.
Фронтенд-команда айти-агентства Фьюче собрала практики, которые помогают в реальных проектах. Не просто набор инструментов, а только то, что проверено на деле и даёт результат.
Такие стандарты, как Airbnb Style Guide, выручают в повседневной разработке и помогают команде писать код в одном стиле. Соблюдение гайдлайнов снижает вероятность появление багов, упрощает поддержку и улучшает читаемость кода.
Инструмент статического анализа, который помогает держать качество кода под контролем и предотвращать ошибки ещё до запуска.
Чем полезен
Инструмент автоформатирования, наводит порядок и избавляет команду от споров о стиле кода.
Чем полезен
Инструмент для унификации базовых настроек форматирования кода между редакторами и разработчиками в команде.
Чем полезен
Инструмент для статического анализа CSS, SCSS и LESS, который помогает держать стиль кода под контролем.
Чем полезен
Инструмент для настройки Git-хуков позволяет запускать нужные скрипты до коммита или пуша.
Чем полезен
Инструмент запускает линтеры и другие проверки только для файлов в стейдже, что сильно экономит время и нервы.
Чем полезен
Когда каждый пишет в своём стиле, легко запутаться, особенно если над проектом работает несколько человек. Чтобы избежать хаоса, важно договориться об одном подходе и придерживаться его на протяжении всей разработки. Это снижает количество конфликтов, упрощает чтение и делает код более предсказуемым.
Как делать
Последовательность в стиле именования — залог понятного и поддерживаемого кода. Простое правило, но работает отлично, особенно на больших проектах.
Один из самых простых способов сделать код понятным — давать переменным и функциям осмысленные названия. Имя должно отражать, что именно делает функция или за что отвечает переменная. Так другим разработчикам (и вам самому спустя время) будет проще разобраться, что к чему. Понятные названия снижают риск ошибок и делают поддержку кода проще.
Что важно
// Плохоconst d = new Date();
const n = d.getDay();
//
// Хорошо
const currentDate = new Date();
const currentDayOfWeek = currentDate.getDay();
//
Если в коде встречаются непонятные числовые константы или строки, которые используются без контекста или комментариев, это есть магия. Точнее, магические значения. Они сбивают с толку и усложняют работу с кодом.
Чтобы упростить жизнь себе и другим, выносите такие значения в константы с понятными названиями. Так код становится чище, понятнее и проще в поддержке.
// Плохоif (userType === 0) { grantAccess() } //
// Хорошоexport const USER_TYPES = { ADMIN: 0, USER: 1, }
//... в другом месте в кодеif (userType === USER_TYPES.ADMIN) { grantAccess() }//
При работе над проектом важно следить за количество и качеством сторонних библиотек. Ненужные зависимости увеличивают размер проекта, вызывают проблемы с производительностью, становится сложнее поддерживать код и выше риск уязвимости.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13203 тендера
проведено за восемь лет работы нашего сайта.
Например, для проверки чётности или нечётности числа можно найти отдельные библиотеки вроде is-odd и is-even. Но стоит ли подключать их, если то же самое можно сделать простым выражением num % 2 === 0?
const isOdd = (num) => num % 2 !== 0; const isEven = (num) => num % 2 === 0;
Когда проект растёт, мы в команде добавляем новые зависимости, тестируем новые фичи и со временем часть из них перестаёт использоваться, но остаётся в проекте. Эти «мертвые» зависимости просто занимают место, утяжеляют сборку и могут замедлять работу.
Поэтому полезно время от времени проверять, какие зависимости действительно используется, а что можно смело удалить.
Здесь на помощь приходит Depcheck — удобный инструмент для сканирования проекта и отображения, какие библиотеки больше нигде не задействованы. Особенно это актуально в больших проектах, где вручную уследить за всем становится сложно.
TypeScript про предсказуемость, безопасность и порядок. ****Он снижает количество багов и упрощает поддержку. Проект растёт — вместе с ним растут и требования к архитектуре. В таких условиях TypeScript становится не просто полезным, а по-настоящему нужным инструментом. Особенно если вы хотите, чтобы в команде всё работало слаженно.
При работе с формами или получением данных от бэкенда важно проверять, соответствуют ли данные ожидаемой структуре. В противном случае это может привести к ошибкам в логике приложения и потенциальным уязвимостям.
Использование валидации с Zod или Yup делает ваш код надежнее и защищает приложение от ошибок. Это особенно полезно при работе с формами и API-запросами, где важно контролировать корректность данных.
Если у вас TypeScript, и нужна строгая типизация, смело используйте Zod. А если хочется больше гибкости и асинхронности, попробуйте Yup.
При работе с API часто приходится вручную писать код для взаимодействия с бэкендом: отправлять запросы, обрабатывать ошибки и типизировать ответы. Это занимает время, особенно если API меняется, и приходится обновлять все связанные вызовы.
Для этого тоже есть полезный инструмент, всю эту работу берёт на себя Orval. Он автоматически генерирует API-клиент на основе OpenAPI (Swagger) схемы. В итоге вы тратите меньше времени на рутину, меньше ошибаетесь, и ваш код всегда соответствует актуальному API.
Кажется, сейчас все уже понимают, насколько это важная часть поддержки кода, особенно когда над проектом работает команда. Такой подход помогает новым разработчикам быстрее вникнуть в суть, а остальным избежать ошибок из-за недопонимания.
При этом не стоит перегружать код комментариями. Хорошо написанный код должен быть понятен сам по себе. Сообщения лучше оставлять там, где действительно нужно пояснить почему всё сделано именно так, а не просто описывать, что происходит в строке.
// Плохо (избыточные комментарии)
// Объявляем переменную для хранения имени пользователяconst name = "Alice";
// Функция, которая возвращает имя пользователя function getName() { return name;}
// Хорошо (объяснение причины, а не действий)
// Используем setTimeout, чтобы избежать слишком частого запроса данных setTimeout(() => fetchData(), 500);
Хорошо организованная структура проекта помогает быстрее ориентироваться в коде, упрощает разработку и снижает шанс допустить ошибку.
Cбалансированная структура для приложения на React (SPA)
api/ — всё, что связано с запросами к внешним API (REST, GraphQL, WebSockets). Здесь удобно хранить обёртки, адаптеры и хуки для Tanstack Query или RTK Query
assets/ — статические ресурсы: изображения, иконки, шрифты и глобальные стили
components/ — переиспользуемые компоненты, которые используются на разных страницах
hooks/ — кастомные хуки, которые можно применять в разных частях приложения
pages/ — страницы, каждая соответствует своему маршруту (Home, Dashboard, Profile). Внутри можно держать компоненты (хуки, стор, утилиты), если они нужны только этой странице
router/ — настройка маршрутов и логика навигации
store/ — управление состоянием (Redux Toolkit, Zustand)
utils/ — полезные функции (работа с датами, форматирование текста, парсеры)
