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

1️⃣ "Designing Data-Intensive Applications" (Martin Kleppmann)

Это must-read для тех, кто работает с высоконагруженными системами. Книга особенно ценна тем, что:

- Детально разбирает различные модели данных (реляционные, документные, графовые) и помогает понять, когда какую использовать
- Объясняет принципы построения распределенных систем, включая работу с Apache Kafka, Hadoop и Spark
- Рассматривает стратегии масштабирования и отказоустойчивости
- Дает практические рекомендации по выбору технологий хранения данных

Плейлист с подробными разборами каждой главы от senior+ инженеров из нашего сообщества.

2️⃣ "Software Architecture in Practice" (Bass, Clements, Kazman)

Эта книга - отличный фундамент для понимания базовых концепций архитектуры ПО:

- Объясняет, почему архитектура - это не просто дизайн, а набор осознанных решений
- Детально разбирает архитектурные стили и их применение
- Показывает, как архитектура влияет на жизненный цикл разработки
- Учит работать с качественными характеристиками системы

3️⃣ "Building Evolutionary Architectures" (Ford, Parsons, Kua)

Книга особенно актуальна для тех, кто работает над долгоживущими системами:

- Вводит концепцию "fitness functions" для оценки качества архитектуры
- Объясняет, как делать архитектуру адаптивной к изменениям
- Рассматривает практики resilience engineering
- Учит выстраивать процессы непрерывного улучшения архитектуры

4️⃣ "Software Architecture: The Hard Parts" (Ford, Richards, Sadalage, Denghani)

Практическое руководство по современной распределенной архитектуре:

- Глубоко погружает в особенности распределенных систем
- Разбирает архитектуру микросервисов и связанные с ней компромиссы
- Охватывает serverless и облачные решения
- Помогает понять trade-offs при проектировании распределенных систем

Эти книги дополняют друг друга: Kleppmann даст глубокое понимание работы с данными, Bass и соавторы обеспечат фундаментальную базу, Ford научит делать архитектуру эволюционной, а Richards поможет разобраться с современными распределенными системами.

👉 Ключевые моменты из этих и других книг + примеры из продакшена реальных проектов + практические задачи на проектирование архитектуры высоконагруженных систем + фидбек от solution-архитектора Miro и EPAM Павла Вейника = курс [Технический Лидер].

Узнать о курсе подробнее и записаться на консультацию вы можете здесь. В феврале стартуем следующий поток, не пропустите!

📍Друзья, уже в этот четверг 30 января ждем вас на второй встрече из мини-серии, посвященной Structurizr. В этот раз в формате Live Session вместе шаг за шагом разберем:

1. Установка и настройка: как поднять разные версии Structurizr и базово администрировать их в своей среде.
2. Решение реальной задачи: определим примерную задачу, напишем для нее код и детально разберем, что, как и почему.
3. Документация и ADR: покажем, как эффективно документировать архитектуру с помощью Structurizr и использовать подходы архитектурных решений (Architecture Decision Records, ADR).

Спикер: Cаша Белян, Python developer .

Запись первой встречи можно посмотреть на нашем Youtube-канале

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

Все чаще сталкиваюсь с проблемами найма техлидов, архитекторов и CTO, поэтому написал статейку для нанимающих менеджеров и фаундеров, ликбез о том, как нанять техлида/архитектора/CTO в небольшую компанию.
(Павел Вейник)
https://www.linkedin.com/pulse/%D0%BD%D0%B0%D0%BD%D0%B8%D0%BC%D0%B0%D0%B5%D0%BC-%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%B0-%D0%B2-%D0%BD%D0%B5%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D1%83%D1%8E-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8E-pavel-veinik-lnajf/?trackingId=wFYikCLISMmsVwB2ZAd%2FoA%3D%3D

Принцип 80/20 в выборе технологий: как senior-разработчикам и архитекторам фокусироваться на главном

На что смотреть при выборе инструментов?

Критичные Non-functional Requirements. Если ваш сервис обрабатывает 1 млн TPS, но вендор СУБД хвастается «горизонтальным масштабированием», проверьте, как это работает при частичной потере сети. Для highload систем смотрите не на «среднюю» производительность вендора, а на p99 latency под нагрузкой.

Экосистема, а не фичи. Более высокая производительность не стоит того, если для внедрения нового инструмента в вашу систему придется 3 года писать кастомные интеграции.

Команда > Технология. Работали ли вы и разработчики в вашей команде с инструментом? Если нет, то как быстро вы сможете изучить его? И не стоит забывать про bus factor.

Как проверить инструмент, если лично с ним не работали?

