Denis Zarin
Звучит сюрно, но я как менеджер многому научился на этом кейсе.
К слову, этот сервер раньше стоял в прихожей у нашего старшего товарища, и мы выменяли его на огромного детского тигра для его дочки. Сейчас он директор по разработке в одном из мобильных операторов.
Это я к тому, что как у нас люди появляются в рассмотрении, сразу все невиданную глубину обретает. Да что я, ДеМарко все сказал..
Согласен. Но есть и другая сторона. Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством. Я в свое время писал на emacs, и многие мои друзья писали на emacs, и там по логу можно легко в этом убедиться.
Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система. А именно в этом и заключается архитектура, как утверждал Рольф Джонсон, - в коллективном понимании того, как устроена система.
Таким образом, архитектура на 90% оказывает влияние на velocity. Дальше можно долго рассказывать про Coupling&Cohesion, управление сложностью, пределы краткосрочной человеческой памяти, роли типовых решений в коллективном понимании устройства системы, системном мышлении, цикломатической сложности и т.п.
В конечном счете все сводится к одному - утрата контроля над сложностью программы приводит к экспоненциальному взлету стоимости изменения кода. Управление сложностью осуществляется через абстракции. А тут мы приходим уже к другому определению архитектуры, данное Г.Буч, архитектура - это многоуровневая система абстракций.
В общем, если с velocity беда - то это проблема архитектуры, ну, если только дело не в отвертке в системнике. Системной архитектуры, разумеется.