Front-end разработка

Содержание:

Использование технологий

Повар не все­гда гото­вит всё сам — ино­гда он исполь­зу­ет полу­фаб­ри­ка­ты или гото­вые изде­лия. Напри­мер, если ему нуж­но сде­лать тар­та­лет­ки, он не будет выпе­кать их, а зака­жет гото­вые. Потом про­сто поло­жит в них наре­зан­ные ово­щи с сыром, поста­вит в духов­ку и полу­чит вкус­ное блюдо.

Фронтенд-разработчик тоже не пишет весь код с нуля. Если он пони­ма­ет, что какую-то часть логи­ки будет слож­но реа­ли­зо­вать на стра­ни­це, то может отпра­вить её на сер­вер, что­бы все вычис­ле­ния были там. В ито­ге фрон­тенд попро­сит ребят на сер­ве­ре сде­лать такую-то функ­цию, кото­рая будет обра­ба­ты­вать дан­ные со стра­ни­цы — точ­но так же, как повар зака­зы­ва­ет гото­вые корзинки.

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

Web performance. Adopt

Скорость работы веб-приложений с каждым годом становится важнее. Скорость первоначального запуска и последующей работы интерфейса является частью UX, от этого зависит ранжирование в поисковых системах, что в совокупности влияет на бизнес-конверсии и успешность вашего продукта

Важно, чтобы скорость интерфейсов была в культуре разработки

Если вы раньше не думали о таком нефункциональном требовании, как скорость работы интерфейса, то начните с определения бюджета скорости: задайте те ограничения на performance-метрики, за пределы которых нельзя выходить

Важно согласовать эти бюджеты с владельцем продукта, чтобы было общее понимание ценности, бюджет учитывали при постановке задач и выделяли время на улучшение скорости

Для контроля бюджета нужно иметь мониторинг скорости работы приложения на основе данных от настоящих пользователей (RUM), желательно с автоматическими уведомлениями при достижении критических значений. Также нужно иметь синтетические тесты, которые исполняются в тестовом окружении. Желательно, чтобы такие тесты были интегрированы в процесс CI/CD: это позволит на раннем этапе замечать потенциальные проблемы и решать их до того, как они попадут к пользователям.

Ввести бюджет и инструменты контроля может быть недостаточно. Вы должны обучать вашу команду современным практикам разработки быстрых веб-интерфейсов, следить и делиться новыми подходами. У нас есть регулярная встреча по Web performance, на которой обсуждаются новости и хорошие примеры оптимизации. Так мы распространяем культуру быстрых интерфейсов и обмениваемся опытом.

В нашем блоге мы подробно раскрывали тему производительности, рекомендуем ознакомиться:

  • Клиентский мониторинг производительности
  • Синтетический мониторинг производительности

Фронтенд-разработка на практических примерах

В процессе своей практической деятельности фронтэнд-разработчик может получать от веб-дизайнера макеты будущего сайта либо сервиса или другие задания, на основании которых он создаёт клиентскую часть, выполняя:
— вёрстку дизайна сайта, создание шаблонов его будущих страниц с помощью HTML и CSS;
— настройку работы слайдеров, кнопок, онлайн-форм и прочего запланированного функционала (специалист по frontend-разработке либо использует готовые скрипты из библиотек, либо создаёт свои);
— проверку работы созданного функционала;
— оптимизацию скриптов для ускорения загрузки страниц и т. д.

Также фронтендер может консультировать по вопросам реализации того либо иного функционала. При этом в отличие от обычного верстальщика, знающего HTML+CSS, frontend-разработчик способен программировать интерактивные элементы на web-страницах и хорошо владеет языком программирования JavaScript, а также рядом других технологий. Но давайте остановимся на этом подробнее.

