Скоро стартует 32 поток нашего курса-долгожителя про профессиональную вёрстку сайтов. Кто-то из читателей запомнил его как «Базовый HTML и CSS» или даже как «Разработку веб-интерфейсов с помощью HTML и CSS». 

32 поток — знаковый для нас, и к его началу мы подготовили самое глобальное и серьёзное обновление курса за всю историю. Работа над ним заняла целых девять месяцев!

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

Обновление критериев качества

Критерии — это боль для авторов (серьёзно, их очень сложно делать и обсуждать), но это и сердце каждого курса, ведь всё начинается с них.

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

Зачем вообще было обновлять критерии

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

Ответ прост — в старой системе критериев накопилось очень много «технического долга». В индустрии многое изменилось за последние годы, и это повлияло и на то, как нужно верстать: случились пришествие флексов и гридов, отказ от ИЕ, переход с Фотошопа на Фигму. С ударами мы справлялись, латали отдельные критерии, но вся система страдала: копились противоречия и слепые пятна.

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

Здесь же отметим то, что нас особенно радует в новых критериях:

1. Критерии полностью синхронизированы с требованиями рынка и «Лиги А.». Представители Лиги Академии участвовали в разработке критериев от первых черновиков до окончательной шлифовки формулировок. Напоминаем, что «Лига А.» — это фронтенд-аутсорс Академии, в котором выпускники профессий работают над коммерческими проектами.

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

3. Мы избавились от «всенародно любимых» критериев-сборников наподобие «Б4. Грубые ошибки в разметке» (тут олды должны всплакнуть) и заменили их отдельными критериями с чётким перечнем правил проверки.

4. Система критериев свежа, бодра и актуальна, как резвый кот в четыре часа ночи, и прослужит нам ещё много лет.

С гордостью показываем финальный результат, о котором мы уже рассказывали на Хабре. 

Обновления проектов

С их помощью которых студенты закрепляют учебный материал и оттачивают навыки.

На заре существования Академии проекты для курсов полностью зависели от дизайнера. В письме я просто перечислял примерные блоки, которые должны быть на макете («шапка, подвал, список товаров, форма входа и так далее»), а всё остальное дизайнер определял сам.

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

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

Поэтому мы решили не просто обновить макеты, а сделать это серьёзно и по науке! И провели предварительное исследование (ещё в конце 2020 года).

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

Затем мы попросили у «Лиги А.» (а у неё на тот момент было уже более 500 выполненных проектов) описать типовые элементы макетов, которые им приходится часто делать, и особенно те элементы, с вёрсткой которых у выпускников возникают проблемы.

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

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

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

Можете полюбоваться обновлённым учебным проектом «Барбершоп».

Вёрстка учебного проекта

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

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

Пытались ли вы посадить рядом трёх взрослых мужиков и сделать так, чтобы они договорились о том, каким должен быть код? Пытались ли вы это сделать на десяти проектах подряд? Вот, то-то же. А теперь немного хронологии.

Ладно, давай обернём эти поля формы в тег <p>, а за это ты сможешь ставить точки в конце альтов

Март 2021 года. На руках у нас есть критерии и есть макет обновлённого учебного проекта. Мы планируем за недельку сделать его вёрстку и за пару неделек разбить её на шаги. В итоге на это ушло не три недели, а два месяца, Карл!

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

Мы сделали конечную реализацию и стали планировать шаги. Получилось девять. Ок. Давайте писать код.

И тут выяснилось, что самое сложное не написать код, а договориться о конечном варианте. Было жарко, были и разумные аргументы, и шантаж, и торги разработческими фетишами: «Ладно, давай обернём эти поля формы в тег <p>, а за это ты сможешь ставить точки в конце альтов». Кстати, если у вас есть свои «специфические вкусы» в коде, вроде любви к тегу <b>, поделитесь в комментариях.

И всё-таки мы справились. Мы получили девять полностью готовых состояний проекта, больше 9000 строчек кода на HTML и CSS и полное понимание того, какие именно задачи нужно решить ученику на каждом этапе. И как бонус, полное взаимопонимание и согласие между авторами.

