Корпоративный курс HexSchool по Node.js
Несколько разрозненных мыслей и размышлений после завершения корпоративного курса HexSchool по Node.js.
Зачем я пошёл на этот курс? Какую проблему хотел решить?
Это дорогой курс. Учитывая специфику HexSchool (по коммерческим причинам они не могут отказать платящим студентам), содержание курса неизбежно строится на более простом уровне.
При таких условиях регистрация может показаться невыгодной. Но на практике есть несколько аспектов, которые стоит рассмотреть:
Командная работа
Курс с самого начала предполагает групповое сотрудничество. Поскольку большинство участников приходят с фронтенд-бэкграундом и практически не имеют опыта в бэкенде, это возможность попрактиковаться в коммуникации и координации при разработке серверной части.
С другой стороны, люди, с которыми вы сотрудничаете, могут стать вашими будущими контактами и помогать друг другу в дальнейшем — это способ расширить свою профессиональную сеть.
Невозвратные затраты
Как я уже упоминал, это недешёвый курс. Даже если вы ленивы, как я, но не хотите, чтобы деньги пропали зря, вам придётся после работы прикладывать усилия, чтобы не отставать от проекта и уложиться в дедлайн. В каком-то смысле это заставляет быть дисциплинированным.
Новые перспективы
Весь проект проходит от идеи дизайна до разработки, от начала до конца. Объективно содержание довольно поверхностное, но каждый участник всё равно проходит рабочий процесс PM, UI/UX, фронтенда и бэкенда хотя бы один раз. Это даёт новые перспективы для будущей работы.
Содержание курса
Помимо основ команд MongoDB и реализации API на Node.js, самая ценная часть, на мой взгляд, — это интеграция со сторонними сер висами: например, авторизация через сторонние сервисы и обработка платежей. Это по своей природе рутинная работа, требующая времени на изучение документации провайдера, поэтому структурированное обучение экономит эти усилия.
Кроме того, в некоторых частях курса по-прежнему используется MVC в качестве примера архитектуры, поэтому команде пришлось самостоятельно разбираться с разделением фронтенда и бэкенда во время проекта. Это ещё одна область, требующая времени и размышлений.
Некоторые занятия фактически были переданы приглашённым преподавателям для проведения в формате живых лекций, что может создавать пробелы. Например, на занятии по модульному тестированию примеры были только для фронтенда, и если вы хотели попрактиковаться в тестировании бэкенда, приходилось разбираться самостоятельно.
Проектная работа (очень субъективный взгляд)
Проектная работа — это то, что я считаю самой ценной частью курса, и ключ к ней — внутренняя координация и планирование команды.
Будьте честны перед формированием команд
Перед формированием команд проводится самооценка ваших навыков. Если вы не знакомы с какой-то областью, будьте честны. Если разрыв в навыках внутри команды слишком велик, это легко приводит к серьёзным разногласиям, и проект разваливается.
Закладывайте запас времени на разработку
Поскольку большинство людей — это фронтенд-разработчики, впервые сто лкнувшиеся с бэкендом, есть множество подводных камней, которые замедляют работу — вещи, о которых фронтенд-разработчикам раньше не приходилось беспокоиться. Например, после интеграции обработки платежей неизбежно приходится работать с заказами, а заказы предполагают временные метки транзакций и другие сложности.
Для фронтенд-разработчиков эти вопросы раньше были вне поля зрения. Всё сводилось к вызову API и рендерингу списков. Но на стороне бэкенда это то, о чём обязательно нужно думать.
Нацеливайтесь на запущенный проект
Пожалуйста, серьёзно рассмотрите эти пункты:
- У всех членов команды есть основная работа, и они могут вкладывать только ограниченное количество времени (невозможно предсказать, будет ли у кого-то срочная работа или переработка)
- Дедлайн очень жёсткий, реальное время на разработку ограничено
- У боль шинства участников не будет бэкенд-опыта, поэтому неизбежно придётся тратить время на решение проблем
Поэтому цель первой фазы должна быть — сделать то, что работает, а не идеальный продукт. Не стоит на этом этапе увлекаться архитектурой, оптимизацией или тестированием — всё это придёт позже.
Если вы гонитесь за совершенством, вы не только застрянете на времени разработки, но, что ещё хуже, можете привести команду к расколу (скрытые конфликты повсюду, особенно когда вы не можете понять, испытывают ли коллеги рабочее давление в течение дня). Когда команда раскалывается, проект на 94,87% мёртв. Запуск некрасивой, но работающей функции очень помогает повысить уверенность каждого.
В частности, избегайте бесконечного расширения технологического стека команды. На фронтенд-стороне у вас никогда не должно быть одновременно React и Vue. Даже если кто-то в команде отлично владеет одним фреймворком, это не значит, что другие смогут его освоить достаточно быстро, чтобы вносить вклад.
Расширение и оптимизация
После того как проект завершит свою первую ролевую функцию, можно считать первую фазу законченной. Помимо передышки, можно начать думать о дополнительных функциях, включая то, что вы хотите попробовать технически, или улучшения UX.
В нашем проекте мы постепенно добавили обмен сообщениями через websocket, поддержку PWA, анимации, систему отметок посещений и другое, обогащая общий сайт.
Заключительные слова
Вот развёрнутые URL и репозитории нашего проекта. Можете ознакомиться.
Client
Admin
<!-- тестовый аккаунт и пароль -->
account : admin
password : 12345678