Статья написана по мотивам моего выступления на Usetech Mobile Meetup #2. Также по ссылке в видео вы найдёте доклады Анны Жарковой и Павла Кондратьева.

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

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

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

Есть в программировании и свои «боксёрские мешки» — это pet‑проекты. Но в отличие от единоборств, не совсем очевидно, что свой домашний проект и реальный коммерческий — это не одно и то же. В итоге ребята, старательно разрабатывающие очередное приложение для списка дел или просмотра погоды, рискуют заложить фундамент сомнительного качества, выстраивая цитадель своей профессиональной экспертизы.

Если вы начинающий программист и хотите повысить положительный эффект от работы над pet‑проектом, то эта статья для вас. Мы обсудим, как сделать так, чтобы через своё домашнее приложение вы развили навыки, необходимые при работе на коммерческом проекте. В тексте использованы примеры из Android, но основной посыл будет релевантен для всех, кто в качестве pet‑проекта задумал написать клиентское приложение.

Коммерческий опыт vs pet-проект

Для логичности нашего повествования давайте определим, чем pet-проект отличается от коммерческой разработки:

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

• Макеты, дизайн. Внешний вид будущего pet-проекта надежно хранится в чертогах разума разработчика. В отдельных продвинутых случаях начинающие программисты могут использовать готовые макеты из сети или с учебных курсов.

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

И даже если проект небольшой, на дизайнера денег не хватило и «макеты» представляют собой рисунок в блокноте менеджера, это всё‑таки внешний критерий, под который необходимо подводить реализацию в коде, причём порой это сделать очень не просто.

• Сложность кода. Код в pet‑проекте новичка пишется по видео‑урокам и статьям для начинающих. В лучшем случае в проект будут включены варианты продвинутого кода, полученные от лектора на курсах. Кроме того, на pet‑проекте средства и фичи языка программирования, которые можно использовать, ограничены только глубиной знаний и фантазией программиста.
  
  На коммерческом проекте почти всегда существуют договоренности по написанию кода: как именовать переменные, где размещать классы, какие конструкции можно использовать, а какие нельзя. Например, я встречал правило, ограничивающее применение scope‑функции with из Котлина, чтобы повысить читаемость кода.

Также на коммерческих проектах много своих внутренних конструкций, упрощающих работу программиста. Например, на проекте «Альфа‑Мобайл» существует своя библиотека для работы с RecyclerView, поэтому код классов экрана с использованием данного UI‑элемента сильно отличается от того, что можно увидеть в уроках для начинающих.

• Релизный цикл и публикация. Pet‑проекты в большинстве случаев благополучно хранятся в репозиториях без надежды на публикацию в магазинах. Соответственно, нет версионирования приложения и обратной связи от пользователей. Новые версии коммерческих проектов публикуются с определённой периодичностью, которая в зависимости от особенностей проекта может варьироваться, например, каждую неделю, раз в 2 недели или раз в месяц.

• Баги. Автор pet‑проекта сам находит баги и чинит их, к тому же проще найти ошибку в собственном коде. В коммерческом проекте баг может найти тестировщик или пользователь, соответственно, появляются жёсткие горящие сроки на устранение неисправности. А автором бага может быть не только сам программист, но и его «внимательные» коллеги по цеху. Природа бага не всегда очевидна, порой на исправление ошибки может уйти не один день или даже неделя.

• Тесты. Unit‑тесты в pet‑проектах пишут только отчаянные энтузиасты, чья отвага почти граничит с безумием. На коммерческом проекте unit‑тестами может быть покрыта большая кода, могут писаться UI‑тесты. Также, как было отмечено выше, разработчики на реальных проектах часто очень плотно взаимодействуют с тестировщиками.

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

• умение читать и разбираться в чужом коде;

• умение оперативно искать и исправлять баги;

• написание тестов, понимание процесса тестирования;

• навыки общения с коллегами, объяснения им технических нюансов и выяснения потребностей заказчика и пользователя;

• навык командной работы над проектом и общей кодовой базой.

Почему работодателю важны эти навыки? Потому что они позволяют новому сотруднику быстрее адаптироваться на новом месте и начать решать реальные задачи, причём решать их не только быстро, но и качественно.

Выжимаем из pet-проекта максимум

Можем сделать вывод, что для развития указанных навыков необходимо изменить процесс работы над pet-проектом, привести его к виду, идентичному натуральному, т.е. близкому к процессам на коммерческом проекте. Вот что я предлагаю для этого сделать:

