Главная | Все статьи | Код

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

Время чтения статьи ~9 минут 200
Анатомия проектов Хекслета главное изображение

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

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

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

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

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

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

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

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

Окружение

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

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

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

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

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

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

Рефакторинг

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

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

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

Наставник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

Аватар пользователя Kirill Mokevnin
Kirill Mokevnin 29 апреля 2022
200
Похожие статьи
Рекомендуемые программы
профессия
Осваивайте разработку веб-страниц, оживляйте дизайн макетов, публикуйте сайты и приложения. Отслеживайте ошибки в интерфейсе и устраняйте их
10 месяцев
с нуля
Старт 5 декабря
профессия
Обучитесь разработке бэкенда сайтов и веб-приложений — серверной части, которая отвечает за логику и базы данных
10 месяцев
с нуля
Старт 5 декабря
профессия
Выполняйте ручное тестирование веб-приложений, находите ошибки в продукте. Узнайте все о тест-дизайне.
4 месяца
с нуля
Старт 5 декабря
профессия
Научитесь разработке веб-приложений, сайтов и программного обеспечения на языке Java, программируйте и используйте структуры данных
10 месяцев
с нуля
Старт 5 декабря
профессия
новый
Собирайте, анализируйте и интерпретируйте данные, улучшайте бизнес-процессы и продукт компании. Обучитесь работе с библиотеками Python
9 месяцев
с нуля
Старт 5 декабря
профессия
Занимайтесь созданием сайтов, веб-приложений, сервисов и их интеграцией с внутренними бизнес-системами на бекенд-языке PHP
10 месяцев
с нуля
Старт 5 декабря
профессия
Создание веб-приложений со скоростью света
5 месяцев
c опытом
Старт 5 декабря
профессия
Обучитесь разработке визуальной части сайта — фронтенда, а также реализации серверной — бэкенда. Освойте HTML, CSS, JavaScript
16 месяцев
с нуля
Старт 5 декабря
профессия
Разработка бэкенд-компонентов для веб-приложений
10 месяцев
с нуля
Старт 5 декабря
профессия
новый
Организовывайте процесс автоматизации тестирования на проекте, обучитесь языку программирования JavaScript, начните управлять процессом тестирования
8 месяцев
c опытом
Старт 5 декабря