AT
Я бы использовал в названии позиции слово архитектор когда речь идет о 2-х или большем количестве команд разработки
Size: a a a
2019 September 20
SB
Замечу, что и композиторы, и дирижёры обычно играют на *нескольких* музыкальных инструментах. Это не значит, что они делают это во время концерта, но, однако, регулярно делают во время репетиций.
PS
Замечу, что и композиторы, и дирижёры обычно играют на *нескольких* музыкальных инструментах. Это не значит, что они делают это во время концерта, но, однако, регулярно делают во время репетиций.
А архитектору микросервисной архитектуры, я так понимаю, предлагается выучить 5-6 языков, несколько платформ и до кучи devops, чтобы соответствовать этому высокому статусу?
SB
Ну 2-3 на профессиональном уровне, еще 2-3 на обзорном уровне. А девопс - это про ответственность, кстати, а не про технологии.
AP
Petr Shmotov
А архитектору микросервисной архитектуры, я так понимаю, предлагается выучить 5-6 языков, несколько платформ и до кучи devops, чтобы соответствовать этому высокому статусу?
Как будто это что-то сложное. Нет, дело в другом. Просто времени на написание кода нет, да и незачем тратить ресурс архитектора на кодинг
PS
Ну 2-3 на профессиональном уровне, еще 2-3 на обзорном уровне. А девопс - это про ответственность, кстати, а не про технологии.
А зачем, если не секрет, ревью кода сеньоров проводить?
SB
Для понимания, как минимум, того, что на барабанах и арфе одну и ту же мелодию не сыграть ;-)
PS
Для понимания, как минимум, того, что на барабанах и арфе одну и ту же мелодию не сыграть ;-)
Вы же прекрасно понимаете, что в данной области каждые полгода выходят обновления, языки меняются, и знания архитектора без постоянного мониторинга изменений теряют ликвидность. Предлагается наравне с разработчиками следить за всеми нововведениями, или оперировать устаревшими данными, показывая некомпетентность в вопросе? )
PS
Для солюшн архитекторов это ещё возможно, с оговорками, для энтерпрайз-системных-итд смысла не имеет 🤷♂
PO
Я бы использовал в названии позиции слово архитектор когда речь идет о 2-х или большем количестве команд разработки
Команды на проектах разные.
PO
И не связаны.
AP
Petr Shmotov
Вы же прекрасно понимаете, что в данной области каждые полгода выходят обновления, языки меняются, и знания архитектора без постоянного мониторинга изменений теряют ликвидность. Предлагается наравне с разработчиками следить за всеми нововведениями, или оперировать устаревшими данными, показывая некомпетентность в вопросе? )
Кстати вот не соглашусь. Я вообще не понимаю, откуда взялся этот миф про ИТ, который слышу сколько себя помню. Рюшечки меняются, фундаментальные же вещи крайне редко появляются новые. Тяжело тем, кто плохо шарит в фундаменталке и мыслит предметно - им и каждый ЯП как новые ворота, и каждый новый продукт с нуля изучать
PS
Кстати вот не соглашусь. Я вообще не понимаю, откуда взялся этот миф про ИТ, который слышу сколько себя помню. Рюшечки меняются, фундаментальные же вещи крайне редко появляются новые. Тяжело тем, кто плохо шарит в фундаменталке и мыслит предметно - им и каждый ЯП как новые ворота, и каждый новый продукт с нуля изучать
Чтобы знать фундаментальные вещи, достаточно почитать базис ООП и про структурные языки. Как, например, в Яве сейчас происходит наследование или публикация интерфейса - это архитектору зачем, что это даст? Я знаю несколько языков, но в работе архитектора это не помогает от слова совсем - оперирую технологиями и возможностями, а не языковыми конструкциями.
AP
AP
но выяснить конкретную конструкцию, если знать, что тебе нужно - дело минуты
AP
ну если вдруг программисты в ступор впали
PO
Такой набор подойдет?
- Разработка и согласование концепций, технических требований, сценариев взаимодействия информационных систем и их компонентов
- Определение правил и ограничений при интеграции компонентов систем, интеграции с внешними системами
- Проектирование программных интерфейсов (API) и баз данных
- Разработка технической документации
- Проведение анализа применимости решений, сравнение различных вариантов решений, выбор решений
-Архитектурный контроль разработанных решений:
- Контроль Технических Заданий, Технических Решений, и другой технической документации на предмет соответствия разработанному архитектурному решению
- Оптимизация и рефакторинг функциональности решений
- Разработка и согласование концепций, технических требований, сценариев взаимодействия информационных систем и их компонентов
- Определение правил и ограничений при интеграции компонентов систем, интеграции с внешними системами
- Проектирование программных интерфейсов (API) и баз данных
- Разработка технической документации
- Проведение анализа применимости решений, сравнение различных вариантов решений, выбор решений
-Архитектурный контроль разработанных решений:
- Контроль Технических Заданий, Технических Решений, и другой технической документации на предмет соответствия разработанному архитектурному решению
- Оптимизация и рефакторинг функциональности решений
Pavel, это описание к техлиду?
SB
А базы данных знать надо? А брокеры сообщений? А стриминговые платформы? А инфраструктуру?
SB
Это имхо все такие же технологии, как и язык.
PO
И вот ещё, может быть, в ваших компаниях это будет кому то интересно.