Хабрахабр

Трайбы, гильдии, build train и никаких TDD: как устроена мобильная разработка в Uber, Spotify, «Одноклассниках» и Авито

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

Филипп Уваров, Android developer в Spotify. В компании работает последние полгода — в одной из платформенных команд, которые занимаются поддержкой других разработчиков в Spotify. Живет в Швеции. До Spotify работал в одном шведском стартапе, а еще раньше — в Avito.

Помимо собственно разработки, отвечает за архитектуру, проектирование, распределение задач, согласования с дизайном, API backend-а и т.п. Артем Ольков, Lead IOS Developer в «Одноклассниках».  В данный момент возглавляет iOS-разработку одного из продуктов. В команде Артема — 11 человек. Всего в «Одноклассниках» сейчас около 60 мобильных инженеров, которые делятся на более мелкие команды.

Входит в команду «rider payments», которая занимается обработкой всего, что связано с платежами в приложении для пассажиров Uber. Максим Ефимов, Senior software engineer в Uber. В компании работает два года, занимается Android-разработкой. В Uber в рамках подразделения, которое занимается платежами, есть еще несколько подобных команд для других приложений, а также инфраструктурные команды — в общей сложности это несколько десятков команд. До этого разрабатывал под Android в других компаниях — в основном, на заказ, а еще раньше — писал на С++ (серверные решения для SCADA-систем).

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

Давайте начнем с особенностей. Чем отличается работа команд при большом штате разработчиков в компании?

Грубо говоря, если ваша команда делает мобильную платформу, на которой базируются другие приложения или сервисы компании, к ней будет прилетать 1000 запросов из разных уголков и без хорошего product manager-а разработка захлебнется. Артем Ольков (Одноклассники): На мой взгляд, особенности связаны скорее не с масштабом компании, а с тем, как внутри нее устроены процессы и какую роль в этих процессах играет команда. Если же команда делает отдельно стоящий сервис без сложных интеграций, то процесс будет выглядеть гораздо проще.

Максим Ефимов (Uber): На мой взгляд, самая характерная черта — это скорость работы.

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

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

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

А еще у нас очень сильно разделены сферы ответственности. Филипп Уваров (Spotify): Я думаю, основная особенность в том, что я не знаю всех Android-разработчиков в лицо. Это позволяет всегда находиться в контексте того, что ты делаешь, и достаточно быстро доставлять продукты в своем направлении.

Как ваша команда синхронизируется с другими внутри компании?

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

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

Они объединены в структурные подразделения, которые отвечают за большие области, например, мобильное приложение. Максим Ефимов (Uber): У нас команды небольшие, в каждой не более 20 человек. При этом сами команды достаточно автономны, потому что если все свести к какой-либо единой системе управления с прямым подчинением, мы получим очень неэффективную систему.

Есть отдельная структура, которая объединяет этих людей и помогает формировать понимание того, как и куда мы движемся. Общая продуктовая идея доносится до отдельных команд через product manager-ов или owner-ов. Ну а детали решаются на один — два уровня ниже. На каком-то верхнем уровне могут определяться стратегические цели вроде заботы о безопасности пассажира. Например, у нас есть определенные механизмы обеспечения безопасности в странах, где люди в основном пользуются наличными для оплаты.

Так скажем, мы — стартап внутри большой компании. Артем Ольков (Одноклассники): Мы занимаемся отдельным сервисом. А во всем остальном мы сильно отделены. Понятное дело, мы живем в одной инфраструктуре. Даже в рамках интеграции мы зачастую пользуемся публичным API наших же инструментов.

С чем вам приходится сталкиваться? А есть ли проблемы, типичные для больших команд?

Евгений Суворов (Avito): На мой взгляд, в большой команде в первую очередь страдают процессы.

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

А это значит — качественный Continuous Integration, Continuous Delivery, автоматизация тестирования.

Я могу не иметь представления о том, что происходит в каких-то далеких командах. Филипп Уваров (Spotify): Я думаю, самая масштабная проблема — это распространение знаний внутри компании. Именно здесь ощущается масштаб. И то же самое верно в обратном направлении: многие команды понятия не имеют, что у нас в Spotify вообще существует команда аналитики.

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

Артем Ольков (Одноклассники): Да, проблемы действительно две: передача знаний и согласование действий, в том числе по модернизации.

