​​Contract First

Чтобы запилить стандартную фичу команде разработчиков нужно внести изменения в разные компоненты. Компонентами могут быть Бэкенд и фронты, несколько микросервисов или даже сущности в коде одного приложения. Казалось бы, накодить компоненты и интегрировать их друг с другом.

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

Типичная проблема: допустим, с бэка на фронт забыли отдать одно поле для отображения пользователю. Очень легко (но не бесплатно) пофиксить эту проблему, если это поле есть во внутренней структуре данных. Достаточно пробросить его в API.
Сложнее и дольше, если для этого поля нужно делать еще бизнес-логику, запрос в БД или взаимодействие с другими компонентами. Дополнительно встает вопрос архитектуры и нагрузки.

Было бы здорово позаботиться об архитектуре и нагрузоустойчивости на этапе проектирования и декомпозиции фичи. Проработка контракта — один и способов подумать о потоках данных фичи. Поэтому мы включили пункт «Проработан драфт контракта» в Definition Of Ready (for sprint). Это просто шпаргалка, о чем еще можно подумать при проработке задачи.

Бывает, что даже совместно и заранее спроектированное апи оказывается не совсем подходящим. В такой ситуации спасает ранняя интеграция компонентов на заглушках. Очень просто сразу после проектирования апи запилить mock-заглушку. И в эту заглушку сразу интегрируются все компоненты.
Во-первых, это тоже помогает выявить неизвестности как можно раньше. Быстрый фидбек — ключ к успеху.
Во-вторых, это развязывает руки для паралельной разработки. Можно не ждать реализации бизнес-логики на бэке, сверстать фронт и получить обратную связь от дизайнера и QA. При этом быть уверенным, что после реализации бизнес-логики интеграция не изменится.

Благодаря Contract First подходу мы ускорили Time2Market и пришли к таким Contract-First Best Practices:
1️⃣ — Проектируем контракт при декомпозиции фичи, чтобы подумать обо всех данных фичи и спроектировать архитектуру;
2️⃣ — В проектировании участвуют эксперты во всех компонентах, чтобы интеграция была удобной для всех;
3️⃣ — При начале разработки фичи сразу выкатываем mock-заглушки контрактов, чтобы интеграция была как можно более ранней;
4️⃣ — Описываем контракт в виде кода в общей shared-библиотеке, чтобы переиспользовать её на серверной и клиентской стороне.
5️⃣ — Бонус, документация апи готова еще до того как фича разработана.

Для визуализации нарисовал наглядную картинку, которая показывает как именно подход Contract First экономит время при разработке.