Документация и бенчмарки. Главное, отфильтровать маркетинговые истории от реальных данных. Если вендор хвастается скоростью в 1 млн RPS, проверьте: размер полезной нагрузки (1 байт vs 1 КБ?), тип дисков (NVMe vs HDD?), уровень изоляции (Read Uncommitted?). В идеале, ищите бенчмарки, где код и конфиги выложены на GitHub.

Реальные кейсы. Поищите, какие вопросы задают на stackoverflow, с чем возникают проблемы и как их решают. Читайте инженерные блоги компаний вашего масштаба.

Прототип. Сделайте не «демку», а эмуляцию реальной нагрузки. Пример:

— Для базы данных: напишите скрипт, который генерирует 70% read / 30% write запросов (ваш реальный сценарий), и добавьте фоновую нагрузку на сеть.
— Для очереди: проверьте, как поведет себя система при повторной обработке 100k «зависших» сообщений.

Новые технологии: инновации vs хайп

Концепция «innovation tokens» от Dan McKinley: у каждой команды ограниченный ресурс на поддержку «модных» инструментов. Больше рисков возникает там, где пересекаются unknown unknowns. Если вы внедряете новые технологии, делайте это постепенно.

Спросите себя:

🔸Что случится, если этот инструмент перестанет развиваться через год?
🔸Какие 3 основные операции он должен выполнять? Если инструмент решает почти все нормально, но ваши 3 — плохо, это провал.
🔸Сколько человек в команде готовы экстренно чинить его в 3 часа ночи?

Выбор правильной технологии – одна из задач техлида и архитектора при проектировании системы. На курсе [Технический Лидер] вы научитесь решать архитектурные задачи по шаблону, основанному на опыте десятков реальных компаний – от сбора и уточнения бизнес-требований до проектирования устойчивой к переменам архитектуры, а также узнаете, как отстаивать свои технические решения перед стейкхолдерами, чтобы обеспечить долгосрочное развитие системы.

👉Записывайтесь на консультацию!

🚀 Software Craftsmanship Meetup №29 уже в этот четверг!

📅 Дата: 6 февраля
⏰ Начало в 20.00 по GMT+3

Как техлиду и архитектору правильно работать с бизнес-метриками? Почему они так же важны, как и технические? Об этом и не только поговорим на ближайшем митапе!

Программа митапа:

✅ Что такое бизнес-метрики и чем они отличаются от технических?
✅ Почему эти метрики важны? Практические примеры.
✅ Как собирать и работать с бизнес-метриками на всех этапах проектирования и разработки?
✅ Влияние архитектуры на бизнес-метрики. Связь нефункциональных требований с бизнес-метриками.
✅ Заключение: бизнес-метрики как связующее звено между бизнес-целями и технической реализацией.

🔗 Регистрация: https://hardsoftskills.dev/meetup29

Друзья, если вчера пропустили, Software Craftsmanship Meetup уже доступен на нашем ютубе.
🔗 Майндмэп по ссылке
Приятного просмотра и хороших выходных!

Как проектировать систему, не зная деталей кода

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

💡Системы строятся на нескольких уровнях абстракции:

1. Низкоуровневый код (ассемблер, машинный код)
2. Языки высокого уровня (Java, Python и др.)
3. Фреймворки и библиотеки
4. AI-инструменты, no-code и low-code решения

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

Чем шире скоуп ответственности, тем на более высоком уровне абстракции нужно рассуждать:

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

❗️Преодоление боязни отрываться от кода – умение делегировать и доверять тем, кто реализует код. Рост выше сеньора без этого невозможен. Архитектор может не знать особенностей recovery в Kafka или всех деталей работы Cassandra. Достаточно понимать:

▫️ Основные принципы работы технологий
▫️ Их сильные и слабые стороны
▫️ Типовые сценарии применения
▫️ Базовые гарантии, которые они предоставляют

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

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

Архитектор может и должен знать, как устроены наиболее критичные части системы. Но погружение в детали не должно мешать видеть общую картину и решать главную задачу – создание работающего продукта для бизнеса. Как это делать – учим на курсе [Технический Лидер]. Стартуем уже на этой неделе – успейте записаться!

Привет! Завтра в 20.00 GMT+3 на H&S Conclave будем разбираться как обращаться с токсчиными звездами в команде.

Обсудим:
✔️ Почему мы терпим разработчиков, которые приносят отличные результаты, но отравляют атмосферу в коллективе?
✔️ Правда ли, что "гений" может быть незаменимым, или он тянет команду вниз?
✔️ И самое главное — почему софт-скиллы для разработчиков так же важны, как технические знания?

🔗 Регистрация на сайте. До встречи!

Как спроектировать систему, которую все будут ненавидеть, и стать легендой

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

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

