Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.

Доклад был рассказан на конференции для мобильных разработчиков, поэтому истории и примеры Егор приводит тоже для них. В процессе доклада я насчитал шесть трендов, а не пять, но названия статьи менять не буду.


Доклад

Доклад Егор начинает с примера из жизни. Он хотел создать демо-приложение для iOs, но у него не получалось. Все туториалы, говорит он, приводят примеры написания кода. Егор же интересовался сборкой проекта и его публикацией хоть где-нибудь. Код - это наименьшая часть проекта, считает Егор, а вот сборку проекта, юниттесты, настройку CI/CD и публикацию приложения он считает самой главной его частью. И Егор удивлен, что остальные разработчики не уделяют достаточно внимания этим процессам и их автоматизации.

1. Deploy First, code next

Чаще всего разработчик при входе в новый проект не сталкивается с проблемами настройки окружения, деплойментом, CI/CD - все уже настроено до него или за него другими людьми. Отсюда и складывается тенденция, что разработчики совершенно не умеют заниматься этим. А ведь эти процессы и механизмы и делают продукт из набора классов и файлов, которые пишет программист. Программисты не видят полный цикл сборки проекта, они не знают, как написанный ими код попадает на продакшн-сервер.

Егор приводит еще один пример, почему деплой проекта важнее настроить в первую очередь, прежде чем что-либо кодировать. Он рассказал историю создания приложения на Flutter. Парень предложил помощь с этим фреймворком и разработать демо-приложение. Спустя некоторое время этот разработчик возвращается с репозиторием и говорит: “сделал, проверьте”. А как получить этот набор файлов на смартфон? Егор попросил упростить процесс проверки прилоежния до максимального. Разработчик подготовил TestFlight и объяснил что нужно сделать, чтобы установить себе тестовое приложение. Егор увидел, что есть пара ошибок в приложении и хотел закоммитить правки и отправить pull-request, однако чтобы убедиться, что его код не ломает приложение, он хотел как минимум собрать приложение с измененным кодом. Сделать этого не получилось “из коробки”. Егор попросил написать разработчика инструкцию и положить ее в репозиторий, но эта просьба осталась без ответа.

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

Разработчик из истории поступил как “одиночка”, который сам знает что делать и как делать. Его опыт можно экстраполировать на так называемую “продуктовую команду” - команду людей, которые работают вместе довольно давно над одним продуктом, и знания и компетенции содержатся в их головах. Такой подход Егор считает неверным, так как тендеция идет к тому, что в проекты все чаще заходят люди с аутсорса и фрилансеры со всего мира. Чем выше текучка, тем лучше, ведь новые люди - это новые компетенции и более новые практики. Новички, приходя в ваш проект, должны попадать в дружественное к себе окружение и должны видеть весь скоуп проекта без необходимости “пообщаться” с кем-то из старожил проекта. Причем запуск билда и деплой не должен зависеть от IDE автора проекта, ведь эту IDE еще нужно настраивать в течение длительного времени. Весь этот процесс, считает Егор, должен запускаться из командной консоли одной командой.

2. No pet projects? A bad programmer!

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

Если вы считаете себя хорошим разработчиком мобильных приложений, у вас должен быть как минимум один опубликованный pet-проект в App Store или Google Play Market. Действительно специалист мобильной разработки должен уметь пройти весь цикл приложения от А до Я, в том числе и публикация в официальном магазине приложений. И пусть там будет около нуля загрузок - это не важно. Важно умение сделать из проекта продукт. Егор также считает, что все pet-проекты должны быть opensource, чтобы к нему могли присоединиться и другие контрибьютеры при желании. И чтобы эти контрибьютеры показали, как у них “не получается” задеплоить ваше приложение.

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

3. How much you can code in 100$?

Многие разработчики не умеют работать с деньгами: они привыкли получать оплату в конце месяца и не умеют оценивать свою работу в меньших масштабах. Многих вводит в ступор вопрос “сколько кода ты напишешь за 100$”. Сколько они хотят получать за месяц знают почти все, а вот в обратную сторону и за меньшие порции денег - почти никто.

