Персональные инструменты
 

Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Андрей Бибичев

Знакомо ли вам:

— Как нам выполнять работу итерациями, если у нас реализация одной фичи занимает месяц-два?

— Декомпозируйте!

— Да мы декомпозируем: всё разбито на модули, но каждый модуль жестко зависит от всех остальных и мы вынуждены делать синхронные правки в каждом, а потом еще долго-долго тестировать и стабилизировать!..

Или:

— Как нам в Agile с его итеративным процессом и инкрементальным дизайном не вырастить код-гидру, то есть когда правишь один баг, а в результате привносишь еще N?

— Декомпозируйте!

— Так мы и так используем объектно-ориентированный подход, то есть вся логика разбита по классам, но при этом каждый класс зависит от других стапятьсот классов, так что исправления в одном неведомым образом стреляют в другом…

И наконец:

— Мы всё медленнее и медленее развиваем наш продукт — у нас тяжелый и сильно связанный код. Что нам делать?

— Вы знаете/используете Inversion-of-Control?

— Конечно! У нас все сервисы оформлены в виде интерфейсов, а глобальный контекст работает по принципу Service Locator

— А зачем вы используете глобальные контексты?

— Так это же удобно! И разве можно иначе?!

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

Целевая аудитория: разработчики, архитекторы, руководители проектов с техническим background-ом.

Видео


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011).pdf


Примечания и отзывы

Утро началось с бодрого и энергичного доклада Андрея Бибичева на тему переосмысления архитектурных принципов в Agile. Андрей затронул в докладе идеи модульности, компонентности, принципы ООП и ООА, а также много других полезных принципов дизайна. Неуверен, что всем доклад был полезен, но я очень рад, что технический доклад приняли на конференцию. Мне очень нравится манера докладчика объяснять правильные принципы на простых и интересных примерах, в то же время добавляя свою изюминку в виде заковыристых выражений и различных полезных фактов. Вообщем, от доклада получил истинное удовольствие. Конечно, все эти принципы появились не благодаря Agile подходам. Но если все будут считать их неотъемлемой частью Agile и стремиться к ним, то я готов с радостью согласиться. ©


Андрей Бибичев

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

Star.svgStar.svgStar.svgStar.svgStar.svg

Андрей, как всегда, рассказывал доклад ярко и убедительно. Ну, и конечно, нельзя не отметить фирменный стиль изложения Андрея, наполненный «физическими» (такими, что, кажется, можно пощупать) примерами и аналогиями, яркими терминами. Доклад и презентацию смело можно использовать повторно и включать в обязательный «Курс молодого бойца» в ЗИСах, наряду с «Учетной машиной».

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

Спектр тем, освещенных в докладе, был достаточно широкий:

  • Ценность модульной архитектуры
  • Понимание порочного влияния связности
  • SOLID-принципы проектирования
  • Закон Деметры
  • Правильное использование механизмов наследования (принцип Лисков)
  • Принцип Inversion of Control
  • Современные паттерны — удачные и неудачные
  • Программирование по контрактам
  • Вопросы облегчения кодирования с учетов всего вышеперечисленного
  • Переход от проектирования системы классов к системе высокоуровневых сервисов

Презентацию можно взять здесь (видеозапись).

В добавок к презентации Андрей рекомендует:

Вообще, по этим ключевым словам можно найти массу материала, но суть в том, чтобы настойчиво применять эти принципы в каждодневной практике, а не только «знать, что такое где-то есть».

В заключение хочется только вздохнуть о том, что

а) Андрей уже не с нами
б) Когда закладывалась основа cis-uni.net, такой полноты понимания проблемы еще ни у кого в ЗИСах не было.

Доклад Андрея. Оказался очень низкоуровневым. По сути, это хорошие практики кодирования… Причем он в этот раз докладывал не очень структурировано…

Выводы: Мне это уже не очень интересно. Разработчикам наверное стоит посмотреть.

Докладчик
Андрей Бибичев
Компания
iPi Soft
Презентация
Документ на slideshare.net

Доклад Андрея, однозначно, понравился.

Доклад очень яркий и образный, емкий (аж 110 слайдов по объему). Много метафор (очень забавна аналогия, приведенная на слайдах 41-43, мне лично понравилась)

Обобщил пути уменьшения связанности:

Андрей активно рекламировал два следующих доклада (Антона Бевзюка и Коли Гребнева), в какой-то степени являющихся продолжением темы (увы, Антон не приехал).

Заинтересовал термином «идемпотентные операции» (см. статью, которую Андрей упомянул).

Вывод: яркий, насыщенный доклад, с большим интересом пролистал сейчас презентацию на slideshare.net

Андрей Бибичев.

Презентация
Документ на slideshare.net (Спасибо Диме Белобородову за ссылку)

Хороший доклад про паттерны и антипаттерны ООП. Интересно, однако, что внедрение многих хороших упомянутых практик в RMS (и в ЗИС вообще) началось по инициативе «снизу», а не пришло из TechEvol.

Вполне можно использовать как справочник или мантру для размышления каждый вечер

Общее

  • Неустойчивый код =
+ Side-effects
+ Избыточная область видимости
+ Мутабельность всего и вся
+ Большие глобальные контексты
  • God-класс
    • Огромные классы, которые умеют «все». Их рост все труднее остановить, так как новую функциональность становится все проще реализовать внутри такого класса и все сложнее вне его.
    • Может помочь паттерн State (GoF)
    • В RMS пример такого класс — InitialDataTestBase, базовый класс тестов с деревней
  • Огромные функции
    • Андрей привел пример из Open-Source проекта, функцию длиной 9520 строк

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

  • Длинные руки объектов = длинные цепочки вызовов по большим графам объектов

Как бороться?

  • Inversion of Control (наиболее предпочитаемый метод — через конструктор)
  • Law of Demeter
  • Принцип «Tell, don’t ask»
    • рекомендую посмотреть пример из презентации

Наследование

Способы:

  • Общие данные + helper-методы к ним
    • чаще всего наследников мало
    • не предполагаться написание новых наследников
    • сам базовый класс в API никак не фигурирует
    • правки наследников рушат базовый
  • Расширение функциональности за счет перекрытия виртуальных методов
    • Отдельная проблема — когда вызывать базовую реализацию в перекрытом методе, «до» или «после»
    • Очень тяжело, если на n+1 уровне нужно что-то изменить
  • Наследование как отношение «is»
    • Методы добавляют новое поведение
    • иногда очень тяжело правильно понять, к какой иерархии отнести класс, цена ошибки очень высока

По возможности, от наследования лучше отказываться:

  • Interface over inheritance
  • Composition over Inheritance
  • Delegation over Inhertance

Что еще

  • AOP
  • Design by contract
    • Хорошо не статическим проверками, а тем, что программист задумывается над тем что пишет
    • Инструмент .NET — Microsoft Code Contracts
    • Варианты проверок: предусловия, постусловия, инварианты

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

Если говорить о предмете доклада, то он весьма актуальный — как уменьшать связность фрагментов при реализации систем, чтобы обеспечить их независимость и устойчивость системы в целом при развитии. Какие есть принципы, и как с их точки зрения оцениваются те или иные design pattern. А сам вопрос весьма важный для динамично развивающихся систем, потому что именно хорошая изоляция обеспечивает возможность достаточно безболезненного развития функционала.

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



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011)»