Шаблоны документации – пустая трата времени или действительно полезно?

Рассказываю, почему шаблоны важны

🥲 Что если их нет

Недавно работал на проекте крупной компании, где было замечательно все – большая команда, интересный продукт, слаженные процессы, команда СА. Документация в виде SRS на каждую часть системы на первый выглядела классной и исчерпывающей

Но потом я вчитался и понял, что документация несколько хаотичная 🫠. Cтруктура страниц, содержимое, используемые макросы, стиль написания переменных и прочие детали отличались у каждого аналитика

Поинтересовался, есть ли шаблон доки – сказали нет. Может, сделаем? Да, как-нибудь потом ❌

К чему это привело за почти год работы:
🤍 Непонятно, что брать за референс при создании своей доки
🤍 Постоянные недоумения при кросс-ревью: не на что опираться
🤍 Старший аналитик часто отходил от своих же требований и требовал следовать им: а ничего и не предъявишь
🤍 Разработчики возмущались, почему у нас написано по-разному

Какой-то катастрофы не случилось, но мелкие моменты триггерили, потому что их легко можно избежать

🙌 Что если шаблоны есть

То к тебе минимум претензий по части оформления и структуре. Ты больше сосредоточен на сути задачи, а не тратишь время на то, каким шрифтом выделить названия переменных и прятать ли под спойлером use case, иначе не пройдешь ревью

Подобный опыт тоже был в другой крупной компании – шаблон стандартизирован, все изменения обсуждаются на весь отдел СА, никаких вопросов

📌 Когда применять?

Несмотря на очевидную пользу, шаблоны нужны не везде:

🤍Если проект с нуля и он еще не запущен
🤍Какое-то небольшое решение (например, корпоративное), которое поддерживают, но не развивают
🤍Начинающий стартап
🤍Если вы один аналитик на проекте

То есть если нет команды, проект новый, не развивается и не масштабируется – то на шаблонах вы потеряете время, и никто кроме вас на них не взглянет

————————

В итоге шаблоны – полезная вещь, но нужны не везде. Если сталкиваетесь с проблемами, описанными выше, стоит внедрить шаблоны или предложить это старшему аналитику

⬇ А вы пользуетесь шаблонами в своей работе?

💯 Да, использую
😐 Нет, не вижу смысла

#полезное_системный_анализ

Что такое Polling и причем тут Шрек 🐸

Помните, как во второй части Осел постоянно спрашивал Шрека, приехали они или нет? Делал он это чуть ли не каждую секунду, несмотря на отрицательный ответ

Этой узнаваемой сценой можно легко объяснить «асинхронный» механизм Polling, который встречается в системах

📌 Polling простыми словами

Polling (он же опрос) – периодическая отправка запросов от клиента к серверу с целью обновления информации. Если данные есть, сервер сразу отдает их. Цикл повторяется бесконечно, вне зависимости от ответа

Механизм создает иллюзию асинхронности путем периодической фоновой отправки синхронных HTTP-запросов: например, отправка GET-запроса каждые 5 секунд с клиента на сервер. Никакой магии!

Пример работы с Ослом и Шреком в комментах ⬇

💡Где используется?

Там, где нужно обновлять данные в а-ля реалтайм: чаты, новостные ленты, системы мониторинга

🔹 Пример из жизни

🤍В приложении для вызова такси polling можно использовать для обновления геопозиции клиента и водителя
🤍Сайт с новостями может раз в 10 секунд опрашивать сервер на предмет новостей
🤍В ненагруженном чате мы можем проверять статус пользователя (в сети или оффлайн)

👍 Плюсы

1. Просто реализовать
2. Из «асинхронных» механизмов наиболее понятный и простой
3. Можно контролировать частоту запросов

👎 Минусы

1. Холостые запросы создают бесполезную нагрузку на сервер
2. Под капотом это все же синхронный механизм, а значит есть задержки при получении данных
3. Не подойдет, если система нагруженная – если много пользователей, сервер от такого пинга приляжет поспать

💪 Старший брат Long Polling

У Polling есть «продвинутая версия» – Long Polling. Почему длинный? Когда клиент отправляет запрос на сервер, тот открывает соединение на какое-то время. Если данные будут, отправит их, если нет, не отправит

Так вместо 5 запросов за 5 секунд мы отправляем 1 запрос и держим соединение 5 секунд. Плюсы и минусы почти такие же, как выше

➡ Итог

Если вдруг спросят на собесе про эти штуки, или попадутся на проекте – не пугайтесь, все просто:

🤍Polling – раз в n-секунд опрашиваем сервер для обновления данных через HTTP-запросы
🤍Long Polling – при аналогичном опросе открывается соединение и держится n-секунд

Было полезно? Ставь лайк 👍

#полезное_системный_анализ

Рецензия на пост «Размывание целей» Марии Серёгиной 📝

Итак, я еще участвую в конкурсе «Продолжи мысль» от @systems_education и успешно прошел во второй тур 🎉

В этом туре нужно оставить рецензию на пост другого участника. Наиболее интересным мне показался пост «Тенденция к снижению производительности» или «Размывание целей» на примере чашечки кофе Марии Серёгиной

📌 О чем пост?

Про один из системных архетипов – и нет, не про паттерны архитектуры или другие технические приколы. Системные архетипы описывают скрытые закономерности в поведении, применимые к людям, организациям, корпорациям – в общем, в разных контекстах. Для каждого эти архетипы будут близки по-своему

Мария разбирает архетип «Тенденция к снижению производительности» на уровне организации, используя пример с кофейней ☕

Пример выбран удачно – ситуация откликнется каждому, но наверняка вы не задумывались, почему вы принимаете то или иное решение и к каким последствиям это приводит. Например: если кофе стал хуже, то можно не оплатить и возмутиться, или оплатить, но никогда больше не вернуться в эту кофейню 🤔

👍 Что понравилось

🤍Четкая структура поста – понятно, от чего и к чему идем
🤍Приятное оформление, ничего не отвлекает от темы
🤍Сама тема нестандартная и интересная
🤍Разбор архетипа на простом примере
🤍Оставлены ссылки на предыдущие посты – в итоге легко найти первоисточник и прочитать про другие архетипы
🤍Есть аналогия с IT-областью
🤍Не просто объяснение концепции, но и вывод, что с этим делать – в посте есть практическая ценность

💡 Что бы я улучшил

🤍Вторую часть поста читать сложнее, чем первую. Информации много, а абзацы к концу становятся длиннее и «тяжелее». Я бы разделил на два или сократил бы
🤍Было бы интересно прочитать о примерах из других сфер

🤔 Какие мысли вызвал пост

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

Например, когда работал копирайтером, ставил себе цель писать не менее 20000 символов в день. Но за этот день у меня могла быть учеба в вузе, я мог съездить за продуктами, потратить время на готовку – в итоге цель чаще всего не была достигнута 🥲

Другой пример – стремление накопить какую-то сумму, но минутные и импульсивные траты не позволяли этого достичь (то есть, цель была «размыта» мелкими тратами). В итоге опускал планку и убеждал себя, что это тоже нормальный результат

Думаю, это и есть описанный Марией архетип. Теперь я могу распознать его, но получится ли бороться с ним – вопрос времени и силы воли

—————

⬇ А что вы думаете про «Размывание целей»? Бывали ли такие случаи? Пишите в комментариях, интересно обсудить

#продолжи_мысль_SE

Как я НЕ стал техническим писателем 🙅‍♂️

В августе 2022 года я окончательно распрощался с попытками работать инженером и решил входить в IT. Рассказываю, как это было

🥵 Войти в айти

Из навыков тогда – инженерное образование и годы копирайтинга (помните, писал уже о них ранее?). Складываем два плюс два, получаем наиболее вероятную точку входа – технический писатель

Прошел экспресс-курс на технического писателя за 2 недели и 7000 руб. Полностью переписал резюме под тех писателя, а в качестве опыта работы взял 6 лет копирайтинга 😏. Начал откликаться, и буквально через пару дней меня пригласили на собес в Москва Сити 🌈

Подготовился за день, на самом собесе отвечал неуверенно – я тогда не знал ни про API, ни про БД, ни еще что-то. Но как-то рассказал, думал, что провалился – но меня приняли

Но не все так просто

🤔 В чем подвох?

И вот я начал работать техническим писателем. Документации на проекте не было, поэтому я изучал код, чтобы восстановить архитектуру, описывал API, макеты интерфейса, функциональные требования, базу данных, затем ставил задачи на разработку… Что-то тут не так

Через четыре месяца осознал, что выполняю работу системного аналитика, а не технического писателя. ГОСТ, docs as code, инструкции, мануалы – всего этого тут не было. Максимум писал release note, и все. Все остальное подходило под описание работы СА

А по записи в трудовой книжке я вообще был программистом 😁

🏃‍♂️‍➡️ Что я сделал

Осознав это, в январе 2023 поступил на четырехмесячный курс СА. Знания сразу применял – дорабатывал то, что уже написал, и старался внедрить практику СА в команде, т.к. в процессах творился хаос

И уже через 2 месяца стало даже получаться, но на работе произошел лютый треш, из-за чего пришлось срочно увольняться. Это достойно отдельного поста

После этого искал работу уже СА, пытался пройти несколько собеседований – но говорили, что опыт маловат. Попросил помощи у компании, которая меня обучала, в итоге устроила к себе на аутстафф

Там немного набрал опыта, структурировал знания и уже через пару месяцев устроился в хорошую компанию сразу на Middle+

———————

Вот такой у меня путь в IT. В итоге техническим писателем я не проработал ни дня, получилось «перепрыгнуть» эту ступень, что и так было в планах. Работодатель просто не знал, кто такие СА, и думал, тех писатели от слова «писать», а писать доку надо было срочно

⬇ А как вы начинали свой путь в IT?

#истории_системный_анализ

Я – Senior. Что дальше? 🤔

Рассказываю свое видение дальнейших тропинок ведущего системного аналитика

🤍 Team Lead/Руководитель СА

Меньше hard skills, больше soft skill. Меньше работы с задачами, больше с людьми: найм и увольнение, контроль состояния, принятие различных решений и ответственности за них

Рекомендую:
🤍Попробовать менторство (от 2 и более людей)
🤍Прокачать теорию управления людьми – через литературу или курсы
🤍Просить руководителя делегировать часть своих задач

Заметил, что чаще стали появляться курсы для тимлидов – знаю, такие есть на Отусе и Стратоплан. Из книг советую начать с «Пять пороков команды: притчи о лидерстве»

🤍 Архитектор

Если развивать hard skills, то со временем можно попробовать стать архитектором. Они бывают разные:

🤍Системный архитектор (Software Architect)
🤍Архитектор решений (Solution Architect)
🤍Корпоративный архитектор (Enterprise Architect)

Их обязанности отличаются, но, как мне пояснил архитектор с опытом, на практике их не всегда разделяют, особенно в небольших и средних компаниях

Что делать, если хочешь уйти в архитектуру (общие рекомендации):
🤍Изучать теорию по архитектуре – через литературу или курсы
🤍Найти проект с микросервисной архитектурой, где СА вовлечен в задачи архитекторов и разработчиков
🤍Брать сложные задачки, которые требуют проработки архитектуры
🤍Осваивать технологии (OpenShift, Docker и др)
🤍(необязательно) Освоить язык программирования и написать pet-проект

➡️ Подробности – в следующем посте

🤍 Tech Lead

Организует техническую работу команды, принимает ключевые архитектурные решения, менторит разработчиков, а также может писать код и закрывать сложные задачи. В отличие от Team Lead, фокус в техническую сторону. В отличие от Архитектора, больше вовлечен в код.

На мой взгляд наименее вероятная ветка перехода, нужен опыт разработчика 🤯

🤍Разработка/QA/DevOps/иная смежная роль

Если системный анализ уже не нравится, или есть желание попробовать что-то новое, то рядом много профессий – разработка, тестирование, управление проектами, аналитика данных, системная инженерия.

Правда, придется доучиться и откатиться по ЗП и грейду 💸 – но опыт СА определенно будет плюсом

Шаги по смене профессии очевидны: обучаемся через курсы или книги, дорабатываем резюме и пробуем устроиться на работу

🤍Фриланс/подработки

Можно остаться Senior и укреплять свои hard и soft skills без смены рода деятельности, и направить внимание на:

🤍Фриланс – проекты вне основной работы
🤍Менторинг – персональное обучение
🤍Преподавание в онлайн-школах – тоже обучение, но на широкую аудиторию
🤍Личный бренд – выступление на конференциях, участие в активностях сообщества, развитие своего блога
🤍Открытие своего дела – онлайн-школа, компания по разработке

Скиллы тоже будут прокачиваться, но горизонтально, однако никто не мешает позже попробовать лидерство или архитектуру

————————————

💡 В следующем посте поделюсь своим планом по переходу в архитекторы – что уже сделал, что предстоит, возможно ли это вообще и что я думаю по этому поводу

#полезное_системный_анализ

Не забывайте надевать футболку перед созвоном 🙈

Еще готовлю посты про свои планы по переходу в архитектуру – там будет много интересного и полезного, но потребуется больше времени

А пока держите кринжовую историю о том, как мы вели демо с элементами легкой эротики 🔞

Итак, история

Жаркое лето, очередное демо на проекте 👨‍💻. Вели его в паре с разработчиком на удаленке. На созвонах со своими сидим без камеры, но перед заказчиком обязательно включаем ее для хорошего тона

Начали, но разработчик, который сначала не включил камеру, вспомнил и включил ее уже во время демо. Лучше бы он это не делал 🫣

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

Тем не менее, легкую эротику нужно было прекратить, поэтому мы начали агрессивно спамить разработчика в рабочие и личные чаты 🆘. Тот увидел эту оплошность, скрыл камеру, но не сдался и продолжил вести демо. Его титанической выдержке можно только позавидовать

Что в итоге?

Как итог – ничего страшного не случилось, разработчик поймал стыд, мы же (и заказчик тоже) просто запомнили эту юморную ситуацию. Однако если бы перед экраном сидели корпораты в костюмах, думаю, было бы не до смеха ❌

———

Я сам частенько боюсь этого конфуза, т.к. на работе общение с камерами – обычное дело. Но когда солнце нещадно жарит, можешь банально забыть надеть футболку. Видел и другое - кто-то работал в трусах и во время созвона вставал в полный рост, что было тотальной ошибкой 😁

⬇ А какие у вас были кринжовые ситуации на работе, связанные с камерой?

#истории_системный_анализ

Путь до архитектора. Часть 1 🚀

Как и обещал, рассказываю о своих планах по переходу в архитекторы

Разбил пост на три части – тут делюсь чек-листом по темам архитектуры ПО. Им со мной поделился мой ментор – опытный архитектор

Делюсь доской в Холст – там весь чек-лист можно рассмотреть подробнее. А еще оригинал картинки в комментариях

📌 Чек-лист по темам

🤍 Теория по проектированию систем (System Design)

Must have темы для изучения, развитие базы системного аналитика:

🤍Паттерны архитектуры: монолит, сервисная, микросервисная, Serverless, корпоративная
🤍Сеть: топология, DNS, OSI & TCP/IP, протоколы
🤍Интеграции: REST, SOAP, GraphQL, gRPC, WebSockets, Webhook, Kafka, ActiveMQ, RabbitMQ
🤍Прокси: балансировщики нагрузки, Reverse Proxy, API Gateway
🤍Процессные движки: BPM, Activiti, Camunda
🤍Базы данных: DML & DDL, транзакции, ACID, изоляция, нормализация, реляционные БД, нереляционные БД, in-memory БД, индексы, репликация, шардирование, профилирование, CAP-теорема
🤍Кэширование: CDN, клиентский кэш, серверный кэш
🤍BigData: Hadoop, S3, Spark
🤍Поисковые движки: Elasticsearch, Opensearch
🤍Безопасность: виды аутентификации, хэш-функции, SSL/TLS, HTTPS

🤍 Алгоритмы и структуры данных

Двигаемся далее и погружаемся в алгоритмы и структуры данных:
🤍Алгоритмы: понятие сложности алгоритмов, оценка сложности
🤍Структуры данных: массивы, списки, очереди, графы, деревья, хэш-таблицы

🤍Frontend & Backend

Наиболее сложная и объемная часть для тех, кто ранее не программировал. И пригодятся темы только архитекторам, работающим с кодом

🤍Frontend: базовое понимание устройства (протоколы, веб-сокеты, cookie). В идеале изучить какой-нибудь язык (например, JavaScript) и написать небольшой pet-проект
🤍Backend: общие принципы работы (ООП, SOLID, Паттерны проектирования), изучение языка (например, Java) и pet-проект

🤍DevOps & Тестирование:

Не обязательно углубляться, достаточно изучить общие концепции и инструменты:
🤍DevOps: как устроен CI/CD, Docker, Kubernetes
🤍Тестирование: теория, интеграционные тесты, unit-тесты, Postman, Swagger, Charles

🤍Методологии разработки & Soft Skills:

Все что связано с управлением проектом и взаимодействием с людьми:
🤍Методологии: Waterfall, Agile, Lean
🤍Soft Skills: все, что с ними связано

И как все это осилить? 🤯

Курсы, книги, менторство, pet-проект, сложный проект на работе:

🤍Курсы. Дорого и эффективно. О курсах, которые для меня покрыли бОльшую часть тем System Design, расскажу в будущих постах
🤍Книги. Углубляют знания, полученные на курсах. Мне помогли Крис Ричардсон «Паттерны микросервисной архитектуры» и Алекс Сюй «Прохождение сложного интервью по System Design», о которых я уже писал
🤍Менторство. Хороший способ выявить пробелы и восполнить знания – проверено
🤍Pet-проект. Лучший способ попробовать все технологии и инструменты. И благодаря ИИ это будет не так сложно
🤍Сложный проект на работе. Это как кидать ребенка в воду, чтобы тот научился плавать

—————

💡 Если тоже хотите начать изучать архитектуру – сохраняйте пост себе, чтобы не потерять

Это была первая часть. Во второй части – список рекомендуемых книг, в третьей – мои мысли по поводу перехода в архитекторы

#полезное_системный_анализ

Путь до архитектора. Часть 2 🚀

Первая часть тут. Во второй – список годных книг по архитектуре в желаемом порядке чтения 📚

📌 Забирайте себе, чтобы не потерять

🤍Погружаемся в архитектуру

В целом о том, что такое архитектура и для чего нужна:

🤍«Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы»: Нил Форд, Марк Ричардс

🤍 Знакомимся с типами архитектуры и распределенными системами

Подробнее про типы архитектуры: монолит, микросервисы

🤍«Распределенные системы. Паттерны проектирования»: Брендан Бернс
🤍«От монолита к микросервисам»: Сэм Ньюмен
🤍«Создание микросервисов»: Сэм Ньюмен

🤍 Углубляемся в корпоративные приложения и интеграции

Некоторая информация в этих книгах устарела, но они такие же классические, как Вигерс:

🤍«Шаблоны корпоративных приложений»: Мартин Фаулер
🤍«Шаблоны интеграции корпоративных приложений»: Хоп, Вульф

