Привет Хабр! Сегодня публикуем вторую часть материала об архетипах программных архитекторов. Если пропустили, то вот первая часть.

3. Архитектор, или инженер уровня Staff+?

На ресурсе «The Pragmatic Engineer» редко используется термин «архитектор». Причина этого в том, что заслуженные Big Tech-компании и множество более молодых стартапов отказались от подобного названия должности, отдав предпочтение названию «инженер», к которому добавляется «Staff», «Principal» или «Distinguished». Эти компании обычно подчёркивают в названиях должностей слово «инженер». Делается это для того, чтобы сразу были понятны их ожидания от опытного инженера: он должен обладать серьёзными практическими навыками. Так как я, в основном, пишу о Big Tech-компаниях и о стартапах, получается, что, ориентируясь на общепринятую практику, «архитекторов» я обычно называют «Staff+-инженерами».

Правда, понятия «Staff+-инженер-программист» и «программный архитектор» часто взаимозаменяемы. В конце концов, инженеры уровня Staff+ — это обычно самые «сеньорные» инженеры в команде, а иногда — и во всей организации. Они, конечно, обычно серьёзно вовлечены в работу над архитектурой ПО и возглавляют многие начинания компаний. Часто можно слышать, что инженеры называют «архитекторами» других инженеров, которые внесли наибольший вклад в проектирование некоей системы. И это, чаще всего, самые «сеньорные» инженеры уровня Staff+.

В этом материале я уделяю основное внимание инженерам-программистам, которые очень много занимаются архитектурой ПО. Это могут быть и не инженеры уровня Staff+. Это могут быть Senior-инженеры, или даже инженеры-учредители компании, которые росли вместе с ней.

Но существует и множество компаний с официальными должностями, которые называются «Программный архитектор». Это обычно достаточно традиционные компании, существующие уже около 20 лет или дольше. А некоторые компании намеренно создают должности наподобие должности «архитектора». Делается это для того, чтобы подтолкнуть тех, кто их занимает, к тому, чтобы они уделяли бы больше внимания бизнесу, соблюдению всяческих регламентов и законодательных требований.

В итоге — по мере того, как инженер профессионально растёт, он тратит меньше времени на создание программ и больше времени на решение других задач.

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

4. Какие архетипы «лучше» других?

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

Но если говорить об архитектуре ПО, то тут нет таких понятий, как «самый лучший» или «самый худший» подход. Архетипы, которые сильнее смещены в сторону теории, могут приносить огромную пользу. Например — в проектах очень больших масштабов. Кроме того, когда нужно принимать решения, которые сложно отменить, более «теоретические» архетипы могут предложить организованные подходы к планированию, могут детально всё продумать, а это — как раз то, что нужно в подобных ситуациях.

Ещё — представители более «теоретических» архетипов часто тратят больше времени на то, чтобы разобраться в особенностях конкретной компании, её бизнеса, и индустрии в целом. Это может привести к тому, что, когда потребуется принимать решение о том, что нужно создать компании, чтобы преуспеть, интуиция подскажет таким людям правильный ответ.

Но, в то же время, «практические» архетипы дают нам большой плюс в виде тяги к действию. Они готовы, без лишних размышлений, сразу же создавать ПО и писать код. Они свободно владеют кодовыми базами, они, реализуя свои идеи, действуют быстрее, чем большинство Senior-инженеров.

Для достижения целей, возникающих на разных стадиях развития команд и компаний, требуются различные архетипы:

• Ранняя стадия развития продукта. Здесь большую пользу принесут «практические» архетипы. Быстрое создание и развёртывание ПО на данном этапе важнее, чем подробное планирование. В конце концов, когда продукт только появился, ещё даже не ясно — будет ли им кто-нибудь пользоваться! Стремительная интеграция — это вотчина архетипов, близких к практике.