1️⃣ Микросервисы — это модно и современно, но зачем усложнять себе жизнь?

Монолит – это понятно и даже звучит надежно. Поэтому сделайте свои микросервисы похожими на монолит!

Совет 1: Пусть каждый сервис знает всё о своих соседях. Зачем нужны API, если можно просто дергать друг друга напрямую?

Совет 2: Обязательно сделайте цепочки вызовов. Например, чтобы обработать один запрос, сервис A должен вызвать B, B — C, а C — снова A. Разработчики работают в команде, пускай сервисы тоже будут командой!

Совет 3: Используйте общую базу данных для всех сервисов. Это же так удобно — не нужно думать о консистентности данных, транзакциях и миграциях.

2️⃣ Игнорируйте изоляцию сбоев

Наши сервисы – это команда, а в команде все проблемы должны быть общими.

Совет 4: Никаких circuit breakers, retry-логики и bulkheads. Пусть один упавший сервис валит всё подряд.

Совет 5: Если сервис упал, пусть он продолжает пытаться выполнить запрос бесконечно. Это же упорство, а не баг!

Совет 6: Не тестируйте отказоустойчивость. Зачем тратить лишние ресурсы, если пользователи сами найдут все баги?

3️⃣ Предсказывайте будущее

Гениальный архитектор видит развитие системы на годы вперед. Зачем впопыхах переписывать систему, если можно подготовить все заранее?

Совет 7: Добавьте в систему все возможные абстракции, которые могут когда-нибудь пригодиться. Если вы делаете интернет-магазин, сразу добавьте поддержку квантовых вычислений. Вдруг пригодятся?

Совет 8: Создайте десятки слоев абстракции. Если разработчики тратят 80% времени чтобы понять, как работает код, – это их проблема, что они не гении.

Совет 9: Не документируйте ничего. Пусть вся информация о том, как работает система, будет только у вас в голове. Все равно документацию никто не читает.

4️⃣ Демонстрируйте интеллектуальное превосходство

Ваша цель — создать систему, которая будет жить вечно, потому что никто не сможет её понять или изменить.

Совет 10: Используйте максимально сложные технологии. Зачем брать проверенные решения, если можно взять что-то экспериментальное и модное? А еще лучше – написать все самостоятельно!

Совет 11: Никогда не проводите рефакторинг. А что, разработчики не могут сразу написать хорошо?

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

5️⃣ Убедите бизнес, что всё идёт по плану

Бизнес не должен знать, что система — это бомба замедленного действия.

Совет 13: Говорите, что все проблемы — это временно. Например: "Мы просто в процессе оптимизации, скоро всё наладится".

Совет 14: Обвиняйте разработчиков. Это они не смогли понять вашу гениальную архитектуру.

Совет 15: Постоянно меняйте требования. Пусть команда думает, что это бизнес виноват, а не ваша переусложненная система.

6️⃣ Заключение: как стать легендой

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

Но если вдруг вы передумаете и захотите создать что-то полезное, просто сделайте всё наоборот. А лучше записывайтесь на курс [Технический Лидер] и проектируйте эффективные системы вместо легендарных!

Друзья, 20 февраля приглашаем вас на H&S Conclave c Алексеем Лобан на тему "Собеседования 2.0: что мы изменили в нашем подходе и как это повлияло на найм"

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

Программа доклада:
🔍 Фильтр на старте: как анализировать резюме и отбирать кандидатов на собеседование.
🔍 Кого мы ищем? Определение grade разработчика и соответствующих задач.
🔍 Вопросы с фокусом на человека, а не GPT – как составить интервью, которое раскрывает кандидата.
🔍 Красные флаги на собеседовании: какие сигналы должны насторожить.
🔍 Советы для тех, кто в поиске работы: что важно учитывать, проходя интервью.

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

🔗Регистрация на сайте. До встречи!

Написал какой-то код, получил зарплату. А что дальше?

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

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

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

Чтобы по-настоящему влиять на продукт, просто писать код недостаточно – нужно расширять свой скоуп ответственности:

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

🎓 Менторьте и помогайте коллегам
Один из самых эффективных способов почувствовать себя полезным — это делиться знаниями. Дайте чуть больше подробностей на код-ревью, проведите внутренний митап для команды, попробуйте себя в роли спикера на мероприятиях Hard&Soft Skills 😉

📈 Фокусируйтесь на impact, а не на output
Количество написанного кода или закрытых задач – это метрика для вашего менеджера, но не для оценки своей полезности. Вместо этого задайте себе вопрос: "Как мой код или решение повлияет на продукт, пользователей или бизнес?" Даже если это небольшой модуль, подумайте, как он улучшит производительность, упростит жизнь другим разработчикам или решит проблему пользователя.

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