🟧🟧🟧🟧🟧🟧🟧🟧🟧

Для удобства подготовил навигацию по постам, разбил по темам. Всем вновь прибывшим – добро пожаловать!

🔹 О личном
– Кто я и зачем пишу
– Лучшее лекарство от стресса – спорт

🔹 Мысли и про бытовуху на работе:
– Я поругался с разработчиком и его уволили
– 2 навыка, которые помогли мне стать middl SA за 9 месяцев
– Проект провалился, я виноват?
– Нужно ли СА знать программирование? + Краткий анализ рынка
– Так ли плох аутстафф?
– Поработал на двух работах в IT и сгорел
– Почему я впервые отдохнул только в 26 лет
– Фронт раньше бэка – это вообще законно?
– Шаблоны документации – пустая трата времени или действительно полезно?

🔹 Просто о сложном:
– Просто о кэшировании
– Реплицирование vs Партиционирование vs Шардирование
– Просто о репликации
– Просто о партиционировании
– Просто о шардировании
– Паттерны микросервисной архитектуры для СА
– Как понять, что сбор требований завершен? Чек-лист для СА
– Самый важный паттерн МСА на примере неудавшегося отпуска
– Что такое Polling и причем тут Шрек

🔹 Про собеседования:
– Цвет настроения желтый: как я проходил собеседование в Т-Банк
– Как я сходил на собес в Магнит Tech
– Собес на 20 минут – red флаг при трудоустройстве?

🔹 Обзоры книг:
– System Design: как выжить на собеседовании? Обзор книги Алекса Сюя
– Прочитал книгу «Микросервисы. Паттерны разработки и рефакторинга» и делюсь мнением
– Польза и вред той самой книги Вигерса

🔹 Обзоры курсов:
– Отзыв на воркшопы System Education

🔹 Инструменты для работы:
– Как увидеть запросы в режиме онлайн? Используем Charles

Самый важный паттерн МСА на примере неудавшегося отпуска

Представь, ты собрался в отпуск – забронировал авиабилеты, отель и даже экскурсию. Ты молодец - все спланировал заранее и теперь не нужно париться🌴

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

Шаблон «Saga» (или «Повествование») – шаблон, обеспечивающий согласованность данных в микросервисной архитектуре в конечном счете. То есть, если бизнес-процесс затрагивает три сервиса, то после его выполнения данные должны быть актуальными и правильными

🔹 Локальные транзакции

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

В системах несколько сервисов могут участвовать в одном бизнес-процессе, и под локальной транзакцией понимают изменение в БД или публикацию события

Например, в Uber 🚕 нужно создать заказ, назначить водителя, запустить поездку и обработать оплату

🔹 Компенсирующие транзакции

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

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

Например, в Uber Saga координирует цепочку: принятие заказа → назначение водителя → поездка → оплата. Если водитель отменит заказ, система компенсирует изменения (вернет заказ в очередь)

🔹 Поворотные транзакции

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

В системах подобные транзакции называются поворотными. После поворотной транзакции полная компенсация невозможна (только частичная)

В примере с Uber поворотная транзакции – начало поездки. До этого момента заказ можно отменить без штрафа, после компенсация будет частичная (например, пассажир получит штраф 🤑)

🔹 Координация транзакций

Два способа координации транзакциями в системах:

1. Хореография
2. Оркестровка

При хореографии сервисы обмениваются событиями (например, через Kafka), и каждый решает, как реагировать. Это как если бы самостоятельно планировали отпуск – забронировали авиабилеты, получили событие в мозг, пошли бронировать отель (не обязательно сразу)

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

📌 Кратко о важном

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

В итоге Saga – это не про идеальный сценарий, а про то, как грамотно откатиться при ошибках и поддержать данные в целостности

————

Теперь яснее, как мы обеспечиваем согласованность данных в микросервисах?

👍 Да, гораздо
🤔 Нужно разобраться

P.S. Пока писал пост, увидел новый конкурс авторских ТГ-каналов. На этот раз от ребят из System Education, куда мой канал вписывается куда лучше, чем в предыдущем конкурсе

В этом конкурсе несколько номинаций. Думаю, этот пост отлично вписывается в «Ясное объяснение». Оставлю пометку, что участвую в конкурсе от @systems_education.

#полезное_системный_анализ
#продолжи_мысль_SE