• Стадия роста и масштабирования продукта. Тут пригодится смесь «практических» и «теоретических» архетипов. На данном этапе важно понимать траекторию движения бизнеса. Часто это понимание достигается через беседы с разработчиками продукта, с дата-сайентистами, с руководством компании. Всё это отвлекает инженеров от клавиатуры, но их время тратится с пользой — на построение ментальных моделей, которые позволяют лучше понимать бизнес.

• Поддержка зрелого продукта. Этим могут заниматься и «теоретические», и «практические» архетипы. Обычно, когда продукт достигает такого уровня, в решении задач по написанию кода уже нет былой срочности.
  

  • Работа в сильно зарегулированном окружении обычно хорошо соответствует «теоретическим» архетипам. Дело в том, что в таких условиях важнее безопасность, а не скорость. А решение о любом изменении, воздействующем на бизнес, лучше несколько раз проверить и перепроверить.

  • Поддержка устаревших систем, как правило, подталкивает инженеров в сторону более «теоретических» архетипов, так как их работа, в основном, заключается в том, чтобы во всём разобраться и ничего не поломать, а не в том, чтобы сделать что-то новое.

• «Военное время» — это условия, когда фортуна благосклоннее относится к более «практическим» архетипам, готовым идти вперёд. Дело тут в том, что быстрое принятие решений и быстрая разработка в «военных» условиях важнее, чем достижение консенсуса. Тут наблюдается и меньшая терпимость к необходимости тратить много времени на принятие решений.

• «Мирное время» — это когда обычно процветают «теоретические» архетипы. Это время, когда предпочтительнее выглядит идея сделать всё как нужно и не наломать дров, а не идея скорости. Подробности об этом смотрите здесь.

5. Сочетание различных архетипов

Доказывая то, что нет «хороших» и «плохих» архетипов, я вспоминаю об одном идеальном архитекторе, с которым мне довелось работать. Но это был не один человек. Это была команда из двух людей. Один из них — представитель глубоко «теоретического» архетипа, а второй — архетипа, в высшей степени «практического».

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

Одна из наиболее плодотворных «пар архитекторов» всех времён — это Джефф Дин и Санджай Гемават из Google. Оба пришли в компанию в самом начале её развития и объединились для того чтобы сделать поисковую систему Google масштабируемой. Они взяли исходный прототип и сделали так, чтобы он мог бы обрабатывать объёмы трафика, росшие в экспоненциальном масштабе вместе с ростом Google. Ещё они создали MapReduce — базовую систему для обработки больших объёмов данных. Джефф и Санджай были первыми и единственными людьми, которых повысили до должности Google Senior Fellows, и были первыми инженерами компании 11 уровня. В наши дни Джефф Дин возглавляет подразделение Google, занимающееся искусственным интеллектом, а Санджай Гемават остаётся самым результативным индивидуальным контрибьютором Google.

В 2018 году издание «The New Yorker» опубликовало подробный очерк об этих людях. В этом материале моё внимание привлекли два интересных момента.

Первый — Джефф и Санджай написали большую часть своего кода, применяя парное программирование за одним компьютером. И они были чрезвычайно эффективными парными программистами. Вот что написано об этом в той статье:

«Парное программирование» — это когда два программиста работают за одним компьютером. Один играет роль «водителя» а второй — роль «штурмана». Хотя разработчики иногда и говорят о «парном программировании», они обычно представляют себе подобное партнёрство в свете избыточности, как если бы программисты играли бы роль «пилотов» и «вторых пилотов» авиалайнеров. Джефф и Санджай, в отличие от этого представления, иногда казались двумя половинками единого ума. У некоторых из их наиболее известных публикаций имеется около дюжины соавторов. При этом Билл Кугран, один из их менеджеров, вспоминает: «Они, работая в паре, были такими производительными и эффективными, что мы часто создавали вокруг них команды».

