предисловие
Когда вы нажимаете на приложение для найма и выбираете Интернет-технологии в качестве критерия фильтрации, среди большого количества перечисленных вакансий часто есть несколько с "архитектор«Три слова о высокооплачиваемых должностях. Когда вас привлекает высокая зарплата и вы нажимаете, чтобы просмотреть сведения о вакансии, вас отговаривают ее высокие требования. Они часто требуют более 5 лет опыта работы и требуют от соискателей наличия Опыт работы от 3 лет Более 10 лет опыта системного проектирования, знание различных архитектурных паттернов и системных фреймворков, но я не соответствую ни одному из условий.
Архитектор программного обеспечения — такая желанная, но захватывающая должность. Точно так же, как дизайнеры-архитекторы всегда мечтают стать главными дизайнерами, работники аэрокосмической отрасли всегда стремятся стать главными инженерами Я считаю, что у каждого инженера-программиста есть идея стать архитектором программного обеспечения. Цитируя определение из Википедии,В обязанности архитектора программного обеспечения входит определение основных технических вариантов, проектирование основной структуры системы в соответствии с требованиями разработки программной системы, а также ответственность за построение и реализацию.. Однако навыки, необходимые архитектору, выходят далеко за рамки выбора технологии и проектирования системы. В этой статье в основном представлены определение архитектуры программного обеспечения и некоторые навыки, необходимые для того, чтобы стать архитектором программного обеспечения, чтобы вы могли глубже понять должность архитектора программного обеспечения.
Большинство идей в статье исходят отОсновы архитектуры программного обеспеченияДля получения более подробной информации рекомендуется прочитать оригинальную книгу.
Определение архитектуры программного обеспечения
заАрхитектура программного обеспечения(Архитектура программного обеспечения), мы обычно рассматриваем его как план программной системы (план), но часто трудно дать точное определение. Википедия определяет архитектуру программного обеспечения как:Абстрактное описание общей структуры и компонентов программного обеспечения, используемое для разработки различных аспектов больших программных систем.. Однако это определение также является односторонним. Архитектура программного обеспечения — это не только общая структура и компоненты системы. Их самих по себе недостаточно для проектирования хорошей программной системы.
В книге Марк Ричардс и Нил Форд описывают архитектуру программного обеспечения с четырех сторон, а именноStructure,Architecture characteristics,Architecture decisionsиDesign principles.
Structure
Структура описывает архитектурный стиль, используемый программной системой., такие как наиболее распространенная многоуровневая архитектура, архитектура, управляемая событиями, архитектура микроядра, архитектура микросервисов и т. д. Когда вы спрашиваете архитектора, какую архитектуру использует программная система, если он говорит вам: «Система использует архитектуру микросервисов», то он просто указывает архитектурный стиль системы. Если вы хотите понять программную архитектуру всей системы, вы должны иметь глубокое понимание характеристик архитектуры, архитектурных решений и принципов проектирования.
Architecture characteristics
Характеристики архитектуры — это нефункциональные требования, о которых мы часто говорим, такие как доступность (Availability), масштабируемость (Scalability), надежность (Reliability) и так далее. Новички в программном обеспечении часто упускают из виду характеристики архитектуры, но они очень важны для программных систем. Если функциональные требования определяют нижний предел программной системы, то нефункциональные требования определяют ее верхний предел.
Architecture decisions
Архитектурные решения описывают правила, которым необходимо следовать при разработке программных систем., как в примере на рисунке, для системы с многоуровневой архитектурой разработчикам необходимо следовать следующим правилам: только бизнес-уровень может напрямую обращаться к сервисному уровню, а уровень представления не может напрямую обращаться к сервисному уровню. Архитектурные решения являются скорее ограничением, нарушение которого может не повлиять на функционирование системы, но является источником повреждения системной архитектуры.
Design principles
Принципы проектирования относятся к принципам проектирования системы., который используется для того, чтобы помочь команде разработчиков выбрать техническое решение, которое больше соответствует характеристикам системы. Принципы проектирования дают только направление, а не конкретную реализацию. Например, принцип проектирования системы, приведенный в примере на рисунке, заключается в том, что производительность системы должна быть максимально улучшена за счет асинхронного взаимодействия между микросервисами. Что касается реализации группой разработчиков асинхронной связи через REST или RPC, принципы проектирования не ограничены.
Навыки, необходимые архитектору
Точно так же, как архитектура программного обеспечения — это не только общая структура и компоненты системы, чтобы стать архитектором программного обеспечения, далеко не достаточно только выбора технологии. Квалифицированный архитектор программного обеспечения должен обладать следующими навыками:
Принимать архитектурные решения
An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise.
Это самый базовый навык, которым должен обладать архитектор, он должен дать команде разработчиков принципы системного проектирования и ограничения системной разработки.Роль архитектора здесь скорее проводник, а не производитель конкретных технических решений.. Например, если команде разработчиков необходимо выбрать интерфейсную среду, архитектор должен дать совет выбрать интерфейсную среду в реактивном стиле (посоветуйте команде выбрать между React.js, Angular, Vue.js). или другие интерфейсные фреймворки в стиле Reactive), а не прямо предлагать выбор фреймворка React.js. Первое — архитектурное решение, второе — техническое.
Постоянный анализ архитектуры системы
An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement.
Точно так же, как жизненный цикл программной системы не заканчивается в конце фазы разработки, программная архитектура не является одноразовой сделкой. Это требует, чтобы архитекторы постоянно анализировали архитектуру системы и вносили предложения по улучшению, чтобы система по-прежнему могла поддерживать хорошую архитектуру перед лицом двойных изменений в бизнесе и технологиях.
Оставайтесь в курсе технологий и отраслевых тенденций
An architect is expected to keep current with the latest technology and industry trends
Как архитектор, вы всегда должны быть чувствительны к технологиям и отраслевым тенденциям. В соответствии с тенденцией гибкой разработки характеристики программного обеспечения будут часто меняться, но инфраструктура программного обеспечения часто меняется редко. Если архитектор не может понять современные технологии и тенденции развития отрасли, разработанная архитектура программного обеспечения не сможет справиться с бизнес-и технологическими изменениями в ближайшие несколько лет, что будет иметь катастрофические последствия для программной системы.
Следить за тем, чтобы команда развивалась по установленным правилам
An architect is expected to ensure compliance with architecture decisions and design principles.
Архитектору необходимо не только установить принципы проектирования и ограничения разработки, но и обеспечить, чтобы команда всегда могла разрабатывать программное обеспечение в соответствии с этими правилами. Это требует от архитекторов проведения проверки кода основного кода, представленного разработчиками, иначе системная архитектура будет легко повреждена.
Расширить широту знаний
An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.
Архитектору не нужно владеть каждым фреймворком, платформой и языком, но, по крайней мере, понимать их как можно лучше, чтобы лучше поддерживать архитектурные решения. Это требует от архитекторов постоянного изучения новых знаний и постоянного выхода из зоны комфорта. Лучше всего владеть 2-3 языками и фреймворками, а также быть знакомым с различными широко используемыми языками и фреймворками в отрасли.Только при сочетании такой глубины и широты знаний может быть лучшая архитектура программного обеспечения. разработан.
Обладать определенными знаниями предметной области
An architect is expected to have a certain level of business domain expertise.
Все технологии служат существующему бизнесу, а программная технология, лишенная бизнеса, бесполезна.. Архитекторам не нужно владеть различными системами системы, как экспертам предметной области, но, по крайней мере, они должны иметь определенный бизнес-накопление. Программное обеспечение используется для решения проблем Архитектор, который не разбирается в бизнесе, занимается проектированием архитектуры программного обеспечения, это равносильно тому, что он начинает решать проблему, прежде чем он ее поймет, и результат часто бывает контрпродуктивным. Например, если бизнес, требующий низкой задержки, передается архитектору, который не разбирается в бизнесе для проектирования систем, может быть получена архитектура с высокой пропускной способностью.
навыки межличностного общения
An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.
Для большинства разработчиков и архитекторов это, пожалуй, самое сложное требование. Они умеют и с удовольствием решают технические проблемы, но довольно устойчивы к человеческим проблемам. Но это пункт, который должен преодолеть квалифицированный архитектор, потому что архитектору нужно не только сформулировать технические правила, но, что более важно, привести команду к развитию в соответствии с установленными правилами, что неизбежно предполагает лидерство и межличностное общение.
Когда инженер-разработчик решает использовать в разработке требованийодноэлементный шаблон, возможно, остальная часть команды не обратит на это особого внимания. Однако, когда архитектор решает использовать микросервисную архитектуру для проектирования системы, разные люди в команде могут возражать ему. Например, менеджер версий может решить, что микросервисная архитектура слишком сложна и не повлияет на ритм поставки. ; разработчики могут подумать, что многоуровневая архитектура реализована лучше. В этом случае архитекторы должны обладать хорошими навыками межличностного общения, чтобы убеждать разных людей, чтобы проект мог развиваться лучше.
Суммировать
Архитектура программного обеспечения — очень абстрактная вещь, и большинство ее текущих определений — очень общие описания.Основы архитектуры программного обеспеченияАрхитектура программного обеспечения описывается в четырех измерениях, что дает более четкое представление об архитектуре программного обеспечения. Исходя из этого, в книге также предлагаются некоторые навыки, которыми должен обладать квалифицированный архитектор программного обеспечения. В общем, этоТрудно разработать хорошую программную архитектуру, но еще труднее быть хорошим архитектором программного обеспечения..
Кроме того, в книге также предлагаются два принципа архитектуры программного обеспечения, очень разумные, но немного абстрактные. но это неважно,Не пытайся понять это, почувствуй это.
1. Все в архитектуре программного обеспечения — это компромисс.
2. Почему важнее, чем как.