Каждый раз рассказывая свой доклад про архитекторов качества я слышу один, самый популярный вопрос: "С чего начать?" - Хороший вопрос! Но прежде чем на него ответить, я предлагаю задаться таким вопросом: "А подходит ли это вам?"
Архитектор - это человек, у которого много, очень много ответственности и очень мало влияния на реализацию архитектурного решения! Вне зависимости от того, какой это архитектор: архитектор решений, архитектор качества или системный архитектор.
Сеньоры, мидлы и даже джуны (разработчики/тестировщики) ежедневно влияют на качество проекта тем, что разрабатывают и тестируют код. Девопсы следят и поддерживают инфраструктуру проекта. Лиды ежедневно влияют на качество проекта, работая с командами. Архитектор же не работает ни с кодом, ни с командами, ни с проектными процессами. Его влияние не такое явное, и ограничено его сферой деятельности по построению архитектуры. Архитектура должна быть проработана, удовлетворять требованиям заказчика как явным, так и неявным, и затем передана в работу команде. После передачи архитектуры в работу заканчивается и влияние архитектора, далее архитектор только корректирует нюансы. Но при этом ответственность за проект и за эффективность проекта все равно остается на архитекторе. Работа архитектора - это как дизайн-проекта дома или квартиры, который заказчики видят красивым при визуализации, но качество его реализации зависит еще и от строителей. Т.е. соответственно, архитектор отвечает за все, практически не имея физической возможности повлиять на качество работы.
Возвращаясь к исходному вопросу, если это вас не смущает и не пугает, то архитектор – ваша стезя.
Так с чего же начать?
Конечно, начать со списка навыков, которыми должен обладать архитектор, провести соответствие с собой, какие навыки надо подтянуть, а какие необходимо развить.
Навык коммуникации
Один из основных навыков архитектора - это навык коммуникации! Иначе говоря, этот человек, у который soft скилы становятся hard скилами, т.к. это тот человек, который должен донести виденье заказчика команде и минимально исказить это видение в процессе. Или, если мы говорим об архитекторе качества, то донести до заказчика важность и необходимость хорошего, разностороннего тестирования, а команде, как это тестирование проводить. Это уже не только технический человек, а больше эмпатичный, цель которого сделать всех счастливыми. Для успешной коммуникации есть целый ряд методик, проведение которых и изучают в школе архитекторов. Но развивать этот навык надо с самого начала (рождения желательно), на уровне архитектора - уже поздновато, но при желании можно. Например, при помощи специальных упражнений или игр.
Навык быть лидером
Следующий навык, которым должен обладать архитектор - это навык лидера, причем в нашем случае, это навык неявного лидера, этакие серые кардиналы, которые способны увлечь за собой не только джунов интересной идеей, но и лидов команд, у которых обычно критическое мышление развито хорошо, и к интересным идеям они относятся с опаской. Этот раздел в школе архитекторов не изучают, подразумевается, что на эту роль приходят люди с развитыми лидерскими качествами. Вот пару ресурсов, которые рассказывает о лидерских качествах: развитие лидерских качеств и 12 социальных навыков, которые совершенствуют работу руководителей IT-проектов.
Технические навыки
Технические навыки включают в себя: знание доменной области, знание процессов разработки, тестирования, установки приложений, знание работы с инфраструктурой, архитектурные стили, шаблоны и тактики.
Знание доменной области. Это знания подводных камней и возможностей обойти эти камни в какой-то конкретной области. Например, проблемы в gameDev будут отличаться от проблем при разработке или тестировании e-commerce. Это нарабатывается только опытным путем, и никак иначе. Почитав статьи, можно собрать информацию о типичных проблемах и как другие их решали. Но в реальности у каждого архитектора есть свое кладбище своих неудачных решений, на которых основан его опыт и знания, что можно или нельзя делать в этом домене. Более того, сеньерность архитектора увеличивается с количеством доменных областей, которые он знает.
Знание процессов разработки, тестирования, установки приложений, работы с инфраструктурой. Об этом очень много написано, существует огромное количество видео, тренингов. Тут каждому надо определить самому, какую область ему необходимо подтянуть и в каком количестве. Но хочу напомнить о базе, с которой начинается хорошая разработка и тестирование, которую сейчас несправедливо забывают - Роберт Мартин "Чистый код". Но справедливости ради, прикладываю статью и на альтернативное мнение "О книге Боба Мартина «Чистый код»"
Архитектурные стили, шаблоны и тактики. В IT как и у строителей существуют свои подходы для решения тех или иных проблем. Эти решения основываются на архитектурных стилях, шаблонах и тактиках.
Архитектурный стиль - это способ организации кода, который решает проблемы и предоставляет преимущества архитектурного решения . Например: клиент - сервер архитектура, монолит, микросервисная архитектура.
Архитектурный шаблон - это типовое решение для повторяющихся проблем. Говоря об архитектуре могу привести такие примеры: CQRS, шардирование.
Архитектурная тактика - это низкоуровневое решение конкретной архитектурной практической задачи.
Основной уклон архитектурных школ - это именно изучение стилей, шаблонов и тактик. Оставлю тут книгу, в которой хорошим и простым английским описаны практики архитекторов - Software Architecture in Practice (можно найти бесплатно в pdf формате). В следующих статьях я буду разбирать подробно эти практики.
Навык доверять
И самый последний навык архитекторов, который я хочу сегодня упомянуть - это навык доверять. Становясь архитектором надо четко осознавать то, что от некоторых привычных активностей и привычного контроля необходимо отказаться. Т.е. ответственность за код теперь лежит на плечах разработчиков, ответственность за тестирование - на тестировщиках, а командами управляют лиды команды. Архитекторы обычно - это бывшие лиды, вышедшие из сеньеров, и они знают как писать код, как делать ревью кода, как распределять задачи "лучше всех". Но на этом уровне необходимо команде доверить делать свою работу! Этот навык тоже развивается и начать можно с соответствующей литературы. Доверие в командах: зачем это нужно и как построить, Доверие в бизнесе
Заключение
Это статья - введение, которая только дает общие понятия, что необходимо развивать архитектору. Как видите, в навыках архитектора нет ничего специфичного, кроме знаний и подходов к построению архитектур. В остальном же - это все те же навыки, что каждый из нас использует в работе ежедневно.
В дальнейшем цикле статей все понятия, описанные выше, будут специализированы и раскрыты именно с точки зрения работы архитектора:
с кем архитекторы общаются и какие тактики общения и для чего при этом применяют,
разобраны архитектурные стили, шаблоны и тактики на примерах,
и так же прольется свет на такую загадочную деятельность как preSale,
и многое другое!
BugM
Простите. А уметь писать код совсем не нужно, да?
irishaspir Автор
А вы внимательно статью читали?
На всякий случай подсвечу еще раз:
BugM
«Навык доверять» плохо похоже на на «Навык писать код»
powerman
Архитект, который прекращает регулярно писать код, через всего-то 3-5 лет превращается во вредителя. Устоявшегося термина для таких нет, иногда называли "воздушный архитектор" (в контексте — строитель воздушных замков) или "бумажный архитектор", но по сути — это вредитель, потому что придуманные им архитектуры создают больше проблем чем решают, поэтому разработчики склонны полученные от такого архитектора документы просто втихую игнорировать (и их сложно за это винить!). При этом он сам продолжает считать себя суперпрофи и что он всё знает лучше других, что только осложняет ситуацию. У нас область такая, всё очень быстро меняется, и на одном чтении профильных статей, не "щупая ручками" — долго сохранять квалификацию просто невозможно.
irishaspir Автор
А что это за архитектор который за 3-5 лет теряет квалификацию, а что он все это время делает? Ничем не интересуется? Ничего не изучает?
powerman
Мало читать про технологии, их надо щупать руками, причём на реальных проектах. Иначе очень быстро отрываешься от реальности.
irishaspir Автор
Совершенно с вами согласна, но с оговоркой, если разговор идет про архитекторов первых уровней «джунов», максимум «мидлов». А дальше с увеличением уровня архитектора идет развитие целых направлений, а тут уже код смотреть слишком мелко и даже «вредно».
ggo
По вашему, чувак, который умеет классно проектировать здания, просто обязан уметь классно класть кирпичи и штукатурить?
;)
Чувак, который умеет классно проектировать ракеты, просто обязан быть классным сварщиком и фрезеровщиком? И при этом обязан варить и фрезеровать регулярно, иначе потеряется навык проектирования ракет?
;)
powerman
По-моему, некоторые аналогии просто напросто некорректны. Проектирование софта часто пытаются сравнивать с проектированием зданий, но столь же часто приходят к выводу, что несмотря на некоторую схожесть, это всё-таки совершенно разные вещи.
ggo
А можете развернуто пояснить, что принципиально отличает софтостроения от хардостроения?
Ну кроме материальности объектов приложения усилий. Вследствие чего существенно сокращается цикл: появилась идея -> получил готовый результат.
Чем принципиально отличается работа проектировщика ракеты от работы проектировщика большой ИТ-системы?
powerman
Развёрнуто — нет времени, извините. Плюс я не проектирую ракеты, так что конкретно сравнить сложно. Но я могу намекнуть: дома и ракеты не перепроектируют в режиме agile непрерывно на всём протяжении их постройки, плюс технологии используемые при их создании не меняются пару раз в год.
ggo
Ну тут вы начали утрировать.
Agile, смена фреймворков пару раз в год и прочее — это все следствие нематериальности объектов усилий. Цикл «идея -> результат» схлопывается до минут, часов, дней. Да, с материальными объектами так не получается. Да, обратная связь с софтостроении существенно быстрее.
Но деятельность проектировщиков больших артефактов (домов, ракет, ИТ-систем) принципиально не поменялась.
И умение писать классный код, очень полезное умение, но очень опциональное для архитектора. Такое же опциональное, как умение писать sql-запросы, как умение администрировать ОС и БД, и куча прочих умений и знаний, которые задействованы в реализации большой ИТ-системы.
BugM
И получается очередной менеджер. Местами полезный даже. Но к разработке он не имеет никакого отношения. Разработчики сами будут думать как писать и проектировать. Все как обычно.
maxim_ge
Можно зайти несколько с иной стороны. Укладку кирпичей можно автоматизировать так, что результат будет выше среднего. Хороший Software Developer не "автоматизируется".
ggo
А что есть такое «автоматизация»?
Если смотреть на нее в несколько более широком смысле, то автоматизация это когда ты свою головную боль перекладываешь на некое решение. И стоимость владения этим решением тебя беспокоит меньше, чем снятая головная боль.
Если смотреть на автоматизацию с этой колокольни, то замена разработчика, это куча различных вариантов: покупка готового коробочного решения, использования готовых библиотек и фреймворков и т.д. Приснопамятный serverless опять же про автоматизацию. Тебя не интересует, что там под капотом, тебя, в общем случае, волнует только — приносит ли serverless-сервис пользы больше, чем ты за него платишь.
Т.е. деятельность Software Developer вполне себе «автоматизируется». Конечно, кто-то может сказать, что Software Developer все равно нужен, пусть и в меньших объемах. Но так и в строительстве несмотря на автоматизацию операции «класть кирпичи» (в современных стройках классические каменщики остались для очень узкой ниши работ), люди-строители все равно нужны.