Никита Поляков
ЧИСТЫЙ КОД (Part 4)
👋 Привет Пол (и привет всем)
В одном из прошлых постов мы говорили на тему вариации контекста, формирующего решения разработчика.
Теперь спустимся на уровень конкретных примеров и подумаем, а как можно в разном контексте действовать.
💼 Представим, что мы работаем в крупной корпорации N, где есть ресурсы на реализацию максимально качественных решений.
🎯 Нам была поставлена задача:
Разработать калькулятор комиссий, который заменит менее гибкое и производительное вендорское решение.
Ответим на вопросы о контексте:
🧑🏻💻 Кто наши стейкхолдеры? Каковы их запросы и ожидания?
• Команда бизнеса — хочет предлагать клиентам уникальные условия, а потому ожидает гибкости решения в виде точечных настроек калькулятора и быстрого добавления новых вариантов комиссий. Однако на первом этапе считает достаточным просто заменить вендора.
• Команда поддержки — недовольна сложностью текущей системы, где в случае ошибок трудно разобраться в причинах и найти корректный способ исправления.
• Финансовый контроль — косвенный стейкходлер, который заинтересован в точности расчетов и прозрачности начислений, чтобы исключить возможные ошибки.
⚠️ Каковы архитектурные риски и ключевые качества системы?
• Во время пиковой нагрузки могут возникать задержки обработки запросов
→ Требуется высокая производительность и масштабируемость системы, а именно способность обрабатывать большое количество расчетов в короткие сроки, а также сохранять этот параметр при росте нагрузки
• Ошибки в расчетах могут приводить к финансовым потерям
→ Важна целостность данных, учет атомарности операций, работа с округлениями и защита от ошибок интеграций.
• Бизнес ожидает, что со временем появятся новые требования
→ Система должна обладать расширяемостью. Если изначальная архитектура не учитывает возможность модульного расширения, стоимость доработок может вырасти в разы.
• Калькулятор комиссий, скорее всего, будет зависеть от других сервисов (биллинг, CRM, внешние платежные системы)
→ Непродуманная работа с интеграциями может стать узким местом.
🛠 Какой объем изменений ожидается в будущем? Долгосрочная или краткосрочная ли ожидается поддержка?
• Значительный объем изменений
• Долгосрочная поддержка
⏳ Насколько жесткие дедлайны?
Сроки гибкие, но первый тип комиссии должен начать работать через 2 месяца.
После этого начнется этап переноса остальных комиссий и, при необходимости, разработка новых.
⸻ ⸻ ⸻ ⸻ ⸻
Даже получив ответы на вопросы выше, объем известного значительно меньше того, что мы до сих пор не знаем. Но откладывать больше нельзя — пора начинать писать код.
Думаю, все мы знаем это чувство, когда легче начать, а разбираться уже при необходимости по ходу дела. Благо, agile давно помог нам справляться с этой сложностью.
В нашем кейсе уже изначально мы можем предсказать, что и core, и integration слои будут сложными.
Интеграции — это больше техническая проблема, поэтому решать её нам легче — применяем гексагональную архитектуру. Со второй же проблемой так просто не получится, поэтому применяем мудрость из прошлого поста и просто откладываем решение до лучших времён. А текущую реализацию делаем максимально простой, но при этом не забываем про 100% покрытие core тестами, которые дадут нам уверенность при необходимости менять код по 50 раз в день.
Уже в дальнейшем, когда наберётся некоторая критическая масса кода в ядре, мы сможем его отрефакторить и реализовать onion / clean architecture / DDD.
💬 Как бы вы подступились к решению этой задачи? Делитесь в комментах!
2 · 362 ·