Олег Аксенов — архитектор и менеджер проектов в компании FogSoft, Microsoft MVP (Solution Architect 2005—2007, ASP/ASP.NET 2008—2010),
поделился личным опытом в решении архитектурных проблем:
Необходимость выхода за рамки стереотипного мышления (всегда ли хороша многоуровневая архитектура).
Факторы, влияющие на выбор технологий и методологий (плюсы и минусы консерватизма).
Практические иллюстрации на основе разнообразных проектов (зависимости от бюджета/размера проекта).
Набор рекомендаций.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
Оценку трудоемкости нового проекта можно/нужно проводить по аналогии со сделанными, но делать новый проект по аналогии совсем не нужно.
Жесткие рамки «спущенной» архитектуры служат демотиватором для разработчика (хм, смотря для какого).
После оценки проекта домножает на 1.4 и выкатывает оценку заказчику.
Докладчик спокойный, умный, но скучный. Слайды - как любит Стас: только ключевые слова.
По ходу доклада у аудитории сложилось впечатление, что FogSoft-овцы не боятся кардинально архитектуру по ходу проекта. Это не так: речь шла о том, что не стоит паниковать, если в середине проекта обнаружилось, что у вас не предусмотрена система логирования или разграничения прав.
Доклад о выборе архитектуры для проекта/команды
Докладчик поделился опытом разработки заказных проектов различного масштаба силами разных команд. Основные мысли доклада:
если в повседневной жизни мы привыкли полагаться на авторитетное мнение, то в разработке приложений это не всегда срабатывает
каждому проекту и команде — своя методология и архитектура
важна команда — квалификация, специализация, сплочённость, размер
кроссфункциональная команда — хорошо для архитектуры, но в то же время важно наличие специалистов по отдельным направлениям
красивый дизайн ≠ удовлетворение заказчика
иногда проще переделать с нуля
в некоторых проектах эволюционный дизайн плох
Впечатление положительное. Некоторые мысли банальны, но было что послушать.
Fail'овый доклад. Автор рассказывал о том, что (кто бы мог подумать!) для каждой задачи нужно выбирать оптимальную архитектуру, а если в задаче все меняется, то и архитектуру можно поменять. Рассказывал медленно, долго, занудно, скучно. Апофеозом был вопрос к залу «Я не слишком быстро говорю?», после которого в зале раздался нервный смех тех, кто еще не уснул.
Свои идеи автор иллюстрировал историями из практики. Например, была высказана мысль, что архитектуру нужно подлаживать и под команду. Мне это показалось престранным - я всегда думал, что нужно команду, как более динамичное звено подбирать/обучать под архитектуру, которая более статична в силу статичности задачи (исключая, конечно, совсем клинические случаи).
Автор иллюстрировал свою идею примерно так: «У нас была задача. А из людей был только студент, знавший ASP и опытный DBA. Если бы мы стали делать трезвенную архитектуру, все бы закончилось плохо. Вместо этого мы написали всю логику на триггерах, а на ASP – сделали очень простое отображение данных. И все работает, проект сдан.» Может, это только мне кажется странным примером «success story» об архитектуре?
Пожалуй, единственное, что мне понравилось в докладе – это фотография аппарата из эксперимента Милднера. Этот психологический эксперимент наглядно демонстрирует огромную силу авторитета (любого, ну, например, Мартина Фаулера). Человек может быть очень сильно подвержен влиянию авторитета в каком-то вопросе, причем сам этого не осознавать. Подробнее об этом эксперименте, а также многих других удивительных психологических эффектах влияния можно прочитать в прекрасной книжке Роберта Чалдини «Психология влияния». Рекомендую к прочтению всем, независимо от рода деятельности.
Еще были упомянуты несколько статей, думаю, их стоит посмотреть:
Алистер Коберн, «Каждому проекту свою методологию»
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