• Собрать команду

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

Где можно найти коллег:

— среди студентов курсов из вашей группы;
— на мероприятиях для программистов (митапы, конференции, встречи сообществ);
— в чатах профессиональных сообществ. Например, мобильных разработчиков можно найти в чатах Mobile Broadcast или в сообществе Алексея Гладкова;
— в социальных сетях

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

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

Где искать лида: можно воспользоваться вариантами для поиска из предыдущего пункта. Дополнительно можно поискать вашего будущего лида на специализированных сайтах для менторов, например, на GetMentor.

• Изучить System Design. Когда в рамках менторинга ребята просят подтянуть их по архитектуре, я предлагаю им в режиме собеседования нарисовать архитектуру учебного или pet‑проекта, над которым они сейчас работают. Помимо наглядного изображения архитектуры приложения такое упражнение будет хорошей подготовкой перед архитектурной секцией собеседования в будущем. Начать изучение можно со статей о чистой архитектуре, применительно к Android — гайда по архитектуре от Google, записей открытых собеседований по System Design.

• Изучить исходники библиотек и open source проектов. Чтобы научиться читать чужой код, нужно, как ни странно, читать чужой код. Поскольку под рукой у вас нет кодовой базы существующего проекта, так как вы пишете его с нуля, можно почитать исходники базовых Android‑классов и используемых в проекте библиотек. Также можно изучить проекты с открытым кодом. Например, Android‑приложения Flipper. Можно не ограничиваться самим чтением, но и попробовать переиспользовать кастомные конструкции и архитектуру в своём проекте.
  
  Очевидно, что важен не только сам факт чтения, но и способность программиста понять конструкции, написанные другим человеком. Объять необъятное всегда трудно, говорят, что сознание человека способно удерживать одновременно 7–10 объектов в «оперативной памяти». Поэтому если я читаю код большой библиотеки или модуля с множеством классов, то обычно делаю пометки в блокноте в виде схемы взаимосвязей отдельных элементов. Мне это сильно помогает понять, что хотел сказать автор кода.

• Опубликовать приложение, выстроить релизный цикл. Многие компании в описании вакансий в числе требований указывают опыт публикации приложений. Также наличие опубликованного приложения и достаточного количества скачиваний говорит о том, что у вас есть опыт взаимодействия с пользователями. Если организовать регулярное плановое обновление приложений, у вас будет некоторое понимание, как работает Release Train на реальном проекте.

• Продумать монетизацию. Это может помочь в будущем говорить на одном языке с заказчиком или product owner. Вы будете понимать, как приложения зарабатывают деньги и что для этого нужно сделать. Ну и доходы от pet‑проекта — это не только приятный материальный бонус, но и осязаемое доказательство того, что разработанный вами продукт успешен.

• «Стартап» вместо pet‑project

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

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

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

Также многое зависит от удачи, целеустремлённости, выбора идеи для проекта и т. д. Нужно заметить, что я не основывал стартапы с прибылью и пишу с позиции стороннего наблюдателя, поэтому буду признателен, если при необходимости поправите/дополните меня в комментариях.

Во‑вторых, от многих переменных зависит только успех последних двух пунктов плана: это монетизация и превращение проекта в стартап. Остальные позиции вполне себе выполнимы и достижимы без помощи сверхъестественных сил.

Вместо вывода: не думай про pet project свысока. И кайфуй

«История помнит» немало примеров, когда из pet‑проектов рождались интересные гениальные результаты или когда они вырастали во вполне себе настоящие коммерческие. О таких примерах можно прочитать здесь и здесь. Быть может, и нам всем не стоит лишать свои pet‑проекты возможности превратиться во что‑то чудесное и масштабное, для начала хотя бы в собственном воображении.

И ещё одна мысль напоследок. Говорят, один из ингредиентов счастливой жизни — это удовольствие от процесса. Деньги — хороший стимул. Но в программировании пламя мотивации на таком топливе рискует быстро угаснуть.

Pet‑проект — отличный способ проверить, нравится ли вам программирование настолько, чтобы посвятить ему как минимум несколько лет своей жизни. А быть может, вам больше понравится организовывать процесс работы над проектом, продумывать стратегию развития и вопросы монетизации. Выбор, чем в итоге продолжить заниматься, как всегда, предстоит сделать самостоятельно.