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

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

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

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

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

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

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

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

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

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

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

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

PM — Project manager

менеджера проектовPMPM

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

• английский Upper Intermediate и выше, так как ПМ коммуницирует со стороной заказчика от лица команды;
• широкие технические знания, но не сильно глубокие, чтобы можно было понимать, кто чем занимается, как происходит работа в целом, не сильно углубляясь;
• навыки управления проектами и участвующими в них командами;
• сильнейшие коммуникационные навыки, так как работа PM в основном состоит из коммуникаций с членами команды, руководством;
• развитые навыки ведения переписки. К примеру, часто нужно посылать письма на email заказчика от лица команды, компании, и письмо неправильно составленное или с ошибками никто не оценит;
• аналитический склад ума, который будет полезен при решении проблем, возникающих во время работы над проектом;
• навыки тайм-менеджмента, использование которых позволит держать проекты в рамках графика и бюджета (ведь время=деньги);
• навыки планирования ресурсов и задач.

700$1200-4500$В кого можно вырасти:

• delivery manager (DM) — прямое продолжение PM-a, стоит сразу над группой PM-ов и координирует их проекты на более высоком уровне;
• program manager — координирует несколько взаимосвязанных проектов, но я сам не сильно понимаю различие с DM-ом;
• chief technical officer (CTO) — технический директор, несущий ответственность за разработку продуктов и улучшение их процессов создания;
• chief executive officer (CEO) — главный исполнительный директор;
• account manager (AM) — менеджер по работе с клиентами;
• переучиться и перейти в другую специальность ))

Оплата труда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trunk based development (TBD). Assess

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

В TBD ветки с новым кодом вливаются в основную ветку не реже чем раз в 24 часа. С помощью этого команда получает ускоренный цикл обратной связи по задаче. В более распространенных моделях ветвления изменения дольше копятся, часто в момент попадания изменений в основную ветку объявляются неожиданные проблемы, исправление которых несет дополнительную сложность из-за позднего времени их обнаружения. В TBD все изменения делаются максимально атомарными, интегрируются с самой новой версией основной ветки как можно чаще, что создает определенные требования к архитектуре приложения, такие как поддержка Feature Flags, чтобы иметь возможность отключать из исполнения еще не завершенные задачи.

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

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

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

Frontend языки

Список популярных языков, которые регулярно используются в сфере разработки интерфейсов, включает в себя:

• JavaScript: с его структурами и библиотеками, это ядро разработки в интерфейсе и за его пределами. Это первый клиентский язык, который по-прежнему является самым вездесущим сценарием на клиентской стороне в Интернете.
• HTML5: HTML диктует организацию и контент сайта, все взаимодействие, так что это то, что должен знать каждый frontend разработчик. Элементы HTML могут аннотировать нижние колонтитулы, заголовки, как отображаются тексты, как появляются медиа и изображения, и многое другое.
• CSS3: последний стандарт для каскадных таблиц стилей (CSS). CSS3 разбит на модули и содержит код для каждого графического элемента — от фона до шрифта — который составляет внешний вид веб-сайта.
• Также полезно: предварительный компилятор CSS, такой как Sass или LESS
• AJAX: JavaScript + XML, он позволяет обновлять определенные части сайта без обновления полной страницы путем асинхронного подключения к базе данных и вытягивания блоков данных на основе XML.

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

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

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

MVVM — Model View ViewModel

MVP великолепен, и для него есть много возможных вариантов и сложных деталей, но с точки зрения фронт-энда MVVM действительно выделяется. В некоторых реализациях он также известен как Model-View-Binder. MVVM очень похож на Passive View MVP, но с добавленной особенностью привязки данных (data binding). Это техника программирования, которая связывает данные поставщика и потребителя вместе и синхронизирует их. Она избавляет от большого количества стандартного кода, который нам традиционно необходим для синхронизации View и Model. Это позволяет работать на гораздо более высоком уровне абстракции.

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

1. ViewModel — это объект, который предоставляет связываемые (bind-able) свойства и методы, которые используются View.

2. MVVM имеет дополнительный элемент Binder, который отвечает за синхронизацию View с ViewModel. Каждый раз, когда свойство ViewModel изменяется, Представление автоматически обновляется, чтобы отразить изменения в пользовательском интерфейсе.

Мы еще раз вернемся к привязке данных в разделе веб-приложения.

Как стать фронтенд-разработчиком

Для начала снять розовые очки. Обучение — это труд и самодисциплина. Большинство начинающих айтишников отсеиваются на этапе «хочу стать программистом и получать зарплату в долларах, но не думал, что придётся так много учиться».

Уникальность программирования и вообще любой айтишной специальности ― в постоянном самообучении. В этом и сложность, и прелесть IT-сферы. Если вас это не пугает — круто! У вас есть все шансы стать отличным специалистом.

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

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

Затем взяться за JavaScript: синтаксис, архитектура и возможности языка. Освоить популярные фреймворки и библиотеки, параллельно полюбить системы контроля версий и какой-нибудь из популярных таскраннеров. Добавить препроцессоры и фреймворки CSS, разобраться в серверных технологиях. А дальше можно пить смузи на Бали и шлифовать полученные знания до бесконечности.

Примерный путь начинающего фронтенд-разработчика. У вас он будет свой

Пройти этот путь можно как в одиночку, так и с наставниками (вузы, курсы). Вот какие самые популярные форматы обучения разработчиков по версии StackOverflow:

Данные StackOverflow

Мифы о UI/UX-дизайнерах

Вначале я хотел бы обратить внимание на предвзятое отношение и недоверие фронтендщиков к UI/UX-дизайнерам. Далее по тексту я опущу приставку UI/UX и буду писать просто «дизайнер», подразумевая именно дизайнеров интерфейсов.  Выделим несколько мифов, которые мешают в коммуникации

Мой дизайнер ни за что не изменит свой макет. Это один из самых распространённых мифов. Многие разработчики думают, что макет для дизайнера — это как картина для художника, он закончил её и больше ни за что не изменит. В реальности всё не так. Как программисты продолжают работать над кодом, устраняя технический долг и совершенствуя код, так и дизайнеры продолжают работу над макетами. Если команда большая, макет вообще может начать жить своей жизнью. В моей практике почти все дизайнеры шли мне навстречу, если я просил что-то изменить. Даже в самом глубоком энтерпрайзе, где макеты проходили несколько этапов согласований, мы всё равно находили возможность что-то подкорректировать. В любом случае изменения в макетах неизбежны, ведь не все из гипотез дизайнера проходят проверку на реальных пользователях. Если вы можете доходчиво объяснить причину предлагаемого изменения (например, ваш вариант позволяет сэкономить на времени разработки вдвое или есть готовая библиотека с нужным поведением, но немного отличается внешне), вы найдёте компромисс со своим коллегой. Он либо поправит макет по вашим предложениям, либо объяснит, почему его вариант важен для проекта.

Мой дизайнер самый ленивый. Этот миф возникает, когда приходишь несколько раз с одной и той же просьбой к своему дизайнеру, но он её упорно игнорирует. Зачастую дизайнеров меньше на проекте, и они всегда завалены работой и техдолгом (как я уже упоминал выше, техдолг есть не только у разработчиков). Если работа простаивает без помощи дизайнера, лучше сходить к тимлиду — возможно, есть задачи, которыми можно заняться в ожидании макета. Например, настроить инфраструктуру, среду для тестирования или что-нибудь ещё. Если тимлида нет, можно спросить дизайнера, чем он занимается, и помочь ему с расстановкой приоритетов. Объясните, какие экраны нужны в первую очередь, а какие могут подождать. Возможно, ваш дизайнер готовит дизайн-систему для проекта, тогда его лучше вообще не отвлекать, ведь как и у программистов, у них всегда есть важные задачи, при работе над которыми лучше не отвлекаться. Если вам действительно что-то очень нужно, объясните почему, спросите, когда у коллеги будет возможность заняться вашим вопросом, и до этого времени постарайтесь его не беспокоить.