Я согласен с наблюдением, в соответствии с которым у инженеров редко встречается столь глубокое и долговременное сотрудничество по схеме парного программирования. Я видел, как множество инженеров пробовали это, и как они многому благодаря этому научились, но мне пока не удалось наблюдать инженеров, которые программировали бы в паре многие годы.

Ещё один момент, который меня зацепил в той публикации, касается того, насколько Джефф и Санджай от друга отличаются. Это — контрастные личности. Если бы мы попытались найти их аналогии среди архетипов, то они, определённо, относились бы к разным типам архетипов. Вот что об этом написано:

«Джефф отлично умеет предлагать новые безумные идеи и создавать прототипы», — говорит Уилсон Хсиех — их давний коллега. «Санджай был тем, кто строит на века». В жизни Джефф более общительный, а Санджай — более замкнутый. А в коде у них всё наоборот. Джефф пишет поразительный код. Он может в короткий срок выражать удивительные идеи, но, из-за того, что делает он это быстро, руководствуясь духом открытия, читатели этого кода могут не успеть за Джеффом. А у Санджая код социальный, располагающий к общению.

Силверстайн говорит, что код некоторых людей получается слишком свободным. На одном экране с кодом имеется слишком мало информации. Поэтому для того чтобы понять, что происходит, приходится постоянно туда-сюда прокручивать экраны. Другие пишут слишком плотный код. Когда на него смотришь — может возникнуть такая мысль, что читать его не хочется. А Санджаю как-то получилось найти «золотую середину». Когда смотришь на его код — осознаёшь, что он тебе понятен, но при этом одна страница содержит много информации. Когда мне нужно было добавить новый функционал в код Санджая, у меня возникало такое ощущение, что там уже есть места для моего кода. Я чувствовал себя Сальери [классический композитор, коллега Моцарта]. Я догадывался, что передо мной гениальное произведение. Но я не понимал того, как оно создано.

Когда представителей разных типов личности и архетипов объединяют в пары — это может дать потрясающие результаты. Доказательство этому — партнёрство Джеффа Дина и Санджая Гемавата. Но такие объединения очень редко бывают столь успешными. Я, до сих пор, сталкивался с таким лишь несколько раз.

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

Итоги

Архетипы инженеров-программистов — это интересная тема. Особенно — когда пытаешься понять, какой из них подходит твоим существующим или прошлым коллегам. Но в том, чтобы разобраться в архетипах, есть и ещё один плюс: это — инструмент для самоанализа.

Можно «разложить» людей из своей команды по разным архетипам. А к какому архетипу ваши коллеги отнесут вас, учитывая то, как вы проявляете себя в сфере архитектуры ПО? Что вам ближе — теория или практика?

Размышления об архетипах могут заставить вас задуматься о том, какой подход вы сознательно применяете к работе над программным обеспечением. Вы — «философ»? Или «интегратор»? А может вы — «охотник за новым и ярким»? И самое важное — относитесь ли вы к тому архетипу, к которому хотите относиться?

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

Помните о том, что эти архетипы описывают поведенческие сценарии, и о том, что поведение может изменяться и изменяется. Неважно то, к какому архетипу вы отнесли себя сегодня. Завтра вы можете изменить своё поведение и подход к работе, став представителем какого-то другого архетипа.

Используйте эти архетипы для того чтобы порефлексировать над тем, где вы находитесь в данный момент. Если вам не нравится быть представителем того архетипа, с которым вы соотносите себя сейчас — измените ситуацию так, чтобы приблизиться к архетипу, который лучше всего подходит для вас и для той среды, в которой вы работаете.

Узнали ли вы себя — сегодняшнего, или вчерашнего — в каком-либо из описанных здесь архетипов? Если хотите — напишите мне об этом. Рабочая обстановка в наши дни подвержена быстрым изменениям, а рост сектора удалённой занятости, вероятно, приведёт к появлению новых архетипов для новых времён. Известны ли вам архетипы, с которыми вы встречались на работе, но о которых я не писал? Если так — расскажите о них.