Одна из самых сильных черт Хекслета — проекты. Это специальные задачи, приближенные к реальной жизни, выполняемые вне среды Хекслета на собственном компьютере. В этой статье расскажем, как устроены проекты, сколько времени нужно на их выполнение и почему плохой код не пройдет.
Каждый проект — это законченная программа: например, консольная утилита или полноценный веб-сайт. Проекты хранятся на GitHub в открытом доступе и используются нашими студентами как портфолио для трудоустройства. Проекты принимаются нашими преподавателями, поэтому отличаются высоким качеством кода.
Немного технической информации: всего в каждой профессии до четырех проектов. Каждый проект основан на определенных курсах, но технически приступить к его выполнению можно без их прохождения. Это поможет оценить сложность задачи и начать относиться к курсам серьезнее. Единственное ограничение — проекты можно проходить только строго по порядку.
Курсы не описывают всех задач, с которыми придется столкнуться будущему разработчику. Программисты непрерывно копаются в сети в поисках нужных библиотек и документации по ним. Проекты — формат, который предлагает большое количество самостоятельной работы. Придется много думать, гуглить и попадать в ситуации, из которых, кажется, нет выхода.
Практика на Хекслете позволяет сфокусироваться на задаче и не отвлекаться на организационно-технические детали. Это удобно для новичков, которые завалены большим объемом информации. Но чем дольше человек учится, тем сильнее это мешает. Без самостоятельного и комплексного кодинга невозможно научиться писать полноценные программы. Программирование — это далеко не только набор кода: это еще и взаимодействие с операционной системой, контроль версий, настройка инструментов, тестирование, управление внешними библиотеками и запуск с сопровождением.
Все это невозможно по-настоящему постичь в теории, читая книги или проходя курсы. Здесь нужна реальная практика в реальном окружении. Проекты — именно то место, где придется повозиться с инструментарием и организацией правильного процесса разработки.
Проект «Игры разума» — хороший пример. Для его выполнения придется установить пакеты, зависимости, babel, eslint, makefile, работать с git, создавать правильные имена для коммитов, travis, исполняемых файлов, предварительно публиковать пакеты, писать инструкции, модули, а также выполнять операции импорта и экспорта. Но самое главное — рефакторинг. Все эти моменты являются неотъемлемой частью работы программиста. Понять их можно только на практике.
Для многих студентов становится большим открытием, насколько сложной для их уровня оказывается работа вне практики на Хекслете и как много времени может занять простая установка интерпретатора или компилятора языка. Возникают разные проблемы с Windows, пакетными менеджерами и даже настройкой линтера для редактора.
К этому надо быть готовым. Инфраструктура — неотъемлемая часть разработки. Ее не делает кто-то еще: уметь быстро и эффективно настраивать среду, работать с git и взаимодействовать с операционной системой заниматься ей — прямая обязанность разработчика. Надо быть готовыми заниматься этим всегда, и это поначалу будет сложно, а иногда и очень сложно (а еще долго).
Проекты устроены так: каждый из них разбит на небольшие шаги численностью от трех до 12. Каждый шаг — это законченная часть проекта, она может касаться только настройки или реализации какой-то функции. Важно, что к следующему шагу нельзя перейти, не закончив предыдущий.
С одной стороны, такой подход помогает снизить страх перед большой задачей, начать выполнять которую сложно. С другой — приближает проекты к реальной жизни. В реальном мире проекты, которые делаются по готовому техническому заданию и не меняются в процессе, – фантастика. Так не бывает, если проект живой, а не делается «в стол» (такое бывает, когда он никому не нужен). Настоящие проекты как живые организмы: они постоянно меняются, обрастают новыми требованиями и устаревшим кодом (легаси). Внесение изменений в проект начинает приводить либо к дублированию кода, либо к переписыванию старого, так как он перестает укладываться в текущие требования. Этот процесс называется рефакторингом.
Наличие в проекте нескольких шагов поощряет рефакторинг. Это нормальная ситуация, когда на очередном шаге студент решается переписывать старый код, так как с ним становится неудобно работать. Это не всегда легко принять, но именно такой подход позволяет отличить плохие решения от хороших.
Все проекты проверяет преподаватель. В самом начале проект проверяется автоматически, что не дает гарантии качественного кода. Если говорить о преподавателе, то это человек, который принимает проект и оценивает его качество после завершения всех шагов. Проверка — одна из самых непростых и вместе с тем прокачивающих тем в проектах. Поговорим об этапах проверки преподавателем подробнее:
Процесс проверки выглядит так: