Проводим архитектурное ревью продуктовой фичи - Максима Педченко - Яндекс Go Product Engineering Meetup (Рубрика #Architecture)
Хороший доклад от Максима Педченко из Yandex, в котором он рассказал зачем проводить архитектурное ревью и даже показал на +/- реальном примере как оно выглядит. Забавно, что пример был из домена реферальных программ, а проще говоря как сделать фичу с промокодами, которыми пассажир сможет делиться со своими друзьями. Эта фича обычно направлена на активацию механики сарафанного радио, когда ты customer acquisition cost несешь не на рекламу, а раздаешь его тому, кто рекомендует сервис и тому, кто пользуется рекомендацией и становится новым клиентом. В управлении маркетинговых технологий, что входит в мой юнит есть сервисы на эту тему и они называются BAF (Bring a Friend) и они приносят значимую часть новых клиентов.
Но если возвращаться к самому докладу, то в нем неплохо описана проблематика + приведен алгоритм архревью продуктовой фичи
- Появление идеи проекта
- Проверка гипотезы
- Задача на полноценную разработку (с стандартными НФТ по надежности, безопасности, и так далее)
- Создание RFC/ADR с описанием изменений и дальше ревью по стандартному флоу вопросов. В самом докладе станадартный список был в конце выступления и звучал примерно так
-- Какую продуктовую проблему решает проект
-- Какое место занимает решение в системе
-- Какие фолбеки предусмотрены внутри и снаружи
-- Какая ожидается нагрузка
-- С какими компонентами взаимодействует фича
А в примерах ревью разбирались реальные фичи, поэтому вопросы были в их контексте и они были такими
-- Сколько пользователей (ожидаемая нагрузка)
-- Как масштабироваться (scalability)
-- Можно ли сделать оптимальнее (performance)
-- Что с отказами и 500x (отказоустойчивость)
-- Могут ли быть гонки (что делать для обеспечения консистентности данных при паралелльных/асинхронных запросах)
-- Как сделать удобнее для пользователя (некоторые оптимальные решения с точки зрения прямо ломают UX в corner cases, а значит надо сделать чуть сложнее, но удобнее для пользователя)
-- Идемпотентность вызовов (включая идемпотентность во времени) - если так проектировать, то проще обеспечить надежность системы, так как условные ретраи будут безопасными
- Под конец автор замечает, что ревью не должно длиться бесконечно и когда-то мы должны остановиться и сказать good enough, а потом пойти реализовывать спроектированное решение. Иначе мы можем бесконечно крутиться в цикле paralysis of analysis. Условно говоря, лучшее - это враг хорошего:)
- Для условных экспериментальных фичей такое сложное ревью можно не делать, так как это может быть слишком дорого для эксперимента. Причем дороговизна с одной стороны за счет траты времени инженеров, а с другой стороны за счет замедления lead time изменений. Но если мы делаем уже что-то на долгосрок, то там архревью принесет много пользы на долгом горизонте.
- Для того, чтобы архревью работало надо описать его цели и правила, а также зафиксировать SLA по его проведению (например, сроки в которое оно должно быть пройдено и получен ответ)
#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems
Хороший доклад от Максима Педченко из Yandex, в котором он рассказал зачем проводить архитектурное ревью и даже показал на +/- реальном примере как оно выглядит. Забавно, что пример был из домена реферальных программ, а проще говоря как сделать фичу с промокодами, которыми пассажир сможет делиться со своими друзьями. Эта фича обычно направлена на активацию механики сарафанного радио, когда ты customer acquisition cost несешь не на рекламу, а раздаешь его тому, кто рекомендует сервис и тому, кто пользуется рекомендацией и становится новым клиентом. В управлении маркетинговых технологий, что входит в мой юнит есть сервисы на эту тему и они называются BAF (Bring a Friend) и они приносят значимую часть новых клиентов.
Но если возвращаться к самому докладу, то в нем неплохо описана проблематика + приведен алгоритм архревью продуктовой фичи
- Появление идеи проекта
- Проверка гипотезы
- Задача на полноценную разработку (с стандартными НФТ по надежности, безопасности, и так далее)
- Создание RFC/ADR с описанием изменений и дальше ревью по стандартному флоу вопросов. В самом докладе станадартный список был в конце выступления и звучал примерно так
-- Какую продуктовую проблему решает проект
-- Какое место занимает решение в системе
-- Какие фолбеки предусмотрены внутри и снаружи
-- Какая ожидается нагрузка
-- С какими компонентами взаимодействует фича
А в примерах ревью разбирались реальные фичи, поэтому вопросы были в их контексте и они были такими
-- Сколько пользователей (ожидаемая нагрузка)
-- Как масштабироваться (scalability)
-- Можно ли сделать оптимальнее (performance)
-- Что с отказами и 500x (отказоустойчивость)
-- Могут ли быть гонки (что делать для обеспечения консистентности данных при паралелльных/асинхронных запросах)
-- Как сделать удобнее для пользователя (некоторые оптимальные решения с точки зрения прямо ломают UX в corner cases, а значит надо сделать чуть сложнее, но удобнее для пользователя)
-- Идемпотентность вызовов (включая идемпотентность во времени) - если так проектировать, то проще обеспечить надежность системы, так как условные ретраи будут безопасными
- Под конец автор замечает, что ревью не должно длиться бесконечно и когда-то мы должны остановиться и сказать good enough, а потом пойти реализовывать спроектированное решение. Иначе мы можем бесконечно крутиться в цикле paralysis of analysis. Условно говоря, лучшее - это враг хорошего:)
- Для условных экспериментальных фичей такое сложное ревью можно не делать, так как это может быть слишком дорого для эксперимента. Причем дороговизна с одной стороны за счет траты времени инженеров, а с другой стороны за счет замедления lead time изменений. Но если мы делаем уже что-то на долгосрок, то там архревью принесет много пользы на долгом горизонте.
- Для того, чтобы архревью работало надо описать его цели и правила, а также зафиксировать SLA по его проведению (например, сроки в которое оно должно быть пройдено и получен ответ)
#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems