Работа с исключениями
Таковы наши принципы и инструкции, определяющие порядок создания систем. А что происходит, когда система от них отклоняется? Иногда принимается решение о том, что это всего лишь исключение из правила. В таком случае стоит, наверное, зарегистрировать такое решение где-нибудь в рабочем журнале как напоминание на будущее. При возникновении довольно большого количества исключений может появиться смысл изменить принцип или инструкцию, чтобы в них отразилось новое понимание действительности. Например, у нас может существовать инструкция, утверждающая, что для хранения данных нужно всегда использовать MySQL. Но затем возникнет вполне резонный интерес к использованию в качестве широко масштабируемого хранилища системы Cassandra, и тут мы внесем в свою инструкцию поправку, гласящую: «Большинство требований по хранению данных удовлетворять за счет применения MySQL, пока не обнаружится перспектива большого разрастания их объемов, в случает чего применять Cassandra».
Наверное, еще раз нужно напомнить, что все организации разные. Мне приходилось работать с компаниями, где команды разработчиков пользовались высокой степенью доверия и автономности и инструкции не были строгими, а потребности в конкретной работе с исключениями значительно снижены или вовсе отсутствуют. В более жестко структурированных организациях, где разработчики имеют меньше свободы, отслеживание исключений может быть жизненно необходимым для того, чтобы убедиться: установленные правила четко отражают те сложности, с которыми приходится сталкиваться. После всего сказанного я сторонник микросервисов как способа оптимизации автономии команд, дающего им как можно больше свободы в решении текущих проблем. Если вы работаете в организации, накладывающей массу ограничений на деятельность разработчиков, то микросервисы могут вам и не подойти.
Руководство и ведущая роль центра
Чтобы справиться со своими задачами, архитекторам нужна руководящая роль. Что подразумевается под
Применительно к ИТ руководство может касаться многих аспектов. Мы же хотим уделить особое внимание техническому руководству, что, по моему разумению, и является задачей архитектора. Если одной из задач, выполняемых архитектором, является обеспечение наличия технической концепции, то руководство имеет отношение к тому, чтобы обеспечить соответствие создаваемого этой концепции и участвовать в развитии концепции, если необходимо.
Архитекторы несут весьма многогранную ответственность. Они должны обеспечить наличие набора принципов, которые могут послужить руководством для разработки, а также соответствие этих принципов стратегии организации. Они должны также удостовериться в том, что эти принципы не требуют таких рабочих инструкций, которые будут в чем-то ущемлять разработчиков. Они должны двигаться в ногу с новыми технологиями и знать, когда нужно идти на разумные компромиссы. Это очень высокая ответственность. Кроме всего этого, им еще нужно вести за собой людей, то есть удостовериться в том, что коллеги, с которыми они работают, уяснили принятые решения и готовы к их выполнению. К тому же, как уже упоминалось, им нужно уделить время командам, чтобы осознать степень влияния их решений, и, возможно, даже вникнуть в создаваемый код.
Слишком большая ответственность? Конечно. Но я твердо придерживаюсь того мнения, что они должны справиться с ней самостоятельно. Чтобы частично разгрузить архитектора и уточнить концепцию, с ним вместе может работать толковая группа представителей руководства.
Вильям Л Саймон , Вильям Саймон , Наталья Владимировна Макеева , Нора Робертс , Юрий Викторович Щербатых
Зарубежная компьютерная, околокомпьютерная литература / ОС и Сети, интернет / Короткие любовные романы / Психология / Прочая справочная литература / Образование и наука / Книги по IT / Словари и Энциклопедии