Егор считает, что наиболее успешные проекты будут строиться группой разработчиков-фрилансеров, которые собираются временно, пилят проект и разбегаются. Люди приходят, когда проекту нужны их компетенции, и уходят, когда эти компетенции становятся не нужны. Эра, когда группа разработчиков “сидят” в компании и вынуждены периодически переучиваться на новые технологии и языки, проходит. Компании, если она хочет создать новый проект с новым стеком технологий, станет невыгодно мпереучивать своих штатных разработчиков, ей будет легче найти фрилансеров со знаниями и быстро запилить проект.

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

Егор считает, что резюме разработчика должно состоять из списка pet-проектов, а не компаний, где разработчик отработал N лет своей жизни. Законченный pet-проект - это умение довести проект до состояния продукта, а работа в компании в течение N лет - это чаще всего лишь допиливание существующего продукта, где врядли человек занимается чем-то большим. Что умеет разработчик из компании, какие у него компетенции и навыки - остается неизвестным, пока этот разработчик, собственно, не начнет проявлять себя в проекте.

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

Совет Егора разработчикам: учитесь работать по контракту. Даже будучи занятым fulltime на текущей работе, разработчикам нужно находить микро-проекты и учиться работать по контракту на них. Это позволит понять, нужны ли вы рынку как эксперт, или только одному боссу, который боится вас потерять и именно поэтому готов платить больше.

Умение посчитать время разработчика отсутствует не только у самих разработчиков, но и у заказчиков. Заказчик не понимает “ценообразования” часа работы программиста и просто хочет подешевле, когда слышит стоимость. “Давай не 100$, а 50$?”. Егор видит в таких случаях, что заказчик не понимает цены, но вполне может согласиться на цену в два раза меньше и скажет потом, что работа займет в два раза дольше. Заказчики привыкли к fulltime-оплате за 8 часов в офисе, и отсюда и неумение считать стоимость часа работы программиста.

4. Good programmers write code, best ones - tickets!

Программисты и заказчики привыкли к неформальному общению.

Неформальное общение в виде чатов, звонков и митингов только разрушают проект, делают ему только хуже

Неформальное общение остается “в воздухе”, принятые решения в таких коммуникациях трудно отследить. Когда команда меняется (а она будет меняться), очень важно для команд будущего насколько понятен скоуп проекта, его контекст, почему были выбраны те или иные решения. Новички в команде не хотят искать человека в офисе, который объяснит все это, они хотят просто прочесть эту информацию в репозитории или тикетной системе.

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

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

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

По мнению Егора, есть два вида разработки:

  • Continious Development - когда разработчик садится в 9 утра за рабочий стол и начинает кодировать до 5 вечера.
  • Incremental Development - когда разработчик работает исключительно по тикетам. Пока нет тикета, разработчики ничего не должны делать. Каждый тикет оканчивается pull-request’ом в репозиторий, который будет принят, а тикет - закрыт.

Инкрементальная разработка - это когда на тикет уходит час-два времени, а не неделя. Когда на тикет уходит неделя и заканчивается он пулл-реквестом на 5000 строк - это уже continious development.

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

Нужно учиться разбивать задачу на маленькие подзадачи.

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

5. What programming language should I learn first? English!

Русскоязычное комьюнити - это плохо, считает Егор. Он рекомендует двигаться в сторону использования только английского языка в своей профессии.

Так как Егор считает, что так как индустрия software development движется в сторону мультиязычных команд, то и позиционировать себя нужно как “Swift software engineer” вместо “разработчик на Swift’е из Москвы”. Это значит, что конкурировать за проекты разработчики из Москвы будут с англоговорящими. Учитывая, что большинство платежеспособных заказчиков тоже англоязычные, то русскоговорящие разработчики могут запросто проиграть эту конкруренцию. На глобальном рынке такие разработчики могут легко стать изгоями.

Рекомендации, которые дает Егор для прокачки своего английского языка:

  • Читать книги и материалы только на английском языке.
  • Смотреть фильмы на английском языке с субтитрами. Только так можно понят реальный английский язык, на котором разговаривают в жизни.
  • Участвовать в чатах на английском языке. И не только readonly-режим.
  • Писать на английском языке: telegram-канал, твиттер, блог, что угодно.

Мир меняется не сторону программистов, которые хорошо знают алгоритмы, а в сторону тех людей, кто умеет сделать продукт.

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

