agile architecture

@dmytromindra #xpdays

Agile Архитектура

Дмитрий Миндра

Lohika


Что я обещал

Я обещал поделиться своим представлением об архитектуре и

проектировании в Agile. Многие популярные методологии не

описывают архитектурные практики. Некоторые команды,

работающие по гибким методологиям не уделяют достаточно

внимания проектированию. Но проектирование было и остается

той важной основной, на которой строится любое программное

обеспечение. Проектирование – это принятие решений.

Традиционный подход утверждает, что эти решения должны быть

приняты в самом начале. Гибкий подход заключается в том, что

решения должны приниматься тогда, когда они действительно

необходимы. Таким образом с развитием проекта гибкая

архитектура эволюционирует. И эта гибкость дает больше

возможностей для адаптации к изменениям. В индустрии

разработки программного обеспечения нет серебряных пуль. Я

постараюсь развеять некоторые мифы и познакомить

слушателей с проверенными практиками.


Разработка ПО – это просто !


Проблема №1: Завершенность

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


Проблема №2: Дефекты

Объем работы, связанной с устранением дефектов и ошибок в «завершенном» программном продукте, необходимой для того, чтобы сделать продукт готовым к использованию часто занимает значительное количество времени. Часто это время больше чем время разработки продукта.


Проблема №3: Требования Функциональность программного обеспечения редко соответствует требованиям конечных пользователей.


Проблема №4: Поддержка

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


Программист или инженер ?

http://www.codethinked.com/the-programmer-dress-code


Программист 1.0

Спецификация Программный продукт

Спецификация на входе – программное обеспечение на выходе.

Изменения в спецификациях не любит. Расценивает как угрозу.

Старается всячески избегать изменений.



Программист 2.0 и клиенат 2.0 учатся понимать друг друга.

Программист 2.0 все еще боится изменений, поэтому приписывет к

каждой версии продукта BETA.



Понимает клиента, его бизнес, разделяет ценности.

Всегда готов к изменениям. Понимает и принимает их необходимость.

Стремится делать рабочее и готовое к использованию ПО.


Agile методологии говорят о

людях


Миф: Архитектор

Сидит отдельно. Все решения принимает сам.

Занимается асоциальным проектированием.

Охраняет свою территорию.


Agile Архитектура

Ваш менеджер

вне всяких

сомнений

будет рад

Agile

архитектуре


Agile Architecture

Как это ?


Agile ценности

• Individuals and interactions

• Working software

• Customer collaboration

• Responding to change


Что такое архитектура и

проектирование?

В наиболее успешных программных

проектах, опытные разработчики

обладают общим пониманием

структуры системы. Это общее

понимание называется "архитектура".


Более официальное, но все еще

хорошее определение.

Архитектура является основной

организации системы, воплощенной в ее

компонентах, их отношениях друг к другу

и к окружающей среде, и принципы,

определяющие ее дизайн и эволюцию.

[IEEE 1471]


Характеристики Качества

Correctness

Robustness

Extendibility

Reusability

Compatibility

Efficiency

Portability

Easy of use

Functionality

Timeliness

Verifiability

Integrity

Reparability

Economy


Самые важные характеристики

Корректность Усточивость

Расширяемость

Возможность повторного

использования


Наш враг сложность


Враги архитектуры

Неподвижность Жесткость

Вязкость Хрупкость


Масштабируемость

Больше серверов

Больше людей


Coupling (Сцепление)

Сцепление классов, когда изменения в

одном могут повлиять на другой и

наоборот. К сожалению полностью

избавиться от сцепления невозможно.


Cohesion (Сплоченность)

Сплоченность классов, по своей

ответственности. Т.е. классы,

выполнябщие похожие действия

сгруппированы в одном и том же модуле.


Scocialization


Latency

Задержка – это время, которое должно

пройти прежде чем первая

функциональность увидит свет


Throughput

Пропускная способность – количесво

функциональности, которое можно

реализовать за определенное время.


Все всегда начинается с проблемы


Объектно

Ориентированный

Анализ


Вход:

Проблема

Выход:

концептуальная

Модель (Domain objects,

Use cases, Interactions,

some UI mockups )

Анализ


Методы OOA

