А как правильно-то?

На занятиях регулярно повторяется ситуация: разобрали задачу, спроектировали несколько вариантов решения, обсудили плюсы и минусы каждого. Далее следует вопрос: "А как правильно-то?"

Обычно в такой ситуации просят чеклист. Обычно я отвечаю, что чеклист - абсолютное зло. Кроме своего.

Но как принимать решения?
1. Описываем задачу и контекст
2. Описываем варианты решения
3. Каждое решение обладает характеристиками, часть будет отличаться
4. Собираем табличку: характеристики vs варианты решения
5. Сортируем свойства по важности в рамках задачи
6. Заполняем клетки значениями
7. Анализируем, делаем выбор

Пример на картинке.

Где брать нужные свойства?
• Атрибуты качества системы aka NFR
• Ограничения: сроки, бюджеты, организационное, техрадар
• Продуктовые метрики - реже, но бывает

Что важно:

• Чаще всего хватает 3-4 характеристик, важных для нашей задачи.

• Максимально старайтесь использовать численные оценки, где это возможно. gRPC быстрее REST - правда? А на сколько? В 10 раз или на 10%? А оно нам надо?

• Не надо улучшать все сразу. Нам точно нужны 10.000+ rps в региональном магазине мебели?

• Когда мы улучшаем одну характеристику системы, обычно ухудшаем другую. Если решение ничего не ухудшает - скорее всего что-то пропустили.

• Обязательно прикрепляем табличку к ADR, Decision Log, Летописям Гениальных Костылей, или что там у нас. Команде, потомкам и агентам в будущем будет намного проще.

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

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