У многих есть ощущение, что это что-то, что делается изначально и потом не меняется.
Программу довольно легко написать и без особых знаний в архитектуре. Вопрос скорее в том что случиться со временем: без внимания к архитектуре разработка новых фич практически остановится. Выглядит это как значительное количество ошибок (времени на “стабилизацию”).
В целом, архитектура – это удовлетворение противоречащих друг другу условий. Например, есть команда (или легко нанять), знающая язык 1. При этом, специфика приложения такова, что хорошо бы использовать язык 2. Что выбрать? Как раз вопрос к Software Architect, и его работа.
В целом, для архитектора крайне важно иметь “насмотренность”: большинство возможных решений должны приходить моментально, и по каждому из них должен быть какой-то опыт, чтобы понимать особенности. А работа заключается в выборе и согласовании между собой множества этих выборов.
В этом заключается большая схожесть с архитекторами зданий. При этом видно, что даже в такой старой индустрии как строительство на достаточно ответственных ролях (архитектор) часто встречаются некомпетентные люди. Хотя знаний в индустрии более чем достаточно. Что уж говорить про гораздо более молодую сферу разработки ПО.
Основное же различие с архитекторами зданий, что разработка ПО условно никогда не заканчивается, а это означает, что постоянно нужно подправлять архитектуру под новые требования и обстоятельства. Часто немного, редко – кардинально. При этом отсутствие этих “немного” довольно быстро накапливается в реальные проблемы разработки.
Ответ: практически постоянный рефакторинг, но при этом быстрый (не занимает много времени), т.к. небольшой за раз.
А теперь немного об определении архитектуры. Ранее в заметке она не определялась. Старое определение Фаулера “некие конструктивные решения, которые после их принятия с трудом поддаются изменению” сейчас скорее неверно, т.к. часто проще перевести проект на другой язык и фреймворк, чем исправить какую-то проблему в текущем фреймворке (например, если он уже несколько лет не поддерживается). А это одно из самых с трудом поддающихся изменений.
Я бы сказал, что архитектура – это набор явных и неявных правил, используемых в текущем проекте. Например, правила фреймворка, терминология и т.п.