Skip to content

Latest commit

 

History

History
640 lines (458 loc) · 83.7 KB

frontend.md

File metadata and controls

640 lines (458 loc) · 83.7 KB

INTRO

Тут собраны задания программы обучения по Frontend

У каждого задания есть свой чатик в телеграм для общения и вопросов.

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

В этом же доке вы можете найти другие полезные материалы по программе обучения:

  1. FAQ по программе обучения для первого этапа.

  2. Список с наиболее распространенными ошибками стажеров на этапе код-ревью

Введение и структура курса

Задания разбиты на 5 этапов. Ниже приведены средние сроки прохождения каждого этапа при активном изучении по 30-40 часов в неделю:

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

  • Вёрстку,
  • Инструменты сборки,
  • Архитектуру вёрстки,
  • Теорию по JavaScript,
  • MVC и применение его на фронте,
  • Написание тестов (чтобы понимать, зачем они нужны).

Изучение этого материала разбито на 4 этапа с практическими заданиями, а последний 5-й — это большой рефакторинг на основе наших стандартов с созданием issues в ваших GitHub-репозиториях, а также в пятом задание вам предстоит поучаствовать в групповом проекте. Вас ждут условия, как в реальной работе: требовательные заказчики, добрый скрам-мастер, внимательный продакт-оунер, горящие дедлайны, скоростное изучение новых технологий, взаимное код-ревью, меняющиеся по ходу проекта требования и полная удовлетворенность результатами работы как итог этапа.

Коммуникация во время обучения

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

Если вы уже знаете вёрстку или проходили курсы, то вы можете сразу перейти ко второму заданию!

Как задавать вопросы?

Вопросы — это хорошо, задавать их нужно: это поможет не только вам, но и всем кто проходит или будет проходить обучение. Помните, глупых вопросов не бывает.

  • Вопросы по задачам задавать лучше в чате, соответствующего задания.
  • Вопросы организационные лучше задавать в личном сообщении админам чата или менеджеру программы обучения в Telegram.
  • Перед любым вопросом, конечно же, смотрим сначала вопросы, которые ранее уже тут задавались, и гуглим в гугле. Если вы не нашли ответ, тогда задавайте вопрос )

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

Оформляйте код в jsfiddle или codepen с вашей проблемой, чтобы там ее можно было найти и сразу же повторить. Там должен быть только минимальный код, описывающий проблему. Возможно, пока вы будете оформлять минимальный код, выпиливая все лишнее, вы сами и найдете проблему.

Не бойтесь вставлять скриншоты (пример программы для скриншота: joxi), где показывайте интерфейс, который у вас почему-то не строится, как надо.

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

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

Как правильно задавать вопросы - Eric Steven Raymond

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

По любым вопросам по программе обучения пишите Светлане в Telegram: @Lana_Dulceva

Если вы уже знаете вёрстку, то вы можете сразу перейти ко второму заданию!

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

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

Описание задания

В основе всей работы frontend-разработчика лежит создание интерфейсов. Первый и важный навык — умение скомпоновать внешний вид на HTML+СSS по макетам дизайнера.

Часть 1

Мы рекомендуем начать обучение с курса — Stepik Веб-разработка для начинающих: HTML и CSS (без последних 2-х блоков)

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

Часть 2

Вам необходимо изучить Git (систему контроля версий). Для изучения мы рекомендуем — https://githowto.com/ru

Задание вам даст

  • Уверенные знания вёрстки с HTML и CSS.

  • Уверенное владение Git. Если вы уже владеете следующими темами, то можете по гиту пока больше не изучать и идти дальше:

    • Индексация
    • Коммиты
    • Ветки (Создание, переключение)
    • Мерж веток
    • Просмотр изменений между коммитами или между ветками
    • Разрешение конфликтов
    • Клонирование репозиториев
    • Подключение нескольких удалённых репозиториев

Дополнительный материал к первому блоку

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

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Материалы рекомендованные другими участниками программы обучения

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

Пройдите небольшой опрос — в конце опроса вы найдёте ссылку на чат для участников второго этапа.

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

Описание задания

Макет страниц по поиску номеров в отеле находится по ССЫЛКЕ

Если вдруг увидели сообщение "Editor limit reached", то вот вторая ССЫЛКА

В макете две вкладки. На первой вкладке представлен UI Kit, а на второй вкладке сами страницы по поиску номеров отеля. Переключение между вкладками находится в левом верхнем углу, рядом со значком ладошки.

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


Требования к верстке:

  • Вся вёрстка должна быть выложена на Github в ваш публичный репозиторий, результатом задачи будет как раз этот репозиторий. Под каждый проект создаём новый репозиторий. Присылать ссылку на него необязательно, это можно будет сделать только в пятом задании в личные сообщения организатору.

  • Для второго задания выделить отдельный репозиторий (мы потом отдельные issues можем туда делать). Макет опубликовать через Github Pages: https://youtu.be/9h1UiqBuxO0, чтобы мы могли быстро проверить конечный результат.

  • Ссылку на Github Pages добавить в Readme проекта, чтобы мы при проверке могли быстро перейти к самой вёрстке.

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

  • Все коммиты должны иметь осмысленные названия и быть написаны на английском языке.

  • Ориентироваться на последние версии Chrome и Firefox. На Safari и старые IE можно не обращать внимания для этих заданий

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

  • Все шрифты должны быть подключены и сгенерированы в форматах .ttf, .woff, .svg, в сервисе Font2Web

  • Количество картинок должно быть минимальным: если элемент состоит из текста, он должен быть текстовым, если элемент — это просто круг, сделать его чистым css, без картинок

  • Все страницы должны быть по максимуму responsive (здесь примеры чем responsive отличается от adaptive и liquid). Можно максимальной ширину сделать 1920, а минимальной 320, а между этими значениями подстраиваться под ширину страницы.

  • Ставить в приоритет использование современных способов создания сеток, таких как flexbox и grid.

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

  • Компонентность. В стандартах будет требоваться использование БЭМ, так что предлагаем сразу его использовать. Необходимо настроить Parcel или Webpack и шаблоны, чтобы каждый БЭМ-овский блок находился в отдельной папке (там будет шаблон самого блока и все его стили, скрипты и картинки.

    Затем в index.pug вы будете просто подключать самые верхние блоки, а они уже будут внутри себя импортировать вложенные блоки, где надо.

    Каждый отдельный элемент лучше делать отдельным БЭМ-блоком. Мы сделали небольшой туториал по компонентной архитектуре, где вы можете понять основные принципы.

  • Использовать в макетах препроцессоры по максимуму. Вам в любом случае надо будет это сделать для соблюдения предыдущего требования про компонентность, импорты и вставки компонентов друг в друга вы на сыром HTML не сделаете.
    Подключайте Parcel (или Webpack), он же нужен будет для 4-го задания, и через него настройте сборку Pug (замену HTML) и SCSS (замена CSS).
    Конкретно эти технологии просто рекомендации, можете использовать другие препроцессоры, главное, чтобы они позволяли вам сделать вкладываемые компоненты с чёткими контрактами.

  • Небольшие расхождения в PerfectPixel допускаются в местах, где есть неточности в макете (пример: разная ширина у одинаковых блоков).

  • Макет был подобран так, чтобы вы явно почувствовали типичную проблему верстки — когда есть несколько (от 3-х до 100) страниц верстки, в которых используются часто похожие (совсем похожие или с небольшими отличиями) блоки.

  • UI-Kit — это единый макет дизайна и единая страница верстки, с которой берут типовые блоки и используют в конечных страницах

  • На страницах UI-Kit responsive не требуется.

  • В этом задании вам нужно сверстать все элементы из макета, разбив на компоненты. То есть прямо по макету накидать на одной странице все компоненты.

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

  • Так же такие вещи, как бегунки, календари и дропдауны должны быть сделаны через JS. можете подключать какие угодно jQuery-плагины для этого (вообще ради этого макет и подбирался, чтобы был опыт экспериментов с подключением jQuery и его плагинов)

  • Проект можно сразу реализовывать с учетом наших СТАНДАРТОВ разработки. Именно на соответствие этим стандартам будет проводиться ревью проекта. Ссылка на стандарты (best practices).

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

Задание вам даст:

  • Понимание, как верстать большие макеты с большим количеством одинаковых элементов.
  • Навыки проектировать компонентную архитектуру, где каждый блок можно переиспользовать.
  • Работу с препроцессорами Pug и SCSS.
  • Базовые знания БЭМ.
  • Навыки отзывчивой вёрстки.
  • Самые базовые навыки работы с JavaScript.
  • Базовые знания систем сборок Parcel или WebPack по выбору.
  • Умение подключать и настраивать шрифты так, чтобы они корректно отображались в разных браузерах.
  • Умение искать, подключать и настраивать JavaScript-библиотеки и jQuery-плагины в частности.
  • Навыки работы с макетами в Figma

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Дополнительные материалы:

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

Перед тем, как вы приступите к выполнению 3 или 4 задания, поделитесь с нами впечатлениями от прохождения второго задания.

В конце опроса вы найдёте ссылку на чат в телеграме для этого и следующего уровней.

ВАЖНО! После входа в группу нужно нажать на кнопку “Я не бот”, иначе вас выкинет из группы.

Описание задания

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

Полезные ссылки для изучения JavaScript:

  1. https://htmlacademy.ru/courses/javascript — если вы не проходили в первом задании курс по JS в HTML Academy, и не обладаете начальными знаниями языка, то самое время сделать это сейчас. К сожалению, только несколько самых базовых заданий сейчас оставили доступными без платной подписки. Чтобы учиться бесплатно, лучше воспользоваться другими ресурсами.
  2. https://learn.javascript.ru/ — начальный ресурс по изучению языка JavaScript, на этом портале в трёх частях описаны основы языка, как минимум стоит изучить "Язык JavaScript".
  3. https://learn.javascript.ru/css-for-js — отдельно обратите внимание на главу про CSS для JS-разработчиков.
  4. «JavaScript. Сильные стороны.» Д.Крокфорд — мы готовы взять на работу только тех ребят, кто посчитал нужным уделить немного времени, чтобы осилить эти менее 150 страниц качественных рекомендаций. (некоторые периферийные фичи можно пропустить, например, главу про регулярные выражения и приложения Г и Д). Книга написана ещё до появления ES6, однако почти все моменты из книги до сих пор встречаются на практике либо в коде проекта, либо в коде библиотек, так что знать про это нужно обязательно
  5. «Секреты JavaScript ниндзя» Дж.Резиг, Беэр Бибо
  6. «JavaScript. Подробное руководство» Д.Флэнаган, советуем хотя бы 4 самые полезные главы про сам JavaScript: от 6-ой до 9-ой включительно.
  7. Codewars — ресурс с интересными задачками на разных языках. Много полезных упражнений, все разделены по уровням сложности. Крайне рекомендуем после выполнения задания ознакомиться с решениями других ребят, часто там можно встретить так нужные новичку best practices.
  8. Watch and Code — на ресурсе есть бесплатные курсы про JS

Желательно несмотря на начальный уровень знаний приступать к следующему заданию параллельно с этим сразу после изучения базовых возможностей языка (переменные, функции, управляющие конструкции). Это поможет вам совместить теорию и практику, закрепить полученные знания и понять как и куда двигаться дальше. Готовьтесь к тому, что вы будете переписывать свой код на много раз (минимум 5!) — это абсолютно нормально, и даже крайне полезно с педагогической точки зрения. В реальности разработка проектов чаще состоит как раз из модификации существующего кода, а не из написания абсолютно нового, поэтому навык рефакторинга крайне полезен с самых первых месяцев работы.

Задание вам даст

  • Уверенные знания самого языка JavaScript, а именно:
    • управляющие конструкции (циклы, условия);
    • основы создания и вызова функций;
    • контекст вызова функций (this);
    • области видимости/замыкания;
    • работу с массивами:
      • разные способы конструирования массивов;
      • разные способы вставки элементов в массив;
      • разреженные массивы;
      • переборы массивов через управляющие конструкции;
      • переборы массивов через методы filter/map/reduce;
      • добавление свойств массивам;
      • объекты ведущие себя как массивы (например, arguments);
      • методы (indexOf, shift, splice, slice, join, split, reverse, sort, concat);
    • работу с объектами:
      • объекты как ассоциативные массивы;
      • работа с ключами объектов (назначение, удаление, проверка существования);
      • создание через литералы и через конструкторы;
      • переборы свойств объектов;
      • передача объектов по ссылкам;
    • методы объектов;
    • конструкторы, дескрипторы, геттеры и сеттеры;
    • наследование через прототипы:
      • В том числе нюансы разных способов наследования.
    • работа с таймаутами;
    • броски и перехваты исключений;
    • работа со временем.

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Это последнее самостоятельное задание перед ревью. Чат для отчетов остаётся прежним — из 3-его задания.

Описание задания

Задание заключается в написании плагина для jQuery, который бы реализовывал функционал «бегунка» (также называемого слайдером) — специальный контрол, который позволяет перетягиванием задавать какое-то числовое (будет круто, если в реализации можно сделать не только числовое) значение.

Этот элемент уже использовался во втором задании, дизайн можно взять оттуда.


Перед началом практического задания рекомендуем познакомиться с стандартами разработки (bestpractices) по которым, на 5м задании, будет проводится код-ревью ваших проектов. Имеет смысл делать сразу по этим стандартам, чтобы ревью прошло быстрее. Ссылка на стандарты продублирована сюда из 5го задания.


Требования:

  • Плагин должен иметь удобное API для подключения его к элементам на странице и соответствовать best practices по созданию плагинов для jQuery.
  • Плагин должен уметь работать независимо, если подключен несколько раз на странице, не должен ломать стили остальных элементов на странице.
  • Плагин должен быть максимально кастомизируемым. Помимо базовых конфигов вроде мининимально, максимального и текущего значения, надо позволить настраивать:
    • размер шага - он может быть ЛЮБЫМ ВАЛИДНЫМ, подстраивать max или min значения слайдера под размер шага при этом не нужно, как и наоборот, не нужно подстраивать размер шага под max или min значения,

      Пример невалидных значений: При min 0, а max 10, шаг не может быть 11.

    • вертикальный/горизонтальный вид,

    • одиночное значение или интервал,

    • возможность на лету изменить значение "снаружи" javascript-ом,

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

    • шкала значений - элемент, который отображает диапазон значений, в пределах которого можно двигать ползунок. Минимальное значение шкалы = значению min слайдера, максимальное = значению max слайдера. Шкала должна быть интерактивной. Т.е. при клике на значение шкалы, ползунок должен перемещаться на позицию этого значения.

    • прогресс бар - элемент от min до значения первого ползунка, при одиночном значении, либо, от значения первого ползунка до значения второго ползунка при интервале. Узнать как выглядит прогресс бар (разноцветные полоски)

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

    • Работа на тач устройствах - слайдер должен корректно работать на тач устройствах

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

  • Панель должна быть синхронизирована со слайдером.
  • Для манипуляций числовыми значениями нужно использовать input с типом number или text.
  • Весь код должен быть на Github в вашем публичном репозитории, результатом задачи будет как раз этот репозиторий.
  • Требования к ежедневности коммитов и их названиям остаются, как во втором задании: коммиты минимум раз в день, когда вы хоть что-то сделали, у всех элементов должны быть осознанные названия.
  • Обязательно написание кода на TypeScript. Мы используем этот язык в разработке, он помогает держать сложность больших проектов под контролем, а также выручает при проектировании. Cтарайтесь настроить tsconfig максимально строгим образом. Код тестов желательно тоже писать на TypeScript, но это нестрого обязательно.
  • Использовать ‘any’ разрешается только в одном случае. Когда у вас совершенно никак не получается затипизировать без использования ‘any’ и вы испробовали все возможные варианты. Также вам ОБЯЗАТЕЛЬНО нужно будет написать подробный комментарий, почему вы не смогли обойтись без использования ‘any’.
  • У вашего приложения должны быть четко разделенные слои приложения:
  • Нужно сделать отдельный слой управления данными (Model), который будет содержать бизнес-логику приложения и не производить никаких расчетов, которые нужны для отображения.
  • Отдельный слой для управления отображением (View) — здесь нельзя проводить никаких расчетов, относящихся к бизнес-логике. Слой должен содержать логику, связанную с отображением (например, для изменения положения ползунка слайдера на экране), а также реагировать на взаимодействие пользователя с приложением. Каждый компонент слайдера (бегунки, шкала и т. д.) должен быть представлен отдельным классом. Благодаря такой декомпозиции View, функционал будет четко разделен между subViews, а вы научитесь решать проблемы взаимодействия в рамках многоуровневой структуры.
  • Отдельный слой для обновления модели и отображения (Controller или Presenter). Это - единственный слой среди трех, который может иметь зависимость от других слоев. Он будет:
    • реагировать на сообщения от отображения о действиях пользователей и обновлять модель;
    • реагировать на сообщения об обновлении модели и обновлять отображение.
  • На выходе должно получиться подобие MVP-архитектуры с Passive View. Обязательно прочитайте про MVC архитектуру, про то, зачем она нужна, и какие у нее есть ответвления. Также изучите, как можно писать MVC-приложения на JavaScript. Вот несколько полезных источников:
    • https://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/ — описание MVC и MVP архитектур и различий между ними;
    • https://habrahabr.ru/post/321050/ — подробный разбор MVC, часть 1;
    • https://habr.com/ru/post/322700/ — подробный разбор MVC, часть 2;
    • https://habrahabr.ru/post/276593/ — основы архетектуры, статья довольно сложная для новичка, нормально, если вы её в первый раз не очень глубоко поймёте, а потом под конец 4-го задания ещё раз вернётесь;
    • Мы ожидаем, что это требование создаст больше всего проблем для вас и вызовет больше всего вопросов, зато для вас это будет самым ценным опытом — разобраться в простейших паттернах проектирования и попробовать создать что-то свое небольшое с нуля, используя такие паттерны. По возникшим вопросам (правильно сформулированные, например, по рекомендациям данным выше) вам всегда могут помочь в общих чатах нашей программы. Так что смело задавайте вопросы, экспериментируйте и готовьтесь к тотальному переписыванию кода минимум пару раз :)
  • Архитектура приложения должна быть задокументирована:
    • В README проекта нужно добавить описание вашей архитектуры.
    • После проектирования слоёв приложения, в README вам нужно написать, как вы отвязываете ваши слои приложений от внешних зависимостей, и осуществляете передачу данных снизу-вверх по слоям приложения. Возможно, вы обратили внимание, что получившиеся слои не являются равнозначными: есть слои с высокими уровнями абстракции, а есть — с низкими. Помимо этого, возможно, вы заметили, что каждый класс вашей архитектуры отвечает за отдельный аспект приложения.
    • Помимо этого, вы должны составить UML-диаграмму своего приложения, которую тоже нужно добавить в README. Программа для составления диаграммы: https://www.draw.io/
    • Приложение должно быть покрыто тестами:
      1. Самые основы можно почитать в главе у Кантора: https://learn.javascript.ru/testing. («В этой главе мы разберём основы автоматического тестирования. Оно будет применяться далее в задачах, и вообще, входит в “образовательный минимум” программиста.»).
      2. Сами тесты обязательны к написанию, должны находиться так же в репозитории, команда запуска тестов должна быть описана в README, запуск тестов после клонирования должен быть максимально простым (в идеале выполнения одной команды npm i && npm test должно быть достаточно), тестами должны быть покрыты все слои вашего приложения.
      3. TDD (которое в том числе немного описано у Кантора) — это когда сначала пишутся тесты, а после уже сами модули и методы.
      4. Это необязательное условие, особенно допустимо его нарушить для первой версии вашей программы. Желательно потом после создания каркаса попробовать некоторую функциональность добавить пару раз с использованием техники TDD (это как раз про то, что сначала должны быть тесты, потом сам код), это поможет вам лучше почувствовать методику.
    • Желательно попробовать какие-нибудь новые молодежные фичи: все на ваш выбор и все необязательно. Будет круто, если сможете написать кастомные правила для линтера или небольшой сервачок, например. Но ни в коем случае не фреймворки (Angular, Ember, etc) и не React, вам нужно самим проработать MVC-архитектуру, а указанные решения навязывают сверху что и как делить в приложении.
    • Проект можно сразу реализовывать с учетом наших СТАНДАРТОВ разработки. Имеено на соответствие этим стандартам будет проводиться ревью проекта.
      Ссылка на стандарты или best practices.