Что следует знать дизайнерам о фронтенде

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

    • box-sizing — определяет, как вычисляется общая ширина и высота элемента;

    • margin — определяет внешний отступ;

    • padding — определяет внутренний отступ;

    • border — отвечает за все персональные свойства границ;

    • overflow — работает с переполнением;

    • flex/grid — наиболее популярные типы отображения элементов.

  • Одна из основных методологий в CSS — БЭМ. Дизайнеру она нужна, чтобы понять образ мыслей фронтендщика, который будет собирать страницу, и позволит хранить элементы проекта аналогично тому, как это будет делать фронтенд-разработчик.

  • Отличие блочных элементов от строчных. Это позволит глубже понять композицию веб-страницы.

  • Браузерные инструменты разработчика упростят процесс проведения авторского надзора и помогут проверить некоторые гипотезы непосредственно в рабочей среде.

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

Что говорит статистика

Какие технологии и инструменты чаще всего используют фронтенд-разработчики? Во-первых, трудно представить фронтендщика, не умеющего в JavaScript. Это подтверждают опросы:

  • по данным StackOverflow, JavaScript в списке инструментов фронтенда лидирует с огромным отрывом (90,5%);
  • исследование компании O’Reilly, проведенное среди европейских программистов в конце 2016 года, тоже ставит JavaScript на первое месте.

Далее идут различного рода фреймворки и библиотеки, самые популярные из которых Angular, Node.js, React. Кроме обязательного JavaScript, фронтенд-разработчики также используют и другие языки, хоть и не так часто. Лидируют PHP, SQL, Java и С#. И, конечно же, не обойтись фронтендщику без навыков работы с CMS. Самый популярный выбор — WordPress.

Данные StackOverflow

Если сгруппировать самые популярные инструменты в стеки, то получим такую ситуацию:

Данные StackOverflow

А набор самых популярных фреймворков и библиотек всех разработчиков выглядит следующим образом (см. иллюстрацию). Приятно видеть среди этого списка инструменты фронтенда:

Чем занимается фронтенд-разработчик?

Профессия фронтенд-разработчика началась ещё в начале 2000-х с довольно примитивной вёрстки. Вёрстка — это создание визуального контента в специальном виде, который понимает браузер. В начале нулевых веб-страницы представляли из себя нечто вроде элементарных страничек с текстом, изображениями и ссылками на другие веб-страницы. С развитием технологий и распространением интернета у пользователей и компаний начал появляться спрос на более сложные вещи, которые может предоставить веб-страница. 

Сейчас фронтенд-разработчик чаще занимается разработкой сложных веб-приложений, чем просто веб-страниц. Например, сайты для вызова такси, различные интерактивные формы, игры и онлайн-мессенджеры. 

Вместе с требованиями к веб-приложениям выросли и требования к обязанностям современного фронтенд-разработчика. Сейчас его работа может включать практически всё: и вёрстка, и настраивание процессов развёртывания и тестирования приложения, и написание unit и end-to-end тестов, поддержка accessibility для людей с ограничениями, а иногда и сам UX/UI дизайн. 

В Evolution фронтенд-разработчик занимается разработкой игр. Мы делаем весь функционал для игроков, который ложится поверх стриминга видео в режиме реального времени, а также разрабатываем VR- и 3D-игры, используя самые современные для этого технологии.

Оплата труда

Ступеньки карьеры и перспективы

Начинающий фронт-энд разработчик должен обладать навыками верстальщика. Далее карьера может развиваться в нескольких направлениях:

специализация в бэк-энд разработках (Python, РНР) приведёт его к профессии бэк-энд разработчика;
увлечение пользовательским интерфейсом — к профессии фронт-энд разработчика;
внимание к дизайнерской части проекта — к профессии дизайнера;
совместное владение навыками фронт-энд и бэк-энд разработчика — к профессии фулл-стак разработчика. 

Дальнейшая карьера может складываться по-разному, в зависимости от места работы, личных предпочтений. В любом случае, в IT-сфере полезно развиваться в горизонтальном направлении, осваивая смежные профессии, чтобы стать настоящим гуру.

