На каком уровне системный архитектор должен знать технологии?

Question

[Алексей Николаев]

Доброй ночи.
Системные архитекторы - вторые после бога, определяющие путь развития продукта и стек используемых технологий. Соответственно, вполне логично, что архитектор должен глубоко знать все и обо всем: базы данных (широкий спектр), ЯП (широкий спектр), фреймворки (широкий спектр), быть в курсе достоинств и недостатков каждого, чтобы, таким образом, выбирать оптимальный набор технологий для каждого конкретного случая. Кроме всего, архитектор должен хорошо уметь в системное администрирование.

Однако не секрет, что даже в своем узком стеке из одного ЯП и ключевых фреймворков среднестатистическому программисту может быть непросто успевать за темпом развития отрасли, и тем более, держать в голове хотя бы ключевые моменты текущего положения вещей. Full-stack разработчикам сложнее в пару-тройку раз, т.к. у них как минимум два рабочих ЯП и в два раза больше технологий.

Исходя из этого, назревает вопрос: насколько сверхчеловеком должен быть системный архитектор, и во сколько лет он должен потерять девственность насколько глубоко он должен знать каждую технологию, включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам? Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит? Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Заранее спасибо.

Answer 1

[Станислав Макаров]

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?

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

Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).

Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно:

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

Comments

[Алексей Уколов]

Прекрасный ответ. Это я как тех. дир. говорю :)

[Everything_is_not_so_bad]

Можно ссылку про контейнеры в винде, пожалуйста?

[Станислав Макаров]

Роман Мирр
это про контейнеры:
https://msdn.microsoft.com/en-us/virtualization/wi...
https://msdn.microsoft.com/en-us/virtualization/wi...

это конкретно про докер:
https://blog.docker.com/2016/09/dockerforws2016/

[Everything_is_not_so_bad]

Станислав Макаров: благодарю

Answer 2

[parkito]

У архитекторов есть паттерны, которым они следуют. Эти патерны позволяют им видеть технологи несколько с иной стороны, нежели девелоперы. "Базовых" технологий не так уж и много, знать их на уровне среднего разработкчика - возможно. Многочисленные фреймворки это имплементации технологий. Все строится на более фундаментальных вещах. Однако их кругозор должен быть широк, чтобы охватить как можно больше технологий.

Answer 3

[Евгений]

Вы прям словами моего препода по программированию говорите. Он тоже боготворит системных архитекторов. По его мнению - это те люди которые проектируют/пишут либо ядро (а-ля Linus Torvalds) либо целиком ОС . Они живут в немного искаженной реальности и немного в другом пространстве времени, им доступны тайны мироздания, а еще они ходят на работе в домашнем халате и тапочках, и используют каретку CD-ROMа в качестве подставки для кружки с кофе.

Вадим Борисович - мое почтение.

Answer 4

[Михаил Усоцкий]

Ну системный архитектор понимается мною как работа на уровне аппаратной части. То есть он должен уметь заставить аппаратуру послать два байта до космической станции, кружащего вокруг Плутона. А так системный архитектор должен в совершенстве электронику и схемотехнику, цифровую схемотехнику (перечень технологий и архитектур тоже включается в этот список, но не обязательно всё знать; важно уметь схватывать на лету появляющиеся новые технологии, и разбираться в них), низкоуровневое программирование (можно и опкодами программировать) на ассемблере, а также системные языки программирования, прямо затрагивающиеся создания операционных систем, драйвер и иже подобными. А всё остальное уже не совсем для системного архитектора. Базами данных и прочими занимаются другие программисты.

Answer 5

[Елизавета Борисова]

У нас в вузах слово системный как-то неправильно трактуется повсеместно. Даже код специальности "системный программист" зачастую вообще не соответствует программе.
По поводу архитекторов, стоит отметить, что для веба это крайне редко выделено в отдельную позицию. За архитектуру отвечает техлид/тех.дир или старший разработчик, решения принимаются из совокупности своего и внешнего опыта.

Comments

[Алексей Николаев]

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