Как прошёл 12 поток курса «JavaScript. Архитектура клиентских приложений»
В Академии закончился очередной поток курса по архитектуре клиентских приложений — на него записались 333 студента, 127 из которых успешно закончили обучение.
На прошлом потоке мы получили много отзывов от студентов, внимательно всё прочитали и сделали курс ещё лучше — обновили программу и исправили мелочи, чтобы сделать обучение ещё удобнее. После изменений оценка курса от студентов выросла до 8.7 из 10. Но мы не останавливаемся, и на 13 потоке будем улучшать курс и дальше. Например, мы уже пересобрали программу, чтобы нагрузка студентов на протяжении курса стала равномернее.
Наставники
Наставники — действующие разработчики, которые помогают студентам учиться. Они проводят ревью кода, помогают в сложных моментах и поддерживают во время защиты проектов.
Выбрать наставника — непростая задача, но оценка показывает, что все наставники — большие мастера, которые не оставят студента в сложной ситуации. На этом потоке студенты оценили наставников в среднем на 9.5 из 10.
Вот список наставников, которых оценили на 10 баллов минимум двое студентов: Руслан Малогулько, Виктор Кан, Екатерина Малецкая, Иван Шалагин, Альбина Токарчук, Сергей Шершнев, Максим Деев, Станислав Посиделов, Александр Пасунько, Артём Мязитов, Сергей Рожков и Даниил Царёв.
Лайвы
На курсе прошло 10 лайвов — это разборы сложных моментов теории и закрепление их на практике в прямом эфире. На лайвах авторы курса общаются со студентами и отвечают на вопросы.
Фрагмент лайва по введению в объектно-ориентированное программирование
Вдобавок к лайвам студенты получили доступ к 20 интерактивным демонстрациям, обширному списку статей и дополнительных материалов, а также могли в любой момент задать авторам вопросы.
Личные проекты
Личный проект — выпускная работа, которая показывает, чему студент успел научиться. На этом потоке было два проекта — «Киноман» и «Большое путешествие». Для каждого проекта подготовлены свёрстанный макет, подробное техническое задание, описано поведение страниц и то, как интерфейс должен вести себя в непонятных ситуациях.
«Большое путешествие». Современный сервис для настоящих путешественников. Сервис помогает детально спланировать маршрут поездки, рассчитать стоимость путешествия и получить информацию о достопримечательностях. Минималистичный интерфейс не даст повода отвлечься и сфокусирует внимание на планировании путешествия.
«Киноман». Сервис для фанатов большого кино. Подробная информация о горячих новинках кино, возможность выбрать и сформировать собственный список фильмов к просмотру, обсуждение кинофильмов и многое другое. «Киноман» — поможет провести время интересно.
Ну кто не хотел сделать свой киношный портал?
В этот раз студенты разделились в выборе личных проектов почти поровну — половина выбрала «Большое путешествие», другая половина — «Киномана». Но выбор никак не влиял на полученные знания и навыки, так как оба проекта включают сложные элементы на JavaScript, которые могут встретиться в реальной работе.
Кто и зачем записывался на курс
Больше 70% студентов курса — работающие специалисты с высшим образованием, которые решили сменить профессию и стать разработчиками. Они прошли тренажёры в HTML Academy, прошли курс «JavaScript. Профессиональная разработка веб-интерфейсов» и сделали следующий шаг, чтобы научиться строить архитектуру клиентских приложений. Ниже — отзывы студентов о курсе.
Хотите разобраться с архитектурой приложений на JavaScript?
Запишитесь на следующий поток.
Отзывы выпускников
Алексей Сергеев Как ни странно это прозвучит, курс одновременно и лёгкий, и сложный. Здесь не понадобится придумывать какие-то сложные алгоритмы. Каждый модуль, каждое задание очень подробно объясняет преподаватель. Главное — это внимательность и терпение. Программа обучения очень грамотно построена по принципу «от простого к сложному» и постепенно формирует представление о том, как устроены современные приложения и подходы к их разработке.
Татьяна Ли Это очень интересный курс. У тебя получается кодить на JS и этот код работает. Магия!
Nikita Shatskiy Первый интенсив, на котором я действительно понял значение слова «интенсив» и ощутил неумолимость приближения дедлайна. Интенсив — суть абстракция, за которой скрывается огромный пласт новых знаний, ежедневная учеба и море практики. Интенсив — это ошибки, это радость от нахождения оптимального решения и отправка задания на проверку в 4 ночи. Первые лекции интенсива коварны — они вводят в заблуждение и успокаивают своей легкостью. Ты быстро справляешься со всеми заданиями, ты уверен в себе, тебе кажется, что ты постиг все тайны JS но… Чувствуешь запах? Это шестая лекция, сынок. Больше ничто в мире не пахнет так. Я люблю запах датабиндинга поутру. Однажды мы выполняли задание по проекту двенадцать часов подряд. И когда всё закончилось, я попытался привести голову в порядок. Там уже ничего не было, даже ни одной жалкой мысли. Но запах! Весь мозг был им пропитан. Это был запах… победы! Самые важные вещи при прохождении курса — это время и способность к самоорганизации. Необходимо быть готовым, что весь привычный досуг отойдет на второй план и уступит место учебе и только учебе. Не стоит терять мораль, если какое-либо задание кажется слишком объёмным и сложным, достаточно подумать над ним чуть больше, и решение придет мгновенно, я гарантирую это. Наставник — ваш лучший друг, и готов всегда прийти на помощь, но перед тем, как писать наставнику, есть смысл задать себе вопрос: «А точно ли я сделал всё, что было в моих силах?». И хотелось бы отметить, что даже если вы работаете на каторге, у вас нет выходных, и вы умудряетесь проваляться неделю с температурой, то пройти интенсив на 100% абсолютно реально. Было бы желание, а оно у тех, кто приходит в HTML Academy, есть.
Дмитрий Безродный Интенсив заставил попотеть не на шутку. Тут тебе и ООП, и паттерны, и датабиндинг, и работа с другими библиотеками, и даже работа с чужим кодом. Тебя просто берут за ручку и проводят, через огонь, воду и медные трубы. После чего, без сомнений, чувствуешь себя профессионалом.
Масштабируемые JavaScript приложения
Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».
Пришло время ответить на данный вопрос. Я немного затянул т.к. хотел рассказать доклад на одноименную тему на Я.Субботнике. Доклад был очень коротким многие важные моменты пришлось выкинуть. Статья — более-менее полная версия.
Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.
Если вы работаете над веб-приложением, то большую часть времени вы тратите на дописывание кода, исправлении ошибок. Только малая часть уходит на дописывания нового функционала. Любое сложное веб-приложение постоянно меняется. Сегодня — 1 строка, завтра — 20, послезавтра — 300.
Давайте посмотрим какой же код есть на сайтах:
Чаще это jQeury, мы навешиваем события, подключаем плагины, выполняем ajax-запросы. Если какой-то плагин удалить, то все сломается. Мы получаем своеобразный клубок кода в который намешаны фреймворки, плагины, наш код. Такой клубок не очень большой (строк 100) и, как правило, создается и поддерживается одним человеком. Большинство сайтов создается 1 раз и не поддерживается вообще, поэтому для них что-то большее может быть вредно и может увеличить себестоимость всего сайта в целом.
Если применить такую архитектуру к GMail, Yandex.Mail, Портал Yahoo!, Twitter, то мы получим огромный клубок кода(10000+ строк), который создает несколько человек. Огромный клубок очень сложно распутать, а запутать ещё сожнее, чтобы ничего не сломать. Веб-приложения постоянно развиваются, поэтому такой клубок приходиться постоянно распутывать и запутывать.
Код сайта не структурирован, а его архитектура имеет сильную связанность. Для веб-приложений такую архитектуру использовать невозможно.
Архитектура
Рассмотрим одну из нескольких архитектур, которая позволяет без проблем создавать масштабируемые приложения. Архитектура взята у N.C. Zakas, она мне очень нравится (будет здорово если вы смотрели его презентацию и вспомните о чем идет речь), в ходе я её немного изменю, а конечный результат вы уведите в примерах.
Фреймворк
В любое приложение, как правило, входит фреймворк. Все клиентские фреймворки будь jQuery, Mootools, YUI, dojo — это всего лишь коробка с инструментами. Инструменты помогают вам забивать гвозди, пилить доски. Какие-то инструменты очень нужны, есть и которые пылятся. Если основных инструментов мало, то подключаются более тяжелые, например, Backbone.js + Underscore.js
В жизни заменить коробку от jQuery на Mootools не составит труда. Подумайте, что вам будет стоить отказ от jQuery или вашей любимой библиотеки сейчас? Чтобы замена была легкой необходимо добавить обертку над функциями библиотек — им может быть Ядро приложения.
Кроме обертки библиотек ядро выполняет и другие функции: оно управляет жизнью частей системы, предоставляет коммуникационный интерфейс, контролирует ошибки всего приложения.
Модули
Приложение состоит из модулей — это независимые части приложения, управляемые Ядром, но не имеющие прямых связей с самим Ядром. Тяжелое JavaScript приложение такое же сложное как и космическая станция. МКС имеет расширяемую архитектуру в ней десятки модулей, каждый выполняет свою собственную роль. Модули станции делали в различных странах, доставляли в различное время и их очень много, но все они работают как единое целое.
Модули веб-приложений состоят из HTML + CSS + JavaScript + Ресурсы
Ресурсы модуля — локализация, дескрипторы и другие приватные данные модуля.
Каждый модуль должен жить отдельно от всего приложения. Задача каждого модуля — выполнять узконаправленную функцию. Модули должны быть обособлены и чем меньше модуль знает о других модулях тем будет проще поддерживать всё приложение. Когда вы создаете новый код и навешиваете зависимости, подумайте о том, что завтра нужно будет выкинуть его.
Для обеспечения слабой связанности и для ограничения свободы модуля его необходимо огородить специальным объектом-медиумом — песочницей. Каждый модуль обязан находиться внутри своей песочницы и общаться только с ней. Это единственный объект о котором знает модуль. Роль песочницы проста. Она выступает в роли охранника — знает что может делать модуль, знает с кем может общаться модуль. Песочница обеспечивает связь модуля с ядром.
Модуль может вызывать свои методы и песочницы, использовать свой HTML элемент. Модуль должен спрашивать разрешения перед выполнением каких-то действий. Модулю запрещено создавать глобалы, использовать нестандартные глобалы, общаться с другими модулями напрямую.
Субмодули
Каждый модуль выступают в роли микроприложения, которое может иметь свои правила, правила не должны противоречить глобальным. Каждый модуль может делегировать свою песочницу своим частям, подключать другие модули (во время сборки проекта).
Ядру не важно как модуль будет управлять своими частями — ему важно, чтобы соблюдались глобальные правила для каждого модуля.
Подчиненность
Для уменьшения числа связей внутри системы нам нужна жесткая подчиненность
— Только библиотека знает о браузере и имеющемся АПИ
— Только ядро знает о библиотеке
— Только песочница знает о ядре
— Каждый модуль знает только о своей песочнице
Ни один из объектов не должен знать о всем приложении.
Наше приложение должно постоянно изменяться. Пользователи хотят новый функцинал — мы его добавляем. Браузеры получают новую фичу — мы её прикручиваем.
Поэтому каждый объект должен изменяться
— Библиотека расширяется за счет плагинов — Браузер получает новый API — добавляем плагин
— Ядро обновляется за счет расширений — Заменили протокол с XML на JSON, поменяли формат отправляемых данных, изменили AJAX транспорт — добавили расширение
— Все приложение расширяется за счет модулей — Пользователи желают новую функцию — мы добавляем какой-либо модуль
Коммуникация
Все знают, что HTML DOM изобилует событиями. События есть везде — есть у элементов, есть в API (XHR, Workers). События в DOM позволяет объектной модели документа бесконечно расширяться и создавать расширяемые приложения. Я считаю, что события — это лучшая база для веб-приложений.
Если вызов метода заменить событием, то модули станут независимыми (будут слабо связаны).
В модуле 1 мы слушаем событие event, модуль 2 вызывает событие event с какими-либо данными и хэндлер события отрисовывает данные в консоль
Да, архитектура сильно меняется, но мы избавляемся от сильной связанности.
Асинхронные функции
События неминуемо влекут за собой асинхронность, думаю все знаю, что HTML DOM изобилует асинхронными методами. XHR, JSONP, отправка данных из фрейма в фрейм, пересылка данные в воркер и обратно. Асинхронное программирование сложнее и его использование не всегда оправдано. Но в нашем случае асинхронные функции могут быть невероятно полезными.
Переделаем наш код с заменой localStorage:
У нас была простая функция получения данных и 10 строк исходного кода. Мы добавили 1 строку и изменили 4 строки. Получили практически 50% изменений (и то я учитывал скобки). Если бы не наши события, то пришлось менять и код, использующий Storage. Используя асинхронный подход в функциях получения и сохранения данных мы избавляем себя от части проблем в будущем.
Как правило, все асинхронные методы связаны с отправкой и получением данных (XHR, Location API, File API), поэтому все функции сохранения и получения данных лучше сделать асинхронными либо подключить события.
Плюсы такой архитектуры
Пример: масштабируемое JavaScript приложение, которое легко поддерживать
Библиотеки и технологии
Структура проекта
Модули
Начнем сперва с модулей. Каждая часть модуля должна подключаться динамически и статически(при сборке в один файл), либо и так и так. Все должно быть максимально прозрачно для разработчика: есть модуль — используем, нет — загружаем и используем.
Пример модуля (модуль DataGenerator)
Согласен, что много мусора в коде. У нас именно такой формат из-за требований к модулю: Ядро авторитарно оно само подключает модули, можуль должен подключаться как статически так и динамически. В JavaScript нет модулей как таковых, поэтому каждый создает свой вид. Есть какие-то «стандартные», но чаще — это велосипед под конкретные задачи.
Пример дескриптора (модуль DataGenerator)
Пример локали (модуль MessageView)
Пример шаблона (модуль MessageView)
Плюсы такого формата
Каждая логическая часть отделена. Мы можем использовать каждую часть неоднократно. Например, дескриптор мы можем использовать для автоматический генерации скелета юнит-тестов.
Нам необходимо загружать и регистрировать модули. Мы должны это уметь делать как при сборке так и динамически. jQuery Deffered нам в этом очень сильно помогут. Т.к процесс загрузки одной части модуля практически ни чем не отличается от другой, а частей у нас много, то нам необходимо выделить фабрику по производству функций загрузки:
ModuleManager
Менеджер модулей просто загружает части модулей и кэширует их. У него есть ряд методов для регистрации модуля без загрузки(статическая сборка).
Я оставил скелет объекта, чтобы много место не занимал. В любом случае ни кто не читает. Полная версия в исходниках.
Шаблонизатор
Будем использовать простой шаблонизатор от John Resig
EventManager
Использование глобального менеджера событий имеет один важный плюс: Мы можем записать лог событий, а потом из лога восстановить ход событий (удобно для отлова багов на стороне пользователя).
Удалил тело функций и JSDoc блоки.
Извне нам нужны только некоторые методы из всех наших модулей ядра. Будем экспортировать только их:
Песочница
Каждый модуль имеет свою собственную песочницу, поэтому мы создадим конструктор Sandbox, порождающий песочницы. Песочница получает в качестве аргумента дескриптор модуля. Все методы песочницы может использовать модуль.
Сборка ядра
Каждая часть ядра должна лежать в отдельном файле и собираться воедино препроцессором, в примере я не использую препроцессор(он сферический в вакууме), поэтому скинул все вместе.
Дескриптор приложения
Приложение тоже имеет дескриптор, который описывает какие модули входят в приложение, где находятся части модулей, определяет текущую локаль, описывает базовую разметку. Дескрипторов может быть несколько под разные сборки.
Приложение: index.js
Как вы поняли из дескриптора приложения, у нас будет 4 модуля. Приложение получилось простейшим без каких-либо взаимодействий с сервером. Код модулей я не прикладываю в статье — он есть в репозитории.
MessageView — отображает сообщение по событию newData
DataGenerator — раз в секунду генерирует событие newData с данными Math.random()
Logger — слушает событие newData и записывает в консоль то, что пришло
Hook — навешивает хук на событие newData. Если в событие приходит строка, то хук прерывает событие. Если приходит число меньше 0.5, то оно умножается на 100.
Сборка
Сборка index.js
Для сборки index.js мы будем использовать сферический в вакууме препроцессор, который имеет функции: require, buildFrom. Функции препроцессора обрамлены в блочные комментарии, поэтому они не мешают работе всего приложения (и подходят как для JavaScript так и для CSS). index.js подается на вход препроцессору, который сканирует файл и собирает проект.
После сборки файл может выглядеть как-то вот так:
C require все понятно, вот с buildFrom немного сложнее. Эта функция использует дескриптор приложения для подключения определенных файлов. В нашем случае я собрал модуль Logger (остальные тоже как-бы подключены). Логика buildFrom может быть немного сложнее она может чистить локализацию (в нашем случае удалит «en»: «He said: » ), выполнять предварительную проверку и тп.
Для среды dev приложение может не собираться — модули динамически загружаются ядром.
Сборка index.css
В примере у нас простая структура модулей: каждый модуль имеет 1 блок, поэтому мы ограничимся тем же сферическим в вакууме сборщиком:
Логика buildFrom в контексте css следующая: он смотрит конфиг приложение на наличие layout и для каждого лейаута, подключает соответствующий блок у нас это b-message-view — все просто. Это предельно упрощенный вариант сборки, который может не подойти для более сложных приложений, но для примера этого достаточно. Например, сборщик БЭМ использует json файл с описанием блоков приложения.
Сборка index.html
На выходе мы получим:
Makefile — Общая сборка
Юнит-тесты
Ещё раз о наболевшем. Многие считают, что тесты нужны только для фреймворков, но ваше приложение тоже фреймворк, только узконаправленный, созданные под конкретную задачу и его используют другие разработчики, работающие с вами.
Используя наш дескриптор приложения и дескриптор модуля, мы можем применять автоматическое создание юнит-тестов. Генератор (он тоже сферический в вакууме) соберет необходимые ресурсы модуля и, используя acl в дескрипторе модуля, создаст скелеты тестов для событий, которые генерирует и слушает модуль. Все остальное ручками.
Как правило, каждое событие имеет свой собственный формат, чтобы упростить задачу тестирования мы создадим семплер событий:
Для тестирование мы будем использовать QUnit. Рассмотрим на примере MessageView. Генератор юнит-теста создает (автоматически) тест из одного модуля MessageView, создает скелеты тестов для проверки интерфейса модуля — те события, которые он слушает и генерирует. Это минимум того, что мы должны проверить.
Код теста: index.js
Из всей этой массы кода разработчик должен дописать всего 5 строк я их отметил » «.
Код теста index.html очевиден — не прикладываю.
Автоматизация тестирования и покрытие кода тестами
Если вы не используете автоматизированное тестирование, то полезность ваших тестов сокращается процентов на 60 (вы не сможете постоянно запускать тесты на всех браузерах, да и это неблагодарная работа). Если вы не проверяете покрытие кода тестами, то польза от таких тестов тоже сокращается (есть шанс пропустить важный момент). Есть несколько фреймворков, которые сильно упрощают эту задачу (это не тема данной статьи, поэтому упомяну вскользь):
— js-test-driver — дружит с QUnit, имеет встроенный модуль покрытия кода.
— TestSwarm (вики) — модуль от Резига и Mozilla Labs
— JSCoverage
Делайте тесты, чтобы они реально работали и выполняли свои задачи. Не делайте тесты «что бы было». Если вы не желаете вводить автоматизицию и покрытие кода, то лучше подумать о необходимости юнит-тестов.
Валидация кода и сборка документации
Тоже не тема данной статьи, но упомянуть стоит. Если вам нужны доки, то по заданным конфигам сборщик проекта может собрать документацию, используя Dox, jsdoc-toolkit и т.п. см. Написание документации
Перед сборкой проекта в тестинг и перед коммитом в репозиторий необходимой проверять код валидатором. Если не проверять код во время прекоммита (проверять перед сборкой или когда вздумается), то может быть слишком поздно — может накопиться большой объем кода, а большой объем кода сложнее исправлять и рано или поздно вы можете забить на валидацию. Для предотвращения ошибок сборки необходимо проверять код (не так строго) после сборки проекта.
Общие моменты
Код приложения из примера
Исходники лежат на GitHub scalable-js-app (полные тексты модулей, комментарии)
Чего нет в приложении: автоматической сборки, автоматической генерации юнит-тестов, всех тестов (кроме MessageView), автоматической сборки документации.
Почитать/Посмотреть
Надеюсь, было интересно. Предложения, пожелания, критика приветствуются! В будущих статьях я хотел бы подробнее описать процесс сборки проекта и автоматизированного тестирования. Если у вас есть вопросы — самое время их задать.
Отзывы о профессиональном онлайн‑курсе
«JavaScript. Архитектура клиентских приложений»
в HTML Academy
Онлайн‑курс «JavaScript. Архитектура клиентских приложений» рассчитан на выпускников курса «JavaScript. Профессиональная разработка веб-интерфейсов» и на практикующих разработчиков, желающих поднять свои навыки. На курсе студенты приобретают навык создания Single Page Application (SPA), JavaScript-приложений с объектно-ориентированной архитектурой (ООП) и JavaScript-приложений по шаблону проектирования Model-View-Presenter (MVP).
Здесь выводятся отзывы реальных студентов об их опыте обучения на курсе «JavaScript. Архитектура клиентских приложений».
средняя оценка курса учениками последнего потока
Без прохождения базового курса по JS, этот курс лучше обойти стороной, чтобы поберечь свои нервы, и вообще не бросить изучение JS))
Также хочу отметить что, даже если у вас есть база по JS, то простой копипаст кода из демо-проекта, без понимания того что происходит, вам не поможет, рано или поздно вы упретесь в то что у вас вообще ничего не будет работать, и придется все равно во всем разбираться, и ваш мозг будет очень этому сопротивлялся))
Курс показал, что лучше идти в потоке, а не откладывать все на потом «ну это мне все понятно»
Очень важно следовать гайдлайну и обращать внимания на детали.
Курс на порядок сложнее, чем JS 1-го уровня, но и настолько же интереснее.
Когда знакомился с личным проектом, то сразу стало понятно, что выполнить его без использования специальных концепций, т.е. той самой архитектуры приложения — невозможно.
На данном курсе архитектура реализуется без использования сторонних фреймворков и библиотек, на чистом JavaScript, применяется объектно-ориентированный подход (ООП), а точнее — паттерн Model-View-Presenter (MVP).
Сторонние библиотеки тоже используются, и значительно больше, чем на прошлом курсе, но не в части архитектуры, а для удобства представления данных.
Слышал много отзывов, что большие приложения в реальной жизни не пишут на чистом JS, везде используют фреймворки, и поэтом курс не имеет практической ценности. Пройдя курс, я могу согласиться только с первой частью, да — фреймворки значительно упрощают разработку и не использовать удобные инструменты в разработке было бы просто странно. Но ценность данного курса состоит в том, что он дает понимание и практический опыт построения архитектуры приложения, т.е. разделению приложения на данные, их представления и логику, и реализацию взаимодействия между этими составляющими. Ведь не надо забывать, что все библиотеки и фреймворки только на первый взгляд работают магически легко и просто, а под капотом много-много-много сложной логики на самом обычном JavaScript.
Лично я курсом остался доволен, получил от него то, что хотел. Но еще раз повторю, тем, кто будет его проходить, что он очень не простой, и поэтому, советую отложить все прочие дела, чтобы с головой погрузиться мир архитектурных абстракций.
Основное что хотелось бы выделить — стараться идти по курсу без отставаний и не накапливать домашние задания. Иначе потом может быть тяжело наверстать такой объём работы сразу. Не расстраиваться и не опускать руки, если что-то непонятно сразу — это нормально и все через это проходят. Повторить материал несколько раз и всё встанет на свои места. Либо спросить совета у наставника. На крайний случай можно обратиться к авторам курса.
Ещё один совет — если долго сидите над одним участком кода и не понимаете почему он не работает, то просто передохните или отложите проект на следующий день и посмотрите на него свежим взглядом. И тогда вы удивитесь как могли не заметить такой очевидной ошибки до этого. Самое главное — поставить себе цель и идти к ней, тогда всё получится.
Перед курсом мне попалась история Алексея Александрова, который прошел этот курс только с третьего раза. Так что шла с ощущением, что будет сложно.
Я совмещала прохождение курса с работой фултайм. Курс отнимал почти всё свободное время, некоторые домашки я делала неделю. К открытию защиты я только приступала к 6й домашке. В какой-то момент захотелось сдаться и не доделывать проект, но тут решающую роль сыграла поддержка наставницы. На первую проверку отправила за 15 минут до закрытия. Защитилась со второй попытки. Так что курс научил меня не только архитектуре клиентских приложений, но и сохранять спокойствие перед надвигающимся дедлайном.
Всё хорошо, главное сохранять настрой и обдумывать материал и изучать глубже
Будет сложно, но потом, когда вы оглянетесь на два месяца назад, вы поймёте, как многому научились за это время, какой огромный объем информации усвоили. Это был очень интересный курс, который заметно подтянул мои навыки и теперь я с полной уверенностью могу говорить, что могу программировать что-то (пусть пока и не сильно сложное) на JavaScript.
Я однозначно рекомендую этот курс, правда, для совсем новичков он не подойдёт, им нужно сначала пройти первый курс по JavaScript.)
Темп курса «JavaScript. Архитектура клиентских приложений» не даст заскучать, самое главное с самого начала стараться выполнять задания в установленный срок, придерживаясь ТЗ. Следуя заветам Линуса Торвальдса, нужно изначально уделить особое внимание структурам данных, дабы не городить сложный «адаптер» при переходе с моков на API. Используя абстракцию, декомпозировать приложение на компоненты, предоставлять в виде публичного интерфейса только необходимые методы классов и инкапсулировать приватные, наследовать от родительского класса основные методы и свойства, соблюдая DRY и при помощи полиморфизма совместно использовать или перегружать поведение методов родительских классов.
Планируйте время на обучение, усердно работайте над проектом, своевременно отдыхайте и по окончании курса у Вас получится SPA с задатками PWA, реализованное по методологии ООП с применением шаблона проектирования MVP.
Я однозначно рекомендую этот курс. Если бы к этому курсу предлагали оценить шкалу сложности, я выбрала 10 из 10. После первого курса JavaScript, обучение на втором курсе напоминало мне мем о том, что в классе мы решаем примеры 2+2, дома 2+2-1, а на контрольной нам дают логарифмы) Александр Сушко и Игорь Антонов — отличные лекторы, присутствовать на лайвах одно удовольствие.
Отдельное спасибо за упорядочивание заданий на Github. Материалы и лекции — школа и домашка, а вот контрольная начинается, когда ты остаёшься один на один со своим проектом. Некоторые задания я кодила по 12 часов, да и что говорить, всё своё время я тратила на курс (читала доп материалы, смотрела видео на youtube и другое). Часто опускались руки, но мне удалось это сделать и я безумно рада такому опыту, никто не говорил, что будет легко. Благодарна лектору, наставнику, ребятам в чате за поддержку, знания и огромный опыт.
Курс очень крутой, первое и самое главное в отличие от других школ вы делайте настоящий проект в котором есть полноценное ДЗ. Кто-то говорит мол одни и те же проекты из потока в поток, но попробуй его сделать и защитить проект. Ну что выдохнем дальше больше дальше react
Курс сложный, но вполне проходимый. Как для меня, человека который программирует впервые, он оказался по зубам. В первую очередь рекомендую разбирать уроки внимательнее и решать задания в точности как делает это автор на лайве, иначе можете запутаться и упустить время, которого очень не хватает.
Главное не бросать проект. Даже если не понимаешь, очень сложно и невозможно и дануегонафиг. Информацию искать где угодно и как угодно. Спрашивать, рассказывать наставнику, как сам понял.
Наверное, самый интересный курс на профессии (я ещё Реакт не пробовал). С первого взгляда, кажется, сложно, но потом начинаешь по-другому смотреть на код. Всё-таки изучение архитектуры для конструирования приложения и понимания его функционирования очень важно. Во всяком случае, этот курс помог мне заполнить множество пробелов в моих знаниях. Грамотная подача информации в лайвах, а также большое количество источников для самостоятельного изучения гарантируют реализацию и защиту собственных проектов. Главное, не копировать бездумно код, а попытаться его понять, и, конечно же, отдыхать.
Благодарю авторов курса, наставников, кураторов и Кекса, конечно же), за полученные знания и положительные эмоции.
P.S. Говорят, курс упростили по сравнению с предыдущими. Хотелось бы мне пройти неупрощенный курс, так сказать, для сравнения.
Замечательный курс! В меру сложный, то есть бросает вызов, но не заставляет опустить руки. Отличный баланс 
Товарищи, когда Саша Сушко говорит, что домашку надо делать в день лайва или около этого, в зависимости от часового пояса, то так и надо делать. Потом этого времени 100% не хватит и будете с кровью из глаз и прочими выделениями получать допуск. Неделя на домашку в этом курсе это обманчиво, может не хватить и получится снежный ком.
Если вы готовы учиться, то HTML Academy вас научат и сделают это максимально профессионально. Больше всего мне нравится на курсах то, что учебный проект хоть и похож на личный, но каждый раз, приступая к работе, ты сталкиваешься с индивидуальными сложностями проекта, которые можно решить, только погрузившись в тему, и перечитав материал, а не просто скопировать с учебного проекта. Знаю, что на многих других платформах обучение в формате «повторяй за мной», но тут происходит действительно много самостоятельной работы. Лучшим комплиментом учебной программе, думаю, являются мои оценки за защиту проектов. Ведь если человек, который до этого никогда в жизни не занимался программированием, защитил уже 2 проекта на 100%, значит, программа действительно даёт знания и помогает развивать профессиональные навыки.
Очень насыщенный курс. Дают много информации за короткий срок. Иду по профессии, еще раз убеждаюсь тому, что сделала правильный выбор в пользу HTML Академии.