Интересные факты о профессии

Типы разработчиков

Гуру — это профессионал с богатейшим опытом работы, обладает навыками практически во всех IT-профессиях. В сложнейших ситуациях умеет сконцентрироваться, быстро вникнуть в суть проблемы и единолично решить её. Занимает должность технического директора и имеет большой авторитет у сотрудников.

Теоретик — специалист, который подкован теоретическими знаниями в области информационных технологий. Постоянно учится новому сам и учит других. Будучи сильным в теории, оказывается слабым специалистом на практике.

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

Планктон — неопытный разработчик, который не понимает ни того, что он делает, ни того, что происходит в компании. Но это не самое страшное. После его вмешательства в систему, обязательно что-то перестаёт работать. Ему категорически требуется наставник, так как поиски решений на свои вопросы в поисковых системах не дают положительного результата.

Экспериментатор — специалист, который находится в курсе всех новейших технологий и инструментов в сфере IT. Он постоянно стремится использовать новинки в своей работе.

Спагеттикодер  — это специалист, работающий очень быстро, но результат его работы всегда оставляет желать лучшего. Его коды называют спагетти-кодом или лапшой. Не всегда это происходит от неопытности. Иногда — из-за сжатых сроков  или излишнего давления руководства. Но на всякого лапшакодера найдётся свой Мистер рефракторинг. Так что не так всё плохо в этом лучшем из миров! 

Автор Флюра Ягофарова

Эпоха современной архитектуры настольных систем

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

Большая часть функциональности Контроллера была взята на себя операционной системой. Идея View трансформировалась. Раньше это был единственный виджет. Теперь это была композиция виджетов. Представление могло содержать другое представление. Представление стало двунаправленным в том смысле, что оно реагировало на действия пользователя, а также отображало данные модели.

С точки зрения связей:

  1. Презентер (Presenter) следит за логикой Представления. Презентер может изменить Представление напрямую. Представление делегирует пользовательские события Презентеру.

  2. В зависимости от реализации, Представление подписывается на Модель и полагается на Презентер для сложной логики, или Представление просто полагается на Презентер для всего.

Какие трудности могут быть? Ошибки в начале пути

Изучение фреймворков вместо базовых знаний

Иногда будет казаться, что лучше сразу изучать какой-нибудь популярный фреймворк или библиотеку. Это достаточно частая ошибка, особенно во фронтенде: люди начинают изучать React или верстают с помощью Bootstrap и Material UI, не разобравшись в основах и не получив достаточных знаний по HTML, CSS и JavaScript. Можно использовать такой подход, если вы «бежите на короткую дистанцию» и вам нужно быстро сделать какой-нибудь проект. Но если вы планируете стать разработчиком, это не принесет нужного результата.

Нет необходимости знать наизусть абсолютно все CSS-свойства или методы в JS, вы сможете поискать их, если забудете

Важно понимание основных концепций и тонкостей: это то, что будет вашим крепким фундаментом во фронтенд-разработке

Обучение — это труд, самодисциплина и много практики

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

Не пугайтесь, изучайте пошагово и постепенно, больше практикуйтесь — так вы сможете быстрее продвинуться в обучении. Всем нужно какое-то время, чтобы научиться новому.

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

Вспоминайте о мотивирующих именно вас моментах, когда ваш код не будет работать, а очередной блок не будет выравниваться так, как вы этого хотите Если вам нравится видеть результат своей работы, изучайте материал через практические задачи или создание своего проекта, так вы будете быстрее получать отдачу.

Копирование чужого кода

Если вы столкнетесь с проблемами и ошибками, которые не сможете решить, то не стесняйтесь искать помощи в Google. Учитесь пользоваться поиском и находить причину возникшей проблемы, но не копируйте чужой код вслепую.

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

Не доверяйте на 100% коду, который вы находите