• Метод OOSA Шлеер-Меллора • Метод Коада • ОМТ • Метод Мартина Оделла и средства проектирования Ptech • Метод “класс-связь” • OSA • Метод SEOO • Метод BON • Fusion • OBA • Syntropy • MOSES • Метод Текселя (Texel) • Метод OORAS


Проектирование

Вход:

концептуальная

модель

Выход:

Архитектура (дизайн)

системы


Принципы и инструменты OOD

SRP — The Single Responsibility Principle

OCP — The Open Closed Principle

LSP — The Liskov Substitution Principle

ISP — The Interface Segregation Principle

DIP — The Dependency Inversion Principle

REP — The Reuse Release Equivalency Principle

CCP — The Common Closure Principle

CRP — The Common Reuse Principle

ADP — The Acyclic Dependencies Principle

SDP — The Stable Dependencies Principle

SAP — The Stable Abstractions Principle


А также

• Design Patterns

• Domain Driven Design

• CQRS

• Event Sourcing

• MVC

• DCI

• SOA

• …


Кажется, что можно все

спланировать ?

Подробнее в книге Agile Samurai ;)


Big Upfront Design (BUFD)


No Upfront Design (NUFD)


Миф о рефакторинг

Ничего не будем делать заранее, сделаем

как получится, затем сделаем

рефакторинг и будет архитектура.


TDD и Архитектура

TDD укажет вам на проблемы в проектировании. Но

если вы не задали основные направления для движения

и эволюции, дизайн и архитектура не получатся.


UnixWay от Кента Бека

• Make it work

– ( Сделай что-то рабочее)

• Make it right

– ( Сделай рабочее правильным)

• Make it fast

– (Сделай правильное быстрым)


Инструменты

А также принципы и практики


Парное программирование

• Не программируй один. Найди себе

друга.


Ревью кода

Тимлид сурово смотрит в код ...


DDD


CQRS


Event Sourcing

Состояние доменного объекта переносится в событие. Система хорошо

распараллеливается.


Design Patterns


ООП

• ООП – это как в C#

• ООП – это как в PHP

• ООП – это как в Java


Пользователь


Что же делает пользователь ?

Это отражено в коде ?


Один UseCase разнесен по многим

классам.


Мы что-то теряем


MVC 1979

MVC улучшает восприятие

Но по-прежнему не отражает поведение


DCI


Как пользователь представляет

себе это действие ?


Ментальная Модель пользователя

Данные Роли

Взаимодействия


Простой пример

Transfer Money

User

Берем один счет,

затем берем другой счет,

определяем сумму перевода,

переводим деньги.


Данные (Data)

Account

Sav ingsAccountCheckingAccount


Роли (Interaction)

«interface»

TransferMoneySink

«interface»

TransferMoneySource

Пассивные (Methodless)

«interface»

TransferMoneySink«interface»

TransferMoneySource

TransferMoneySourceTrait

+ TransferTo() : void

Активные (methodful)


Контекст (Context)

Берем один счет,

Берем другой счет,

определяем сумму перевода,

переводим деньги.

«interface»

TransferMoneySink

«interface»

TransferMoneySource

TransferMoneySourceTrait

+ TransferTo() : void

TransferMoneyContext

«Property»

+ TransferMoneySource

+ TransferMoneySink

+ Ammount: int

+ Execute() : void


DCI & MVC вместе


DCI – это еще одна точка зрения


Комбинируя подходы мы получаем

архитектуру системы

MVC

DCI

Domain Model

Концептуальная модель

проектирование


Do try this ;)


Links and References

http://www.artima.com/articles/dci_vision.html

http://www.leansoftwarearchitecture.com/

http://www.artima.com/articles/dci_vision.html




Source Code

https://github.com/DmytroMindra/DCI-Simple-Sample







Итоги

• В проектировании очень важны знания

• В проектировании очень важен опыт

• В проектировании очень важно

понимание

• Agile архитектура – это люди

• DCI стоит попробовать дома

• Попробуйте Lean


В заключение

Программное обеспечение не ограничено физикой, как здания. Оно ограничено фантазией, дизайном, организацией. Короче говоря, оно ограничено свойствами людей, а не свойства мира. "Мы встретили врага, и этот враг мы сами".

-- Мартин Фаулер


Спасибо!

agile architecture

Technology