Анатомия проектов Хекслета
2026-02-26 20:16 Diff
https://ru.hexlet.io/blog/posts/anatomiya-proektov-heksleta

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

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

Немного технической информации: всего в каждой профессии до четырех проектов. Каждый проект основан на определенных курсах, но технически приступить к его выполнению можно без их прохождения. Это поможет оценить сложность задачи и начать относиться к курсам серьезнее. Единственное ограничение — проекты можно проходить только строго по порядку.

Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика

Содержание

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

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

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

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

Окружение

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

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

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

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

Читайте также:

Как сохранять фокус на протяжении всего обучения: советы от Хекслета

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

Рефакторинг

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

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

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

Наставник

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

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

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

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

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

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

Другая причина связана с тем, какие замечания и в каком количестве дает наставник во время проверки. Любой проект делится на уровни: например, на втором проекте это настройка -> тесты -> общая логика -> логика вывода. Логика такая: если на базовых уровнях есть проблемы, переходить к следующим нет смысла.

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

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

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

Когда я только брался за проект, думал: «Легко, я такие задачки на CodeBasics решал». За два дня запилил весь проект по сути. Потом мне написал наставник, я сначала не понял претензий — все же работает. Исправил один раз, другой, и тут то до меня стало доходить, почему мне это было действительно нужно.

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

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

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

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

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

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

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

Выводы

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

Никогда не останавливайтесь:

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