Предвижу, что за этот пост мне знатно прилетит, но я обещал его сделать, поэтому вот он 😎
Сегодня поговорим о том, какими хардами, по моему субъективному мнению, должны обладать специалисты на разных грейдах.
Без классического видеоформата, потому что в тексте можно нагляднее сравнить.
Дабы не дублировать строчки, писал только в сторону усложнения от грейда к грейду.
Ну что ж поехали... 💫
Стажеры
Тут все очень просто, делать самому с нуля, скорее всего, ничего не придётся, поэтому будет достаточно:
🔸Понимать, кто вообще такой аналитик и его роль в команде;
🔸Уметь читать схемы в базовых нотациях, чтобы проще было погружаться в проект;
🔸Понимать разницу между клиентом, сервером и базой данных;
🔸Отличать FE и BE разработчиков друг от друга;
🔸Иметь представление о популярных форматах (json, XML).
Джуны
Как показывает мой опыт, любое профильное образование поможет вам зайти сразу сюда, минуя ступеньку стажёра:
🔸Уметь внятно описывать сценарии работы системы, не важно в каком формате;
🔸Моделировать схемы в базовых нотациях (UML, BPMN). Касательно UML, сильно не упарывайтесь, будет достаточно ER, Sequence и в редких случаях use-case, ещё реже может пригодиться data flow;
🔸Отличать аутентификацию от авторизации и понимать, зачем они нужны;
🔸Понимать, что такое REST API, уметь проектировать с нуля новые эндпоинты, а также понимать, чем HTTP-методы отличаются друг от друга;
🔸Чуть-чуть знать о брокерах сообщений, достаточно понимания на уровне "черного ящика";
🔸Если говорить о базах, то будет достаточно понимания реляционных СУБД (связи и типы данных, без усложнения) и написания простых SQL-запросов на уровне join.
Мидлы
Основная прослойка специалистов, с самым большим разбросом, поэтому описываю ключевые, как мне кажется, моменты:
🔸Проектирование отдельных сервисов системы с нуля, без глубокого погружения в архитектуру;
🔸Для этого сервиса спроектировать интерфейсы (REST, gRPC и тп);
🔸Понимать отличие JWT от API KEY;
🔸Если есть работа с брокерами, то описать, что, как и в каком формате;
🔸Работу брокера, который используется на проекте, желательно знать поглубже, хотя бы на уровне балансировки сообщений;
🔸Проектировать модели данных с нуля для отдельного сервиса;
🔸SQL на уровне понимания FWGHSOL и написание простых запросов для анализа, без всяких оконных функций, хранимых процедур и тд;
🔸Уметь читать и править С4.
Синьоры
Когда ты почти архитектор, но ещё не принял этого:
🔸Подготовка архитектуры с нуля целых модулей (несколько сервисов) существующей системы со всеми вытекающими;
🔸Проектирование интеграций уже превратилось в рутину, независимо от технологии и способа;
🔸Помимо глубокого понимания устройства брокеров вашего проекта, неплохо понимать, в каких случаях применять нативные коннекторы и тп;
🔸Есть опыт работы и проектирования различных баз под разные задачи (OLAP, кеши, графы и тд);
🔸К теме работы с данными ещё круто понимать, что такое CDC и когда его применять;
🔸Балансировка нагрузки, многопоточность, прокси, CDN — не просто фоновый шум в созвонах, а понятные инструменты;
🔸Описание всего этого хозяйства в С4, желательно в DaC формате.
Архитекторы
Тут всё ещё проще, чем у стажёров: "Всего побольше и можно без хлеба"
🔸Чем больше кругозор технологий, тем лучше, поэтому услышали новое слово, сходили, почитали, взяли на вооружение. Глубоко копать не нужно, пока речь не идёт о реальном внедрении, а то голова лопнет.
Отдельное внимание хочу обратить на то, что нигде не писал про "самостоятельность", "принятие решений" и тд. Я считаю, что человеческий фактор присутствует на всех грейдах, поэтому хоть стажеру, хоть архитектору обязательно нужно ревью от коллег и взгляд со стороны 🔍
А размазывать ответственность "коллективными решениями" — это вообще мёд 🍯
Ваш опыт и матрицы компетенций внутри компаний 100% могут отличаться, буду рад, если поделитесь в комментариях, обсудим 👍
Про использование ИИ специально не написал, расскажу отдельным постом :)
🔝 Паблик VK
😀 Системный анализ | Дмитрий Помаскин