Чтобы этого достичь, нужно как минимум начать делать это.

6. No GitHub followers? You are not a programmer.

Весь мир идет к opensource, считает Егор. Приватными останутся только Nasa-вские и военные проекты. Разработчики должны уметь писать опенсорс и участовать в нем. В опенсорсе никто никому не нужен, никто не знает вас как человека, важен лишь проект, который вы пишете. Именно такой подход и будет превалировать в продакшн-разработке в будущем.

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

Когда вам понадобится эксперт в какой-то области на разовую работу, то проще всего будет начать искать такого эксперта именно на гитхабе или StackOverflow.com. Это в случае, если вы выступаете в качестве заказчика работы. Эта же логика работает и в обратную сторону - вы сможете найти себе микропроект так же через GitHub-аккаунт, если у вас будет какое-то влияние на комьюнити.

Вопросы из зала

Наиболее интересные.

Что делать, если хочется выпускать контент качественный на английском языке

Пользоваться proofreading’ом. Егор сам пользуется услугами native-speaking фрилансера (с upwork.com) для проверки всех своих статей для блога. Стоит это, по словам Егора, около 15-25$, и это не так дорого, если писать в блог 1-2 раза в месяц. Без проверки статьи лучше не публиковать, потому что качество контента - это важно.

Егор еще раз упомнялу, что цель производства контента - собратб вокруг себя аудиторию, заинтересовать их, “продать” им идею или проект, и сделать это можно и без идеального английского. Главное - стараться.

Есть сомнения, что нужно следовать принципу Deploy first, в особенности в отношении pet-проектов, ведь иногда нужно только “провалидировать” идею/видение.

Упаковка и соответствующие сборке процессы не должны занимать много времени, Егор считает, что максимум - это несколько часов первоначальной настройке. Когда он начинает новые проекты, то он тратит не более 2х часов на настройку деплоймента, но зато в итоге он уже в самом начале работы имеет возможность увидеть, как его собранный пакет “висит” публичном репозитории, откуда его может скачать любой желающий. Таким образом, Егор может заинтересовать других контрибьютеров гораздо раньше.

Как не ошибиться и не нанять посредственного кодера с раскрученным GitHub-аккаунтом вместо отличного разработчика без фолловеров?

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

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

Я разработчик из продуктовой компании, и меня зацепили слова про то, что продуктовые команды разработчиков “не нужны”, ведь продукт живет и развивается.

Егор считает, что выражение “хороший продукт пишет хорошая команда разработчиков” - это заблуждение. Прежде всего хороший продукт выходит из хорошего кода / репозитория. Команда же должна ротироваться, и это делает код репозитория только лучше. Егор считает, что

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

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

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

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

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

Мой вопрос пересекается с предыдущим. Если в будущем команды будут “фичевые” - преходящие для имплементации одной конкретно взятой фичи (feature), то как можно говорить о поддержке кода? Ведь каждая новая команда захочет просто все переписать по-новому или использовать разные паттерны. Получается, должны быть какие-то четкие архитектурные правила. А как насчет непосредственно доставки инкремента продукта? Будет какая-то отдельная преходящая команда, которая будет отвечать только за доставку? А если есть внешние зависимости между командами?

Много в этом вопросе содержится ответов. Действительно, каждый новый разработчик будет всегда видеть “ужасный код”, который написали до него и будет хотеть все переписать. Этому противиться должен сам репозиторий проекта. Задача репозитория - выжить, потому что между ним и разработчиками идет постоянная война.

Чтобы репозиторий был целостен и сохранял свою архитектуру, он должен иметь CICD, юниттесты, проверку синтаксиса, документацию, код-ревью и прочие вспомогательные вещи помимо самого кода. Тогда новички в команде не смогут так легко изменить все кардинально и радикально одним лишь pull-request’ом.

Если же в репозитории нет перечисленных Егором вещей и каждый может просто запушить в master-branch все, что ему захочется, значит репозиторий эту войну проиграл. Если репозиторий сильный, то он просто не пропустит подобной ситуации, когда каждый новый “ковбой” пытается его сломать.

Если какая-то ситуация приводит к поломке репозитория в процессе его жизни, то это лишь повод усилить его и закрыть брешь.