Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.
Доклад был рассказан на конференции для мобильных разработчиков, поэтому истории и примеры Егор приводит тоже для них. В процессе доклада я насчитал шесть трендов, а не пять, но названия статьи менять не буду.
Доклад Егор начинает с примера из жизни. Он хотел создать демо-приложение для iOs, но у него не получалось. Все туториалы, говорит он, приводят примеры написания кода. Егор же интересовался сборкой проекта и его публикацией хоть где-нибудь. Код - это наименьшая часть проекта, считает Егор, а вот сборку проекта, юниттесты, настройку CI/CD и публикацию приложения он считает самой главной его частью. И Егор удивлен, что остальные разработчики не уделяют достаточно внимания этим процессам и их автоматизации.
Чаще всего разработчик при входе в новый проект не сталкивается с проблемами настройки окружения, деплойментом, CI/CD - все уже настроено до него или за него другими людьми. Отсюда и складывается тенденция, что разработчики совершенно не умеют заниматься этим. А ведь эти процессы и механизмы и делают продукт из набора классов и файлов, которые пишет программист. Программисты не видят полный цикл сборки проекта, они не знают, как написанный ими код попадает на продакшн-сервер.
Егор приводит еще один пример, почему деплой проекта важнее настроить в первую очередь, прежде чем что-либо кодировать. Он рассказал историю создания приложения на Flutter. Парень предложил помощь с этим фреймворком и разработать демо-приложение. Спустя некоторое время этот разработчик возвращается с репозиторием и говорит: “сделал, проверьте”. А как получить этот набор файлов на смартфон? Егор попросил упростить процесс проверки прилоежния до максимального. Разработчик подготовил TestFlight и объяснил что нужно сделать, чтобы установить себе тестовое приложение. Егор увидел, что есть пара ошибок в приложении и хотел закоммитить правки и отправить pull-request, однако чтобы убедиться, что его код не ломает приложение, он хотел как минимум собрать приложение с измененным кодом. Сделать этого не получилось “из коробки”. Егор попросил написать разработчика инструкцию и положить ее в репозиторий, но эта просьба осталась без ответа.
Егор рассказал эту историю, чтобы показать, почему сборка важнее кода. Не настроив сборку и деплоймент до буквально нажатия одной кнопки или запуска одной команды скрипта, вы не сможете привлечь новых контрибьютеров в свой проект. Вы как мейнтейнер своего проекта, который хочет расширить сферу своего влияния и упростить порог вхождения новых людей в проект, должны упрощать сборку и другие процессы. Иначе люди с разным уровнем компетенции просто не смогут вам помочь в развитии вашего продукта.
Разработчик из истории поступил как “одиночка”, который сам знает что делать и как делать. Его опыт можно экстраполировать на так называемую “продуктовую команду” - команду людей, которые работают вместе довольно давно над одним продуктом, и знания и компетенции содержатся в их головах. Такой подход Егор считает неверным, так как тендеция идет к тому, что в проекты все чаще заходят люди с аутсорса и фрилансеры со всего мира. Чем выше текучка, тем лучше, ведь новые люди - это новые компетенции и более новые практики. Новички, приходя в ваш проект, должны попадать в дружественное к себе окружение и должны видеть весь скоуп проекта без необходимости “пообщаться” с кем-то из старожил проекта. Причем запуск билда и деплой не должен зависеть от IDE автора проекта, ведь эту IDE еще нужно настраивать в течение длительного времени. Весь этот процесс, считает Егор, должен запускаться из командной консоли одной командой.
Большинство разработчиков работают в команде, и даже если они вдохновятся идеями Егора, то они не смогут одномоментно привнести описываемые им практики в рабочие проекты - будут трудности и сопротивление остальных участников команды. Поэтому один из немногих выходов из этой ситуации - наличие собственных pet-проектов.
Если вы считаете себя хорошим разработчиком мобильных приложений, у вас должен быть как минимум один опубликованный pet-проект в App Store или Google Play Market. Действительно специалист мобильной разработки должен уметь пройти весь цикл приложения от А до Я, в том числе и публикация в официальном магазине приложений. И пусть там будет около нуля загрузок - это не важно. Важно умение сделать из проекта продукт. Егор также считает, что все pet-проекты должны быть opensource, чтобы к нему могли присоединиться и другие контрибьютеры при желании. И чтобы эти контрибьютеры показали, как у них “не получается” задеплоить ваше приложение.
Если у мобильного разработчика нет опубликованных pet-проектов, то этот разработчик, по мнению Егора, не сильно заботится о своей карьере, либо он просто боится пройти весь цикл жизни приложения самостоятельно. И в том, и в другмо случае говорить о высоком профессионализме такого разработчика не приходится.
Многие разработчики не умеют работать с деньгами: они привыкли получать оплату в конце месяца и не умеют оценивать свою работу в меньших масштабах. Многих вводит в ступор вопрос “сколько кода ты напишешь за 100$”. Сколько они хотят получать за месяц знают почти все, а вот в обратную сторону и за меньшие порции денег - почти никто.
Егор считает, что наиболее успешные проекты будут строиться группой разработчиков-фрилансеров, которые собираются временно, пилят проект и разбегаются. Люди приходят, когда проекту нужны их компетенции, и уходят, когда эти компетенции становятся не нужны. Эра, когда группа разработчиков “сидят” в компании и вынуждены периодически переучиваться на новые технологии и языки, проходит. Компании, если она хочет создать новый проект с новым стеком технологий, станет невыгодно мпереучивать своих штатных разработчиков, ей будет легче найти фрилансеров со знаниями и быстро запилить проект.
Чтобы разработчикам можно было жить в таком мире, разработчики должны уметь посчитать свою стоимость и знать, сколько стоит их час работы. Также необходимо каждому разработчику научиться продавать свои компетенции и научиться жить в условиях, когда нужно быстро интегрироваться в новый проект, понять его скоуп, понять свою задачу, затем ее быстро сделать и так же легко уйти.
Егор считает, что резюме разработчика должно состоять из списка pet-проектов, а не компаний, где разработчик отработал N лет своей жизни. Законченный pet-проект - это умение довести проект до состояния продукта, а работа в компании в течение N лет - это чаще всего лишь допиливание существующего продукта, где врядли человек занимается чем-то большим. Что умеет разработчик из компании, какие у него компетенции и навыки - остается неизвестным, пока этот разработчик, собственно, не начнет проявлять себя в проекте.
Такой разработчик хочет, чтобы я взял его на месяц, дружил с ним целый месяц, и неважно, какой от него будет результат.