Мой дизайнер только рисует макеты, откуда он знает, как лучше? Этот миф распространен у Junior-разработчиков. Специально для них объясню, что дизайнеры — то люди, которые прорабатывают макет не только чтобы он смотрелся красиво и современно, но и чтобы им было удобно пользоваться. Они знают множество паттернов поведения пользователя, сочетания цветов и форм, о которых мы не догадываемся, поэтому лучший совет в этом пункте: больше доверяйте своему коллеге, он наверняка знает, что делает.

Мой дизайнер самый упёртый. Наверняка каждый фронтенд-разработчик слышал «нет» от дизайнера, отсюда и возникает этот миф. Опираясь на предыдущие мифы, первый совет — поверьте ему на слово. Если не удаётся, попробуйте получить у него больше информации, почему он говорит «нет», или обратиться к его менее загруженному коллеге за разъяснением (правда, таким образом можно обидеть своего дизайнера, будьте к этому готовы).

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

MVC предков — Первоисточник

Отделение данных от представления является основной темой графических пользовательских интерфейсов (как веб-ориентированных, так и настольных). С MVC — Model View Controller, отделение представления (View) от доменной области (Model) было основной мотивацией проектирования. И, без сомнения, MVC была плодотворной работой, которая повлияла на будущие поколения.

MVC был представлен для Smalltalk-80. В MVC объект View отображает данные, хранящиеся в объекте Model. Прежде чем мы сможем полностью изучить потоки данных в MVC, мы должны понять среды прикладных программ того времени (около 1970-х годов):

• Этот MVC был предназначен только для настольных приложений. Веб еще не родился. Мы говорим о десятилетии до этого.
• Забудьте о Web. Сложных операционных систем с графическим интерфейсом не существует.
• Это означает, что прикладное программное обеспечение было очень близко «железу» систем.

Эти ограничения имели важные последствия для MVC. Обязанностью объекта Controller стало реагирование на пользовательские вводы, такие как клавиатура или мышь, и их преобразование в действия над моделью. Кроме того, отсутствие графических элементов в операционных системах означает, что Представление (View) не соответствует тому, что на экране.

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

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

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

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

2. Модель реализует шаблон Observer, и на него подписывается один или несколько объектов View. Когда Model изменяется, она вызывает событие, и View обновляется после реакции на событие.

В MVC есть два разных потока данных. Во View-потоке Model не участвует. Это только изменение пользовательского интерфейса. Показ эффекта нажатия кнопки или реакция на событие прокрутки мыши — пример View-потока.

Сегодня мы больше не используем этот MVC и поэтому иногда его называют классическим MVC или MVC предков (father’s MVC).

Что должен знать Frontend-разработчик

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

Язык CSS. Практически на всех курсах CSS преподается вместе с HTML. CSS – это система стилей, за счет которых сайты смотрятся красиво.

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

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

Например, есть какая-то база с данными о людях: их пол, возраст, фамилия и имя. Вам надо посмотреть всех людей, которым больше 18 лет – вы указываете этот возраст, нажимаете на кнопочку и на сайте запускается джава скрипт, который «вынимает» нужных людей из базы и показывает вам.

Если вам надо отдельно выгрузить мужчин и женщин – вы нажимаете еще на одну кнопочку – запускаете еще один джава скрипт, который выгружает сначала всех мужчин, а потом всех женщин.

Что должен знать хороший frontend-разработчик?

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

На самом деле это то же самое, что забивать гвозди микроскопом. Верстальщик сможет сверстать готовый макет от дизайнера, пользуясь html и CSS. В отдельных случаях он «прикрутит», куда требуется, в плагин или библиотеку JavaScript.

