Обсуждения архитектуры часто теряются в абстракции — набросках доски, которые никогда не переживают контакт с реальностью, плотной документацией, которая собирает цифровую пыль, и теоретической чистоты, которая рушится под давлением практического применения. После многих лет строительства и восстановления систем в разных масштабах и отраслях, я узнал, что наиболее успешные архитектуры имеют одну важную черту: они разработаны как продукты, а не памятники.
Мой путь к этой реализации начался в исследованиях. Я получил докторскую степень в области электрической и компьютерной инженерии в Университете Фессалоники Аристотеля с акцентом на оптимизацию и совместную робототехнику. Моя более поздняя работа исследовала приложения ИИ в управлении городским трафиком. С тех пор я возглавлял программные усилия в академических и промышленных условиях, включая роли в автомобильной промышленности в Continental, ZF и Aptiv, и в настоящее время я работаю менеджером по разработке программного обеспечения в Meta, где работаю над системами целостности. Ранее я управлял командами в Backbase, компании Fintech в Амстердаме, где я создал основные банковские платформы для розничных и бизнес -клиентов.
Этот сдвиг в перспективе все меняет. Когда вы относитесь к архитектуре как к продукту, вы начинаете задавать разные вопросы. Вместо «это элегантно?» Вы спрашиваете: «Это помогает людям выполнить свою работу?» Вместо оптимизации для теоретического совершенства вы оптимизируете для реальных результатов.
Пользователи вашей архитектуры выходят далеко за рамки инженерных команд
Наиболее трансформирующей реализацией в моем архитектурном путешествии было понимание, кто на самом деле взаимодействует с системами, которые мы разрабатываем. Инженеры являются очевидными пользователями — им нужна ясность, обслуживаемость и уверенность в том, чтобы вносить изменения, не нарушая все. Но это всего лишь один избирательный округ в гораздо большей экосистеме.
Менеджеры по продуктам полагаются на архитектуру, чтобы обеспечить быстрое итерацию и развертываться без избыточных накладных расходов. Когда они не могут развернуться из -за трех команд, которым необходимо координировать тривиальное обновление, это архитектурная проблема. Дизайнеры и инженеры QA требуют стабильных, предсказуемых интерфейсов с четкими границами и предсказуемыми последствиями. Когда небольшая регулировка пользовательского интерфейса становится бэкэнд -хаосом, архитектура подвела их.
Заинтересованные стороны бизнеса заинтересованы в скорости, цене и масштабируемости. Они могут никогда не изучать технические детали, но они мгновенно чувствуют эффект, когда архитектура облегчает или труднее расти. Группы поддержки клиентов ориентируются на архитектурные решения благодаря надежности и отладкости систем, с помощью которых они обрушивают пользователей.
Признавая, что более крупная пользовательская база изменяет то, как вы принимаете дизайнерские решения. Каждое дизайнерское решение теперь является вопросом пользовательского опыта: «Кто это повлияет, и как оно изменит их повседневную работу?
Рассматривать архитектуру программного обеспечения как продукт, а не памятник
Поиск «чистой архитектуры» может быть ловушкой. Я видел красивые системы — прекрасно слоистые, чудесно абстрактные, с красивыми классовыми иерархиями — которые никто не хотел поддерживать. Они выполнили все лучшие практики в книге, но каким -то образом сделали несущественные, неясные и простые изменения опасными.
И наоборот, я работал с так называемыми «грязными» системами, которые любили команды, потому что они смогли с уверенностью отправлять функции, грациозно обрабатывать на края дела и знали, что происходит, когда все пошло не так. Они обменяли архитектурную чистоту на производительность разработчиков, и это того стоило.
Это не приглашение отказаться от хорошей практики дизайна. Структура, разделение проблем и чистые интерфейсы остаются необходимыми. Тем не менее, они должны использоваться в интересах людей, работающих с системой, а не ради себя. Если архитектурный выбор делает работу усерднее, а не проще, что -то было неправильно, даже если методология теоретически обоснована.
Хорошие архитектуры, как правило, не складываются для тех, кто их использует. Они предоставляют четкие решения для обычных вещей, разумные альтернативы для ненормальных потребностей и достаточная гибкость для расширения, не требуя общего капитального ремонта.
Измерение архитектурного успеха через метрики производительности разработчиков
Большинство мониторинга решений заполнены показателями, количественно определяющими поведение пользователей, производительность и результаты бизнеса. Архитектура также заслуживает того же внимания к измерению, но вместо этого измеряется с помощью субъективных аргументов по поводу эстетики дизайна, а не объективной оценки эффективности.
Я начал отслеживать архитектурное здоровье с точки зрения вопросов, непосредственно связанных с производительностью команды: сколько времени нужно для развертывания и выпуска регулярной функции? Сколько команд нужно координировать для перекрестных изменений? Как часто, казалось бы, не связанные части системы влияют друг на друга неизвестными способами? Насколько уверены инженеры, когда они меняют основные вещи?
Эти цифры говорят больше, чем слова. Когда время развертывания сокращается от дней до нескольких часов, когда зависимости перекрестной команды уменьшаются, когда сбои производства происходят реже и проще в отладении-эти результаты более красноречиво говорят о архитектурных решениях, чем любой проектный документ.
Есть моменты, когда прямое измерение невозможно, но сигналы, тем не менее, существуют. Регулярные дискуссии с командами разработчиков показывают болевые точки, узкие места и области, где архитектура обеспечивает или препятствует прогрессу. Именно эта обратная связь образует критический вклад в приоритет архитектурного улучшения.
Строительство архитектуры дорожные карты, которые соответствуют бизнес -целям
Архитектура-это не одноразовое решение, которое вырезается в камне. Это живая система, которая либо намеренно развивается, либо случайно деградирует. Как и любой продукт, он выигрывает от преднамеренного планирования и стратегического мышления о будущих потребностях.
Разрушение архитектурного планирования на три горизонта. «Сейчас» обращается к краткосрочным блокаторам-архитектурному долгу, который в настоящее время активно препятствует командам. Обычно это быстрые победы, которые обеспечивают быстрое облегчение и наращивают импульс для более значительных изменений.
«Следующие» проблемы не чувствительны ко времени, но они повредят, если они не будут рассмотрены. Это может быть масштабирование узких мест, которые возникнут по мере увеличения трафика, или структурные проблемы, которые станут более дорогими для решения по мере расширения кодовой базы.
«Позже» — это все о том, чтобы сделать ставки на будущие потребности с умом. Здесь вы делаете ставки на гибкость для последующих изменений в размерах, объеме или направлении бизнеса. Это более рискованные ставки, но они могут пожинать огромные награды, когда вы понимаете это правильно.
Мудрый выбор — согласовать архитектурные дорожные карты с дорожными картами продукта и бизнеса. Когда архитектурные улучшения имеют высокую степень корреляции с бизнес -целями, такими как более высокая доставка функций, повышение надежности и снижение эксплуатационных затрат — их легче расставить приоритеты и оправдать.
Измерение архитектурного успеха через метрики производительности разработчиков
Самая потрясающая архитектура — это ничто, если команды не принимают ее. Я видел, как слишком много красиво построенных систем собирали пыль, так как команды разрабатывают обходные пути или воспроизводили реализации, потому что «официальное» решение не подходило для них.
Успешное принятие архитектуры — это относиться к внутренним командам, таким как внешние клиенты. Это означает посылать ранние черновики для получения обратной связи, а не окончательных выводов, преднамеренно вымогая идеи о болевых точках и областях для улучшения, и ведет записи, которые отражают реальность, а не выражают желания.
Отслеживание показателей принятия — какие команды используют новые шаблоны, где сохраняются старые подходы, какие обходные пути создаются — дает решающую обратную связь о том, действительно ли архитектурные изменения решают проблемы или просто создают новые.
Мониторинг показателей принятия — какие группы используют новые модели, где они по -прежнему используют более старые подходы, какие обходные пути они применяют — обеспечивает ценную обратную связь о том, фактически ли архитектурные изменения решают проблемы или просто создают новые.
Человеческий фактор: как хорошая архитектура уменьшает когнитивную нагрузку
И последнее, но не менее важное, архитектура — это совместная работа для создания программного обеспечения. Техническая обоснованность необходима, но тоже общение, понимание и доверие. Отличные архитектуры минимизируют когнитивную нагрузку, устраняют координационные накладные расходы и позволяют практические рассуждения о сложных системах, используя простые, но понятные, умственные модели.
Этот человеческий фактор влияет на все, от схем именования до границ обслуживания и процедур развертывания. Когда архитектура противоречит тому, как команды хотят работать, трение неизбежно. Когда он увеличивает и ускоряет естественные потоки, производительность взлетает.
Хорошая архитектура не просто организует код — она организует команды, снижает стресс и создает среду, в которой люди могут сосредоточиться на решении бизнес -проблем, а не на борьбе с техническими препятствиями.
Строительство архитектуры дорожные карты, которые соответствуют бизнес -целям
Архитектура ценна только тогда, когда перестает быть ограничением и становится расширением прав и возможностей. Это происходит, когда вы применяете ту же дисциплину и ориентированную на пользователя подход, который вы могли бы с любым хорошим продуктом к архитектурным решениям.
Начните со знания ваших пользователей — все они, а не только инженеры. Отслеживайте результаты, которые наиболее важны для вашего бизнеса. Создать изменения стратегически, связывая технические изменения с ценности бизнеса. Сосредоточьтесь на усыновлении и реальном использовании, а не на теоретическом совершенстве.
Когда архитектура хороша, это почти невидимо. Команды судоходства более быстрее, системы масштабируются более красиво, а проблемы легче понять и исправить. Именно тогда архитектура перестает быть частью работы вокруг, которая сгибается и становится чем -то, что умножает эффективность команд.
Самая щедрая похвала, которую архитектор может получить, не для прекрасного дизайна, но вместо этого это команды, дополняющие их, говоря, что система просто работает так, как они ожидают. Это архитектура продукта, и это архитектура, которая имеет значение.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Avraam Tolmidis — менеджер по разработке программного обеспечения в Meta, где он руководит командами, работающими над системами целостности. Он имеет докторскую степень в области электрической и компьютерной техники в Университете Фессалоники Аристотеля, с исследованиями на оптимизации и совместной робототехнике и … Подробнее от Avraam Tolmidis