Есть ли в крупных компаниях какие-то проверенные способы решения этих проблем?

Это объединения разработчиков по функциям, например, Android-гильдия, которая раз в две недели проводит какие-то мероприятия: презентации, ланчи, где можно обсудить насущные проблемы или поделиться чем-то, и пр. Филипп Уваров (Spotify): Для решения первой проблемы — шаринга знаний — у нас есть такая штука, как гильдии. Плюс есть почтовые рассылки и т.д. Еще у нас, опять же, по гильдиям, проходят внутренние конференции. Остается простая человеческая проблема: за всем этим сложно угнаться.

У нас есть свой Data University, где можно выучиться на дата-инженера. Отдельной строкой хочется выделить внутреннее обучение (повышение квалификации). Сейчас коллеги думают над созданием такой же схемы для мобильного обучения.

Артем Ольков (Одноклассники): У нас нет ярко выраженных гильдий.

Есть отдельные чатики, например, чисто для iOS-ников. Так или иначе ребята, объединенные одной задачей, пересекаются на различных митапах — друг друга знают, общаются в курилке или за обедом. Внутри команды, понятно, вопрос решается проще — мы все сидим за одной «ромашкой».

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

Вторая проблема — согласование действий — решается грамотным менеджментом.

Я вижу, что сам механизм шаринга отличается. Максим Ефимов (Uber): На самом деле в том же шаринге знаний я не вижу проблему. Собрались — поговорили. В маленьких командах это просто делается абы-как. Про них я, кстати, буду рассказывать в своем выступлении на AppsConf 2018. А у нас есть удобные процессы, которые позволяют организовать все так, чтобы оно работало. Люди из любых команд могут смотреть на то, что делают другие разработчики, и что-то из этого использовать у себя. Идея в том, что в нашей компании практически вся разработка довольно прозрачна.

Мы любим автоматизацию, и эта задача тоже автоматизирована. Евгений Суворов (Avito): У нас также организуются встречи 2 раза в неделю. И если есть повестка, мы собираемся. Есть процесс, когда в течение недели люди накидывают темы, про которые они хотели бы рассказать на общей встрече iOS или Android-разработчиков. В рамках встреч продуктовые команды рассказывают про те фичи, которые они реализовали в продукте, потому что иначе сложно уследить за всем, что происходит.

Мы встречались с самого начала, но именно с ростом компании эти встречи стали наиболее актуальны.

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

По какому принципу имеет смысл разделять множество разработчиков в компании — по платформам, по функционалу или каким-то иным образом?

Артем Ольков (Одноклассники): Это все-таки зависит от того, чем вы занимаетесь и как зарабатываете деньги.

Но для продуктовой компании я с трудом представляю иную форму деления, кроме как по функциональным командам. Я могу в теории представить структуру аутсорсинговой компании, в которой деление, например, по платформенному признаку будет работать.

Потому что если собрать в кучу всех iOS-ников, вбрасывать в них задачи, не имея очень короткого моста общения с дизайном, backend-ом или тестированием, придется тратить слишком много времени на согласования.

Например, наша команда занимается аналитикой и в нее входят и iOS, и backend разработчики, и много кто еще. Филипп Уваров (Spotify): У нас все делятся по продукту. На мой взгляд, это очень разумное деление команд, которое тоже ведет к определенным проблемам, но при этом хорошо работает на таких масштабах.

Она достаточно сильно отделяет разработчиков друг от друга и в итоге синхронизация, к примеру, двух мобильных приложений под разные платформы, будет стоить гораздо дороже. Максим Ефимов (Uber): Мне кажется, идея делить команды по платформам — iOS, Android, backend — на больших масштабах сработает не очень хорошо. Да, с шарингом знаний проще, но стоит ли это того? А профита с того, что люди в команде видят только людей со своей платформы, как мне кажется, не так уж и много. Мне кажется, нет.

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

Евгений Суворов (Avito): Соглашусь.Такая структура вполне удачна и мы как раз недавно внедрили ее у себя в Avito, по крайней мере в продуктовой части бизнеса.

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

И на этом этапе мы начали разбиваться на продуктовые команды: выделились группы «buyer experience», «seller experience», мессенджера, доставки и т.д. В какой-то момент в Avito были две большая команды — iOS и Android-разработки, по 15 человек каждая. Раньше в команды приходило много project manager-ов с запросами на фичи, и для них каждая из этих фич имела приоритет номер один. Это решило вопрос с приоритетами. Вышестоящим людям приходилось управлять этим вручную. В итоге у нас 20 проектов и сквозные приоритеты их не ясны. После выделения многофункциональных команд, у каждой из которых — свой pipeline разработки, свои приоритеты и ресурсы, все стало проще.

При этом у нас остались небольшие платформенные команды, которые делают, как мы это называем, «горизонтальные» решения, раскатывающиеся на все продуктовые команды.

Часто ли проходят реорганизации команд?

В нашей компании команды маленькие и автономные. Филипп Уваров (Spotify): Какие-то перемещения происходят каждую неделю. Насколько часто это происходит — зависит от команды и направления, в котором ты работаешь. При желании можно очень легко перейти из одной в другую. Но Spotify славится тем, что мы работаем по agile и во многом от нас пошли такие вещи, как OKR и т.п. Там, где работаю я, это не ярко выражено. Мы просто переключаемся на что-то другое. Поэтому руководство компании не боится менять приоритеты, если вдруг понимает, что что-то не работает.

В течение года число сотрудников увеличилось чуть ли не в два раза. Максим Ефимов (Uber): У нас были масштабные реформы, связанные в первую очередь с очень быстрым ростом амстердамского офиса. В связи с этим команды просто делились на несколько «подкоманд», каждая из которых занималась более узкой сферой. Те команды, куда набирали людей, стали очень большими и одному менеджеру было тяжело управлять такой структурой. Мне кажется, это естественный процесс.

Согласны ли вы с идеей, что в большой команде, чтобы не страдало качество кода, стоит избегать найма джуниоров и сеньоров с избыточной квалификацией?

Spotify каждый год набирает достаточно много выпускников ВУЗов через летнюю практику (какая-то часть людей после практики получает приглашение на работу). Филипп Уваров (Spotify): Я думаю, ни то, ни другое. Аналогично мы без проблем берем людей с несколькими PhD.

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

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

У нас есть желательное соотношение опытных разработчиков и джунов. Максим Ефимов (Uber): Мы отталкиваемся от несколько иного принципа. Поэтому мы стараемся соблюдать баланс. Как раз для того, чтобы не возникло ситуации, когда есть толпа джунов, а помогать им и объяснять, как надо работать, некому.

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

Евгений Суворов (Avito): На мой взгляд, набирая сеньоров, не стоит бояться, что у них свой царь в голове или что они не будут слушаться.

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

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

То есть джуниоров мы не боимся, но ориентируемся на ощущения команды — нужно ей это или нет.

Планирование, синхронизация, распределение задач

Много ли сил отнимает планирование и синхронизация разработчиков в рамках большой компании (пусть даже в маленьких командах)?

Филипп Уваров (Spotify): Это как раз плюс деления команд по продуктам, а не по функциям: мы занимаемся планированием только нашего небольшого продукта внутри компании и нам зачастую все равно, что там делают остальные миллион разработчиков.

У нас начало разработки, и это дает определенные поблажки — позволяет быть свободнее. Артем Ольков (Одноклассники): Здесь я могу рассказать только про нашу конкретную команду. Все остальное решается в личном порядке. На данный момент у нас есть только ежедневные 15-минутные митинги по текущему статусу и часовое закрытие предыдущего / планирование следующего спринта раз в неделю.

Быть может, раза в 1,5 — 2 больше, чем это занимало у меня, когда я работал на аутсорсе. Максим Ефимов (Uber): В нашем случае — не очень большую.

Грубо говоря, пока какая-то команда, ответственная за свой кусок кода, не посмотрит твой коммит, может пройти просто какое-то время. Правда, есть некоторые процессы в компании, вроде code review, которые тормозят разработку. Это скорее о том, как настроена на низком уровне вся эта схема — кто кого ревьюит, как устроено ожидание и т.п. Но я не думаю, что это относится к плате за синхронизацию.

Евгений Суворов (Avito): Проблему синхронизации мы изначально решили частыми релизами. В итоге сейчас сама синхронизация занимает немного. Все почти автоматизировано.

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

Таким образом, на задачах всегда будут люди, которые ответственно к ним подходят, потому что им же с этим жить потом. Филипп Уваров (Spotify): В больших командах имеет смысл распределение продукта по зонам ответственности. не возникает ситуации, когда все разработчики занимаются абсолютно всем (Петя здесь написал 10 строчек, чуть ниже Василий еще 5 дописал и в итоге получается месиво, которое потом невозможно поддерживать). У них не меняется контекст, т.е.

При этом если работаешь внутри маленького «продукта внутри продукта», ты должен более-менее понимать, как эта вся система работает от backend-а до клиента.

Например, в моей команде сейчас ребята с бэкграундом мобильной разработки пилят микросервисы на backend-е на трех языках — Python, PHP, Go — которые должны выдерживать нагрузку Avito. Евгений Суворов (Avito): Что касается качества, то лучше полагаться на тестирование и code review. обеспечивают на входе джуниоров, а на выходе — качественную штуку. Но коммуникации, автоматизация тестирования и т.п.

Можете ли вы вспомнить одну-две самые интересные задачи, с которыми сталкивалась ваша команда в последнее время?

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

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

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

На backend-е микросервисы зародились давно, а в мобильных приложениях этот тренд появился совсем недавно — может год — два назад. И то в больших зарубежных командах, в России таких мало.

Технологический стек

Сталкивались ли вы в последнее время с каким-то революционным изменением технологического стека в своей компании / команде? И вообще как такие процессы у вас проходят?

Есть эксперименты по внедрению новых технологий, в частности, с переездом Gradle на Bazel или с Teamcity на нашу внутреннюю систему, но не более того. Филипп Уваров (Spotify): У нас такое редко практикуется. Я думаю, у нас невозможны такие революции по определению.

Есть несколько людей, включая меня, кто выступает за Kotlin. Максим Ефимов (Uber): До Uber-а у меня был такой опыт, но здесь это постоянно идущий процесс. Но в целом это возможно. Есть определенные вещи, с которыми нам нужно разобраться, как работать. Мы не должны сидеть и ждать, пока «самый главный разработчик» скажет: «Теперь вы пишите на Kotlin-е». Мы над этим сейчас работаем. Kotlin уже используется в части нашей кодовой базы, но все еще в процессе.

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

Рост компании и модуляризация изменили подход этих команд к работе. Евгений Суворов (Avito): У нас есть две платформенные команды, которые пилят инструменты для внутреннего использования. Им пришлось много коммуницировать, чтобы понять, что же нужно конечным потребителям (разработчикам).

Часто разработчики говорят: «Давайте внедрим эту штуку вместо той, которую мы 5 лет делаем, т.к. В плане технологических изменений у нас появился Technology Radar. Чтобы разобраться с этими предложениями, мы завели Technology Radar, в котором тому, у которого есть инициатива, приходится влезть в небольшую бюрократию, провести какое-то исследование, выразить в цифровых метриках, что нововведение нам что-то ускорит, а что-то замедлит, что есть какие-то риски относительно новой технологии. она морально устарела». Правда, с Technology Radar предложений стало меньше. Это пройдет ревью от нескольких коллег и, если все хорошо, технологию применят.

Сложнее ли проводить такие реформы с ростом масштаба компании?

Допустим, в маленькой компании вас 10 человек и кто-то один хочет что-то поменять. Максим Ефимов (Uber): Сложнее, но не намного. Если же у вас 100 разработчиков, это не значит, что нужно будет договариваться с 99. Для этого ему нужно договориться с девятью людьми. Конечно, далеко не все будут в этом активно участвовать, это не так сложно, как могло бы быть.

Какие из последних технологий лично вам кажутся наиболее интересными с точки зрения применения в крупных командах (даже если они не работают в вашей компании)?

В плане технологий — везде свои особенности. Евгений Суворов (Avito): Наверное, ключевое — это микросервисы, разделение по доменным областям, разбиение на команды, у которых свои приоритеты.

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

Хотя бывают и исключения. Ввиду разбиения на модули у нас страдал Android-проект —  IDE очень долго парсила модель проекта и помогли только новые early adopted preview версии. Там были экспериментальные галочки, с которыми все стало круче работать.

