Aspect-oriented programming

Если что-то появляется, значит, оно кому-то нужно.

И снова новая методология программирования и к ней новый подход к разработке ПО. Приглашаем любить и жаловать: Aspect-Oriented programming (AOP) и Aspect-Oriented software development (AOSD).

В отличии от предыдущей методологии (OOTD) (которая была только идеей и поводом немного задуматься, да и на устои привычной OOP серьезно не покушалась), эта методология вполне оформившаяся и претендует быть кардинально отличной от OOP.

История:

Aspect-Oriented подход разработан в Xerox PARC в 2001 году под руководством Gregor Kiczales. Этой же группой была разработана первая реализация – AspectJ, которая на текущий момент входит в Eclipse Foundation. Кроме AspectJ уже создано несколько десятков реализаций AOP парадигмы, практически для всех языков.

Идея AOP захватила сообщество - существует Aspect-Oriented Software Association (AOSA), проходят ежегодные конференции по AOSD, в которых в качестве спонсоров выступают Microsoft, Google и IBM.

Основная цель, которую себе поставил Gregor Kiczales, и в результате движения к которой появился AOP – уменьшение кол-ва ошибок и улучшение качества кода за счет борьбы с запутанностью кода и разбросанностью функционала.

Дисклэймер:

Я, человек привыкший думать объектно-ориентированно, не совсем поняла их претензии к OOP. Т.е., на мой взгляд, при правильном дизайне системы (в объектно-ориентированной парадигме) нижеизложенные проблемы не дают серьезного ухудшения качества кода. Описание же AOP, на мой взгляд, слишком похоже на патерны. Но то, что я не вижу преимуществ – это не значит что их нет. OOP тоже плохо приживался в процедурно мыслящей среде.

С чем боремся:

В объектно-ориентированном подходе как на уровне системы в целом, так и на уровне отдельных классов присутствует сквозная функциональность (т.е. та, которая реализована понемногу в разных модулях), а так же большое количество кода, который фактически не относится к функционалу системы. На уровне системы это идентификация, защита, логирование, репликации, сериализация/десериализация, сохранение настроек системы и т.д., т.е. или общий или «сервисный» функционал, зачастую реализованный в разных частях системы (примеры: сериализует один модуль - десериализует другой; каждый из модулей системы занимается идентификациеи и защитой), в связи с чем усложняется отладка и поддержка (со временем начинается «расползание»). То же самое на уровне классов – класс инкапсулирует в себя не только функциональную часть, но и внутренние «сервисы», обеспечивающие корректность работы – отлов ошибок, работа с памятью и т.д., которые загромождают код и усложняют чтение логики – в следствии чего, опять же сложности с отладкой и длительной поддержкой.

Метод борьбы:

Выделение сквозной функциональности в отдельные модули, которые называются аспектам (aspects). Поведение аспекта в конкретном месте программы (точке подсоединения, join point) определяет advice (собственно программная реализация модуля). Все точки подсоединения конкретного аспекта описываются в наборе pointcut.

В результате получается: Весь код, относящийся к определенной функциональности собран в одном месте (аспекте), т.е. его проще отлаживать и поддерживать. Точек подсоединения этого аспекта может быть много, но есть единый список точек подсоединения, соответственно, это опять же облегчает поддержку системы. Все особенности работы аспекта в конкретной точке подсоединения определяются не выходя из аспекта.

Так как аспектно-ориентированный подход упрощает поддержку системы авторы методологии рекомендуют аспектно-ориентированный рефакторинг. Т.е. изучение системы на предмет сквозной функциональности и вынесения ее в отдельные аспекты.

Ссылки по теме:

Gregor Kiczales о AOP (Google Video)

Aspect-Oriented programming на wiki

Книги:

Aspect-Oriented Analysis and Design: The Theme Approach. Siobhàn Clarke, Elisa Baniassad.

Aspect-Oriented Software Development. Robert E. Filman, Tzilla Elrad, Siobhan Clarke, Mehmet Aksit.

Aspect-Oriented Software Development with Use Cases. Ivar Jacobson, Pan-Wei Ng.

Aspect Oriented Refactoring. Ramnivas Laddad.

AspectJ in Action: Practical Aspect-Oriented Programming. Ramnivas Laddad.

Объектно-ориентированному дизайну пора потесниться

Явно пришло время изменений. Предыдущий пост был про идею новой методологи разработки, а сегодня пришло время пересмотреть основы программирования и дизайна – OOP и OOD.

Большинство изменений происходят постепенно. За текучкой мы эти изменения не замечаем.

Последнее время все больше и больше внимания уделяется тестированию. Т.е. с тем, что это нужно, конечно и раньше никто не спорил, но бурный рост применения UnitTest-ов (поддержка которых уже встроена в большинство средств разработки), функциональных тестов, использования автоматического тестирования, произошел в последние несколько лет.

OOD сейчас не то, чтобы устарел (к процедурному стилю никто переходить не собирается), но многими принципами приходится поступаться ради удобства тестирования.

Основная проблема – область видимости. Закон инкапсуляции гласит, что все внутреннее устройство объекта никого не интересует и должно быть запрятано внутрь. Однако им приходится часто поступаться - ради возможности протестировать работу приватного метода, его приходится делать публичным. Т.е. теперь все внутренне устройство становится интересно тесту.

Самое неприятное - когда красиво спроектированную архитектуру приходится портить ради тестов. Какой выход из этой ситуации?

Для того, чтобы не ломать архитектуру UnitTest-ы класса можно размещеть в том же юните, что и сам класс. Но такое решение имеет свои недостатки – резкое увеличение объема кода одного юнита, сложность распараллеливания работ над реализацией класса и тестами к нему. Но основная проблема в том, что такое решение подходит только для UnitTest-ов. Для функциональны тестов, использующих объекты, расположенные в разных юнитах нужны дополнительные хитрости – например использование тестовых классов, отнаследованных от тестируемых классов, которые дают публичный доступ ко внутренним процедурам тестируемых классов. Но и тут могут возникнуть проблемы, особенно при сложных структурах наследования. Возможность использовать подобные ухищрения зависит от языка и от утилит тестирования.

Roy Osherove предлагает кардинально другое решение. Он предлагает поменять подход к дизайну и делать его не только объектно-ориентированным, но и тесто-ориентированным. Итак, на замену OOD идет OOTD (Object Oriented Testable Design).

На мой взгляд идея хорошая. Признание факта противоречия классических канонов OOD и тестирования – это хорошая причина уделить внимание проблемам тестирования еще на этапе проектирования.

Бэта должна выглядеть как бэта, а не как готовый продукт

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

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

Клиенты воспринимают степень готовность ПО по степени готовности интерфейса.

Картинка из поста "Don't make the Demo look Done"

Вроде бы очень простая мысль, но она просто не приходила мне в голову раньше.

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

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

Конечно, можно сказать: "А на что history list? Все изменения можно посмотреть там". Но нравится / не нравится - это эмоция, которая возникает не зависимо от того, что написано в history list. Да и сам history list даже профессионалы при использовании сторонних продуктов не всегда читают. Обычные пользователи практически никогда ничего не читают - все должно быть понятно из интерфейса.

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

Готовность интерфейса должна соответствовать функциональной готовности продукта.

В постепенном совершенствовании интерфейса есть еще один плюс: На ранних стадиях, когда есть только основные элементы интерфейса, внимание пользователей будет сосредоточено на функционале, соответственно их замечания и пожелания будут относится, в основном, к функциональной области. Это позволит не "закопаться" в интерфейсных проблемах, а также, если потребуется, изменить концепцию интерфейса без крупных затрат. Ближе к релизу, когда функционал готов, отзывы будут относится, в основном, к интерфейсной части, что позволит ее сделать наиболее удобной для пользователей.

Новых вам интересных и успешных проектов в наступающем 2007 году!

Agile Testing

Очень интересные доклады по Agile методологиям на Google Video. Их довольно много. Вот некоторые (ссылки на остальные видны справа при просмотре):

• Agile Testing (Elisabeth Hendrickson)
• Scrum et al. (Ken Schwaber)
• Kent Beck: Ease At Work (В 7-и частях, к сожалению 1-ю не нашла, эта вторая. При просмотре рядом ссылки на остальные части)

Я пока осилила только Agile Testing. Очень зажигательная докладчица. Elisabeth Hendrickson является консультантом по software testing, основателем Quality Tree Software. На сайте Quality Tree Software есть документы с советами по тестированию продуктов и по набору тестировщиков. Ну и, конечно же, Элизабет ведет блог - Ruminations.

Разработка, идущая от тестирования, для меня, наверно, самая близкая из agile техник.

В корпоративных продуктах тестирование является важнейшей частью процесса производства и чем более автоматизирован процесс тестирования, тем чаще можно выпускать версии и тем надежнее они будут. Ежедневный (может реже, может чаще, зависит от частоты сборки) прогон всех тестов обеспечивает достаточную уверенность, что новый функционал или изменения не порушили ничего из ранее сделанного, а прогон тестов на продуктиве обеспечит уверенность что все корректно перенеслось с тестового сервера. Написание тестов сразу с новым функционалом по времени гораздо экономичнее, чем последующий ручной отлов ошибок или, что еще хуже, отлов ошибок пользователями на живой системе. Но, все-таки, в корпоративной разработке тестирование может вести за собой проект только когда проект достаточно сформирован, когда тестирование помогает улучшить модель использования системы и интерфейс. На этапе проектирования и разработки тестирование идет за разработкой, отставая на пол шага.

А разработка конечнопользовательских продуктов может идти от тестирования с самого начала. Здесь приложение решает проблему (или набор проблем) пользователя и нет четких рамок как это должно происходить – главное, что бы проблема решалась наиболее удобным для пользователя способом. Т.ч. проект сразу начинает жить подстраиваясь и видоизменяясь.

На текущий момент отдельные части кода, объекты и функциональные модули тестируются с помощью UnitTest-ов (которые встроены сейчас практически во все среды разработки). Практика эта довольно распространенная, хотя к порядку использования UnitTest-ов есть вопросы – кто и в какой последовательности должен писать тесты к коду? Должны ли сначала писаться по спецификациям тесты, а потом код? Должен ли сам программист писать тесты к своему коду? У меня пока нет универсального ответа, пробовались разные варианты и у всех есть свои недостатки.

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

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

technorati tags: Agile Testing

Хаос наступает

IT стремится к хаосу. SOA – хаос в архитектуре систем. Agile (XP и, особенно, Scrum) – хаос в производстве систем.

Причем хаос - это не мое видение. SOA и Agile позиционируются как методологии жизни в хаосе.

Новые методологии отрицают планирование, никаких планов развития. Они все сиюминутны.

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

Чем методология разработки более гибкая тем больше ее сейчас любят. Каждая следующая методология оставляет все меньше места планированию и контролю. Roy Osherove, agile консультант, пишет что Scrum продается лучше чем XP в основном потому, что Scrum более настраиваемый, требует меньше управления и не содержит страшного слова "Extreme". Т.е. разработчик наслушавшись как все может быть хорошо с agile, где ему не надо ни за что отвечать ведется и хочет применить это на себя. Причем выбирает методологию – чем проще звучит тем лучше.

Все аgile методологии построены на очень активном участии заказчика, вплоть до того, что заказчик фактически напрямую ставит задачу команде разработчиков (архитекторы, аналитики, технологи – все лишние). Это, опять же, очень выгодно разработчику. Зачем долго выяснять что надо заказчику, потом это согласовывать с десятками отделов, если можно привлечь заказчика к разработке и получать изменения и дополнения от каждого отдела отдельно. Никакой головной боли с противоречием требований. В результате можно сказать – вы именно это и хотели. Если же заказчик начинает понимать к чему может привести этот хаос ему приходится самому внутри себя создавать команду, которая утрясает все требования и разногласия между отделами и уже выдает разработчикам спланированные данные, т.е. разработчик сбрасывает с себя задачу планирования (а с ней и ответственность) на заказчика.

Без отсутствия изначальных требований к разрабатываемой системе (а аgile отрицает любые планы далее чем на одну итерацию) нельзя оценить результат разработки. Никто не сможет сказать сделали ли то, что было нужно или не то. В любом случае разработчик не виноват – он только выполнял пожелания заказчика.

Disclamer: Не бейте меня сильно! Описание ситуации немного утрировано, но, иногда, карикатурная утрированность помогает взглянуть на ситуацию по новому.

technorati tags: SOA, Agile, Scrum, eXtreme Programming

SOA в Amazon.com

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

Как сделать так, чтобы большая компания оставалась мобильной и быстро реагировала на изменения запросов клиентов знает Werner Vogels - CTO в Amazon.com.

Успешный рост Amazon.com был обеспечен сервисно-ориентированной архитектурой (SOA). На текущий момент Amazon.com является набором разнообразных сервисов, разрабатываемых и поддерживаемых независимо друг от друга.

Компания не является монолитной, а состоит из большого количества маленьких agile команд (2 pizza teams), раскиданных по всему миру. Каждая команда занимает свое место в сервисно-ориентированной структуре. Подобная организация дает Amazon.com быстроту реакции маленьких компаний.

Процесс определения требований к продукту Werner Vogels описывает как работу "задом наперед" (working backwards). Для соответствования услуг нуждам пользователей, процесс определения требований к услугам ведется начиная с документации, которая потребуется при запуске (пресс-релизы и FAQ), затем переходя к документации, относящейся непосредственно к продукту (руководство пользователя и прототип поведения пользователей). В результате получается набор документация полностью описывающий продукт. Эти наборы документации позволяют легко передавать знания о продуктах между отдельными командами внутри Amazon.com.

Здесь можно посмотреть интервью Werner Vogels, данное для ACM Queue magazine.

Tags: Development Team, Agile, Werner Vogels