Другие люди тоже могут ошибаться или иметь недостаточно опыта. Если вы находите видеоурок от магистра JavaScript или вёрстки, это не всегда значит, что преподносимое — идеальное решение и лучший возможный код.

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

Frontend frameworks

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

  • AngularJS: эта структура и несколько других инфраструктур JS, таких как Backbone.js, которые используют возможности JavaScript.
  • JQuery: Быстрая, маленькая, объектная библиотека JS, упрощает управление JavaScript в разных браузерах.
  • Bootstrap: эта лидирующая платформа для мобильных устройств; объединяет HTML, CSS и JavaScript, чтобы упростить развивающуюся разработку приложений. С Bootstrap ваш сайт совместим со всеми современными браузерами и отлично смотрится на экране любого размера: от телефонов до планшетов и ноутбуков.
  • Foundation: Созданный ZURB, эта ориентированная на бизнес, отзывчивая внешняя инфраструктура. На данный момент она используется такими сайтами, как Facebook, Yahoo !, и eBay.
  • Семантический UI (интерфейс): эта интерфейсная среда пользователя ориентирована на читаемость кода, чистую логику и структуру и имеет множество функций.
  • Pure.css: Созданный Yahoo !, эта легкая, небольшая структура представляет собой набор гибких модулей CSS, которые помогут упростить разработку мобильных сайтов. Когда вам не нужна тонна функций, расположенных в вашей структуре, Pure предлагает только основы.
  • Skeleton.css: Еще одна отзывчивая структура CSS, которая быстро распространяется. Skeleton — это базовый, без излишеств фундамент — скелет — для сайта.

@ivashkevich

22.08.2017 в 17:51

8887

+55

Шаблоны GUI сложны?

Если вы подробно изучили предыдущие шаблоны (Patterns), то поймете, что шаблоны GUI отличаются от других шаблонов разработки программного обеспечения. Возьмем, например, элементы многоразового объектно-ориентированного программного обеспечения (Elements of Reusable Object-Oriented Software). Большинство шаблонов не зависят от технологии или языка программирования. Однако то же самое не относится к шаблонам GUI.

Таким образом, практически невозможно обсуждать их в теории, не принимая во внимание фреймворки и языки программирования. До сих пор, с достаточно высоким уровнем абстракции, мы могли исследовать эти паттерны

Но по мере приближения к сути статьи мы будем отталкиваться от различных библиотек или структур для описания этих шаблонов.

Большинство шаблонов веб-интерфейса можно разделить на три этапа: эволюционный, революционный и современный.

Эволюционные шаблоны являются просто расширением серверной MVC. Они действительно не пытаются изобрести что-то новое. Они дополняют существующие приложения, улучшая свой UX шаг за шагом.

В то время как революционные шаблоны — это те идеи, которые отделяют разработку интерфейсных приложений от управляемых сервером рабочих процессов. Их прибытие отмечает известность SPA-приложений.

Современные шаблоны похожи на продвинутую версию этих революционных моделей и являются неким общим трендом, в сторону которого движется фронт-энд сообщество.

Конец первой частиЧасть 2

Любопытные ожидания других людей, с которыми пришлось сталкиваться

— Хочу кодить

— Но ты же фронтендер

Реальность: современный фронт это далеко не только вёрстка или кусочки кода для анимации. Это полноценная разработка и программирование, причём иногда не только на JS.

Ожидание: браузер один или они все одинаковые

Реальность: браузеров много и они все разные

Сейчас эта проблема не так ярко выражена, как, например, во время моего вхождения в сферу. Когда для разных браузеров подключались разные стили, руками проставлялись префиксы в больших количествах, а для простой выборки элемента в JS требовалось писать три различных варианта кода под IE, Safari и Opera. Стандартизация понемногу побеждает, и это круто. Но забывать о кроссбраузерности ещё рано.

Эксперимент 3

