Аннотация
- Докладчик
- Андрей Бибичев
Знакомо ли вам:
— Как нам выполнять работу итерациями, если у нас реализация одной фичи занимает месяц-два?
— Декомпозируйте!
— Да мы декомпозируем: всё разбито на модули, но каждый модуль жестко зависит от всех остальных и мы вынуждены делать синхронные правки в каждом, а потом еще долго-долго тестировать и стабилизировать!..
Или:
— Как нам в 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. А сам вопрос весьма важный для динамично развивающихся систем, потому что именно хорошая изоляция обеспечивает возможность достаточно безболезненного развития функционала.
На мой взгляд, это именно то обобщение опыта и рекомендации, которых не слишком много в книгах — как выбрать те или иные шаблоны, и что они за собой несут.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
