Все статьи | Обучение

Анатомия проектов Хекслета

Анатомия проектов Хекслета главное изображение

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

Немного технической информации: всего в каждой профессии до 4 проектов. Каждый проект базируется на определённых курсах сайта. Технически проект можно начать и без их выполнения. Это позволяет оценить сложность задачи и начать относиться к курсам серьезнее. Выполнение конкретного проекта может занимать месяц и более, мы не ограничиваем сроки (пока). Единственное ограничение – проекты можно проходить только строго по порядку (дальше объясню, почему так).

Почему проекты так важны?

Самостоятельность

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

Однако это не значит, что студент остаётся с проектом один на один. В процессе прохождения можно задавать вопросы на сайте и общаться по проекту в канале #hexlet-projects нашего слака

Окружение

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

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

Проект «Игры разума» научил меня очень многому. Установка пакетов, установка зависимостей, babel, eslint, makefile, работа с git, именования коммитов, travis, исполняемые файлы, предварительная публикация пакетов, написание инструкций, модули, импорт, экспорт. И перечислять ещё можно долго. Но самое главное — рефакторинг. Все эти моменты являются неотъемлемой частью работы разработчика, которым особо никто и не учит, пока не выйдешь на работу. Olga Ioffe

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

К этому надо быть готовым. Инфраструктура – неотъемлемая часть разработки. Ее не делает кто-то ещё, это прямая обязанность разработчика — уметь быстро и эффективно настраивать среду, работать с git и взаимодействовать с операционной системой. Надо быть готовыми заниматься этим всегда, и это поначалу будет сложно, а иногда и очень сложно (а еще долго).

Рефакторинг

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

С одной стороны, такой подход помогает снизить страх перед большой задачей, за которую непонятно, с какой стороны взяться. С другой, он приближает проекты к реальной жизни. В реальном мире проекты, которые делаются по готовому техническому заданию и не меняются в процессе – фантастика. Так не бывает, если проект живой, а не делается «в стол» (такое бывает, когда он никому не нужен). Настоящие проекты — как живые организмы. Они постоянно меняются, обрастают новыми требованиями и устаревшим (легаси) кодом. Внесение изменений в проект начинает приводить либо к дублированию кода, либо к переписыванию старого, так как он перестает укладываться в текущие требования. Этот процесс называется рефакторингом.

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

Наставник

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

Сам процесс выглядит так:

  1. Наставник изучает настройку проекта и код.
  2. Оставляет замечания на сайте.
  3. Студент получает уведомление и исправляет замечания.
  4. Если ему что-то непонятно, то он связывается с наставником в слаке и задает уточняющие вопросы.
  5. Студент отправляет проект на проверку, и мы возвращаемся к шагу 1.

Сколько раз может продолжаться этот процесс? В среднем 6 раз. В редких случаях 2-3 раза (часто такое бывает из-за списываний), и иногда 10 и более раз. По времени это может растянуться на достаточно долгий срок. Как правило, исправлять проект дольше, чем его писать. При этом свой код студентам кажется идеальным, и они расстраиваются, когда получают замечания по нему. К этому надо быть готовым. Идеальный код никто не пишет :-)

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

Почему проверок так много? Задача наставника на Хекслете — не просто указать на недочёты, а довести решение до приемлемого уровня. У каждого он немного свой, и все проекты получаются чуть-чуть разными, это нормально, в программировании есть множество способов решать одну и ту же задачу. Кроме того, указать на недочеты недостаточно, между «прочитал и понял» и «смог реализовать» – пропасть.

Другая причина связана с тем, сколько и какие замечания дает наставник во время проверки. Любой проект с нашей внутренней точки зрения делится на уровни, которые зависят друг от друга. Во втором проекте это: настройка -> тесты -> общая логика -> логика вывода. Как правило, если на базовых уровнях есть проблемы, то не имеет смысла копать в следующие уровни. Например, если не настроен линтер, то с большой вероятностью придется править почти весь код. Если нет тестов или они написаны неверно, то значит разработка велась не через тесты, и дальнейшие исправления будут вестись так же без ориентации на тесты. То же самое касается архитектуры проекта (в каждом проекте она своя). Если архитектура построена совсем неверно, то не имеет смысла разбирать ее по деталям, почти наверняка большая часть кода будет переписана после изменения архитектуры. Именно поэтому наставники никогда не выдают полный список замечаний. Это просто бесполезно и позволяет студенту расслабиться и переложить всю ответственность за результат на проверяющего.

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

Переписать проект 3-4 раза в процессе работы с наставником совершенно нормально. Именно здесь происходит основной рост и в этом заключается скрытая мощь проекта, который заставляет расти над собой. Это больно, но без боли нет прогресса.

Когда я только только брался за него, я думал "Пфффф, легкотня, я такие задачки в CodeBasics ещё решал". За два дня запилил весь проект по сути. Потом мне отписался Станислав, я сначала не понял претензий — всё же работает... Исправил 1 раз, другой, и тут то до меня стало доходить, почему мне это было действительно нужно.

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

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

Как оцениваются проекты?

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

Один из ключевых критериев — это простота и понятность. Сюда входит масса всего:

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

Несмотря на сложность проектов, с точки зрения настоящих приложений они достаточно маленькие. Реальный код измеряется десятками и сотнями тысяч строк. В такой ситуации невероятно важно правильно строить абстракции и хорошо именовать (переменные/классы/функции/…). Мы значительно чаще читаем чужой код, чем пишем свой. Именно поэтому в проектах Хекслета делается такой большой акцент на вещи, не имеющие прямого отношения к работоспособности кода.

Выводы

  • Проекты — это не проходная история. Будьте готовы погрузиться и поработать. По-быстрому не получится.
  • Никто не пишет идеальный код. Даже для написания хорошего кода нужны годы опыта.
  • Код должен не только работать, но и быть понятным и удобным в сопровождении.
Аватар пользователя Kirill Mokevnin
Kirill Mokevnin 28 января 2020
Рекомендуемые программы

С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.

Иконка программы Фронтенд-разработчик
Профессия
Разработка фронтенд-компонентов веб-приложений
29 сентября 8 месяцев
Иконка программы Python-разработчик
Профессия
Разработка веб-приложений на Django
29 сентября 8 месяцев
Иконка программы PHP-разработчик
Профессия
Разработка веб-приложений на Laravel
29 сентября 8 месяцев
Иконка программы Node.js-разработчик
Профессия
Разработка бэкенд-компонентов веб-приложений
29 сентября 8 месяцев
Иконка программы Верстальщик
Профессия
Вёрстка с использованием последних стандартов CSS
в любое время 5 месяцев
Иконка программы Java-разработчик
Профессия
Разработка приложений на языке Java
29 сентября 10 месяцев
Иконка программы Разработчик на Ruby on Rails
Профессия
Новый
Создает веб-приложения со скоростью света
29 сентября 5 месяцев