Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
ОЧЕНЬ плохо расписан git flow.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Пример: хочу в БД хранить массив JSON'ов вместо одного JSON'а, аналогичные конструкции записывать в БД, это используют 20 потребителей через вычитку из БД.
В микросервисах обычно не позволяют кому-попало в базу лезть своими руками немытыми.
У сервиса есть контракт с его потребителем, и он должен его соблюдать. способ хранения данных - часть внутренней кухни сервиса.
Как делать хотфикс, если функционал из убежавшего вперед мастера еще не должен быть выпущен? Аналогично Git Flow?
тут есть несколько разных способов.
делать по аналогии с git-flow
идти в сторону ci\cd: фиксить мастер и катить уже его.
Второй подход больше отражает суть TBD - которая приводит нас к чистому мастеру, готовому к релизу в любой момент. И возможность быстро доставлять ценность клиенту
почему одни и те же фичи в TBD — короткоживущие, добавляющие TTM, а в gitflow — порождающие тонны конфликтов?
Далеко не все фичи это 1-3 дня разработки. Как правило времени на реализацию и тестирование тратится существенно больше. (хот-фиксы и перекрашивание кнопок не берем)
Потому - подход TBD позволяет выкатить фичу в прод под флагом. И застолбить под нее место. Обозначить интерфейсы. Другие команды будут видеть код, что под фича-флагами. Будут понимать - что разработка в этом месте ведется и будут это учитывать.
В случае-же git-flow, чем дольше фича не попадает в master будет находится тем дольше и чаще надо будет решать конфликты. Тем больше шансов что появится костыльная дублирующая реализация.
Плюс code review в gitflow легче
Тут термин "легче" штука относительная. И про это я в статье тоже писал.
Отревьювить и дать грамотный фидбек на 50 строк изменений проще и быстрее, чем при 1000 строк изменений.
Но при этом требуется держать контекст предыдущих итераций.
Мое опыт говорит, что опытный разработчик имеющий понимание фичи - достаточно легко справится с поддержанием контекста от итерации к итерации. При этом времени на ревью итерации он тратить сильно не много (итерация маленькая) Ревью будет более качественным (мы когда-то даже статистику строили - зависимость времени ревью от размера PR)
А вот для новичка держать контекст прошлой итерации очень сложно, потому - ему поще делать фичу целиком
Ну и если кратко - если ты позвонил на подменный номер, и позвонишь на него-же завтра - ты точно так-же дозвонишься до продавца. (при условии что оба звонка у тебя идут с одного и того-же телефона)
Если звонил вчера со своего телефона а сегодня перезваниваешь с телефона жены - есть риск не дозвонится.
Лишь подсвечиваю - что мест, которым человек передает свои перс данные море. И та-же запись к парикмахеру через интернет - это тонна метрик + ваш телефон + частота визитов + геолокация + данные с карточки при оплате. Многие сетевые заведения так делают.
И шанс утечки\продажи ваших данных от парикмахера мне видится более высоким, чем у того-же Авито.
Поэтому - оценивая риски, оценивать стоит комплексно. К примеру - какой смысл переживать о том, что из Авито данные утекут, когда они утекают из Я.Еды, или когда паспорт утекает из чатов Тинкофф.
Грубо-говоря - единственный способ предотвратить утечку данных - это не отдавать их вообще никому.
Но в современном обществе это уже выглядит невозможным (пример банального парикмахера выше - он уже знает ТУЧУ всего)
Но это сейчас общий разговор.
Касательно подменного номера:
запись переговоров - ... не является необходимым для площадки
Это необходимо, для поднятия уровня безопасности на площадке.
Подменный номер используем, чтобы убрать мошеннические звонки продавцам. По нашим исследованиям - их все еще очень много. И это один из способов защиты продавцов.
почему вы для всех лотов не оставляете только вариант продажи через Авито-доставку
Такой объем сделок в текущем виде логистика не потянет, вроде это лежит на поверхности.
Мы так-же понимаем, что основная аудитория Авито - это частник-частник, и цели ликвидировать это направление у нас нет (зачем оно нам). Но постараться сделать его цивилизованее и безопаснее мы хотим.
Аналогия такая - был рынок, куда приходили покупатели и продавцы. Пока рынок был небольшим - все было в порядке.
Когда рынок стал огромным - там стали сплошь и рядом сновать кидалы, продавать паль, и откровенно обманывать.
На рынке появились к примеру контрольные весы (и тут-же часть людей начало жаловаться - что у них есть они и так есть, и контрольные не нужны, и вообще - весы только про вес, и объему не помогают)
На рынке появились централизованная служба носильщиков (вместо шныряющих сомнительных людей, что зачастую брали деньги и товар, и свалилвали в закат), и рекомендации пользоваться именно ими (с запретом публично предлагать такие услуги на рынке) и снова часть людей начало жаловаться - что цена то на службу носильщиков стала повыше, и вообще они не нужны. Правда теперь случае когда носильщик убегает с товаром стало в 1000 раз меньше.
итд
Все это делает рынок цивилизованее, спокойнее и безопаснее.
И Важно сказать - что Авито не хочет стрелять себе в ногу. Все изменения тщательно проверяют на цифрах, данных, общих реакциях пользователей. И пока динамика только положительная.
Можно считать - любые данные предоставленные в сеть заранее утекшими.
Такой подход имеет место быть, и знаю людей кто всерьез так и делает.
Можно пойти дальше - отказаться от услуг мобильного телефона, мессенджеров, соц-сетей, банков, магазинов в сети, служб доставок, скидочных карт магазинов и не ездить на машине. Везде есть связь фотки, паспорта, карточки или телефона.
Вы правы. Оптимизацией фронт-части, уменьшение TTFB и прочие метрики - это важная составляющая оптимизации.
И этим нужно заниматься (мы сейчас именно этому способу оптимизации уделяем меньше времени чем хотелось бы)
Но статья вовсе не про это. Картинки, подготовка рекомендаций - это отдельная задача, важная для того, чтобы скрол главной был гладеньким.
Статья о том, что даже решение уровня "закидаем железом" перестало быть достаточно эффективным.
Все верно. спасибо!
Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Жаль ни разу не находил, было бы здорово!
Ну и тут понятно - что есть пачка трейдоф.
К примеру TBD не очень подходит под классический релизный цикл: c отгрузкой инкремента раз в пол года
Или к примеру TBD не очень удобен для опенсорс продуктов (не без исключений. лишь большая или меньшая степень удобства с подходом)
ничего не понял.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Вопрос достаточно сложный, на самом деле.
Я исхожу из предпосылок - что все сервисы имеют свои НЕ СВЯЗАННЫЕ друг с другом тогглы.
Такой подход заставляет каждый раз внутри сервиса думать - что делать если фича включена и выключена.
Так как микросервисы не большие по своей природе - тогглов там не бывает много.
Ну а дальше отталкиваемя от того - что за тоггл. Тоггл новой фичи, нужно включить в dev-середе, и прогнать цикл тестирования
Я наверное не до конца понимаю проблему.
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Немного подушню за математику: не 200 интераций по 50 строк а 20 итераций по 50 строк.
эти итерации делаешь быстро. Учитывая современные команды и гибкие методологии разработки - это только в плюс.
Каждый выбирает фломастер на свой вкус, как говорится. Главное что красный вкуснее=)
Не было задачи показать что git flow - сакс. Но он действительно хуже подходит по современные процессы с ci\cd и гибкими методологиям.
Но при этом git flow хорошо ложится на более медленные циклы разработки, вида классической отгрузки продукта по версиям
В микросервисах обычно не позволяют кому-попало в базу лезть своими руками немытыми.
У сервиса есть контракт с его потребителем, и он должен его соблюдать. способ хранения данных - часть внутренней кухни сервиса.
тут есть несколько разных способов.
делать по аналогии с git-flow
идти в сторону ci\cd: фиксить мастер и катить уже его.
Второй подход больше отражает суть TBD - которая приводит нас к чистому мастеру, готовому к релизу в любой момент. И возможность быстро доставлять ценность клиенту
За одно это с меня пиво!
Ух. Спасибо за комент. Мне прямо нравится!
Далеко не все фичи это 1-3 дня разработки. Как правило времени на реализацию и тестирование тратится существенно больше. (хот-фиксы и перекрашивание кнопок не берем)
Потому - подход TBD позволяет выкатить фичу в прод под флагом. И застолбить под нее место. Обозначить интерфейсы. Другие команды будут видеть код, что под фича-флагами. Будут понимать - что разработка в этом месте ведется и будут это учитывать.
В случае-же git-flow, чем дольше фича не попадает в master будет находится тем дольше и чаще надо будет решать конфликты. Тем больше шансов что появится костыльная дублирующая реализация.
Тут термин "легче" штука относительная. И про это я в статье тоже писал.
Отревьювить и дать грамотный фидбек на 50 строк изменений проще и быстрее, чем при 1000 строк изменений.
Но при этом требуется держать контекст предыдущих итераций.
Мое опыт говорит, что опытный разработчик имеющий понимание фичи - достаточно легко справится с поддержанием контекста от итерации к итерации. При этом времени на ревью итерации он тратить сильно не много (итерация маленькая) Ревью будет более качественным (мы когда-то даже статистику строили - зависимость времени ревью от размера PR)
А вот для новичка держать контекст прошлой итерации очень сложно, потому - ему поще делать фичу целиком
Согласный!
Больше скажу - факторов влияющих на скорость просто огромное количество.
Но отделить импакт каждого из этих факторов крайне-сложно.
Но что могу точно сказать - влияние именно TBD достаточно большое, и без него результаты точно были бы хуже.
Начал отвечать, но осознал, что понятие "конфликт фич" можно понимать по-разному.
Будет здорово, если уточнишь
Спасибо. Поправлю. Изначально использовал TBD акроним, но сказали не понятно_)
Привет.
Ты путаешь звонки через приложение и звонки через защищенный номер
Подробнее про это мы писали в этой статье https://habr.com/ru/company/avito/blog/665436/
Ну и если кратко - если ты позвонил на подменный номер, и позвонишь на него-же завтра - ты точно так-же дозвонишься до продавца. (при условии что оба звонка у тебя идут с одного и того-же телефона)
Если звонил вчера со своего телефона а сегодня перезваниваешь с телефона жены - есть риск не дозвонится.
какой период а оценки? как часто можно промоутится и менять грейды?
Есть ли какой-то механизм балансировки - за неверно поднятый грейд?
Вообще? или только в первый раз?
оценка - это средне-арифметическое между мнением тимлида и самооценкой?
или результат торга, если оценка не сошлась
и в свете этого интересно
Как быть, если мнение инженера и тим-лида не сошлось. Более того - оно падает
Поверьте - сарказма нет.
Лишь подсвечиваю - что мест, которым человек передает свои перс данные море. И та-же запись к парикмахеру через интернет - это тонна метрик + ваш телефон + частота визитов + геолокация + данные с карточки при оплате. Многие сетевые заведения так делают.
И шанс утечки\продажи ваших данных от парикмахера мне видится более высоким, чем у того-же Авито.
Поэтому - оценивая риски, оценивать стоит комплексно. К примеру - какой смысл переживать о том, что из Авито данные утекут, когда они утекают из Я.Еды, или когда паспорт утекает из чатов Тинкофф.
Грубо-говоря - единственный способ предотвратить утечку данных - это не отдавать их вообще никому.
Но в современном обществе это уже выглядит невозможным (пример банального парикмахера выше - он уже знает ТУЧУ всего)
Но это сейчас общий разговор.
Касательно подменного номера:
Это необходимо, для поднятия уровня безопасности на площадке.
Подменный номер используем, чтобы убрать мошеннические звонки продавцам. По нашим исследованиям - их все еще очень много. И это один из способов защиты продавцов.
Какой аргумент позволит вам убедится, что Авито, добавляя подменный номер, фокусируется именно на безопасности?
Такой объем сделок в текущем виде логистика не потянет, вроде это лежит на поверхности.
Мы так-же понимаем, что основная аудитория Авито - это частник-частник, и цели ликвидировать это направление у нас нет (зачем оно нам). Но постараться сделать его цивилизованее и безопаснее мы хотим.
Аналогия такая - был рынок, куда приходили покупатели и продавцы. Пока рынок был небольшим - все было в порядке.
Когда рынок стал огромным - там стали сплошь и рядом сновать кидалы, продавать паль, и откровенно обманывать.
На рынке появились к примеру контрольные весы (и тут-же часть людей начало жаловаться - что у них есть они и так есть, и контрольные не нужны, и вообще - весы только про вес, и объему не помогают)
На рынке появились централизованная служба носильщиков (вместо шныряющих сомнительных людей, что зачастую брали деньги и товар, и свалилвали в закат), и рекомендации пользоваться именно ими (с запретом публично предлагать такие услуги на рынке) и снова часть людей начало жаловаться - что цена то на службу носильщиков стала повыше, и вообще они не нужны. Правда теперь случае когда носильщик убегает с товаром стало в 1000 раз меньше.
итд
Все это делает рынок цивилизованее, спокойнее и безопаснее.
И Важно сказать - что Авито не хочет стрелять себе в ногу. Все изменения тщательно проверяют на цифрах, данных, общих реакциях пользователей. И пока динамика только положительная.
Можно считать - любые данные предоставленные в сеть заранее утекшими.
Такой подход имеет место быть, и знаю людей кто всерьез так и делает.
Можно пойти дальше - отказаться от услуг мобильного телефона, мессенджеров, соц-сетей, банков, магазинов в сети, служб доставок, скидочных карт магазинов и не ездить на машине. Везде есть связь фотки, паспорта, карточки или телефона.
Но такой подход уже пахнет цифровым луддизмом =(