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

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

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

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

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

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

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

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

Что в итоге?

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

———

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

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

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

Путь до архитектора. Часть 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 свой вариант?

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