Задание вам даст

  • Базовые навыки проектирования (ООП, вариации MVC-архитектуры, разделение ответственности).
  • Навыки по созданию удобных библиотек с удобным API (интерфейсом использования для других разработчиков).
  • Навыки разделения конфигурирования и бизнес-логики.
  • Умение документировать свой продукт (описывать заложенную архитектуру, визуализировать её через UML-диаграммы).
  • Навыки автоматического unit-тестирования (включая TDD).

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Дополнительные материалы:

Один из заключительных этапов — большой рефакторинг на основе наших стандартов с созданием issues в ваших github-репозиториях и проверка ваших знаний на личной беседе (в офисе или через созвон) c неограниченным количеством попыток.

Но перед стартом последнего этапа просим вас пройти небольшой опрос.

Ссылка для общения в чате в телеграм.

ВАЖНО! После входа в группу нужно нажать на кнопку “Я не бот”, иначе вас выкинет из группы.

Описание задания

В этом задании у нас три шага:

1. Рефакторинг по нашим стандартам

У нас сейчас есть объемный документ, куда мы собираем все полезные и нужные требования к реальным проектам, готовым к сдаче заказчикам. В документах собраны правила, которые помогают избегать нерасширяемого и не очевидного кода, и все их нужно хотя бы в общих чертах помнить, прежде чем приступать к реальным проектам. А лучший способ запомнить — попробовать исправить все свои ошибки в ваших выполненных за время обучения проектах. Для помощи вам в нахождении неточностей участники программы обучения сами создали плагин для eslint, которым вы можете воспользоваться. (берите в расчет, что плагин ещё активно тестируется, там могут быть ошибки. Не бойтесь создавать ишью в репозитории плагина, а ещё лучше сами начинайте контрибьютить в open-source, исправляя недочёты и открывая Pull Request.)