Це-ле-по-ла-га-ни-е

Это самая нудная, но важная, но скучная, но важная часть.

Вопрос: «А что мы учим делать на этом курсе?».

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

Ответ: «Учим делать идеальную вёрстку без адаптива в идеальных условиях»

Почему так, почему без адаптива, что такое идеальные условия?

Начнём с «идеальных условий». Такие условия наступают, когда верстальщик полностью контролирует свою разметку и у него достаточно времени, чтобы написать идеальный код. И ещё отсутствуют специфические требования, наподобие максимального приоритета скорости загрузки интерфейса над всем остальным. Чаще всего такое происходит при работе над интерфейсами в продуктовых компаниях.

Почему «без адаптива»? Максимально упрощённо: адаптив — это когда верстается не один компонент, а несколько его версий, по сути, несколько компонентов. Да, нужно продумать, как одна версия будет превращаться в другую. Но необходимый фундамент — это умение верстать отдельные компоненты, причём их самые сложные версии (то есть десктопные).

Зачем учить делать «идеальную вёрстку» и «идеальный код»? Потому что это самая сложная задача, и будущие крутые разработчики (а ведь крутым разработчиком хочет стать каждый) должны уметь решать задачи максимального уровня сложности. Вот какой ты сильный разработчик, если не можешь решить задачу на первоклассном уровне?

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

Думаю, теперь понятна роль каждого курса в профессии «Фронтенд-разработчик»:

1. HTML и CSS. Профессиональная вёрстка сайтов — «идеальная» вёрстка без адаптивности.

2. HTML и CSS. Адаптивная вёрстка и автоматизация — «идеальная» адаптивная вёрстка плюс инструменты автоматизации.

3. JavaScript. Профессиональная разработка веб-интерфейсов — «идеальная» реализация интерактивных компонентов на чистом JavaScript.

4. Подготовка вёрстки для cистем управления контентом (CMS) — «неидеальная» вёрстка в специфических условиях, связанных с системами управления контентом (например, часто теряется возможность контролировать разметку, ведь контент создаётся кем-то другим).

5. Вёрстка React-компонентов — «неидеальная» вёрстка с учётом требований экосистемы React.

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

Обновление программы

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

• определились, чему же мы учим (идеальная вёрстка в идеальных условиях),

• изучили рынок и собрали коллекцию компонентов интерфейсов,

• с помощью этой коллекции отрисовали обновлённые макеты,

• обновили систему критериев,

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

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

1. Для каждого шага анализируем код проекта,

2. Описываем задачи, которые решаются на этом шаге,

3. Подбираем материалы, которые нужны, чтобы научиться эти задачи решать.

Вот и весь алгоритм.

Намного интереснее сравнить новую программу и старую:

• В новой программе нагрузка распределена намного равномерней, чем в старой. Мы точно знали, какой объём кода нужно написать ученикам на каждом шаге и какова его сложность, поэтому смогли намного точнее определить время на изучение материалов и выполнение домашек. Например, теперь у нас три раздела про сетки вместо двух, а времени на эти разделы выделено в два раза больше!

• Ушли разделы про вёрстку контентных элементов и про JavaScript. Вёрстка контента – это специфическая задача, которая полностью раскрывается в отдельном курсе про вёрстку для CMS. А JavaScript и так уже отлично раскрывается в отдельном курсе профессии, поэтому мы просто избавились от дублирования.

• Ушёл и отдельный раздел про доступность. Но не потому что она вдруг стала не важна. Наоборот — мы «встроили» доступность в каждый раздел, теперь это неотъемлемая часть курса.

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

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

А тем временем уже 20 сентября стартует профессия «Фронтенд-разработчик», в которую входит обновлённый курс. Пройдите интенсивное обучение с наставниками на пяти курсах и производственный этап — грейдирование, прокачку скорости и качества работы в «Акселераторе» и оплачиваемую стажировку в «Лиге А.». Чтобы получить скидку 10 000 ₽, напишите нашему телеграм-боту, что вы с Хабра и хотите скидку. Мы расскажем, что делать дальше.