Когда-то меня вдохновило выступление Евгения Кривошеева Design & Process Models. В нём рассматривается много аспектов разработки ПО, рекомендую выделить 2 часа и посмотреть видео целиком. Сейчас я хочу остановится на взаимодействии связанных между собой моделей и том, как это можно использовать в повседневной работе:
- Business Model — бизнес заказчика, на чём он зарабатывает деньги.
- Process model — как должен быть устроен процесс формирования ценности: этапы, фазы, роли, артефактры для получения ценности. Описывает также порядок появление нижележащих моделей и их взаимодействие. Например, пишем код и рефакторим до хорошего дизайна или сначала делаем дизайн (upfront) и потом пишем код.
- Requirements Model + Domain Model — какие требования есть к продукту/проекту, тексты, UML-диаграммы и т.д.
- Design Model — архитектура, шаблоны проектирования и т.п.
- Implementation Model — исходный код
Один из возможных результатов выбора на каждом уровне:
Мы ежедневно принимаем решения по проекту. Например, надо решить будем добавлять кэш в инфраструктуру или нет? Будем применять IoC-контейнер или нет? Сделаем Big Design Up Front или начнем создавать архитектуру по ходу работы над проектом? Напишем подробное ТЗ в начале проекта или будем реализовывать самые важные User Story итеративно? Построим процесс по Waterfall или по Agile? Любое решение имеет свои плюсы и минусы, нужно постоянно искать компромиссы.
Основные идеи, о которых говорит Евгений:
- Какое бы ни было решение в любом случае довольно сложно попасть им во все требования вышестоящей модели. Возникает конфликт и приходится искать компромисс. В нашей отрасли такие конфликты типичны, потому что по Cynefin framework разработка ПО обычно лежит в квадрате Complex.
Яркий пример компромисса — это теорема CAP. В зависимости от требований вам придётся выбрать для архитектуры две характеристики из трёх возможных. - Зависимость моделей проявляется не только сверху вниз. Нижележащие модели также могут оказывать влияние на вышележащие.
Например, не факт, что под требования к системе можно подобрать архитектуру. Вполне реальная ситуация, когда приходится изменять требования, чтобы можно было создать жизнеспособную архитектуру. - Мы не можем решить проблему на том же уровне абстракции, на котором она возникла, ответ нужно искать на уровень выше.
Типичный выбор Гибкость или Простота. Сейчас заплатить больше и сделать изначально гибко или сейчас делать проще, а потом выплачивать технический долг. Какое-то решение принять придётся, для этого идём на уровни выше и пытаемся найти ответ там. - Нужно уметь обосновывать свои решения на каждому уровне через вышестоящие модели.
- Нет плохих или хороших решений, за всё приходится платить.
В примерах мы говорим в основном о паре Requirements Model <-> Design Model, но все утвеждения справедливы для любой другой пары моделей.
В итоге, получается, что каждый член команды должен понимать бизнес-модель заказчика (для начала надо уметь явно формировать цели). Как бы это странно ни звучало, но в конечном итоге от бизнес-модели зависит какой вы сделаете метод/класс/интерфейс в коде. Если внимательно отнестить к этой модели принятия решений, то в результате получите снижение стоимости разработки и снижение рисков.
Комментариев нет:
Отправить комментарий