Начинающие разработчики часто усложняют первый pet-проект: выбирают слишком амбициозные или нереалистичные идеи, углубляются в детали или стремятся к идеалу. Это замедляет работу и приводит к разочарованию. Сегодня разберём, как избежать этих ошибок и успешно завершить проект.
Привет! Меня зовут Руслан и я разработчик со стажем.
В начале карьеры разработал много тестовых(pet) проектов как для себя, так и для повышение своей квалификации. Создал более 10 pet проектов и теперь хочу поделиться с вами опытом.
Выбор будущего проекта
Это пожалуй самый главный момент. Поскольку у начинающих разработчиков идеи часто бывают с несуществующими задачами. Это может привести к различным сложностям, как в разработке так и на собеседовании. Например, вас могут спросить касательно бизнес сценария, на которые вам будет сложно ответить.
Чтобы избежать такой ситуации, лучше выбрать актуальный проект, пусть даже с минимальным функционалом. Это не только упростит подготовку, но и покажет, что вы понимаете, как решать конкретные проблемы, а не просто пишете код.
Как выбрать идею для проекта
В качестве первого проекта можно выбрать задачу с готовым ТЗ, чтобы больше сосредоточиться на практике и работать по четкому плану.
Где искать идеи
Готовые ТЗ. На Гитхаб странице Hexlet есть рубрика “тестовые задания”
Open source. Посмотрите проекты на GitHub и Reddit, чтобы вдохновиться.
Важно чтобы выбранная идея проекта была интересной для вас. Это поможет вам лучше погрузиться в суть проекта и сохранит мотивацию для завершение проекта.
Сфокусируйтесь на сути
Перед началом реализации разберитесь в сути проекта и какие задачи он должен решать. Ответьте себе на следующие вопросы:
Какой результат должен получить пользователь?
Какой будет выглядеть интерфейс приложения?
Определите ключевые сценарии(1-2 будет достаточно) работы вашего приложения
Ответив на эти вопросы, вы получите ясное представление о том, что действительно важно для будущих пользователей вашего проекта. Это поможет не тратить время на лишние детали и избежать соблазна добавить ненужные функции. Помните, ваш главный ориентир — пользователь и его задача, а не стремление сделать всё идеально с самого начала.
Не пытайтесь сделать всё идеально
Когда мы выбрали проект, обозначили четко задачи можно начинать. На этом этапе начинающие часто совершают следующие ошибки:
Слишком сложный проект, который требует глубоких знаний и опыта.
Размытые цели – отсутствие четкого понимания, какие задачи должен решать проект и для кого он предназначен.
Стремление к идеалу – попытка сделать всё идеально с первого раза, что замедляет прогресс.
Чтобы избежать этого, необходимо придерживаться предыдущего пункта.
Обрабатывайте ошибки, но без фанатизма
Успешное приложение всегда заботится об обратной связи с пользователем. Во время работы с приложением могут случаться разные ошибки: пользователь может открыть несуществующую страницу, потерять соединение с интернетом или ввести неправильный email.
В таких случаях важно сообщить пользователю, что пошло не так, и как он может это исправить. Например показать ему сообщение о текущей ошибке и что нужно сделать. Это значительно улучшит ситуацию и поможет пользователю продолжить.
Думайте о пользователях
При разработке важно всегда ставить себя на место пользователя. Представьте, как он откроет ваше приложение, с чем он столкнется, какие задачи ему нужно решить. Это поможет вам как разработчику оставаться сфокусированным на главных задачах и не увлекаться лишними подробностями. Почему это так важно?
Когда вы создаете приложение, особенно на начальных этапах разработки, легко забыться и начать углубляться в мелочи, которые не имеют прямого отношения к основной цели.
Возможно, вы захотите сделать интерфейс максимально красивым или добавить функционал, который, с одной стороны, интересен, но с другой — не решает насущную задачу пользователя. В результате это может привести к потере времени и энергии на второстепенные моменты.
Демонстрируем своё мастерство на GitHub
Когда проект готов, его нужно красиво оформить и выложить на GitHub. Это очень важно. Так вы не просто покажете свои навыки, но и сделаете первый шаг к созданию своего профессионального портфолио. Если всё сделано правильно, ваш репозиторий произведёт хорошее впечатление на будущих работодателей.
Добавьте файл README.md, где укажите:
Название проекта и его цель.
Технологии, которые вы использовали.
Инструкции по установке и запуску.
Примеры работы приложения.
Это поможет другим быстро понять ваш проект и покажет ваш профессионализм.
Итого
Первый тестовый проект — это про опыт, а не про совершенство. Начните с главного. Работайте итерациями. И помните: главное — закончить проект, а не застрять на мелочах.
Полезные ссылки:
Комментарии (6)
voidinvader
17.01.2025 05:33Человеку, которому будут полезны и новы приведённые советы, в принципе рановато садиться за пет-проект.
Лично я все свои пет-проекты начинал делать по причине того, что столкнулся с энной проблемой, и не нашёл ни одной готовой реализации для её решения. Это к тому, что если идею для пет-проекта приходится выдумывать или где-то находить - пет-проект почти наверняка получится бесполезным всем, потому что он бесполезен в первую очередь для своего создателя.
Emelian
17.01.2025 05:33Создал более 10 pet проектов и теперь хочу поделиться с вами опытом.
Но, почему-то, не пет-проектами.
Выбор будущего проекта
Вообще-то, я бы начал статью не так. Мол, ребята, мы живем сейчас в «благословенном» капитализме. Чтобы выжить, нужно продать себя подороже. Фирмы берут на работу только готовых специалистов, с опытом работы. Но где его взять «наивному чукотскому юноше»? Выход один – пет-проект.
Раньше, в ВУЗах, были дипломные проекты, которые готовились на преддипломной практике, обычно в последнем семестре учебы. Например, я проходил преддипломную практику в «Керосинке», т.е., Институте «Нефти и газа» АН СССР (от мехмата МГУ). Там я писал дипломный проект по оптимальному извлечении нефти из безнапорных скважин. После защиты диплома, мне предложили поступить в аспирантуру Академии Наук. Но, пришлось отказаться, потому, что это был уже 1990-й год, когда «золотые годы» «Пересройки» (которые длились всего пару месяцев) подходили к концу. Уехал домой, где меня охотно взяли в крутую научно-производственную фирму.
К сожалению, сейчас другие времена (и нравы!), поэтому нужна другая стратегия. К своему пет-проекту надо готовиться со школы. Хорошо, когда рядом есть наставник, который подскажет по какому пути пойти, какой технологии себя посвятить. Иначе, надо плотно работать с техническим Интернетом, чтобы определить современные тенденции и закономерности развития.
Конечно, нужно учитывать собственные интересы. Если ориентироваться на Россию (что очень рекомендую), то здесь в ближайшие годы принципиально важными будут – военная наука, ИИ, оборона и безопасность. Как на инфраструктурном уровне, так и цифровом. Если много и долго учиться нет особого желания, то можно пойти на контрактную службу.
Ваш пет-проект должен понравиться потенциальному работодателю, поэтому нужно хорошо изучить его интересы и сферу деятельности. И развиваться самому в этом направлении.
Однако, звезд с неба хватать не обязательно. Очень хорошее направление, на мой взгляд, это «модульное программирование». При этом, сами модули можно брать из готовых проектов на Гитхабе и адаптировать их в своей проект. Для примера можете посмотреть мою статью «Модульное программирование в C++. Статические и динамические плагины» ( https://habr.com/ru/articles/566864/ ). Не обязательно использовать именно эту концепцию (MDI интерфейс с плагинами). Например, для проекта «МедиаТекст» (не опубликован, но скриншот – http://scholium.webservis.ru/Pics/MediaText.png ) использовался SDI интерфейс с внешними модулями. Один из них реализует просмотр видео и медиа-контента, другой эмулирует примитивный файловый менеджер, третий – пользовательскую панель управления, а четвертый стандартный редактор текста «RichEdit». Большая часть кода для этих модулей найдена на Гитхабе и CodeProject. Собрал всё вместе, получился индивидуальный проект.
Можно делать и более оригинальную сборку модулей, например, перегрузку видов в главном окне приложения. Таковым для меня является пет-проект «Новая компьютерная программа для запоминания иностранных слов и фраз» ( https://habr.com/ru/articles/848836/ ). Из внешних модулей там работа со звуком и графикой плюс механизм переключения видов и движок базы данных SQLite. Из своего – идея работы с интерактивным звуком и иностранными фразами (например, при реализации собственного режима «Видео»). А также, идея разработки обучающих уроков на базе озвученных текстов в оригинальных видео (а процессе разработки).
Чем хорош последний пет-проект, так это тем, что, при создании обучающего курса (на базе существующих материалов Ютуба) можно будет рассмотреть вопрос о донатах. И заодно самому выучить иностранный язык.
Здесь уместно вставить любимую фразу американцев: «Хочешь разбогатеть – думай!»
weirded
Где-то полтора года назад решил сделать самопальный примитивный умный дом. Это, наверное как todo-листы у людей, которые дорвались до mqtt. Плюс захотелось немного поделать что-то отличное от работы, без микросервисов и прочего, а реально компактный монолит (расписание, приём топиков из mqtt с блокировками расписания, сбор данных из внешнего мира, API + экспорт метрик + веб-интерфейс - всё в одном процессе, просто в разных asyncio.Task), пусть и на питоне. Сейчас что-то распухло до 50мб потребление памяти, но было бы время, мне кажется получилось бы до 25 ужаться. Где-то с 0.0.4 версии ушёл в хардкод и пока его не причешу, не заребейзю всё по человечески - не буду публиковать. Беда в том, что с этого момента прошло полгода, а фич я в свой проект добавил эгегей. Да и он особо никому не нужен, лол.
JBFW
К слову, монолит там неудобен и как раз поэтому: "пока не доведу до ума..." )
Лучше 100500 "микросервисов", каждый из которых решает 1 задачу, но именно так как нужно.
Иначе придется писать альтернативу тому же HomeAss, как минимум не хуже.
voidinvader
Ого, да это же я!
weirded
Мне удобно, проблемы будут если надо будет масштабироваться. А мне не надо, производительности хватает со стократным запасом. Это же умный дом, он в одном домохозяйстве крутится, у него полтора пользователя, которые предпочитают его вообще не трогать, пока работает. А учитывая то, что масштабирование/резервирование не требуется, можно извлекать выгоду из того, что состояние системы не распределено, персистентность не требуется, следовательно его можно тупо держать в памяти одного процесса и прекрасно обходиться без системы очередей (если не считать таким mqtt-брокер) и баз данных.
Единственная моя проблема (что нужно довести до ума) в том, что я не знаю как правильно организовать сборку проекта с фронтендом, который хочу распространять целиком через pypi (чтобы pip install, конфиг поправил, системд юнит включил и работает). Бандлить в питоний пакет собранный JS стрёмно, а как без сборки вебпаком использовать сторонние библиотеки (я использую jsonrpc, хотя мог бы болт забить и на это) - не знаю. Может надо дистрибьюцию на докер-образ переводить, но это кажется совсем уж шизой, ради 40 строк на JS и 600 на питоне (где 200 - тесты).
Не понимаю как из выбора монолитной архитектуры следует требование писать home assistant или лучше, к слову.