🤍Думаем о будущем

Важная книга о том, почему архитектура должна быть эволюционной (то есть адаптироваться и меняться со временем):

🤍«Эволюционные архитектуры. Поддержка непрерывных изменений»: Нил Форд, Ребекка Парсонс, Патрик Куа

🤍Глубже изучаем модели данных

О том, почему проработка модели данных – это действительно важно:

🤍«Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»: Эрик Эванс
🤍«Изучаем DDD предметно-ориентированное проектирование»: Влад Хоронов

🤍Собираем все в кучу

🤍«Высоконагруженные приложения. Программирование, масштабирование, поддержка»: Мартин Клеппман

🤍А как же поддержка?

Следующие книги – про релизный цикл, доставку обновлений, поддержку систем, CI/CD и все такое:

🤍«Site Reliability Engineering». Надежность и безотказность как в Google»: Байре, Джоунс, Петофф
🤍 «Release it!! Проектирование и дизайн ПО для тех, кому не все равно»: Майкл Т. Найгард

🤍Про масштабирование и нагрузку

🤍«Масштабирование приложений. Выращивание сложных систем»: Ли Атчисон
🤍«Паттерны Kubernetes: Шаблоны разработки собственных облачных приложений»: Билджин Ибрам, Роланд Хасс

🤍Облака

Сложная и специфичная тема с облачными решениями, особенно востребованная в международных проектах

🤍 «Шаблоны проектирование для облачной среды»: Корнелия Дэвис

––——–––

В следующей части – о том, что успел изучить, что еще предстоит, какие бывают архитекторы и что из этого ближе к системному анализу

#книги_системный_анализ

Путь до архитектора. Часть 3 🚀

Всех с пятницей и хороших выходных! 🌴

Это заключительная часть серии постов про архитектуру (часть 1, часть 2). Расскажу про виды архитекторов в IT, что я сделал по плану и что еще предстоит

Архитекторы в IT 📌

Рассмотрим, какие есть архитекторы в IT, на примере строительства города

🤍 Корпоративный архитектор (Enterprise Architect)

Градостроитель, который видит план всего города и принимает решения, где будут новые жилые районы, промзоны, дороги и так далее. Принимает решения на высоком уровне

В IT такой человек занимается архитектурой всей компании/предприятия, которая состоит из множества решений. Вовлечен в бизнес-процессы и общается с топ-менеджерами, практически никогда не работает с кодом

🤍Архитектор решений (Solution Architect)

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

В IT архитектор решений занимается конкретным проектом (или проектами): собирает требования и подбирает технологии, платформы, сервисы для реализации. Редко вовлечен в код, больше работает с технологиями и проектированием

🤍Системный архитектор (Software Architect)

Отвечает за сложные системы внутри каждого дома: вентиляция, электроснабжение, лифты, отопление. Гарантирует, что все работает надежно и эффективно

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

Куда расти системному аналитику? 🤔

Узнавал информацию у компаний, которые обучают СА, у ментора, у ИИ, из других источников. И в итоге вижу два мнения:

🤍Solution Architect – наиболее частое мнение. Они тоже собирают требования, моделируют и проектируют, но более технически подкованы и смотрят на систему шире. Желательно, но не обязательно, уметь программировать
🤍Enterprise Architect – путь для «стратегов», кого интересует «большая картина». Такие архитекторы более погружены в бизнес-часть и понимают, как архитектурные решения влияют на всю экосистему компании

А Software Architect, на мой взгляд, наиболее подойдет для разработчика, а не СА

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

Мои мысли 💡

Обо всем этом я начал задумываться год назад, когда стал Senior. Прошел несколько курсов и прочитал несколько книг, что покрыло бОльшую часть тем по System Design из первой части

Недавно прошел тестовое интервью по System Design с ментором-архитектором. Ментор оценил мои знания как очень неплохие. По его оценке, уже через полгода могу претендовать на роли в архитектуре

Правда, я в этом сомневаюсь, у меня немного другой план:

🤍Поработать с высоконагруженным проектом с микросервисной архитектурой
🤍Брать сложные задачки с принятием решений
🤍Прочитать хотя бы 50% из списка книг из второй части
🤍Прокачать софт-скиллы
🤍Написать pet-проект а-ля Социальная сеть и пощупать разные технологии (особенно темный лес DevOps)

Без спешки и непредвиденных обстоятельств оцениваю переход в 1.5-2 года. Причем не могу сказать, каким хочу быть архитектором – пока у меня только самурайский путь без цели

——

Если посты на этой неделе были полезны, ставь 🔥

И как вы думаете, куда логичнее расти системному аналитику? Или may be свой вариант?

#полезное_системный_анализ

Собеседование в Samokat.tech (бывший) – или как вызвать аналитика на ковер 😱

Год назад думал о смене работы – и тут мне написала бывшая коллега из Samokat.tech с предложением. Решил попробовать, почему нет? И собес оказался запоминающимся – с негативной стороны

🤍Все начиналось хорошо

По структуре собеса все стандартно – первый этап с HR, второй с техническим специалистом, а третий с командой

Первые два этапа не вызвали сложности – классический скрининг, довольно интересная техничка на полтора часа. Мне нравится, когда технический специалист вовлечен в процесс и любит свое дело, для меня это положительный сигнал о компании 😍

И совсем не нравятся короткие технические собесы на 20 минут – писал о них ранее

🤍 Но настал этап общения с командой…

На встрече присутствовало несколько членов команды – системный аналитик, лидер команды, еще какие-то люди. Общение шло гладко, пока лидер команды не стал предупреждать о том, что СА у них раз в 1 или 2 недели вызывают на ковер 😏

Продукт связан с расчетом логистики, и за неточности расчетов и жалобы клиентов почему-то отвечает СА. Причем вызов на ковер звучал как обычное регулярное мероприятие, типа дейлика 🌾

Лидер команды то и дело ссылался на другого СА на звонке, но радости и эмоций на его лице я не увидел. Интересно, почему

Сразу представил картину – стоишь на экзамене или в военкомате перед длинным столом, за которым сидят суровые дядьки. Говорить можно только по разрешению, шаг влево, шаг вправо – расстрел🌾

Сомневаюсь, что в этом продукте настолько строго, но ассоциации были именно такие

С этого момента я начал сильно сомневаться, речь поутихла, в голове гуляла мысль: «А надо ли мне оно?» 😎. Идти на работу со страхом – ненужный стресс, которого и без того в жизни немало

Взаимного мэтча не произошло, мне пришел отказ – HR предлагала попробовать с другой командой, но желания не было. Еще смущал тот факт, что в тот момент Samokat.tech объединялся со Сбером, а подобные процессы для меня еще один ред флаг

———————

Через некоторое время узнал, что знакомая, которая рекомендовала это место, сама сменила работу 🤣. Я же рад отказу – наверняка в других командах другие процессы, но первое впечатление было испорчено

⬇ А как вы считаете, должен ли системный аналитик отчитываться за косяки продукта и нести полную ответственность? Пишите в комментариях

#собеседования_системный_анализ

API Gateway как бабка-вахтерша от мира IT 😼

Помните непреодолимый пост охраны в общаге, на предприятии, где-нибудь еще? Суровый мужичок или не менее опасная бабуля сидят за столом или у стойки, проверяют у всех пропуска, идентифицируют личность как терминатор – и решают, пропустить вас или нет 🤷

Если не идентифицировали – то не пропускают. Если узнали – то подскажут, куда идти

🤍Что такое API Gateway

В мире IT подобный пост охраны называется API Gateway (шлюз) – единая точка входа, через которую клиенты (мобильное или веб-приложение) общаются с бэкендом

API Gateway это паттерн микросервисной архитектуры, поэтому этот компонент бэкенда вы увидите там

🤍 Основные функции

У API Gateway куда больше полезных функций, чем просто проверка и маршрутизция запроса:

🤍 Единая точка входа – клиенту не нужно знать адреса десятка серверов
🤍 Маршрутизация – шлюз сам решает, к какому сервису направить запрос
🤍 Аутентификация и авторизация – может выступать вместо или перенимать функции сервиса авторизации
🤍 Управление трафиком – можно поставить ограничение для одного клиента (например, не более 1000 в минуту)
🤍 Кэширование – может кэшировать ответ в своей памяти и отдавать данные, не обращаясь к сервису
🤍 Мониторинг и логирование – шлюз формирует журналы запросов, что поможет при отладке и анализе работы
🤍 Агрегация данных – шлюз собирает ответы из нескольких микросервисов

🤍Пример работы

Есть запрос:

GET https://api.my-shop.com/my/orders – получение списка заказов

где https://api.my-shop.com – адрес нашего API Gateway

Порядок работы:

1 – От клиента запрос поступает на шлюз
2 – Шлюз проверяет авторизацию (JWT-токен) на валидность и получает ID пользователя
3 – Шлюз видит URL /my/orders и понимает, что это для сервиса заказов
4 – Шлюз отправляет внутренний запрос в Сервис заказа (GET /internal/orders?user_id=12345)
5 – Шлюз получает ответ 
6 – Шлюз отправляет ответ клиенту

Если нужно агрегировать данные – то между 4 и 5 шагами будет отправка других запросов и агрегация данных

🤍Мой опыт

На проектах, где были микросервисы, всегда был API Gateway. Где-то был задействован полнее (с функциями авторизации и управления трафика), где-то это был просто маршрутизатор

И на этих проектах, как СА, я просто знал, что API Gateway есть и выполняет определенные функции. Максимум моей работы – отобразить компонент на схеме архитектуры и описать возможности 🐸

Знаю при этом, что в крупных проектах, где несколько API Gateway, над каждым работает целая команда – и там, я думаю, СА вовлечен более детально. Если у вас есть такой опыт, пишите в комментах

—————

В итоге API Gateway – важный компонент микросервисной архитектуры, который принимает все запросы, проверяет их и отправляет нужным сервисам, а результат возвращает клиенту. Он разгружает внутренние сервисы и клиента, делая их независимыми, но при этом является единой точкой отказа

➡ Забирай себе, пригодится в работе с микросервисами или на собесах

#полезное_системный_анализ

👨‍💻 Вопрос, который мучает меня всю карьеру Системного Аналитика

Практически на каждом собеседовании спрашивают про SQL – где-то попроще, где-то посложнее с практикой в режиме реального времени. И при этом ни на одном из этих проектов я не написал ни единого SQL-запроса: хватало подключения к DBeaver для просмотра данных

При этом знаю других СА, особенно из области DWH, для которых SQL-запросы стали вторым языком после русского.
У меня это происходит так: практикуюсь с SQL либо перед собеседованием, либо для себя раз в полгода-год. Однако это как езда на велосипеде – если не практиковаться, то быстро забываешь

Но недавно нашел еще один способ поддержания этого навыка – читаю посты Дмитрия с канала Дима SQL-ит (Аналитика данных)

Дима — работает аналитиком данных в Wildberries 🛒

Пишет интересные посты про SQL с примерами таблиц и запросов:

🤍 SQL Ловушка: почему оператор NOT IN ломается, а EXISTS работает
🤍 Казалось бы, агрегатные функции в SQL (SUM, AVG, COUNT) просто считают значения — что тут сложного? Но есть скрытая ловушка: как они ведут себя с NULL?
🤍 Как работают конструкции ANY и ALL в SQL — объяснение на простых примерах

Также Дима не обходит стороной ИИ и их использование в работе и жизни — нашел для себя интересные варианты использования:

🤍Как за 400 рублей в год получить доступ к Claude, ChatGPT, Gemini и Grok через Perplexity и без использования VPN
🤍 Вайбкодинг — бесплатный аналог Cursor AI от Alibaba (Qoder)
🤍 Бесплатные нейросети для аналитики и кода
🤍 Бесплатная нейросеть от Google для работы с любыми материалами — NotebookLM

Но помимо этого Дима пишет не менее интересные посты про личную эффективность, выдержки из книг и просто личные мысли:

🤍Как за год стать в 37 раз лучше: конспект «Атомных привычек» - Джеймса Клира. Часть 1 и Часть 2
🤍10 идей для повышения эффективности, которые я усвоил из книги Максима Дорофеева (Джедайские Техники)
🤍Здоровье в IT: как я борюсь с сидячим образом жизни. Часть 1
🤍Мое понимание мира - прими неопределённость или почему истины нет, а есть только вероятность

Рекомендую подписаться: тут есть, о чем почитать

⬇️ А вы используете на работе SQL? Или эта тема вас также обходит стороной, как и меня? Пишите в комментариях

Обзор малоизвестного инструмента Structurizr + промт для ИИ 🛠

У кого ни спрошу, никто не знает про инструмент Structurizr. Пора это исправить

🤍Принцип работы

Structurizr – бесплатный инструмент для визуалиазации и документирования архитектуры в нотации C4. Используется код для отрисовки документации, как в PlantUML

Пример работы на картинке

🤍Как в нем работать

Сложность инструмента – в синтаксисе кода, который менее интуитивный, чем в PlantUML. Можете изучить его, или поступить проще и попросить ИИ сгенерировать код на промта (см. в комментах)

🤍 Переходим на сайт https://structurizr.com
🤍 Нажимаем на вкладку "Demo"
🤍 Генерируем код на основе промта в какой-нибудь ИИ
🤍 Вставляем код
🤍 Нажимаем кнопку "Render"
🤍 Вы великолепны!

В итоге, просто вставив результат, получим спроектированную архитектуру. Перед публикацией нужно проверить логику и, если что, поправить

🤍Особенности инструмента

🤍 Моделирование в нотации C4 – один из стандартов для архитектуры
🤍 Текстовая нотация – можно версионировать, легко менять, автоматизировать, поддерживать актуальность
🤍 Разные форматы экспорта – в PDF, PlantUML, Mermaid
🤍 Возможность совместной работы

⚠ Недостатки:
🤍 Сложный синтаксис
🤍 Зависимость от кода, что может отпугнуть
🤍 Ограниченная визуализация – нельзя править стрелки и прочие элементы
🤍 Некоторые функции (например, совместная работа) платные

🤍Когда и кому пригодится?

Инструмент ситуативный, в работе пригодится редко и при условии, что вы вовлечены в архитектуру. А ее можно отрисовать единожды, и потом только актуализировать

В своей работе использовал один раз на коммерческом проекте и один раз на обучении – однако благодаря инструменту это заняло меньше часа. Вручную C4, при этом, несложно рисовать, но если можно автоматизировать – почему нет?

————

➡ Если вы работает с архитектурой, или у вас задача отрисовать C4 – попробуйте Structurizr. Если не пригодится в работе – можно блеснуть знаниями на собеседовании. Уверен, оценят

Ставь 🔥, если было полезно и хочешь видеть обзоры других инструментов

#инструменты_системный_анализ
#промты_ИИ_системный_анализ

Версии HTTP – простой вопрос с собеседований 💡

Вопрос звучал так:

Какие есть версии HTTP и в чем их отличия?

Как СА я постоянно описываю интеграции, и не знал, что в первой версии HTTP был только метод GET, HTTP 1.1 используется более 15 лет, а HTTP 3 вышел недавно и активно внедряется 😱

Разберем версии HTTP на примере курьера

🤍 HTTP/0.9 (1991 г.)

Такого курьера вы бы не вызвали – он может привозить только одну вещь, и то без упаковки. После доставки сразу исчезает – и даже не предъявишь, если что-то пошло не так 😡

В базовой HTTP/0.9:
🤍Только метод GET
🤍Никаких заголовков, метаданных, кодов состояний
🤍По запросу приходил голый текст HTML
🤍Соединение сразу разрывалось

🤍 HTTP/1.0 (1996 г)

Этот курьер уже может передавать что-то другим лицам, а на посылках написано, от кого, кому, что внутри. Отправитель получит ответ, все ли ок, или что-то пошло не по плану

В HTTP/1.0:
🤍Появилась структура запросов и ответов
🤍Одиночество GET разбавили POST и HEAD
🤍Проблема – на один запрос одно соединение с клиентом, из-за чего сложные страницы грузятся долго

🤍 HTTP/1.1 (1997 г)

Уже через год наш курьер сильно подкачался 💪 – освоил новые методы работы, и не теряется после доставки товара, а остается на связи и может принести что-нибудь еще

В HTTP/1.1:
🤍Появились все известные нам методы (PUT, PATCH (2010), DELETE, OPTIONS, TRACE)
🤍Поддержка постоянного соединения

Эта основа веба используется по сей день

🤍 HTTP/2 (2015)

Гигачад-курьер отправляет разные заказы одному клиенту на грузовой машине по одной дороге. Улучшется эффективность, но если потеряем один товар, то вся доставка заблокируется, пока не найдем его

В HTTP/2:
🤍Синтаксис не изменился
🤍Появилось мультиплексирование – передача нескольких запросов и ответов в одном соединении TCP.

🤍HTTP/3 (2022)

Сын Яндекс.Доставки, курьер-супергерой, Сэм Бриджес. Вместо грузовой машины из прошлой версии этот гений использует мопеды, поэтому аварии ему не страшны 😼

В HTTP/3:
🤍Синтаксис не изменился
🤍Изменился транспорт: вместо традиционного TCP используется транспортный протокол QUIC поверх UDP, что улучшает производительность, делает потоки независимыми и ускоряет установку соединения

—————

Эта инфа поможет глубже понять REST, дать определение gRPC (который основан на HTTP 2), поразить собеседующего своими знаниями или просто станет интересным фактом

Забирай себе и ставь 🔥 , если узнал что-то новое

#полезное_системный_анализ
#собеседования_системный_анализ

Собесы раньше vs Собесы теперь 🙈

Вопросы на собесе раньше:
1. Как вас зовут?
2. Сколько вам лет?
3. Из какого вы города?
4. Что такое ФТ и НФТ?
5. Что такое REST API?
6. Что такое брокер сообщений?

Результат: поздравляем, вы приняты

Вопросы на собесе теперь:
1. Что такое Cherry Pick в GIT?
2. Делали ли rebase в GIT?
3. Проводили ли вы ревью кода?
4. Разворачивали ли микросервисы самостоятельно?
5. Реализовали ли API запросы в коде?
6. Был ли опыт с WebView, какие параметры передавали?
7. Какие знаешь алгоритмы работы с данными?
8. Что такое Сircuit Breaker и для чего используется в системе?
9. Какие сериалы посоветуете посмотреть?
10. Что такое CQRS?

Результат (даже если на все ответил): извините, нам нужен кандидат посильнее

—————

Утрировано, но по ощущениям сейчас именно так. Вторая часть – реальные вопросы с недавних собесов

При этом на часть сложных вопросов реально ответить (Webview, Circuit Breaker, CQRS, сериалы), другие же вызвали у меня ступор, но не по причине незнания – реально ли у них СА всем этим занимается?

⬇ Если вы как СА черепикаете 5 раз в неделю, разворачиваете микросервисы и сами пишете АПИшку (а разрабы смотрят в сторонке) – отмечайтесь в комментах. А также пишите о своих вопросах, которые вызвали ахуй застали вас врасплох

#собеседования_системный_анализ