Мне кажется, в скором времени все забудут про Java на Android, особенно если у Kotlin станет чуть получше с билдами и мы сможем на него перейти. Филипп Уваров (Spotify): Я думаю, Kotlin —  одна из супер-многообещающих вещей. Насколько я знаю, многие большие команды — вроде Facebook — долгое время противились Kotlin-у как раз потому, что там огромные проекты, которые и без этих проблем собираются три года, а с Kotlin будут собираться по шесть лет.

Из последнего лично мне кажется достаточно интересным Flutter.

Дополнительные фреймворки зачастую не нужны. Артем Ольков (Одноклассники): Я считаю, что лучший стек технологий в контексте разработки под iOS — родной, который предоставляет Apple. За пределами этих команд они зачастую добавляют только больше болей. Есть интересные инструменты, но они построены очень крупными командами только под свои нужды.

Хочется отметить конкретно Unidirectional Data Flow. Есть пара очень интересных подходов, которые сейчас в тренде, и некоторые из них — вполне заслуженно.

А что вы думаете о постепенном переходе на Swift?

Сейчас мы начали новый проект и у нас все на Swift, но есть 150 строк на Objective-C, т.к. Артем Ольков (Одноклассники): Это сложная тема. по определенным причинам мы не смогли с помощью Swift относительно лаконично сделать то, что нам было необходимо.

У многих ребят, которых я знаю, перенос кодобазы на Swift — это именно HR-PR-история, потому что на рынке очень много новых разработчиков, которые просто не знают Objective-C и не хотят его изучать. Если у вас все на Objective-C и вас он полностью устраивает, есть ли смысл переходить на Swift?

Мы влезли в Swift в свое время и он замедлил нам время сборки. Евгений Суворов (Avito): Это как раз наш случай. В целом это себя оправдало в определенной степени. Вообще там было много минусов, но для нас один из ключевых поинтов был в том, что это такая хайповая штука, на которую мы сможем нанимать много разработчиков. Swift сейчас развивается, но на Objective-C, возможно, было бы быстрее, удобнее и меньше проблем.

Идея долгосрочной поддержки может стать поводом для перехода (разработчиков в перспективе должно стать больше)?

Apple все еще находится в той позиции, когда они могут сказать, что Swift больше не поддерживается, и отдать его на развитие open source. Артем Ольков (Одноклассники): На этот вопрос не так просто ответить. Objective-C все еще получает улучшения. Вероятность такого развития событий на сегодняшний день очень мала, но она не нулевая.

Это не сложно, если понимать основные концепции. Лично мое мнение (в Одноклассниках с ним могут и не согласиться) — если просто взять объективные факты — через пять-семь лет будут жить оба языка, а разработчикам нужно будет просто уметь работать и с тем, и с тем. На сегодняшний день разработки под iOS — это больше не про знание языка, а про знание фреймворка, на котором ты работаешь. Зная один, выучить другой — уже не такая большая проблема.

Разработка и тестирование

Когда вы пишете тесты? TDD или уже после написания кода?

Мы обычно пишем тесты параллельно, вместе с разработкой. Филипп Уваров (Spotify): Если честно, с учетом запуска билдов на Android я не верю в то, что можно эффективно писать тесты до кода.

Unit-тесты на совести команды разработчика. Артем Ольков (Одноклассники): Все зависит от того, про какие тесты мы говорим.

Если это интеграционные тесты (API, UI и т.д.) — за них уже отвечают тестировщики по мере появления задач. Конкретно в нашей команде мы покрываем Unit-тестами только определенные слои, в которых нам нужно быть уверенными (проблемы на других слоях мы видим сразу).

Максим Ефимов (Uber):Я знаю, часть нашего бэкенда любит TDD, но среди мобильных разработчиков я таких людей не знаю. Нам важно, что получилось в итоге, а уж в какой последовательности человек это написал — его личное дело.

В самом начале он помогает в постановке задачи, определяет функциональные требования, описывает приемочные тест-кейсы. Евгений Суворов (Avito): Тестировщик присутствует на всем жизненном цикле фичи. В принципе, тестировщик тоже может их писать — у нас отдельная команда, которая занимается инструментом для написания UI-тестов. UI- и unit-тесты пишет сам разработчик.

На каком — маленькие команды решают самостоятельно. Сами тесты можно писать независимо на любом этапе. Они могут использовать или не использовать TDD.

У нас в Android-сообществе есть человек, который это действительно практиковал и пытался найти единомышленников. В целом практика TDD не очень популярна. Он как раз выступает на AppsConf 2018 с докладом про TDD.

Но в основном тесты пишут уже после того, как написали фичу.

Предусмотрены ли у вас какие-то стандарты покрытия?

Но 100% покрытие бизнес-логики unit-тестами обязательно. Филипп Уваров (Spotify): Они могут быть разными, в зависимости от задачи.

Но никто нигде не говорит, какой должен быть процент покрытия. Максим Ефимов (Uber): У нас есть общее понимание того, что мы тесты делаем. Команды это определяют сами.

А существует ли с вашей точки зрения  какое-то «золотое» соотношение тестирования и разработки в проекте?

Филипп Уваров (Spotify): Я не смогу назвать идеальную пропорцию — все зависит от задачи.

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

Евгений Суворов (Avito): У нас на самую большую команду, включающую четыре мобильных разработчика, есть два QA-инженера, которые тестируют не только мобильную часть, но и backend, frontend и все остальное. Но идеальное соотношение зависит от деталей организации процесса. Например, в моей платформенной команде шесть инженеров, но в принципе нет QA.

Предусмотрены ли у вас процедуры контроля качества кода внутри сообщества разработчиков?

Плюс у нас очень много проверок выполняется на CI: у нас подключено несколько инструментов для статического анализа кода, которые проверяют code style и все на свете — и об этом частично я буду рассказывать в своем докладе на AppsConf 2018. Филипп Уваров (Spotify): Да, code review — одна из базовых проверок.

Есть сборки с тестами, правила ведения git-а. Артем Ольков: В Одноклассниках есть pull request, есть контроль code style, который обеспечивают форматтеры; есть линтеры, которые выявляют простые ошибки. Все — очень маленькие шаги, направленные к одной великой цели: сделать так, чтоб кодовая база была хорошей.

Нельзя залить коммит, если его никто не посмотрел. Максим Ефимов (Uber): Code review — такая штука, которой избежать нельзя. Но процесс команды настраивают сами.

Когда разработчик реализует новую фичу, контрибьютит код, он создает пул-реквест, который проходит серию автоматических проверок, в том числе, по качеству. Евгений Суворов (Avito): У нас тоже предусмотрены code review-процессы через пулл-реквесты.  Потом код смотрят соседи-разработчики.

По мере развития компании менялся и сам процесс. Мы запустили этот процесс, как только в команде появился второй разработчик. Чуть позже мы увеличили количество апрувов с одного до четырех, иначе люди были не готовы принимать решения, влияющие на растущую кодовую базу («а вдруг я неправильно оценил?»). Вначале он был ручным, потом появилась автоматизация. При разделении на многофункциональные команды, когда люди разбежались по разным юнитам, мы сбавили количество апрувов до двух.

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

Как часто имеет смысл выпускать релизы в проекте крупной компании?

Филипп Уваров (Spotify): Чем чаще, тем лучше.

К примеру, до «Одноклассников» я работал в «Акронисе». Артем Ольков (Одноклассники): Это также очень сильно зависит от бизнеса, пользователей, модели распространения. У большого продукта было два больших релиза в год — летний и зимний — так исторически сложилось. Там мобильное приложение — это компонент большого десктопного продукта, и его релизы были привязаны к релизам десктопа. В промежутках были только хотфиксы и какие-то быстрые исправления. Поэтому и мобильное приложение релизилось летом и зимой.

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

У нас релизы идут на регулярной основе. Максим Ефимов (Uber): Мне кажется, то, как это организовано у нас — вполне разумно и удобно.

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

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

Если ты не успел в определенный релиз сделать фичу, то ждешь еще месяц. Евгений Суворов (Avito): Изначально релизы у нас были раз в месяц — это всего 12 релизов в год. В итоге люди пытались задерживать релизы, из-за этого тормозились другие команды и страдало качество (некоторые фичи доделывали в спешке, тяп-ляп).

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

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

О деталях спикеры и их коллеги будут рассказывать на AppsConf 2018ApplsConf 2018. Крупные команды имеют и другие отличия. Там будут разговоры и об инструментах, и о принципах организации масштабных команд.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть