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

bigteams, architecture, mobiusconf

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

Описание

Ближайшая конференция — 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 и это просто. Типизировать класс по сути у вас должен быть какая-то айдишник вот сам скрины такой класс как как и нам можете иметь и нам со всеми экранами.

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

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

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

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

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

Спорили о мне говорил что 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 правда на английском языке доклад дальше про сборку: Значит мы включили вардинге все хорошо но у нас так много фич.

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

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

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

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

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

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

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

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

Хештеги:
Поделиться или сохранить к себе:
Моя Мотивация