Денис Неклюдов — Scaling architecture at Lyft

Похожие видео

Описание

Ближайшая конференция — Mobius 2020 Moscow. 11-14 ноября, Online. Отличный докладчик, которому есть чем поделиться по опыту работы в Lyft. Доклад посвящен проблемам, часто встречающимся при масштабировании архитектуры приложения. Lyft Android начиналось как простое приложение, разрабатываемое одним человеком. Сейчас это более 50 разработчиков, два приложения с общей кодовой базой и множество новых фич, выходящих каждую неделю. Требования изменились коренным образом, появились новые трудности. Доклад посвящен эволюции и кардинальным изменениям решений в корневой структуре нашей кодовой базы, текущему состоянию дел и проблемам, которые оно позволяет решить на нашем уровне. Слушатели научатся проектировать изначальную архитектуру приложения с прицелом на дальнейшее масштабирование и узнают, какие решения пригодятся для создания стабильного продукта.

Текстовая версия

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

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

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

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

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

Они начинают еще развивать все это растет развивается умножается потом еще нанимается команда и вы потом превращаетесь. Все в какой-нибудь лифт uber сбербанк все что угодно где 100 плюс разработчиков.

На 50 плюс на одной платформе и вот этот человек. Он не догадывался что все вы вылиться в огромное! Количество разработчиков а если бы он был готов к этому те ребята будущем?

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

У нас все кликается слишком быстро как! Я сказал архитектура заранее не может быть продумано на все 100 процентов какой бы вы гений не были скорее всего вам придется!

Изменять что-то в будущем но фундамент поставить который изменить.

Потом очень тяжело и а3 factory чем лучше он сразу. Построен тем менее болезни будет ваше будущее 5 тем который мы сегодня обсудим там не? Только архитектура понят дел что у нас за архитектура отвечает супермену?

Сегодня мы позовем всех супергероев из разных вселенных да простят меня фанат одессе или фанаты marvel поэтому называют супермен который! Говорит как вам делать архитектуру забил может разобраться только конечно же человек в костюме робота за сеть экспериментов самый быстрый супер герой?

У нас отвечает все это мы свяжем паутинка человека-паука и красивости отдадим на откуп и чудо-женщине сразу дадим слово чудо-женщине. Скорее всего в вашем приложении которое начинает.

Расти появляется много разных экранов и как эту проблему решают в больших компаниях. Потому что когда вы маленький стартап вы скорее всего не задумывайтесь об этом ну нарисовали кнопочку ли сделали стоковый material design! И все хорошо но когда у вас больше одного.

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

Реализовывать кнопки какой-нибудь банальный checkbox они могут. Реализовать по-разному ли радио батон и в таком случае вам на помощь приходит продукт: Сэндвич что такое правда плен вич у нас в лифт есть specs.

По тому какие элементы у нас в юо и вообще возможны и дизайнеры пользуются только согласованными элементами. Из определенных документы они не могут придумывать свои без общего согласований и внесения их в этот. Документ то же самое мы разработчики открываем скетч смотрим скетчи как они реализовали ту или иную кнопку они прям создают название и у нас это название?

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

Определено и прописано и это упрощает жизнь очень сильно? Это что касается дизайна спасибо чудо-женщине переходим.

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

Когда мы говорим там клин или еще что-то там in with что-нибудь это один из уровней абстракции на самом верхнем уровне съесть. Само приложение up она состоит из набора.

Фич соответственно каждой фича должна быть отключаем и подключаем назовем это каким-нибудь: Плагином каждый плагин каждая фича состоит из нескольких экранов или нескольких компонентов. Назовем это экранами соответственно съесть экраны между которым нужно переключать с помощью каких-то роутеров и еще красивые переходники.

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

По себе независимый лайк от экрана часто какой-то компонент набор там 3 кнопочек горизонтальной это отдельный независимый лоик которые подтягивают какие-то! Данные с каких-то репозитории она может быть перри использована поэтому выделим эти сущности еще в один слой и назовем его слоем компонентов и внутри этого компонента. Есть бизнес лойко это прям такой если вы в английский термин plumbing типа соединения труб связывания водопровода и то что мы делаем часть.