В рамках эксперимента 3 выберите один из прошлых экспериментов и проведите рефакторинг своего кода с использованием советов, которые вы узнали выше. Рефакторинг означает редактирование вашего кода так, чтобы он стал проще, в том числе в плане читаемости.

Умение проводить эффективный рефакторинг кода — очень важный навык для фронтенд-разработчика. Создание эффективного кода- постоянный процесс. Возьмите статью CSS архитектура: рефакторинг CSS (англ.) в качестве отправной точки для вашей работы над рефакторингом.

Не важно сделать правильно с первого раза. Важно сделать правильно в конечном результате

Ниже несколько вопросов, на которые вы должны себе ответить в процессе рефакторинга.

  • Не двусмысленны ли названия классов? Через полгода я все еще смогу понять, что означает название класса?
  • Семантичен ли мой HTML и CSS? Можно ли с первого взгляда определить структуру и взаимоотношения элементов?
  • Использую ли я одни и те же цвета в коде? Не будет ли логичнее вынести их в переменные Sass (англ.)?
  • Работает ли мой код в Safari так же хорошо, как в Chrome?
  • Нельзя ли заменить часть кода на систему сеток, например Skeleton?
  • Не слишком ли часто я использую !important? Как я могу это исправить?

Выходим за пределы серверной части

Вот где действительно становится интересно. Почти все браузеры начали реализовывать в себе движки JavaScript. На мой взгляд, именно AJAX изменил ход веб-приложений. Google первым освоил его с помощью своего почтового клиента и картографических приложений.

Мир серверной MVC, генерирующей HTML + JavaScript. Код JS разбросан по страницам. JavaScript в основном используется для улучшения UX за счет сокращения циклов просмотра сервера (Server View Cycles). Такие вещи, как отправка формы, проверка ввода и т.д. обрабатываются клиентским кодом.

Это самая распространенная архитектура в истории веб-приложений. Большинство приложений B2C, SEO-дружественных веб-сайтов, особенно созданных с помощью CMS — Content Management Systems, используют его. Количество клиентского кода зависит от потребностей приложения.

Эта архитектура как таковая никогда не была действительно стандартизирована и поэтому не имеет названия. Она развивалась инкрементном стиле и до сих пор считается расширением Web MVC. ASP.NET MVC, Java Struts, Python Django, Ruby ROR, PHP CodeIgniter — некоторые из широко используемых сред, широко использующих серверную MVC или Web MVC.

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

Как в вакансии

Фронтенд-разработчик дела­ет следующее:

  • соби­ра­ет сайт по маке­ту дизайнера;
  • исполь­зу­ет для это­го HTML, CSS, JavaScript и несколь­ко дру­гих языков;
  • пони­ма­ет про­цес­сы, кото­рые про­ис­хо­дят во вре­мя созда­ния сайта;
  • зна­ет, как опуб­ли­ко­вать сайт в Сети так, что­бы он выгля­дел оди­на­ко­во на всех устройствах;
  • уме­ет рабо­тать с Git или дру­гим инстру­мен­том кон­тро­ля версий;
  • исполь­зу­ет Webpack для сбор­ки про­ек­та и вооб­ще опе­ри­ру­ет препроцессорами.

Зву­чит слож­но, но вот основ­ное: фрон­тенд берёт макет буду­ще­го сай­та (кар­тин­ку) и пре­вра­ща­ет его в код, кото­рый мож­но отпра­вить кли­ен­ту. При необ­хо­ди­мо­сти он про­грам­ми­ру­ет интер­ак­тив­ные эле­мен­ты и ани­ма­цию, кото­рые будут обра­ба­ты­вать­ся на клиенте.

