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

Адаптивная архитектура (Олег Аксенов на ADD-2010)

Материал из CustisWiki

Версия от 21:04, 16 ноября 2011; StasFomin (обсуждение | вклад) (Примечания)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Аннотация

Олег Аксенов — архитектор и менеджер проектов в компании FogSoft, Microsoft MVP (Solution Architect 2005—2007, ASP/ASP.NET 2008—2010), поделился личным опытом в решении архитектурных проблем:

  • Необходимость выхода за рамки стереотипного мышления (всегда ли хороша многоуровневая архитектура).
  • Факторы, влияющие на выбор технологий и методологий (плюсы и минусы консерватизма).
  • Практические иллюстрации на основе разнообразных проектов (зависимости от бюджета/размера проекта).
  • Набор рекомендаций.

Видео


Подкаст


Презентация

Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf Адаптивная архитектура (Олег Аксенов на ADD-2010).pdf

Примечания


Адаптивная архитектура (Олег Аксенов на ADD-2010)

Товарищи занимаются заказной разработкой. Основные мысли:

  • Не доверяйтесь авторитетному мнению, все равно проверяйте даже непопулярные решения сами.
  • Архитектура должна быть итеративной (Continuous design).
  • Оценку трудоемкости нового проекта можно/нужно проводить по аналогии со сделанными, но делать новый проект по аналогии совсем не нужно.
  • Жесткие рамки «спущенной» архитектуры служат демотиватором для разработчика (хм, смотря для какого).
  • После оценки проекта домножает на 1.4 и выкатывает оценку заказчику.

Докладчик спокойный, умный, но скучный. Слайды - как любит Стас: только ключевые слова.

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

Оценка: :-|

Адаптивная архитектура (Олег Аксенов на ADD-2010)

Доклад о выборе архитектуры для проекта/команды Докладчик поделился опытом разработки заказных проектов различного масштаба силами разных команд. Основные мысли доклада:

  • если в повседневной жизни мы привыкли полагаться на авторитетное мнение, то в разработке приложений это не всегда срабатывает
  • каждому проекту и команде — своя методология и архитектура
  • важна команда — квалификация, специализация, сплочённость, размер
  • кроссфункциональная команда — хорошо для архитектуры, но в то же время важно наличие специалистов по отдельным направлениям
  • красивый дизайн ≠ удовлетворение заказчика
  • иногда проще переделать с нуля
  • в некоторых проектах эволюционный дизайн плох

Впечатление положительное. Некоторые мысли банальны, но было что послушать.

Адаптивная архитектура (Олег Аксенов на ADD-2010)

Fail'овый доклад. Автор рассказывал о том, что (кто бы мог подумать!) для каждой задачи нужно выбирать оптимальную архитектуру, а если в задаче все меняется, то и архитектуру можно поменять. Рассказывал медленно, долго, занудно, скучно. Апофеозом был вопрос к залу «Я не слишком быстро говорю?», после которого в зале раздался нервный смех тех, кто еще не уснул.

Свои идеи автор иллюстрировал историями из практики. Например, была высказана мысль, что архитектуру нужно подлаживать и под команду. Мне это показалось престранным - я всегда думал, что нужно команду, как более динамичное звено подбирать/обучать под архитектуру, которая более статична в силу статичности задачи (исключая, конечно, совсем клинические случаи).

Автор иллюстрировал свою идею примерно так: «У нас была задача. А из людей был только студент, знавший ASP и опытный DBA. Если бы мы стали делать трезвенную архитектуру, все бы закончилось плохо. Вместо этого мы написали всю логику на триггерах, а на ASP – сделали очень простое отображение данных. И все работает, проект сдан.» Может, это только мне кажется странным примером «success story» об архитектуре?

Пожалуй, единственное, что мне понравилось в докладе – это фотография аппарата из эксперимента Милднера. Этот психологический эксперимент наглядно демонстрирует огромную силу авторитета (любого, ну, например, Мартина Фаулера). Человек может быть очень сильно подвержен влиянию авторитета в каком-то вопросе, причем сам этого не осознавать. Подробнее об этом эксперименте, а также многих других удивительных психологических эффектах влияния можно прочитать в прекрасной книжке Роберта Чалдини «Психология влияния». Рекомендую к прочтению всем, независимо от рода деятельности.

Еще были упомянуты несколько статей, думаю, их стоит посмотреть:

  • Алистер Коберн, «Каждому проекту свою методологию»
  • Мартин Фаулер, «Проектирования больше нет?»
  • Continuous Design

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

Репликация: База Знаний «Заказных Информ Систем» → «Адаптивная архитектура (Олег Аксенов на ADD-2010)»