Особенно использую там какую-нибудь арык джаву мы делаем этот plumbing. Мы идем в репозитории тащим оттуда даны вот эту нас дан domain объект есть идем в api. Берем оттуда какую-то информацию связан с бизнес.

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

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

И view потом появились фрагменты мы стали делать много activities много фрагмент потом мы activity стали хоть одну и много view вот нас в первом: Ряду сидит константин константин сделал отличный доклад ссылочка про то почему сингл activity довольно таки правильный подход но и за последние. Годы я думаю вас нет сомнений что сингл activity это подход которому идут многие.

Энергий шин лайвли от google и общее течение мыслей и это решает много проблем и памяти. В android достаточно такая идея изначально была activity чтобы убивать при закрытии крана кусок памяти сейчас мы отлично сами ручками можем managed.

Память и activity часто порождает наоборот лики вместо. Того чтобы помогать работать с памятью дальше у нас есть задача нам нужно избегать зависимости от android фреймворк и не наследовать классы!

Из из детей почему я думаю не нужно. Объяснять но на всякий случай если нужно объяснять сейчас мы обсудим это логику из view мы переместим давайте назовем это viewcontroller? Как угодно можно назвать пусть будет viewcontroller и что там представляет не в лифте решили это таким.

Образом у нас есть какой-то viewcontroller в котором мы делаем файл view б.д. только это нами контролируемый.

Find you a и b и диане платформенной и у нас упрощенный жизненный. Цикл нас там есть он attache он detach: И ссылка на layout который нужно за им флэтить но мы не наследуем ся от view мы эту view просто.

Zion флейте внутри логике bass control or if a view байде сами потом сделан из за inflation и вьюшки. Но это не extend платформенного класса и когда нам нужно добавить жизненный цикл допустим там свет стоит.

Им просто добавить статью не будем городить портянку из кучи жизни циклов ну кто из вас реагирует реально на отдельный. Noun пауз отдельно реагирует на und стоп и отдельно он дестрой. Скорее всего вам нужно показать скрыть вам не нужно это сложная лойко.

Зачем усложнять себе жизнь кучей call back off и потом дебага всего это украсили жизни цикл значит несложно сменить реализацию в будущем. Будет не захотели платить виде захотели отвратить фрагмент пожалуйста за хотели перевести вообще на другую платформу пожалуйста теоретически. Вы можете единственно что вас останутся это завязано на название класса вьюшек типа textview ленивый?

Out и все остальное при этом этот слове?

Чуть-чуть легче тестировать меньше локоть методов и жизненных. Циклов и как я сказал жизнь цикл упрощен это вот первый идея который стоит в корне нашей в корне всего.

Что мы используем и это нам довольно таки сильно помогает при чем это не помогает нам тестировать над.

Живее вы знаете чтобы тестировать на локальной машине чтобы быстро тест запускался не диплом seo pack на устройство нам нужно как то это все тепло тысячу. Раз об этом сказали нужно написать из кейс президента. Что угодно куда-нибудь вынести бизнес-логику из слоя view что вообще не был зависимости на android фреймворк ну пожалуйста перенесем в ews кейсы займов сервису space.

Interact арман репозитории как угодно на заимку чеслав. Я все думаю о том что на следующую архитектуру если я буду какую-то! Придумывать вообще придумать новые слова потому что уже слишком стало много:

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

Во вью оставили только связку со слоя у там у нас есть вдруг вы не поняли! О чем и говорю viewcontroller в нем есть жизнь и цикл мы обратились к компьютер суда и нам данные you space?

Вернул нам данные входя в api и viewcontroller показал ну там в идеале еще 10 слоев расписать! Это отдельный доклад про amway как раз таки тут там там кто-то клиент кто-то не клин кто-то мвп значит per sale апеннин только? Как я считаю не сможете слушать меня может не слушать mvp идеальный фреймворк с точки зрения.

