Как начать использовать программную архитектуру?

Иногда проще попросить прощения, чем получить разрешение

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

Я понимаю программную архитектуру и все, о чем вы говорите, но у нашей команды нет времени ею заниматься, потому что мы заняты кодированием основного продукта. Вместе с тем, я знаю, что нам нужна архитектура, поскольку нам не хватает последовательного подхода к решению проблем и т.д. Как ввести архитектуру?

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

• Какие проблемы отсутствие архитектуры создает сейчас?

• К каким проблемам отсутствие архитектуры вероятней всего приведет в будущем?

• Есть ли риск, что эти проблемы повлекут за собой более серьезные последствия (например, потеря репутации, бизнеса, клиентов, денег и т.п.)?

В этом конкретном случае, после короткой беседы и исследований с моей стороны, причиной отсутствия какой-либо архитектурной деятельности является:

Наши менеджеры не дают нам времени заниматься архитектурой. Чаще всего они говорят: или кодирование или архитектура.

"Сколько архитектуры" нужно разработать?

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

Реактивные изменения

Большинство команд изменит свои методы только после того, как случится что-нибудь плохое. Другими словами, необходим катализатор - например, непрерывная череда неудачных развертываний системы или серьезный сбой системы.

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

Проактивные изменения

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

Как же ввести программную архитектуру?

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

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

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


2. Будьте проактивны и служите примером. Если я начинаю работать над проектом, у которого отсутствует высокоуровневая техническая документация, я возьмусь создавать ее, пока другие не увидят преимуществ и присоединятся к процессу. То есть, необходимо подготовить почву.

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

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

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

источник