|
|
| Строка 1: |
Строка 1: |
| | == Аннотация == | | == Аннотация == |
| − | ;Докладчик: [https://profiles.google.com/biBIGone/about Андрей Бибичев] | + | ;Докладчик: [[:Категория:Андрей Бибичев|Андрей Бибичев]] |
| | + | [[Категория:Андрей Бибичев]] |
| | <blockquote> | | <blockquote> |
| | Знакомо ли вам: | | Знакомо ли вам: |
| Строка 46: |
Строка 47: |
| | | | |
| | == Презентация == | | == Презентация == |
| − | [[Файл:Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011).pdf|center|640px]] | + | [[Файл:Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011).pdf|page=-|left|256px]] |
| | | | |
| | | | |
Текущая версия на 22:34, 18 октября 2011
Аннотация
- Докладчик
- Андрей Бибичев
Знакомо ли вам:
— Как нам выполнять работу итерациями, если у нас реализация одной фичи занимает месяц-два?
— Декомпозируйте!
— Да мы декомпозируем: всё разбито на модули, но каждый модуль жестко зависит от всех остальных и мы вынуждены делать синхронные правки в каждом, а потом еще долго-долго тестировать и стабилизировать!..
Или:
— Как нам в Agile с его итеративным процессом и инкрементальным дизайном не вырастить код-гидру, то есть когда правишь один баг, а в результате привносишь еще N?
— Декомпозируйте!
— Так мы и так используем объектно-ориентированный подход, то есть вся логика разбита по классам, но при этом каждый класс зависит от других стапятьсот классов, так что исправления в одном неведомым образом стреляют в другом…
И наконец:
— Мы всё медленнее и медленее развиваем наш продукт — у нас тяжелый и сильно связанный код. Что нам делать?
— Вы знаете/используете Inversion-of-Control?
— Конечно! У нас все сервисы оформлены в виде интерфейсов, а глобальный контекст работает по принципу Service Locator-а
— А зачем вы используете глобальные контексты?
— Так это же удобно! И разве можно иначе?!
Основная цель доклада — показать, что декомпозицию можно и нужно делать и как при этом обеспечить слабую связанность кода. При этом будут рассмотрены все три уровня: отдельные классы и их взаимодействие; организация модуля в целом; взаимодействие между модулями.
Целевая аудитория: разработчики, архитекторы, руководители проектов с техническим background-ом.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Утро началось с бодрого и энергичного доклада Андрея Бибичева на тему переосмысления архитектурных принципов в Agile. Андрей затронул в докладе идеи модульности, компонентности, принципы ООП и ООА, а также много других полезных принципов дизайна. Неуверен, что всем доклад был полезен, но я очень рад, что технический доклад приняли на конференцию. Мне очень нравится манера докладчика объяснять правильные принципы на простых и интересных примерах, в то же время добавляя свою изюминку в виде заковыристых выражений и различных полезных фактов. Вообщем, от доклада получил истинное удовольствие. Конечно, все эти принципы появились не благодаря Agile подходам. Но если все будут считать их неотъемлемой частью Agile и стремиться к ним, то я готов с радостью согласиться.
©
Андрей Бибичев
Андрей рассказал различные способы уменьшения связности между классами, модулями и компонентами системы, типа IoC, программирования по контракту и т. д. Доклад получился достаточно живым и интересным.
Андрей, как всегда, рассказывал доклад ярко и убедительно. Ну, и конечно, нельзя не отметить фирменный стиль изложения Андрея, наполненный «физическими» (такими, что, кажется, можно пощупать) примерами и аналогиями, яркими терминами.
Доклад и презентацию смело можно использовать повторно и включать в обязательный «Курс молодого бойца» в ЗИСах, наряду с «Учетной машиной».
Если попытаться переформулировать тему доклада для большей понятности, то это было бы что-то вроде «Современные хорошие практики объектно-ориентированного проектирования».
Спектр тем, освещенных в докладе, был достаточно широкий:
- Ценность модульной архитектуры
- Понимание порочного влияния связности
- 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. А сам вопрос весьма важный для динамично развивающихся систем, потому что именно хорошая изоляция обеспечивает возможность достаточно безболезненного развития функционала.
На мой взгляд, это именно то обобщение опыта и рекомендации, которых не слишком много в книгах — как выбрать те или иные шаблоны, и что они за собой несут.