Главное — не бойтесь, что мы будем криво смотреть на недочеты в прошлом коде. Мы очень лояльно относимся к коду новичков, так как сами через это проходили :)

Описание стандартов находится в нашем репозитории на Github.

Мы выдаем вам требования, а вы вносите по ним правки в текущие проекты. Затем после рефакторинга напишите нам в чате, что все готово.

ВНИМАНИЕ! Перед тем, как передать нам проекты на ревью окончательно проверьте и убедитесь, чтобы ВСЕ СТАНДАРТЫ ТЩАТЕЛЬНО СОБЛЮДАЛИСЬ. Мы все равно потом будем очень внимательно смотреть ваши проекты и оставлять на все нарушения задачи, но нам не хотелось бы тратить время на банальные и скучные правки, поэтому если вы заранее по максимуму подготовите свой код, то ревьюверы будут вам благодарны, обязательно это отметят, а само ревью будет проводиться гораздо эффективней, а задачи будут гораздо интересней.

2. Код-ревью

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

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

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

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

Чтобы начать процесс ревью ещё раз проведите контрольное ревью проекта по нашим стандартам, и если все правила точно соблюдены, пишите в Телеграм Светлане: @lana_dulceva.

3. Интервью по теоретическим вопросам

В нашем репозитории с картой развития у нас подготовлены около 80 вопросов по материалам из первого и третьего задания (про изучение вёрстки и изучение JavaScript). Там мы проверяем, что вы действительно изучили весь тот материал, помогаем вам побороть неосознанную некомпетентность через получение обратной связи от нас. Количество попыток на сдачу неограниченно, обычно уходит неделя-две, чтобы повторить изученное и ещё неделя на две-три попытки сдачи, после чего задание успешно завершается. В рамках этого шага вы действительно систематизируете все полученные знания, закрываются дыры в знаниях, которые почти наверняка у вас будут, обычно это один из самых эффективных этапов в обучении, когда каждый день на уже крепкую основу ваших знаний укладывается огромное количество нового и полезного материала. Сами вопросы вы можете посмотреть в нашем репозитории на Github (папка junior-1).