У фронтенда задача на порядок более сложная и комплексная. Поэтому и знания у него должны быть соответствующие:

1. Frontend Frameworks;

2. HTML и CSS;

3. JavaScript;

4. JQuery

5. Работа с препроцессорами CSS;

6. Дизайн;

7. Кросс-браузерная разработка;

8. Системы управления контентом и платформы для электронной коммерции;

9. Тестирование и отладка;

10. Системы контроля версий Git и Version.

При этом хорошему фронтенд-разработчику требуется разбираться и в принципах поисковой оптимизации (SEO), различать виды верстки (адаптивная, мобильная, отзывчивая), понимать принципы оптимизации продукта под различные операционные системы и браузеры (если речь о создании сайтов).

Общий монорепозиторий. Hold

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

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

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

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

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

Надеюсь, первый эксперимент дал вам определенную уверенность в написании HTML и CSS. Для эксперимента 2 мы заглянем на ряд сайтов, затем напишем код нескольких компонентов.

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

• Dropbox for Business: Попробуйте повторить их секцию с баннерами (так называемые hero image (англ.))
• AirBnB: Попробуйте повторить их футер
• PayPal: Попробуйте повторить их навигацию
• Invision: Попробуйте повторить секцию регистрации (signup) в нижней части страницы
• Stripe: Попробуйте повторить секцию оплаты

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

Вы можете использовать CodePen для своих экспериментов или выполните их на своем компьютере. Если вы планируете работать локально, то так же можете скачать этот пример проекта в качестве шаблона или создать файлы с нуля. Я советую вам использовать редакторы Atom или Sublime.

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

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

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

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

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

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

Карьерный путь и зарплата фронтенд-разработчика

Карьерный пусть фронтендера обычно начинается с верстальщика — это самый логичный и общепринятый вариант. Сначала изучается связка HTML+CSS, затем на неё наслаиваются знания JavaScript, библиотек и фреймворков. Будущий специалист также изучает ключевые понятия построения серверной части, добавляет сюда инструменты, необходимые для выбранной специализации. Затем всё это шлифуется умением работать с контролем версий, графическими редакторами и пониманием принципов UI/UX-дизайна.

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

У готового фронтенд-разработчика в целом есть три основных варианта развития:

горизонтальный ― совершенствоваться как специалист, тем самым постоянно повышая свою стоимость на рынке труда;

вертикальный ― расти по карьерной лестнице;

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

Сервис PayScale наглядно проиллюстрировал все возможные пути карьерного развития фронтенд-разработчика:

Какой из них выбрать — зависит лишь от самого специалиста и его пожеланий или навыков.

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

Средняя зарплата фронтенд-специалиста по России, рублей/месяц:

По данным «Моего круга»

Средняя зарплата фронтенд-специалиста по Москве, рублей/месяц:

По данным «Моего круга»

Традиционно годовая зарплата фронтенд-разработчиков в США чуть выше, чем по России. Однако, если вы работаете в филиале иностранной компании, вам такой разрыв, скорее всего, не страшен.

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

Сетка. Практически все макеты строятся на основе сетки. Зная её, верстать становится проще, а учитывая, что теперь у нас есть grid, это превращается в удовольствие.
Основы Figma. Говорить с дизайнером на одном языке и понимать особенности и отличия вёрстки в Figma и WEB-е.
БЭМ

Неважно, как вы верстаете, будь то CSS-in-JS или CSS-modules, методология позволяет навести порядок в голове и мыслить правильными категориями.
Наследование стилей. Многие CSS свойства наследуются от родительского блока, в Figma это отсутствует.Чтобы не переписывать все стили, не глядя , помните, какие свойства берутся от родителя, а какие объявляются в самом элементе.
Конечные автоматы

Понимать, сколько состояний может быть у того или иного элемента на странице.

Повторю мысль из предыдущих частей: если вам что-то непонятно или интересно — к своему дизайнеру и задавайте вопросы, набирайтесь опыта в построении интерфейсов у профессионалов.