Часто фрон­тен­дов пута­ют с вер­сталь­щи­ка­ми, но на самом деле вер­сталь­щик — это спе­ци­а­лист узко­го про­фи­ля (вёрст­ка по маке­ту). А фронт кро­ме это­го может и слай­дер при­кру­тить, и шаб­лон в CMS попра­вить, и зако­дить нестан­дарт­ное пове­де­ние кар­тин­ки при нажа­тии, и напи­сать скрипт для про­вер­ки пра­виль­но­сти запол­не­ния дан­ных на сайте.

Серверная MVC a.k.a. Модель 2

Первой известной реализацией серверной MVC является Модель 2 от Sun Microsystems для веб-приложений на Java.

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

Некоторые вещи, на которые стоит обратить внимание:

  • Десктопный MVC имеет два цикла данных (Data cycles), а веб-MVC — три цикла данных.
  • Есть два цикла Представления (View cycles). Первый — это цикл Представления клиента, такой как событие прокрутки, ввод с клавиатуры и т.д. Второй — цикл Представления сервера, такой как обновление страницы, активация гиперссылки и т.д.
  • Наконец, у нас есть цикл модели (Model cycle), который имеет дополнительную сложность по времени, поскольку он пересекает границу клиент-сервер.
  • Front Controller: компонент, обычно предоставляемый базовым технологическим стеком для обработки отправки HTTP-запросов. Например, контейнер сервлетов в веб-приложениях Java, IHttpHandler в классе ASP.NET или HTTP.Server в Node.js.

Считается, что сегодня SSR (Server Side Rendering) — рендеринг на стороне сервера означает совершенно другую концепцию. Однако это не совсем так. Поскольку весь HTML/контент создается сервером, а клиентский код JavaScript не используется, веб-приложения, полностью созданные с использованием серверной MVC, все еще рассматриваются как SSR.

TypeScript. Adopt

Недавно мы провели внутренний опрос фронтенд-разработчиков (как State of Frontend, только по Тинькофф), который прошли 159 фронтенд-разработчиков. В опросе была секция про TypeScript, ответы на которые дали нам уверенность, что TypeScript стал стандартом разработки фронтенда, по крайней мере в Тинькофф.

TypeScript, как язык со статической типизацией, повышает надежность и расширяемость кода. Мы получаем самодокументированный код, интерфейсы, безопасный рефакторинг, короткий цикл обратной связи (узнаем об ошибке в IDE, а не в браузере).

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

В нашем блоге вы можете найти пару полезных статей про TypeScript:

  • Простые TypeScript-хитрости, которые позволят масштабировать ваши приложения бесконечно
  • 12 советов по внедрению TypeScript в React-приложениях

Многообразие типов тестирования

Давайте начнем с самого простого — юнит-теста. Юнит-тест — это по определению то, что тестирует «юнит» (англ. элемент). А что же такое «юнит»? Это зависит от языка программирования. Юнитом может быть функция, модуль, пакет, класс, даже объект (в языках вроде JavaScript и Scala). В JavaScript юнит — это обычно класс или модуль.

Прим. перев. Советуем также прочитать наш перевод статьи «Зачем нужны юнит-тесты».

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

Легко тестировать элемент кода отдельно, когда он не зависит от других элементов вообще. Но что, если я хочу протестировать юнит, который зависит от другого элемента кода? Мы можем сделать две вещи: протестировать два юнита вместе или замо́кать один из них.

Если мы тестируем два элемента кода вместе, это может считаться юнит-тестированием? Педант скажет, что нет. Я скажу, что это не имеет значения. Я обычно называю такие тесты юнит-тестами, но вы можете называть их интеграционными тестами или двойными юнит-тестами.

Что же такое «мок»? Давайте посмотрим на примере:

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

Но заметим, что мы не пишем в файл сами, это пишет другая функция, .

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

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

Итак, с одной стороны мы имеем юнит-тесты, с другой — E2E-тесты, тесты целого приложения. Все тестируется в E2E-тесте, а приложение работает так с теми же настройками, что и у пользователя.

С увеличением количества тестов объем протестированного кода увеличивается, а замоканного кода — уменьшается.