Понимания его разберет любой вася после чушка после колледжа просить! Это в воронежский термин шепот потому можно заменить на онлайн курс и это будет в принципе похоже. Ну серьёзно зачем тратить 5 лет по ту из можно онлайн-курсы.

Mobiusconf

Окончить легко реализовать очень сложно структурировать потому что он растет растет!

Растет freelander как ты сказал презентер презентер становится гигантский и такое месте получается. Такая лапша а мы таких клин хотели сделать не получилось но зато и самый главный недостаток нет единого состояния view вы не можете?

Дам пнуть в юшку и понять что сейчас на нее отображено весь экран. Mvvm пришел нам на помощь в нём есть единое состоянии мы можем узнать вот взять.

Иметь класс который отражает полностью единое состоянии view но нет идеального имплементации из data mining о том почему дата байден qplot. Мы уже миллион раз сказали если хотите. Миллион 1 заходите в чат подкаста или ловите меня здесь в переулке в темном мы обсудим чем дата banning.

Флаг и нет перехода из одного состояния в другое мы не можем за де бо жить нормально кто модифицирует о состоянии: View на этот случай нам приходит amway мол viewing.

And здесь даже автор этого термина есть наверно.

Он не пришел я по-русски разговоре ему не интересно но ханнеса вы можете. Поймать и он нам расскажет что такое мол view intent и intent не android intent и intent! Намерением переход состоянии там легко виден как одна в юшка перетекает из одного.

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

Холивара порождается с этим потому что в отличие от ввп очень.

Много идей как его реализовать и скорее всего вы будете. Реализовывать ручками про м я еще чуть-чуть с горечью нужно написать свой велосипед картинки как люди делают своего теперь я не нашёл. Нашёл как колес идет на английском терме нет invent home basic есть invent!

You will вот значит все создает свои колеса так и мы пишем в каждой команде свой amway фреймворк потому что что потому что он состоит. Из 60 строчек кода реальными from word можно писать в чат строк кода под свои нужды есть готовые велосипеды. Есть mobius от spotify есть amway карат буду тут ребят из bodum:

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

И ребята из flex и они вам расскажут про то как они используют рыб среда кс если вы хотите побольше. Послушай нас есть 80 79 выпуске android?

Лев подкаста где мы обсуждали как раз таки и эти библиотеки amway на русском mobius на английском вроде как разобрались с нижним слоем как сходить? Данные где послушать почитать как организовать что дальше следующий уровень компоненты:

Об этом уровне в компании 10 плюс человек 20 минус мало кто задумывается но когда вы разрастается до еще большим количеством переиспользовать. Просто экран недостаточно вы хотите вынести без слойку в меньшей части например вот вы хотите сделать. Аватар пользователя где есть аватар ими пользователь казалось бы абсолютно независимый.

Юнит он может сам сходить в репозитории пользователя затащить.

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

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

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

Этот репозиторий инжектит себя нижней список документов в список там информация пользователь и верхней это два отдельных тоже независимых внутри!

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

Здесь и получает что дочерней компонент получает зависимости ского по родителя.

Родитель прокинул все зависимости которые в этом скол при должны жить потому что нам достаточно.

Один раз создать репозиторий пользователя и передать?

Его на все верхние уровни и каждый!

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

Меня что-то там внизу на тоже изменить этот? Не должно происходить так что мы нажали на имя own business лайкой своей пошел.

И дернул что-то внизу соседнего компонента знает прямую ссылку на него нет у него должен? Быть просто общей репозитории в котором они изменили данные на которую оба подписан и тогда все будет хорошо. У вас а если они будут друг дружку дергать это будет лапша как происходит менеджмент этих компонентов этих перри используемых вьюшек назовем их просто они могут быть они.

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

Которых я не могу зафорсить обновлять я просто дерна feci флаг и он скроет аватарку пользователи! Еще она не будет inflate тиц и и не будет крышу пользователей если такое произошло на что-то?

Там поменялось мало ли или наша бизнес лойко решила что все завтра мы не должны показывать. Платежи это запрещено там регуляции нового вышли нельзя? Пальцами показывать его номер телефон допустим все манерный фичи флаг на сервере все пользователи позавчерашний версии тоже с этим столкнулись и все у них хорошо.

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

Цикл он включается и выключается и можно сходить в репозитории. Уже через юсб кейс или через интер actor и вот как угодно называйте и почти: Все из этого кроме самого view который мы нфл и этим можем инжектить в него зависимости что тоже:

Очень важно про inject мне сейчас будем отдельно разговаривать и что такое экран по сути экран по сути это тоже пустой компонент который injected.

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

Необычно дальше говорим про экрана активити как я сказал это просто фрейм layout ничего сверхестественного просто. Контейнер и в этот контейнер инжектит какие-то скрины screen! Это еще один frame layout который инжектит в этот frame layout и в него уже энжи птица вот эти вьюшки компоненты которые!

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

Случае если экран b знает об экране а потому что у нас повели если они лежат. В двух griddle модулях у нас появляется сверкал в пятницу у нас не могут. Они старта нуца что же делать мы создаем роутер мы выносим в уровень выше в горы для и здесь есть роутер который знает об apple метаться экрана а экране b.

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

Циклом всей фичи они с жизненным циклом каждого из экранов каждый раз пересоздавая.

Эти зависимости экраны не привязана к activity фрагментом или view могут быть заменены в подкапотное реализации на что угодно?

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

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

Сновном городе где самокатов нет нам нужно иметь возможность отключить одним фичи флагом велосипеды по всему приложению они там расположились повсюду и это должно!

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

Architecture

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

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

Спорили о мне говорил что sql lite это очень нужная вещь в приложении и он не доказал что ты woman да этот ком это! Реально очень важная вещь потому что там у них сложный оффлайн response и где надо сходить в базу данных реагировать куча событий. Пользователя расписание все тоски и показать их offline но ребят я уверен 50 процентов из вас делает online-only приложение где вам просто нужно сходить!

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

Модной рубчики там realm еще не дай бог затащить и поднимите! Руку кого есть у сложной базы данных да да да и скорее всего в этом тридцати! Или сорока процентах из поднятых рук можно было просто взять и сохранить все данные в как-то заступить на диск все реализовав просто.

Что и антон до джейсон string и в sharedpreferences кинуть скорее это кажется очень тупые не perform at но скорее. Всего это вам поможет и спасет вашу жизнь.

Чем будете с этим москве или мучиться все это типизировать все эти аннотации прописывать для грэма просто. Сохранили достали схема изменилось ну и фиг с ним сходили в сеть до стального.

И серьезно и это на масштаб никак на ваш не повлияет а вот как раз таки и миграции. Базы данных очень сильно усложнит вам жизнь мы тут немножко не сказали про rehau и у вас если вы делаете на колбе как ну вдруг в 2019:

Все делать на call back охтова скал был соответственно нужно супермен cause it's супермен зовёт бэтмена. Call бэтмен call back бэтмен к бэтмену нас конечно же арык java.

Куда же без нее но она поможет нам лучше поток данных убрать калмыки управлять трендами на что вам рассказывали java вы знаете с молоком матери впитали конечно?

Же вы сходили на сессии по гугла и которые прошли в этом году и уже знаете?

Что-то муку рутин появился flow что лак дату засунули только я не знаю везде. Она как зависимость идет и это тоже хорошая альтернатива но пока я на них смотрю.

Как вот на робина она рыдала как на бэтмена то есть может я изменю свое мнение. В будущем если мы работаем 40 пару трюков.

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

Качестве там don r или что нибудь: Такое и у вас трубу летает через весь поток? Через весь стрим и вы никак не контролируете это допустим сетевая ошибка произошла и вы просто качестве вы получаете этот трабл.

И реагировать на него принципе неплохо но на большом масштабе.

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

Кидать трубу в цепочку событий or их java сделайте класс очень простой ризал который имеет типизированный сакс сыр они могут. Быть любых типов вы соответственно типизировать и все ошибки и все ошибки и все позитивные.

Результаты он у вас выглядят куда ускакал.

Вот так резал который они и не соответственно любой риза любой секс с любой р.и. это сирт класс который. Бывает двух состояний либо либо он может быть либо саксэс.

Либо р и тогда в институте вы проверяете если не в цепочке пришел результат успешный показать одно если не успешный.

Другой что это вам помогает сделать это помогает вам всегда в реализации учитывать ошибочное состоянии?

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

Что нужно разбить приложение на модуле и и это тоже я вам скажу что разбиение это очень важно. Плюс еще важный вы спрашиваете в листьев 850 модуль или 900 уже я сбился честно за счет игры 2 модулей:

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

Написал означали этот модуль не проверит его и когда вы изменили там 770 модулей пока сесть люди которые.

Ответственны за эти модули не проверит вы свое странное. Изменение зачем вы так много изменили не получено.

Поэт есть там суперпользователь супер разработчики которые у нас помнят почти все модули типа кур архитектор то что они постоянно меняют там 20-30. Модулей за 1к мид и они имеют право такой изменять того что они уже работают. Семь лет в команде они знают все досконально.

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

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

Он отлично рассказывает как это помогает ускорить сборку и еще вот там есть build cache когда у вас. 700 модулей вы на своем компьютере эти 700 модулей не компилить а просто скачивать из сети xcom пиленые и только:

701 который изменился компилить у себя локально с памятью! Лучше работает отдельно доклад его я коментировать не буду просто знаете что гранул возможно!

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

Масштабам в принципе жизнь работать жизнь позволяет иногда для собирать 4 минут инкрементальный сборка 2 30 секунд у нас получается sbs вытянуть? Но это требует отдельного человека на сборке сидящего то есть так чтобы в стартапе сразу за ложились нет над эту с тут не получится.

За ложится сразу скорее всего вы потом к этому придете но если! Вы чувствую сборочка медленно пора уже задуматься об этом а проверки.

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

В пиаре view а еще как-то автоматизировать этот процесс об этом тоже мы говорили много раз continues in the grey. Шин проверки запуск тестов на каждый pr но о чем вам.

Не сказали детском саду о том что помимо.

Этих проверок нужно добавить еще проверки вор рингов если вы думаете а хрен с ним я проверю сегодня. Только ошибочное состоянии а в орган я за ignore the потом когда вы возвращаетесь на 10000 модулей и когда вы захотите на свои 100 человек выкатить.

Проверку всех вор мингов потому что они неспроста придумано они тоже учит людей писать: Красиво и нажмете разрешить и у вас упадет всей потому что что потому что а как от а3 factory теперь убрать миллионы этих вор! Рингов которые вы до этого ignore ли поэтому стартанули новый проект включите.

Самые жесткие проверки которые только может быть и это вам очень сильно поможет поеду я в этом на вертеле! Дтп в пензе song you are prone миллион проверка чем может больше.

На верните на верните не жалейте ваш сосед скорее всего сейчас майнит очередной крипто что-нибудь коэн и портят экологию? И ваши проверки не так сильно испортить?

Экологию зато очень сильно помогут вашему пищеварению ночью от того что ничего не упало и в вардинге.

Тоже часто предотвращают баги они просто делают код чище доклад с прошлых конференций которые я был парень: Из филе из а мой знакома рассказывает как настроить простой.

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

Bigteams

Мы начинали расти у нас уже не один продукт менеджер a7 продукт менеджеров и они все начинают. Конфликтовать горит я хочу чтобы моя фича первая была он говорит. Нет я хочу что моя фича было первое!

А тут еще bug fixes надо зарелизить а вы все заблокировано ждете пока каждая команда сделает все фичи как с этим борется? Большие команды паровозик используют паровозик с релизе коми называется? Фича tray на английском мне попросить прославить?

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

Изменений уже утром мы узнаем о том что она скатилась на наших сотрудников по всему миру и они об этом нас оповестят. Потом каждую неделю мы раскатываем бету все что есть мастере все идет в бету и если бы эта неделя прошла успешно. То эту бету без каких-либо дополнительных изменений или с критичными ход фиксами мы отправляем:

В релиз и так каждый неделю у нас новый релиз новый релиз и бета при последующего релиза который помогает.

Оттестировать и уверенно раз катить на следующий релиз это очень упрощает: Вам жизнь и уменьшает сроки тестирования потому что ваши тестировщики часто так увлекаются. Регрессом and kay что еще нами могут?

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

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

Ребят на большом масштабе так не прокатит шанс. Был момент ваше все к сожалению или к счастью решать. Вам что такое транг bass development вдруг это когда каждый из вас вот всех здесь сидящих мы работаем с вами.

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

Свечу и такой тип и сто пятьсот миллионов строк. В пиаре что с этим делать когда он от reviewed ну и конечно же он такой scroll in hindi scroll включил пролистал и за правду что у них. Нет у него 700 еще релизов а так вы по 300 строчек комитетом по 500 строчек.

И все это ревью вице теми кто ответствен за эти модули и всегда льете в мастера но вы скажите. Как так можно лить мастер если мой офис ещё не готова как я в мастер засуну так вы закройте: Эту фичу фича флагом как закрыть я расскажу на следующих.

Слайдах про сеть сейчас был доклад про domain дэвин development. И мы тоже придерживаемся domain in development.

В том что у нас есть домен есть api вообще-то как внутри. Реализовано в приложении это как реализовано api нас не сильно волнует это не сильно связаны?

Сущности потому что любой response сети мы трансформируем свой собственный объект и внутри без слойки используем по-своему и это помогает: Нам потому что например был случай когда api отдавала. На один запрос гигантский response огромный и с ним был не понятно что делать мы вопросы?

Сразу же разбили на отдельные сущности и с этими сущностями работали место чтобы работать этим гигантским объектом и когда api решила что наконец на до зари factory:

Намного response of мы уже были готовы к этому и просто сменили мапперы. Этих объектов например и сети вам приходит такой объект как секс сыр и сразу. Эти поля оба в одном response и так вы разбейте на 2 на секс с и на r объекты из прокидывать.

Их через 103 zalt который я вам показывал соответственно вас результате получится мабтера был срезал. Там который может быть либо такое либо такой тип и вы будете зависеть от того что там и сети приходит придуманный пример но идея тоже. Фича табло полимеру кто в приложении своих использовать уже вовсю фичи тофу и знаком красавчики всем пяти фон раздаю воздушные?

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

Это обсуждается нами тапах высекли проще говоря у вас есть фича и вы везде проверяете если он если и можно включить покажу итак вы пишете код. И в мир жить в мастер просто выключив эту фичу и она пользователю не будет видно конечно найдется скорее: Всего какой-то research are который за research it'sa депозит ваше приложение и увидит что самокат ими но ещё не показали пользователю ну да есть такой down.

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

Это вам очень поможет плюс вы можете отключать эту фичу и включать сервера в любой момент времени.

Дальше еще маленький такая фиговина который о силе он спасет жизнь. Если вы заложите на ней в начале она нам очень поможет. Сделать и к стану layoutinflater который перед тем как тянуть строки сервака про стойки стянуть is our . strings он еще сходит в map и посмотрит нет!

Ли под этот индификатор у вас еще какого-то а верой да потому что вы сервера можете подтянуть умирает на любой строковый ресурс и показать пользователю print флейте лейаута уже. Заказа украденную строку как это вам поможет пришел продакт менеджер. Говорит цена изменилась во что за хардкоре лице ну вы с ума сошли но если вдруг такое прошу или срочно тайтл переименовать мы переименовали.

У нас теперь пассажира называется не passenger а райдеров? Потому что они могут быть не только passenger на такси но они теперь raider то что нас велосипеды. И скутера появились и вы вместо того чтобы релизе новое приложение.

Раскатывать его вот эти все бед и релизы все так далее вы просто. Берете на сервер идете делать write и теперь. У вас все строки у всех пользователей перезагружены.

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

Схема api часто все мы с вами забываем и забиваем потому что нас вот он сервер девелопер: Сидит за соседним столом мы можем с ним поговорить скатилась то мне надо изменить описку изменить?

Ее из них сидит моему кучу пойдем.

Покурим я тебе расскажу чем мы поменяли и как бы типично development на большой масштабе к сожалению. Когда он в сиэтле вы в нью-йорке и из них сан-франциско? Сложнее синхронизироваться еще вас 50 и где-то:

Вы поменяли и отследить эти изменения а еще у вас есть клиент на вебе еще есть клиент. На каком экспериментально флаттере ще что-нибудь и сложность игры поэтому! Нужно сделать схему берем swagger или что-нибудь похожее и пишем то схема:

Пи и она сама генерится эти вызовы api на все клиенты красота просто красотище потому? Что как мне надоел раньше писать вот этот retrofit. Описать схема описать до точки теперь я пишу только mapper в нашу логику руками остальное все грузится сети.

Красота и вот пожалуйста котлин файлы шмот линда дарт свифт все что угодно за вас swagger зинерит. Но если вы пойдете дальше вам покажет что swagger недостаточно вы напишете в jar писи протокол есть у нас тут евгений!

Сатурн в которой то пейджер писи нету но я его доклад я его доклад прикрепил и uber еще.

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

Сделать завтра но это то что вы должны. Держать в голове что скорее всего сетевой слой должен.

Быть максимально далеко от бизнес-логики потому что его будете переписывать миллиард раз на более. Эффективной реализации дальше связывающий слой пены section.

Есть кто-то кто считает что ты понижаешь не нужен не стесняйтесь спасибо спасибо это подставные! Вы им не верьте они просто троллят и конечно же есть простое такая женщина там dagger.

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

Мы тоже думали что dagger один в принципе достаточно и dagger второе. Нам не нужно но когда мы начали ловить в ран тайме потому что в compal во время компиляции мы не проверяем целостность графа!

И начали ловить что какая зависимость не удовлетворена мы буквально что нет все таки придется мигрировать на эту огромную тварь которую не:

Поднять и не контролировать поэтому dagger2 как единственный нормальной реализации которую в compal тайме говорит разработчику. Ты забыл реализовать эту зависимость что ты тут не интерфейс суешь без реализации к сожалению нужно с ним работать. Без него никуда но пожалуйста не использовать sap компоненты а вы зря смеетесь.

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

1 а потом решили всеми на ней dagger2 а потом решили мигрирует на dagger2 а там во что-то был reflection? Bass и все прекрасные все зависимости сами как-то генерировались. И вот это gradle не знал о том что этот модуль может генерировать эту зависимость.

У себя она генерировалось благодаря тому что в runtime и все это происходило! Они во время компиляции и поэтому такие сейчас.

Я мигрируют на dagger2 думаю я все распутаю. Это лапша она очень легко распутывается и вы думаете что мы все распутали все красота?

Показатель на самом деле вот так вот вы будете выглядеть спустя полгода и пытаясь это распутать? И мы в лифт очень много инвестируем и тратим всеми 7 с человеком чтобы до распутать наша зависимость не доводите:

До греха делайте сразу хорошо на втором до гири зачем вам быть в лапши дальше отошли?

От дагера сейчас мне просто всегда когда подыгрываю немножко: Больно сейчас сейчас пульса становится все воспоминание идите. A dagger android это мы с него мы в него не влезали.

Чтобы у нас это болела сейчас сейчас я отдохну.

Мы тоже передохните это как фильм ужасов посмотреть про лагерь: Вспомнить все возвращаемся значит нам нужно вот допустим вы делаете.

Приложение по социальную сеть и вы понимаете что ваш messenger можно выделить в отдельное приложение так он будет отдельный юнитам отдельные разработчики будут у него.

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

И доставку не знаю конфет детям на детский праздник я уверен это отдельно.

Прим команда из 20 человек это и все это встроено в одно приложение если вы работаете вас есть тут кто работает в азии.

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

Него разделение на приложить на а раздельные а пока очень хорошие задачей это мы вместе. С этим столкнулись у нас был passenger and driver одним приложением потом разделили отдельно приложение. На 2 а пока и стала жить легче птамушта рта пока уменьшу!

Старт приложений уменьшился уменьшились зависимости при этом мы по-прежнему.

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

Для каких-то маленьких различий типы ресурсов используйте flower но если вы хотите двери бизнес лойко разделить на flowers ошибка.

Потому что все что закрыта флэйва рам студии не видят и при факторинге никак: Не реагирует на это вот разделились на два приложения каждое приложение имеет у нас в лифт отдельно applications.

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

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

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

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

Что например сертификат безопасности устарел а вас там куча пользователей или api изменилась настолько критично. Что старая пи никто не хочет поддержки или вообще бизнес говорит вот та фичи которая.

У нас была она не подходит она не должна существовать и что с ним делать. Мы просто берем и форсен пользователя обновиться на новую версию. Но если мы не сделали механизм force апдейтов!

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

Нам что сказали что google play нападает?

Теперь работает и теперь google play может. Вам предоставить аппель который вы сходите который за вас сам сходит в google!

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

Просто вы реализуете и жизнь станет легче мы подходим концу на самом деле полезные: И вредные советы одни из них люда подходит концу структура команды как разделить команду. Как мы это сделали я просто расскажу я не знаю.

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

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

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

Они вот такие вот которые за оптимизировать перформанс вьюшек красиво реализовать. В юшки сделать плавными анимации и вот у них отдельная! Команда где они получают удовольствие от этого процесса и предоставлять для нас уже готовы.

Реализованные компоненты ну и все остальные конечно фичи devil developers и это не просто 1908 про них отдельно еще есть чувак который занимается инфраструктурой он нанял недавно коллегу. Себе теперь их двое и они занимаются отдельно бил системой отдельно помогают настроить себя отдельно помогают ускорить сборку отдельно помогают настроить тестирование. Процесс где-то реально отдельная команда которую вам придется выделить когда вы достигнуть определенного.

Масштаба плюс ко всему фича developer это не кучка. А это отдельный кросс функциональной команды что такой курс национальной команды от когда в команде есть менеджер есть продуктовый.

Человек который придумывает фичи есть android ios тестировщик дизайнер бэкенд аналитик.

И m-elle инженер и и server side of кучка и вот вы реализуете определенную фичу и не и синхронизируйте особо с остальными! Потом вас какой то есть общий сын кафе чем но вы не зависимо от остальных ваших фичи. Работает и вот когда вы доходите до вот этого масштаба вообще.

Строго говоря ваше приложение она становится такой отдельная? Система ну никак приложи как много приложений внутри одного хотя казалось бы мы не хотим быть супер. А пом но при этом все равно как не крути вы настолько не пересекаетесь друг дружкой и только с архитектурой как-то сталкиваетесь.

Что на маленьком масштабе это представить сложно кажется ее знаю все приложение но когда масштаб там.

Все совсем по-другому и мы сейчас с вами в кулуарах поговорим об этом итог итог итог итог мы подходим к концу заранее:

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

Успешными и ты заплатил ни опционы потому что я сотрудник номер 3 а нас уже сорок четыре тысячи. Сотрудников когда мы станем успешными и а стану миллионером давай сразу решим этом и вы поймёте. Приоритеты если у вас реально приоритет на большой рост и вы хотите стать новым гигантским социальном приложением магазинам или крипто супер кошельком чем угодно.

То вы старайтесь предугадать и за ложится на этот раз на этот масштаб архитектуры практике не всегда готовы не всегда! Возможно вы сделать прямо на будущий но фундамент думайте об этом как о фундаменте. Если вы сделаете на костылях фундаменту скорее всего это все при дуновении ветра миллиона пользователей развалятся и общаетесь сотрудниками больших продуктов которые.

Уже этих проблем наелись это ваши логике от кораблей.

Очень сильно сохранит и зачем вам шрамы посреди.

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

Посчитал что у меня была слишком банально и у неё есть! Гораздо лучше мнение или просто есть дополнительный совет дополнить меня пожалуйста поднимите. Руку я очень жду ваше мнение расскажите всему залу об этом мнении серьезно:

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

Дополнительные материалы

Хештеги:
Поделиться или сохранить к себе:
Твой успех