Требования к исправлениям:

  • По каждому замечанию мы будем создавать issue в вашем репозитории. Коммиты с исправлениями по каждому issue стоит называть, ссылаясь на номер ишью через #. Например, для ишью "Убрать неиспользуемые переменные" с номером 14, будет коммит, с названием типа "unused variables removed #14". Это позволит при проверке сразу увидеть, какой коммит к чему относится.
  • Не стоит делать большие коммиты: в идеале каждый коммит по исправлению оставленных issue должен быть в рамках данного конкретного issue. Делать несколько коммитов для одного issue, если он большой — приветствуется, делать один коммит для нескольких issue — нет.
  • Исправляя ошибки по оставленным замечаниям, не забывайте делать это во всем проекте (и даже в других своих проектах, пока, например, ожидаете очередную итерацию ревью), а не только в том месте, которое приводится в качестве примера. Проверяющие не всегда будут сразу находить и указывать на все места, где встречаются те или иные ошибки. Так вы сэкономите время и себе и нам: вы быстрее пройдете ревью, а мы не будем писать одно и то же несколько раз :)

Задание вам даст

  • расширение и закрепление ваших познаний в области проектирования

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

  • закрепление полученных теоретических знаний;

  • базовые навыки командной работы (получения код-ревью и работы с ишью);

  • навыки написания чистого поддерживаемого кода (изучение наших стандартов, чтение ишью от проверяющих);

  • пошаговый рефакторинг своего кода.

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Описание задания

  1. Этот блок совместит в себе изучение библиотеки React и получение опыта работы по гибким методологиям в команде с другими обучающимися (3-7 человек) над одним проектом. Такая команда будет формироваться из обучающихся, кто находится на этапе код-ревью (Задание 5), на проверке заданий ВТОРЫМ ревьюером.
  2. Продолжительность блока — 2,5 месяца (пять 2-недельных спринтов). Работа над проектом в команде, изучение React, код-ревью заданий, а потом и сдача вопросов на Junior-1 будут идти параллельно. Таким образом, вы заполните пользой время между итерациями иногда затягивающегося код-ревью, получая новые полезные скиллы.
  3. На прохождение нового блока программы необходимо выделить минимум 15 часов в неделю свободного времени, по нашим подсчетам. Идеально, если получится уделять проекту по 2-3 часа каждый день. Время в течении дня вы распределяете сами.

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

