Skip to content

Latest commit

 

History

History
79 lines (52 loc) · 5.76 KB

tech_design_review.md

File metadata and controls

79 lines (52 loc) · 5.76 KB
Raw

Tech design Review в Авито

Что такое TDR

Tech Design Review — это процесс описания изменений в дизайне, архитектуре, сервисе или продукте и запрашивания фидбэка у коллег-разработчиков. Похож на ревью Pull Request.

Жизненный цикл TDR

Процесс TDR строится по такому алгоритму:

  • Формулирование проблемы.
  • Создание дашборда для TDR.
  • Создание дизайн-документа.
  • Начало ревью.
  • Сбор оценок и отзывов.

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

Когда стоит делать TDR

Мы рекомендуем проводить TDR в следующих случаях:

  • Портфельный продукт. Если продукт находится в продуктовом портфеле, то до наступления Gate 2 должен быть проведен TDR.
  • Высокий уровень влияния. Если решение затрагивает более одного юнита, то обязательно проведение ревью и участие в нём представителей от юнитов.
  • Значительные инвестиции в разработку. Если суммарно нужно потратить больше 3 челеловек в месяц на работу по задаче.
  • Возрастание тех. долга. Если разрабатываемое решение (например, MVP) может значительно увеличить тех. долг.
  • Передача сервиса или модуля в другую команду. Коллегам будет легче поддерживать и развивать решение, если обсудить его архитектуру в формате TDR.
  • Внедрение новой технологии/продукта. Рассмотренные причины внедрения, альтернативы, будет обоснование и согласованно с архитектурой.

Шаблон TDR

Для проведения TDR нужно создать дизайн-документ. У всех дизайн-документов единая структура.

  • Проблема

Опишите, какая проблема с точки зрения продукта или бизнеса решается предлагаемым изменением.

  • Описание

Опишите, что вы планируете сделать и как это будет работать на решение описанной выше проблемы.

  • Схема зависимостей

Создайте схему зависимостей и прикрепите её в дизайн-документ.

  • Компромиссы

Опишите, на какие компромиссы в решении мы идём и почему, опишите планируемый тех.долг, когда и как он будет устранён.

  • Альтернативы

Если рассматривались какие-то альтернативы, зафиксируйте их здесь.

  • FAQ

В этой секции фиксируются вопросы, которые возникают в процессе проектирования и ответы на них.

  • Нагрузка: в этом блоке собран список вопросов, на которые нужно ответить и сделать описание расчёта.

    • Какая нагрузка в RPM ожидается на сервис?
    • Какое количество реплик нужно на каждый DC?
    • Отношение нагрузки на чтение и запись.

  • Ресурсы: в этом блоке собран список вопросов, на которые нужно ответить.

    • Есть ли похожие по потреблению ресурсов сервисы? Если да, то сколько они потребляют?
    • Закладывались ли ресурсы под этот сервис во время планирования ресурсов?
    • Если нужна база данных, какую конфигурацию вы выбрали?
    • Нужно ли хранилище на ceph для этого сервиса?
    • Нужны ли специфичные ресурсы: например, GPU?
    • Нужно ли хранить дополнительные поля в айтеме?
    • Нужно ли хранить картинки или файлы?

  • Структура баз данных

Опишите структуру базы данных и планируемый способ хранения.

  • Информационная безопасность: обсудите ответы на эти вопросы с безопасниками и покажите им результаты моделированя угроз.

    • Предполагает ли решение добавление публичного API?
    • Предполагается ли хранение или обработка персональных данных?

  • Метрики

Соберите список ключевых бизнесовых, продуктовых и технических метрик.