В преддверии AppsConf 2018 мы опросили специалистов из крупных компаний о том, какие отличительные черты и процессы есть у больших команд, занимающихся разработкой мобильных приложений. Какие подходы к работе применяются, какие подводные камни ждут гребцов, поступающих на громадную галеру. Накладывает ли иностранное происхождение компании отпечаток на рабочие процессы — о всем об этом читайте под катом.
Филипп Уваров, Android developer в Spotify. В компании работает последние полгода — в одной из платформенных команд, которые занимаются поддержкой других разработчиков в Spotify. Живет в Швеции. До Spotify работал в одном шведском стартапе, а еще раньше — в Avito.
Артем Ольков, Lead IOS Developer в «Одноклассниках». В данный момент возглавляет iOS-разработку одного из продуктов. Помимо собственно разработки, отвечает за архитектуру, проектирование, распределение задач, согласования с дизайном, API backend-а и т.п. Всего в «Одноклассниках» сейчас около 60 мобильных инженеров, которые делятся на более мелкие команды. В команде Артема — 11 человек.
Максим Ефимов, Senior software engineer в Uber. В компании работает два года, занимается Android-разработкой. Входит в команду «rider payments», которая занимается обработкой всего, что связано с платежами в приложении для пассажиров Uber. До этого разрабатывал под Android в других компаниях — в основном, на заказ, а еще раньше — писал на С++ (серверные решения для SCADA-систем). В Uber в рамках подразделения, которое занимается платежами, есть еще несколько подобных команд для других приложений, а также инфраструктурные команды — в общей сложности это несколько десятков команд.
Евгений Суворов, руководитель разработки юнита «мобильная архитектура» в 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-а и других новых технологий. Одно дело — прийти и сказать пяти разработчикам: «С сегодняшнего дня мы пишем на Kotlin», но совсем другое — сказать это 100 разработчикам. Существует огромная инфраструктура, которую нужно переводить, как-то поддерживать эти нововведения (CI и т.п.).
Артем Ольков (Одноклассники): Да, проблемы действительно две: передача знаний и согласование действий, в том числе по модернизации.
Есть ли в крупных компаниях какие-то проверенные способы решения этих проблем?
Филипп Уваров (Spotify): Для решения первой проблемы — шаринга знаний — у нас есть такая штука, как гильдии. Это объединения разработчиков по функциям, например, Android-гильдия, которая раз в две недели проводит какие-то мероприятия: презентации, ланчи, где можно обсудить насущные проблемы или поделиться чем-то, и пр. Еще у нас, опять же, по гильдиям, проходят внутренние конференции. Плюс есть почтовые рассылки и т.д. Остается простая человеческая проблема: за всем этим сложно угнаться.
Отдельной строкой хочется выделить внутреннее обучение (повышение квалификации). У нас есть свой Data University, где можно выучиться на дата-инженера. Сейчас коллеги думают над созданием такой же схемы для мобильного обучения.
Артем Ольков (Одноклассники): У нас нет ярко выраженных гильдий.
Так или иначе ребята, объединенные одной задачей, пересекаются на различных митапах — друг друга знают, общаются в курилке или за обедом. Есть отдельные чатики, например, чисто для iOS-ников. Внутри команды, понятно, вопрос решается проще — мы все сидим за одной «ромашкой».
Если возникают какие-то вопросы, поднимаешь руку, машешь тому, кто тебе нужен — и он тебе отвечает. Для передачи знаний мы используем и 15-минутные утренние митинги, на которых все рассказывают, что как, зачем и почему они сделали. Еще есть определенный слой документации, куда выносятся основные пункты.
Вторая проблема — согласование действий — решается грамотным менеджментом.
Максим Ефимов (Uber): На самом деле в том же шаринге знаний я не вижу проблему. Я вижу, что сам механизм шаринга отличается. В маленьких командах это просто делается абы-как. Собрались — поговорили. А у нас есть удобные процессы, которые позволяют организовать все так, чтобы оно работало. Про них я, кстати, буду рассказывать в своем выступлении на AppsConf 2018. Идея в том, что в нашей компании практически вся разработка довольно прозрачна. Люди из любых команд могут смотреть на то, что делают другие разработчики, и что-то из этого использовать у себя.
Евгений Суворов (Avito): У нас также организуются встречи 2 раза в неделю. Мы любим автоматизацию, и эта задача тоже автоматизирована. Есть процесс, когда в течение недели люди накидывают темы, про которые они хотели бы рассказать на общей встрече iOS или Android-разработчиков. И если есть повестка, мы собираемся. В рамках встреч продуктовые команды рассказывают про те фичи, которые они реализовали в продукте, потому что иначе сложно уследить за всем, что происходит.
Мы встречались с самого начала, но именно с ростом компании эти встречи стали наиболее актуальны.
Плюс есть чатики, где можно обсудить какие-то конкретные вопросы.
По какому принципу имеет смысл разделять множество разработчиков в компании — по платформам, по функционалу или каким-то иным образом?
Артем Ольков (Одноклассники): Это все-таки зависит от того, чем вы занимаетесь и как зарабатываете деньги.
Я могу в теории представить структуру аутсорсинговой компании, в которой деление, например, по платформенному признаку будет работать. Но для продуктовой компании я с трудом представляю иную форму деления, кроме как по функциональным командам.
Потому что если собрать в кучу всех iOS-ников, вбрасывать в них задачи, не имея очень короткого моста общения с дизайном, backend-ом или тестированием, придется тратить слишком много времени на согласования.
Филипп Уваров (Spotify): У нас все делятся по продукту. Например, наша команда занимается аналитикой и в нее входят и iOS, и backend разработчики, и много кто еще. На мой взгляд, это очень разумное деление команд, которое тоже ведет к определенным проблемам, но при этом хорошо работает на таких масштабах.
Максим Ефимов (Uber): Мне кажется, идея делить команды по платформам — iOS, Android, backend — на больших масштабах сработает не очень хорошо. Она достаточно сильно отделяет разработчиков друг от друга и в итоге синхронизация, к примеру, двух мобильных приложений под разные платформы, будет стоить гораздо дороже. А профита с того, что люди в команде видят только людей со своей платформы, как мне кажется, не так уж и много. Да, с шарингом знаний проще, но стоит ли это того? Мне кажется, нет.
Плюс мне кажется интересной идея о том, что некоторые команды делают базовые вещи, которыми пользуются все остальные, например, какие-то кнопки, списки, поля ввода текста.
Евгений Суворов (Avito): Соглашусь.Такая структура вполне удачна и мы как раз недавно внедрили ее у себя в Avito, по крайней мере в продуктовой части бизнеса.
Крупной наша команда стала, наверное, тогда, когда у нас появилось пять разработчиков — поскольку уже при таком количестве затруднилась самоорганизация. Ребятам стало сложнее пилить одну фичу, приходилось их как-то разделять, разводить по разным углам, по разным фичам. Начались разногласия в архитектурных и других вопросах, усложнились коммуникации.
В какой-то момент в Avito были две большая команды — iOS и Android-разработки, по 15 человек каждая. И на этом этапе мы начали разбиваться на продуктовые команды: выделились группы «buyer experience», «seller experience», мессенджера, доставки и т.д. Это решило вопрос с приоритетами. Раньше в команды приходило много project manager-ов с запросами на фичи, и для них каждая из этих фич имела приоритет номер один. В итоге у нас 20 проектов и сквозные приоритеты их не ясны. Вышестоящим людям приходилось управлять этим вручную. После выделения многофункциональных команд, у каждой из которых — свой pipeline разработки, свои приоритеты и ресурсы, все стало проще.
При этом у нас остались небольшие платформенные команды, которые делают, как мы это называем, «горизонтальные» решения, раскатывающиеся на все продуктовые команды.
Часто ли проходят реорганизации команд?
Филипп Уваров (Spotify): Какие-то перемещения происходят каждую неделю. В нашей компании команды маленькие и автономные. При желании можно очень легко перейти из одной в другую. Насколько часто это происходит — зависит от команды и направления, в котором ты работаешь. Там, где работаю я, это не ярко выражено. Но Spotify славится тем, что мы работаем по agile и во многом от нас пошли такие вещи, как OKR и т.п. Поэтому руководство компании не боится менять приоритеты, если вдруг понимает, что что-то не работает. Мы просто переключаемся на что-то другое.
Максим Ефимов (Uber): У нас были масштабные реформы, связанные в первую очередь с очень быстрым ростом амстердамского офиса. В течение года число сотрудников увеличилось чуть ли не в два раза. Те команды, куда набирали людей, стали очень большими и одному менеджеру было тяжело управлять такой структурой. В связи с этим команды просто делились на несколько «подкоманд», каждая из которых занималась более узкой сферой. Мне кажется, это естественный процесс.
Согласны ли вы с идеей, что в большой команде, чтобы не страдало качество кода, стоит избегать найма джуниоров и сеньоров с избыточной квалификацией?
Филипп Уваров (Spotify): Я думаю, ни то, ни другое. Spotify каждый год набирает достаточно много выпускников ВУЗов через летнюю практику (какая-то часть людей после практики получает приглашение на работу). Аналогично мы без проблем берем людей с несколькими PhD.
Техническая квалификация — это круто, но этому можно научить. Если же человек не умеет работать в команде, тут будет крайне сложно. Поэтому в таких компаниях чуть ли не больше внимания уделяют именно софт скиллам.
А чтобы качество не страдало, нужны хорошие собеседования, которые позволят отбирать разработчиков не ниже некоего базового уровня.
Максим Ефимов (Uber): Мы отталкиваемся от несколько иного принципа. У нас есть желательное соотношение опытных разработчиков и джунов. Как раз для того, чтобы не возникло ситуации, когда есть толпа джунов, а помогать им и объяснять, как надо работать, некому. Поэтому мы стараемся соблюдать баланс.
Придерживаться принципа «не набирать слишком много сеньоров» не вижу смысла. Поиски сеньора — это довольно тяжелый квест. На рынке много компаний, и конкуренция за разработчиков серьезная. Люди с опытом успешно устраиваются практически в любые места, поэтому отказываться от квалифицированных кадров сегодня, а потом набирать их завтра — несколько нереалистично. Эти люди не будут сидеть и ждать, пока мы захотим их пригласить. И в моей практике, если человек обладает хорошими компетенциями, то не проблема найти ему место в компании. Но надо отталкиваться от конкретной ситуации. Нужно принимать решение в зависимости от того, какие амбиции есть у каждого человека в команде, смотреть на предстоящие проекты, сможем ли мы вытащить их своими силами, кто нам нужен. То есть надо опускаться на низкоуровневое планирование.
Евгений Суворов (Avito): На мой взгляд, набирая сеньоров, не стоит бояться, что у них свой царь в голове или что они не будут слушаться.
В нашей компании разработчики сами предлагают способы решения тех или иных проблем. И у сеньоров часто эти решения качественные. У них есть опыт, поэтому с их участием проблемы могут решаться быстрее. Там есть иная проблема — ваши задачи могут показаться сеньорам недостаточно интересными или амбициозными.
К джуниорам тоже нужно подходить индивидуально. Когда мы еще были одной командой, периодически появлялось интуитивное ощущение, что команда может вывезти еще одного джуна. И в этот момент можно было взять прекрасного амбициозного парня, который довольно быстро вырастал до качественного инженера. В команде с хорошо налаженными процессами обучение проходит действительно быстро. Да и джуны бывают разные — одни приходят после ВУЗа с горящими глазами, но ничего не умеют, а другие имеют за плечами семь лет опыта backend-а, просто только что переключились на мобильные приложения.
То есть джуниоров мы не боимся, но ориентируемся на ощущения команды — нужно ей это или нет.
Планирование, синхронизация, распределение задач
Много ли сил отнимает планирование и синхронизация разработчиков в рамках большой компании (пусть даже в маленьких командах)?
Филипп Уваров (Spotify): Это как раз плюс деления команд по продуктам, а не по функциям: мы занимаемся планированием только нашего небольшого продукта внутри компании и нам зачастую все равно, что там делают остальные миллион разработчиков.
Артем Ольков (Одноклассники): Здесь я могу рассказать только про нашу конкретную команду. У нас начало разработки, и это дает определенные поблажки — позволяет быть свободнее. На данный момент у нас есть только ежедневные 15-минутные митинги по текущему статусу и часовое закрытие предыдущего / планирование следующего спринта раз в неделю. Все остальное решается в личном порядке.
Максим Ефимов (Uber): В нашем случае — не очень большую. Быть может, раза в 1,5 — 2 больше, чем это занимало у меня, когда я работал на аутсорсе.
Правда, есть некоторые процессы в компании, вроде code review, которые тормозят разработку. Грубо говоря, пока какая-то команда, ответственная за свой кусок кода, не посмотрит твой коммит, может пройти просто какое-то время. Но я не думаю, что это относится к плате за синхронизацию. Это скорее о том, как настроена на низком уровне вся эта схема — кто кого ревьюит, как устроено ожидание и т.п.
Евгений Суворов (Avito): Проблему синхронизации мы изначально решили частыми релизами. В итоге сейчас сама синхронизация занимает немного. Все почти автоматизировано.
Нужно ли каким-то особенным образом распределять задачи, чтобы не страдало качество кода?
Филипп Уваров (Spotify): В больших командах имеет смысл распределение продукта по зонам ответственности. Таким образом, на задачах всегда будут люди, которые ответственно к ним подходят, потому что им же с этим жить потом. У них не меняется контекст, т.е. не возникает ситуации, когда все разработчики занимаются абсолютно всем (Петя здесь написал 10 строчек, чуть ниже Василий еще 5 дописал и в итоге получается месиво, которое потом невозможно поддерживать).
При этом если работаешь внутри маленького «продукта внутри продукта», ты должен более-менее понимать, как эта вся система работает от backend-а до клиента.
Евгений Суворов (Avito): Что касается качества, то лучше полагаться на тестирование и code review. Например, в моей команде сейчас ребята с бэкграундом мобильной разработки пилят микросервисы на backend-е на трех языках — Python, PHP, Go — которые должны выдерживать нагрузку Avito. Но коммуникации, автоматизация тестирования и т.п. обеспечивают на входе джуниоров, а на выходе — качественную штуку.
Можете ли вы вспомнить одну-две самые интересные задачи, с которыми сталкивалась ваша команда в последнее время?
Артем Ольков (Одноклассники): Как я уже сказал, мы делаем новый продукт. Самая интересная задача лично для меня, как для человека, который его ведет, — его планирование и проектирование: выстраивать архитектуру, продумывать, что у пользователя будет, а чего не будет, и как разработчикам с этим жить.
Евгений Суворов (Avito): Самым интересным, с чем мы сталкивались в мобильных приложениях, стала модуляризация — разбиение нашей кодовой базы на отдельные модули, которые могут развиваться самостоятельно, не мешая друг другу.
К примеру, просмотр объявления и экран доставки в принципе друг с другом не связаны. Но в кодовой базе они не были разделены, и когда разработчики что-то делали, их коллеги оказывались заблокированными. Мою команду как раз и собрали вокруг этой задачи разделения. Это заняло у нас около полугода и было интересно в первую очередь технически.
На backend-е микросервисы зародились давно, а в мобильных приложениях этот тренд появился совсем недавно — может год — два назад. И то в больших зарубежных командах, в России таких мало.
Технологический стек
Сталкивались ли вы в последнее время с каким-то революционным изменением технологического стека в своей компании / команде? И вообще как такие процессы у вас проходят?
Филипп Уваров (Spotify): У нас такое редко практикуется. Есть эксперименты по внедрению новых технологий, в частности, с переездом Gradle на Bazel или с Teamcity на нашу внутреннюю систему, но не более того. Я думаю, у нас невозможны такие революции по определению.
Максим Ефимов (Uber): До Uber-а у меня был такой опыт, но здесь это постоянно идущий процесс. Есть несколько людей, включая меня, кто выступает за Kotlin. Есть определенные вещи, с которыми нам нужно разобраться, как работать. Но в целом это возможно. Мы над этим сейчас работаем. Мы не должны сидеть и ждать, пока «самый главный разработчик» скажет: «Теперь вы пишите на Kotlin-е». Kotlin уже используется в части нашей кодовой базы, но все еще в процессе.
Да и в целом глобальные изменения в архитектуре имеют место быть, и они исходят в том числе и от нашей команды. Инициатива от людей, которые хотят решить какую-то свою личную боль, у нас вполне допустима. Если все делать правильно, то эти изменения принимаются.
Евгений Суворов (Avito): У нас есть две платформенные команды, которые пилят инструменты для внутреннего использования. Рост компании и модуляризация изменили подход этих команд к работе. Им пришлось много коммуницировать, чтобы понять, что же нужно конечным потребителям (разработчикам).
В плане технологических изменений у нас появился Technology Radar. Часто разработчики говорят: «Давайте внедрим эту штуку вместо той, которую мы 5 лет делаем, т.к. она морально устарела». Чтобы разобраться с этими предложениями, мы завели Technology Radar, в котором тому, у которого есть инициатива, приходится влезть в небольшую бюрократию, провести какое-то исследование, выразить в цифровых метриках, что нововведение нам что-то ускорит, а что-то замедлит, что есть какие-то риски относительно новой технологии. Это пройдет ревью от нескольких коллег и, если все хорошо, технологию применят. Правда, с Technology Radar предложений стало меньше.
Сложнее ли проводить такие реформы с ростом масштаба компании?
Максим Ефимов (Uber): Сложнее, но не намного. Допустим, в маленькой компании вас 10 человек и кто-то один хочет что-то поменять. Для этого ему нужно договориться с девятью людьми. Если же у вас 100 разработчиков, это не значит, что нужно будет договариваться с 99. Конечно, далеко не все будут в этом активно участвовать, это не так сложно, как могло бы быть.
Какие из последних технологий лично вам кажутся наиболее интересными с точки зрения применения в крупных командах (даже если они не работают в вашей компании)?
Евгений Суворов (Avito): Наверное, ключевое — это микросервисы, разделение по доменным областям, разбиение на команды, у которых свои приоритеты. В плане технологий — везде свои особенности.
Для больших команд нужно быть немного ретроградом и не лезть в альфа-бета версии инструментов, потому что ты никогда не знаешь, к чему это приведет.
Хотя бывают и исключения. Ввиду разбиения на модули у нас страдал Android-проект — IDE очень долго парсила модель проекта и помогли только новые early adopted preview версии. Там были экспериментальные галочки, с которыми все стало круче работать.
Филипп Уваров (Spotify): Я думаю, Kotlin — одна из супер-многообещающих вещей. Мне кажется, в скором времени все забудут про Java на Android, особенно если у Kotlin станет чуть получше с билдами и мы сможем на него перейти. Насколько я знаю, многие большие команды — вроде Facebook — долгое время противились Kotlin-у как раз потому, что там огромные проекты, которые и без этих проблем собираются три года, а с Kotlin будут собираться по шесть лет.
Из последнего лично мне кажется достаточно интересным Flutter.
Артем Ольков (Одноклассники): Я считаю, что лучший стек технологий в контексте разработки под iOS — родной, который предоставляет Apple. Дополнительные фреймворки зачастую не нужны. Есть интересные инструменты, но они построены очень крупными командами только под свои нужды. За пределами этих команд они зачастую добавляют только больше болей.
Есть пара очень интересных подходов, которые сейчас в тренде, и некоторые из них — вполне заслуженно. Хочется отметить конкретно Unidirectional Data Flow.
А что вы думаете о постепенном переходе на Swift?
Артем Ольков (Одноклассники): Это сложная тема. Сейчас мы начали новый проект и у нас все на Swift, но есть 150 строк на Objective-C, т.к. по определенным причинам мы не смогли с помощью Swift относительно лаконично сделать то, что нам было необходимо.
Если у вас все на Objective-C и вас он полностью устраивает, есть ли смысл переходить на Swift? У многих ребят, которых я знаю, перенос кодобазы на Swift — это именно HR-PR-история, потому что на рынке очень много новых разработчиков, которые просто не знают Objective-C и не хотят его изучать.
Евгений Суворов (Avito): Это как раз наш случай. Мы влезли в Swift в свое время и он замедлил нам время сборки. Вообще там было много минусов, но для нас один из ключевых поинтов был в том, что это такая хайповая штука, на которую мы сможем нанимать много разработчиков. В целом это себя оправдало в определенной степени. Swift сейчас развивается, но на Objective-C, возможно, было бы быстрее, удобнее и меньше проблем.
Идея долгосрочной поддержки может стать поводом для перехода (разработчиков в перспективе должно стать больше)?
Артем Ольков (Одноклассники): На этот вопрос не так просто ответить. Apple все еще находится в той позиции, когда они могут сказать, что Swift больше не поддерживается, и отдать его на развитие open source. Вероятность такого развития событий на сегодняшний день очень мала, но она не нулевая. Objective-C все еще получает улучшения.
Лично мое мнение (в Одноклассниках с ним могут и не согласиться) — если просто взять объективные факты — через пять-семь лет будут жить оба языка, а разработчикам нужно будет просто уметь работать и с тем, и с тем. Это не сложно, если понимать основные концепции. Зная один, выучить другой — уже не такая большая проблема. На сегодняшний день разработки под iOS — это больше не про знание языка, а про знание фреймворка, на котором ты работаешь.
Разработка и тестирование
Когда вы пишете тесты? TDD или уже после написания кода?
Филипп Уваров (Spotify): Если честно, с учетом запуска билдов на Android я не верю в то, что можно эффективно писать тесты до кода. Мы обычно пишем тесты параллельно, вместе с разработкой.
Артем Ольков (Одноклассники): Все зависит от того, про какие тесты мы говорим. Unit-тесты на совести команды разработчика.
Конкретно в нашей команде мы покрываем Unit-тестами только определенные слои, в которых нам нужно быть уверенными (проблемы на других слоях мы видим сразу). Если это интеграционные тесты (API, UI и т.д.) — за них уже отвечают тестировщики по мере появления задач.
Максим Ефимов (Uber):Я знаю, часть нашего бэкенда любит TDD, но среди мобильных разработчиков я таких людей не знаю. Нам важно, что получилось в итоге, а уж в какой последовательности человек это написал — его личное дело.
Евгений Суворов (Avito): Тестировщик присутствует на всем жизненном цикле фичи. В самом начале он помогает в постановке задачи, определяет функциональные требования, описывает приемочные тест-кейсы. UI- и unit-тесты пишет сам разработчик. В принципе, тестировщик тоже может их писать — у нас отдельная команда, которая занимается инструментом для написания UI-тестов.
Сами тесты можно писать независимо на любом этапе. На каком — маленькие команды решают самостоятельно. Они могут использовать или не использовать TDD.
В целом практика TDD не очень популярна. У нас в Android-сообществе есть человек, который это действительно практиковал и пытался найти единомышленников. Он как раз выступает на AppsConf 2018 с докладом про TDD.
Но в основном тесты пишут уже после того, как написали фичу.
Предусмотрены ли у вас какие-то стандарты покрытия?
Филипп Уваров (Spotify): Они могут быть разными, в зависимости от задачи. Но 100% покрытие бизнес-логики unit-тестами обязательно.
Максим Ефимов (Uber): У нас есть общее понимание того, что мы тесты делаем. Но никто нигде не говорит, какой должен быть процент покрытия. Команды это определяют сами.
А существует ли с вашей точки зрения какое-то «золотое» соотношение тестирования и разработки в проекте?
Филипп Уваров (Spotify): Я не смогу назвать идеальную пропорцию — все зависит от задачи.
Например, если мы делаем прототип чего-либо (proof of concept некой идеи), наверное, здесь тестирование будет стремиться к нулю. Если же мы делаем продукт, который будет использовать вся компания с высокой нагрузкой, то здесь на тестирование должно выделяться столько же времени, сколько и на разработку.
Евгений Суворов (Avito): У нас на самую большую команду, включающую четыре мобильных разработчика, есть два QA-инженера, которые тестируют не только мобильную часть, но и backend, frontend и все остальное. Но идеальное соотношение зависит от деталей организации процесса. Например, в моей платформенной команде шесть инженеров, но в принципе нет QA.
Предусмотрены ли у вас процедуры контроля качества кода внутри сообщества разработчиков?
Филипп Уваров (Spotify): Да, code review — одна из базовых проверок. Плюс у нас очень много проверок выполняется на CI: у нас подключено несколько инструментов для статического анализа кода, которые проверяют code style и все на свете — и об этом частично я буду рассказывать в своем докладе на AppsConf 2018.
Артем Ольков: В Одноклассниках есть pull request, есть контроль code style, который обеспечивают форматтеры; есть линтеры, которые выявляют простые ошибки. Есть сборки с тестами, правила ведения git-а. Все — очень маленькие шаги, направленные к одной великой цели: сделать так, чтоб кодовая база была хорошей.
Максим Ефимов (Uber): Code review — такая штука, которой избежать нельзя. Нельзя залить коммит, если его никто не посмотрел. Но процесс команды настраивают сами.
Евгений Суворов (Avito): У нас тоже предусмотрены code review-процессы через пулл-реквесты. Когда разработчик реализует новую фичу, контрибьютит код, он создает пул-реквест, который проходит серию автоматических проверок, в том числе, по качеству. Потом код смотрят соседи-разработчики.
Мы запустили этот процесс, как только в команде появился второй разработчик. По мере развития компании менялся и сам процесс. Вначале он был ручным, потом появилась автоматизация. Чуть позже мы увеличили количество апрувов с одного до четырех, иначе люди были не готовы принимать решения, влияющие на растущую кодовую базу («а вдруг я неправильно оценил?»). При разделении на многофункциональные команды, когда люди разбежались по разным юнитам, мы сбавили количество апрувов до двух.
По сути это некий регулируемый процесс. По мере роста компании кодовая база эволюционирует, повторяя структуру компании. Команда разбилась по юнитам, кодовую базу мы тоже начали модуляризировать, чтобы отдельные юниты не мешали друг другу и могли разрабатываться относительно независимо. Эта была долгая история. Естественно, это отразилось на пул-реквестах и code review. Параллельно мы стараемся автоматизировать то, что возможно.
Как часто имеет смысл выпускать релизы в проекте крупной компании?
Филипп Уваров (Spotify): Чем чаще, тем лучше.
Артем Ольков (Одноклассники): Это также очень сильно зависит от бизнеса, пользователей, модели распространения. К примеру, до «Одноклассников» я работал в «Акронисе». Там мобильное приложение — это компонент большого десктопного продукта, и его релизы были привязаны к релизам десктопа. У большого продукта было два больших релиза в год — летний и зимний — так исторически сложилось. Поэтому и мобильное приложение релизилось летом и зимой. В промежутках были только хотфиксы и какие-то быстрые исправления.
В Одноклассниках также все зависит от команды. Например, Android-разработчики у нас релизятся жестко каждую неделю.
Максим Ефимов (Uber): Мне кажется, то, как это организовано у нас — вполне разумно и удобно. У нас релизы идут на регулярной основе.
Есть так называемый build train, который отходит каждый понедельник. Если в него что-то не попало — ждет следующего релиза. Потому что иначе синхронизация будет очень дорогая.
Вообще это вопрос уровня бизнеса. У нас было две ситуации, в которых мы не подчинялись еженедельным релизам: это когда мы полностью переписали наше приложение для пассажиров и для водителей. Но в обычной жизни крупных изменений мы не делаем, удобнее регулярные релизы.
Евгений Суворов (Avito): Изначально релизы у нас были раз в месяц — это всего 12 релизов в год. Если ты не успел в определенный релиз сделать фичу, то ждешь еще месяц. В итоге люди пытались задерживать релизы, из-за этого тормозились другие команды и страдало качество (некоторые фичи доделывали в спешке, тяп-ляп).
В итоге мы тоже пришли к популярным релиз-трейнам, которые никого не ждут. Мы увеличили частоту релизов. Первой точкой были релизы раз в три недели. Вторая точка — раз в две недели. Сейчас мы на этой точке и стремимся сделать технически возможным релиз раз в неделю. Не факт, что мы будем пользоваться этой возможностью — есть вероятность, что пользователи не захотят так часто видеть обновления нашего приложения. И не факт, что разработчики успеют за неделю реализовать какой-то полноценный функционал. Поэтому пока две недели для нас выглядят оптимальными.
Но однозначно рекомендовать двухнедельный или недельный цикл всем разработчикам я не могу. Как упомянул коллега, есть продукты, у которых релизный цикл измеряется месяцами и это связано с очень тщательным тестированием функционала. Но там достаточно сложные процессы. А мы стараемся все упрощать. Нам удобнее высокая частота релизов, чтобы команды могли не думать о том, когда следующая дата, а просто делать необходимый функционал. В худшем случае через две недели он попадет в продакшн.
Крупные команды имеют и другие отличия. О деталях спикеры и их коллеги будут рассказывать на AppsConf 2018ApplsConf 2018. Там будут разговоры и об инструментах, и о принципах организации масштабных команд.
