Комментарии 9
Даже не хочу читать статью, учитывая "качество" продукта, который мы получили после объединения яндекс такси и убера.
Думал увидеть шаги, которые начинаются до написания кода или берётся тикет и в бой?
Для тэстовых окружений не встречались с проблемой многих желающих на одно окружение?
Расскажите про дальнейшую судьбу для отключаемой функциональности, тк если не чистить, то я себе представляют скатывание в if лапшу, если чистить всё, то встаёт вопрос о скорости решения отложенных деградаций?
Также интересует подход к обеспечению обратной совместимости или получается никогда таких изменений не вносить вообще?
Как накатывается миграция на prestable и stable, то есть это отдельные базы или миграция сразу для обоих применяется?
Для тэстовых окружений не встречались с проблемой многих желающих на одно окружение?
Встречались, поэтому и сделали карманное окружение, где такой проблемы нет
Расскажите про дальнейшую судьбу для отключаемой функциональности
Её бывает два вида
1) та, которую включают, и потом больше никогда не выключает. Такую стараемся чистить, конечно.
2) та, которую можно отключить для контролируемой деградации, она так и остается.
Если пытаться не вклинивать переключатели непосредственно в бизнес логику, а переключать стратегии, то особо страшной лапши не получается.
Также интересует подход к обеспечению обратной совместимости
Клиентские протоколы не ломаем почти никогда. Это довольно больно, зато позволяет поддерживать старые клиенты на системах, для которых уже не выпускается обновлений приложений. При этом конечно следим за статистикой обращений к АПИ, если видим, что обращений нет, то оно становится кандидатом на выпиливание. Прямо сейчас например мы поддерживаем одно из старых АПИ, по которому к нам поступает 1 заказ в час)
Как накатывается миграция на prestable и stable
Там нет миграции. Это один и тот же контур по данным. prestable — просто часть stable. Базы общие, потоки данных общие.
Встречались, поэтому и сделали карманное окружение, где такой проблемы нет
То есть в основном не нужно чтобы быстро поднятое окружение покрывало все части сервиса, я так понимаю в этом случае 3th party api либо просто мокаются, либо настраиваются ручками?
Да. Это просто позволяет сильно разгрузить настоящие тестовые окружения, которые становится проще использовать для задач, где без них сложно обойтись
На настоящих окружениях мы умеем мержить ПРы разных разработчиков и запускать всё вместе, то есть прям острой конкуренции за общие окружения нет. Но понятно, что когда на них начинают выкатывать код все разработчики сразу, то в итоге окружение просто перестает работать, и никто не может понять почему. А если там только те задачи, которым окружения необходимо для тестирования интеграции, то в целом оно работает.
Я многое повидал, работая с API разных поставщиков, но API Яндекс Такси, а точнее как с ним работа организована по поддержке корпоративных(!) пользователей — это просто дно какое-то. Я очень редко пишу куда-то, но сейчас уже просто накипело! Ниже кратко о той всей боли, которую мы испытываем на протяжении двух лет внедрения Яндекс Такси!
1) Нет тестового API от слова совсем! Да, Яндекс предлагает 10(!) тестовых бесплатных поездок для того, чтобы отладить программу. Есть среди вас гуру тестинга, которым хватит такого числа поездок, чтобы отладить поиск, бронирование, отмену такси в условиях разных ситуаций, после внесения правок программистами? Сделать автоматические тесты на покрытие функционала API? Можно об этом забыть. Доходит до смешного (и одновременно грустного), что приходится гонять реальных таксистов по городу, чтобы отладить код.
2) Вы вот пишите про то, что стараетесь не сломать ничего и поддерживать обратную совместимость, но это не так. Сломать что-то в боевом API — это излюбленная забава команды разработки Яндекс Такси. У вас задекларирована версионность в API, но что же вы ей не пользуетесь? С 2019 года и до сих пор у вас версия 1.0, но в ней вы спокойно меняете реализации уже существующих методов.
3) А сообщить заранее, что в API грядут изменения — это выше собственного достоинства! Изменения происходят внезапно, без предупреждения. На просьбы информировать об этом и присылать заранее документацию по новому API, указывать время ввода в строй новых изменений — только отписки, что это сделать не возможно(!), а если мы хотим получить новую документацию надо написать самим с просьбой её прислать. А узнать, что что-то изменилось я должен из своего хрустального шара, видимо? В статье вы пишите как классно вы мокаете API сторонних поставщиков. Да, я тоже могу так сделать с вашим, но когда вы в очередной раз втихомолку его поменяете, все мои тесты удачно промолчат о ваших изменениях, работая на старых моках. И узнаю я о том, что API сломалось от клиентов.
4) Нет нормальной службы поддержки. Ладно, мы уже не надеемся на контакты программистов, другие поставщики тоже не очень любят переключать на них. Но вы считаете, что это нормально писать технические вопросы менеджеру по продажам, который потом неделю обрабатывает письмо, а любимая отписка: «я направила запрос в отдел разработки, они очень заняты и ответят через неделю»!
5) И да, сами выделенные менеджеры у вас меняются каждые месяца 3-4. Новый не в курсе о том о чём мы говорили с предыдущим и приходится начинать всё заново.
Я не будут проходить по технической реализации API, мы все не безгрешны и делаем ошибки или странную логику, но организовать элементарнейшую систему поддержки своего API — это обязанность поставщика!
Мне не надо многого:
1) заранее информировать, что в API грядут изменения;
2) оперативно присылать новые версии документации со списком изменений;
3) организовать вменяемую службу поддержки: присвоение тикета моему запросу, оперативные ответы и статусы моего запроса. Общаться по почте через менеджера по продажам — это не серьёзно.
4) А если бы вы смогли организовать тестовый API — это было бы верхом профессионализма.
От пул-реквеста до релиза. Доклад Яндекс.Такси