Аналитиков куда больше, чем мы думаем

Иногда ко мне приходят с таким запросом: «На работе я мастер Excel, в основном работаю с данными, даже строю дашборды – хочу стать системным аналитиком» ❓

Несмотря на то, что суть моей магистерской в универе – получение, обработка и представление данных в виде 3D-графиков, работа СА вовсе не про это

Аналитиков в IT можно разделить на две большие группы:

🔹 Аналитики данных
🔹 Аналитики требований

Еще есть финансовые и маркетинговые аналитики, но это уже за рамками IT

Аналитики требований делятся на:

1. UX-аналитики
2. Бизнес-аналатики
3. Системные аналитики (хей, это же я)
4. Аналитики 1С

При этом аналитики данных:

1. Продуктовый аналитик
2. Web/mobile аналитик
3. BI-аналитик
4. Аналитик Big Data

Возможно, я бы тоже поработал аналитиком данных, но уже не в этой жизни – однако заглянуть в этот дивный мир мне помогает бывший юрист и нынешний middle дата аналитик с ВТБ Арина на своем канале IT’s Арина 💡

Арина в основном рассказывает о своем непростом пути в карьере: причем он настолько длинный, что разбит на множество частей, которые читаешь, как сериал 🍿. Рекомендую начать с первой части.

В каждой истории она дополнительно раскрывает какую-нибудь тему: например, Как не работать с мудаками 🤯

Также не забывает делиться интересными находками:

🔹 Метрики, которые стоит знать, если вы работаете в финтехе
🔹 Вопросы с собеседовании на junior

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

➡ Подписывайтесь, впереди немало интересного!

Фронт раньше бэка – это вообще законно? 🤔

История о том, как делать не нужно – а именно выкатывать фронт раньше бэка. И что делать, если это неизбежно

Немного контекста

Работал с продуктом одного банка, где было четкое разделение фронтенд и бэкенд-команд. Я был во фронтенд-команде. По идее аналитики обеих сторон связывают эти части, т.к. высок риск рассинхрона

Однако был один нюанс – бэкенд-команды не было. Ну как, сам бэк с сервисами есть, но его не развивают. Максимум, на что мы могли рассчитывать – один фантомный разраб со стороны банка

Что произошло? 🔥

В работе была огромная фича на весь квартал – новый продукт на фронте со своим отображением. А это новый JSON на 100+ полей со сложными структурами – без бэка не обойтись

Однако бэк делать не торопились, поэтому я писал моки (примеры JSON) на основе дизайна и отдавал своим разработчикам, чтобы им было с чем работать

Подходит конец квартала, в преддверии премии внутренние сотрудники активизировались – появился обещанный бэк-разработчик и сделал свою работу за две недели. Результат: JSON приходит с null полями и ошибками, фронт сломан. На проде 🌾

Исправляли все это еще месяц, пришлось плотно поработать с бэк-разрабом – хотя это нужно было делать до релиза

Можно ли было избежать? 🤔

Спустя время, проанализировал ситуацию, я понял, что нет. Мы не могли предусмотреть, что:

🔴 Команды бэка нет вовсе
🔴 Человек, который в итоге дорабатывал бэк, изначально не должен был этим заниматься

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

Но всегда можно свести риск к минимуму

Со своей стороны мы сделали все что смогли (и вам советую):

🟢 Сами разработали моки, работали с ними и их же скидывали бэк-разрабу для понимания итогового результата
🟢 Написали ТЗ для этого разработчика (хотя не должны были)
🟢 Были всегда на связи, отвечали на все вопросы и были открыты к предложениям
🟢 Постоянно подсвечивали разные проблемы и риски заказчику

—————

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

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

По моему мнению, такого процесса быть не должно – бэк нужно готовить раньше фронта или идти параллельно, но не наоборот. Однако IT-мир жесток

⬇ А вы сталкивались с похожими ситуациями? Делитесь в комментариях

————

P.S. Данный пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Полевой опыт»

#истории_системный_анализ
#продолжи_мысль_SE

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

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

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

Недавно работал на проекте крупной компании, где было замечательно все – большая команда, интересный продукт, слаженные процессы, команда СА. Документация в виде 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: Шаблоны разработки собственных облачных приложений»: Билджин Ибрам, Роланд Хасс

🤍Облака

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

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

––——–––

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

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