Если вы уже завершаете проверку обоих проектов первым ревьюером на 5-м задании и есть возможность начать работу над проектом, напишите менеджеру программы обучения Светлане в телеграм: @lana_dulceva, чтобы рассмотрели возможность поставить вас в проект раньше.

Ссылки для изучения React:

https://ru.reactjs.org/docs/getting-started.html - обзор документации и других ресурсов, которые могут пригодиться при первом использовании React.

Задание вам даст

  1. Опыт работы в команде по Scrum, владение популярной библиотекой React, умение применять полученные знания сразу в этом же проекте. А после трудоустройства в «FSD» вы сможете быстрее получить уровень Junior-2 по карте развития, ещё во время испытательного срока, а значит и новую ЗП.
  2. Практику работы над проектом в максимально приближенных к условиям на реальном коммерческом проекте: с дедлайнами, митингами, код-ревью коллег по команде, тайм-трекером, таск-трекером, тимлидом, менеджером проекта, заказчиком, с той лишь разницей, что можно безболезненно переживать факапы (а они будут) в качестве кода, в дедлайнах, в коммуникации с заказчиком и т.д.

По любым вопросам по программе обучения пишите Светлане в Telegram: @lana_dulceva

Дополнительные материалы:

Всякие полезности

Статьи по JS
Сборник самых заковыристых тем JS — JavaScript Garden

Functions
Objects, classes etc
Other

Книга Выразительный Javascript

30 последовательных урока по изучению базового JS (без установки библиотек, настроек вебпака и тд)
Аналог html academy, только включая JS и другие языки
  • http://skills.itvdn.com.

    HTML&CSS - состоит из 138 заданий
    JavaScript для начинающих - состоит из 94 заданий
    C# Starter - состоит из 40 заданий
    C# Essential - состоит из 90 заданий
    SQL Essential - состоит из 41 задания

Пример сложной архитектуры (браузерная игра)
React day on Frontend Racoon
Вы просто проглядели весь список вверху и не читали оттуда материал к текущему моменту? Это нормально. Вот это уж точно можете прямо сейчас посмотреть
Полезные расширения для VS Code
  • Code Spell Checker - The goal of this spell checker is to help with catching common spelling errors while keeping the number of false positives low.
  • px to rem - This is an extension for Visual Studio Code that allows you to convert px to rem, and vice versa.
  • Local History — save last changes of the files even without Git

Генератор файлов "бэмовского" блока. Очень удобная вещь по упрощению себе жизни