Интеграционными тестами я называю те, которые тестируют больше, чем юнит, но не тестируют все части приложения. Итак, в какой раздел вы поместите свои тесты? Многие люди утверждают, что существует пирамида тестирования: много юнит-тестов, поменьше интеграционных и малое количество E2E-тестов. Но давайте пока оставим эту тему — я собираюсь разобрать каждый из видов тестирования отдельно. Также я написал маленькое приложение, которое мы будем использовать в учебных целях — его исходники можно найти на GitHub.

Что такое фронтенд и чем занимается специалист

Frontend — это разработка интерфейса, с которым взаимодействуют пользователи. Называется она так, потому что это создание наружной части сайта или приложения, а значит, находится снаружи/спереди (front).

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

Основная цель специалиста — сделать использование сайта или приложения максимально удобным для конечного пользователя. Интерфейс должен быть интуитивно понятным, не перегруженным навигационными элементами и в стиле веб-площадки. Эта профессия входит в сферу веб-разработки.

Главные инструменты в этой сфере — языки веб-разметки (HTML, CSS) и программирования (JavaScript):

  • JavaScript используется для создания UI (user interface — интерфейс пользователя) с нуля;
  • На HTML производится основная верстка, где интерфейс переводится на язык, понятный современным браузерам;
  • Через CSS прикрепляются стили к структурированным документам (в случае с frontend это прикрепление стилей к документам HTML).

Фронтенд-специалист несет ответственность за то, чтобы все страницы сайта или приложения выглядели идентично во всех браузерах и их версиях, а также соответствовали макету, который был создан дизайнером (или самим веб-разработчиком). С каждым годом интерфейсы сайтов и приложений усложняются с технической стороны, зачастую становясь все более простыми для пользователя. Также к уже созданным устройствам добавляются новые, будь то планшеты, компьютеры, ноутбуки, смарт-часы и другие гаджеты.

Из этого выходит, что профессия фронтенд-разработчика требует постоянного обучения и нахождения в курсе событий в индустрии.

Отличие frontend от backend

Фронтенд-разработчик напрямую взаимодействует с пользователем через интерфейс, так как отвечает за все внешние элементы, с которыми контактируют клиенты/посетители сайта или веб-приложения.

За все обработки и действия, которые производятся на серверах, отвечает другой специалист — бэкенд-разработчик. Так как это разные профессии, в backend используется другой инструментал, включающий языки программирования PHP, Perl, Java, Python, Ruby, фреймворки и SQL для работы с данными. Кстати, на нашем сайте есть обзор профессии PHP-программиста.

В разработке любого сайта или веб-приложения участвуют оба специалиста. Так, пользователь выбирает определенные элементы в веб-интерфейсе, после чего на сервер отправляется запрос, результат которого отображается в интерфейсе. Есть fullstack-разработчик, который сочетает в себе обязанности и фронтенда, и бэкенда.

Достоинства и недостатки

Как и в любой сфере, во фронтенде есть некоторые плюсы и минусы. Поэтому в список того, что нужно знать фронтенд-разработчику-новичку, входит ознакомление с достоинствами и недостатками профессии.

Перечень плюсов:

  • Востребованность специалистов;
  • Хорошая зарплата;
  • Довольно низкий порог вхождения по сравнению с другими IT-профессиями, ведь нужен всего один язык программирования, а языки разметки и стилей значительно проще;
  • Есть как работа с исходным кодом, так и дизайнерская составляющая деятельности;
  • Со временем можно изучить бэкенд и стать фуллстэк-специалистом.

Список минусов:

  • Во многих вакансиях по этой специальности есть требования, касающиеся бэкенда;
  • Обязательно взаимодействие с другими сотрудниками (далеко не для всех это минус);
  • Хоть JavaScript и не такой сложный и требовательный, как, например, C++, для того чтобы им уверенно владеть, нужно иметь начальные знания алгебры.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector