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

1. Про эволюционный дизайн

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

1.1. Is Design Dead?

  • Тип источника: Статья

  • Рейтинг: 5/5. Если не понимать суть статьи, можно очень легко угодить в ловушку и угробить весь проект.

  • Автор: Martin Fowler. Глыба, экстремальщик, человек, сильно повлиявший на индустрию. Участник первого XP, один из ключевых авторов Agile Manifesto, автор и рецензент множества важнейших книг (Refactoring, DDD, Continuous Delivery).

  • Аннотация: Ключевая статья. Не менее актуальная, чем 25 лет назад. Тут будет плановый дизайн, эволюционный дизайн и рождение Agile.

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

  • Ссылка: https://martinfowler.com/articles/designDead.html

1.2. The First Scrum

  • Тип источника: Статья + Доклад

  • Рейтинг: 3/5. Если пропустить, можно потерять несколько часов в неделю на бесполезные церемонии, но не более.

  • Автор: Jeff Sutherland. Глыба. Один из создателей Scrum, соавтор Agile Manifesto.

  • Аннотация: История создания первого Scrum-проекта — как всё начиналось и какие принципы были заложены в основу. Полезно, чтобы узнать, откуда выросли все эти странные практики, которые все сегодня бездумно повторяют. Отвечает на вопросы, почему дейлик должен длиться час, скрам-мастер — это тимлид, а сам скрам — это все ещё немного водопад.

  • Ссылки:

1.3. Extreme Programming

  • Тип источника: Книга и Доклад (конференция)

  • Рейтинг: 5/5. Если пропустить, то вы рискуете вообще не догнать большинство важнейших идей последних 30 лет: CI, CD, Рефакторинг, DDD и еще очень много чего.

  • Автор: Kent Beck. Легенда, экстремальщик, человек, изменивший индустрию. Создатель XP, TDD, паттернов, xUnit и соавтор Agile Manifesto.

  • Аннотация: XP — важнейшая и страшно недооцененная веха в нашей индустрии. Рекомендую начать с доклада Кента Бека из первой ссылки, чтобы погрузиться в контекст. Затем можно заглянуть и в книгу. Фундаментальный источник: почти все самое важное за последние 30 лет в нашей индустрии берёт своё начало из XP.

  • Ссылки:

1.4. The Land That Scrum Forgot

  • Тип источника: Доклад (конференция)

  • Рейтинг: 4/5. Если пропустить, то вы так и не поймете, почему индустрия сейчас в такой заднице, и как она там оказалась.

  • Автор: Robert "Uncle Bob" Martin. Глыба, экстремальщик. Автор Clean Code, Clean Architecture, SOLID-принципов, один из авторов Agile Manifesto. Талантливый оратор и писатель.

  • Аннотация: Как Scrum убил Agile. История величайшего карго-культа в нашей индустрии.

  • Ссылка: https://www.youtube.com/watch?v=hG4LH6P8Syk

1.5. Почему Водопад не работает

  • Тип источника: Публичная лекция (отрывок)

  • Рейтинг: 4/5. Если не смотреть, то так и не поймете, где именно ломается водопад.

  • Автор: Robert "Uncle Bob" Martin. Глыба.

  • Аннотация: Это самое наглядное объяснение, почему Водопад так ужасно работает.

  • Ссылка: https://youtu.be/l-gF0vDhJVI?si=oQSEFDBVL2PwuEsx&t=1428

2. Про дизайн кода

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

2.1. Simple Made Easy

  • Тип источника: Доклад (Strange Loop, 2011)

  • Рейтинг: 4/5. Топовый доклад, но затянуто. Если пропустить, то рискуете из лучших побуждений нагородить спагетти-легаси на ровном месте.

  • Автор: Rich Hickey. Глыба. Создатель Clojure и Datomic, один из главных мыслителей в области функционального программирования.

  • Аннотация: Одна из самых главных бед софта — сложность, потому что именно с ростом сложности растет стоимость его изменения. Борясь со сложностью, просто необходимо понимать, что такое простое решение и чем оно отличается от лёгкого.

  • Ссылка: https://www.youtube.com/watch?v=SxdOUGdseq4

2.2. Coupling and Cohesion

  • Тип источника: Доклад

  • Рейтинг: 5/5. Пропустить это — все равно, что пропустить факт, что Земля круглая: жить можно, но картина мира будет крайне искаженной.

  • Автор: Kent Beck. Легенда.

  • Аннотация: Базовая база по дизайну: легенда нашей индустрии легко и с юмором объясняет важнейшие понятия в области дизайна, которые люди обычно понимают не очень правильно или не понимают вовсе.

  • Ссылка: https://www.youtube.com/watch?v=yBEcq23OgB4

2.3. Refactoring: Improving the Design of Existing Code

  • Тип источника: Книга + Видео

  • Рейтинг: 5/5. Если пропустить, то с вероятностью 99% спагетти-легаси будет окружать вас всю вашу оставшуюся программистскую карьеру.

  • Авторы: Martin Fowler, Kent Beck, экстремальщики.

  • Аннотация: Код — это не небоскрёб и не мост, его очень тяжело спроектировать заранее правильно. Поэтому его необходимо проектировать и перепроектировать в процессе разработки непрерывно — то есть рефакторить.

    Рефакторинг — это ещё одна практика, которую обычно понимают очень неправильно. Рефакторинг — это НЕ переписывание кода. Это дисциплина последовательного изменения кода маленькими шагами БЕЗ изменения поведения, которой надо учиться. От зеленого к зеленому.

    В видео и в книге можно найти наглядный пример, как же на самом деле выглядит эта практика. В книге также ищите список код-смеллов и методы рефакторинга — те самые "маленькие шаги", последовательностью которых рефакторинг и является.

  • Ссылки:

2.4. Hexagonal Architecture (Ports and Adapters)

  • Тип источника: Статья

  • Рейтинг: 4/5. Можно, конечно, использовать и другие паттерны, но этот до безобразия универсален, удобен и красив.

  • Автор: Alistair Cockburn. Глыба. Один из авторов Agile Manifesto, создатель ныне мёртвой методологии Crystal.

  • Аннотация: Архитектурный паттерн, изолирующий бизнес-логику от внешнего мира через порты и адаптеры. Если вы хотите, чтобы ваши тесты были стремительными, рефакторинг быстрым, а интеграции лёгкими в поддержке, то этот шаблон практически незаменим на больших долгоживущих кодовых базах со сложной доменной логикой и большим числом интеграций (например, в микросервисной архитектуре)

  • Ссылка: https://alistair.cockburn.us/hexagonal-architecture/

2.5. Domain-Driven Design: Tackling Complexity in the Heart of Software

  • Тип источника: Видео/Книга

  • Рейтинг: 4/5. Если пропустить, то вряд ли что-то плохое случится — вы просто украдёте у себя кучу очень полезных инструментов.

  • Автор: Eric Evans. Глыба, экстремальщик.

  • Аннотация: База по моделированию предметной области в коде. Книга читается долго, нудно, поэтому рекомендую начать с видео.

  • Ссылки:

2.6. ORM Hate

  • Тип источника: Статья

  • Рейтинг: 3/5. Если пропустить, то рискуете потерять время, применяя ORM там, где он не нужен, и изобретая велосипед там, где он нужен.

  • Автор: Martin Fowler. Глыба.

  • Аннотация: ORM часто заслуженно критикуют за его сложность, но причина этой сложности не в технологиях, а в плохой совместимости объектной модели данных и реляционной. Очень полезно понимать о наличии такой проблемы, особенно в контексте следующего источника.

  • Ссылка: https://martinfowler.com/bliki/OrmHate.html

2.7. Introduction to NoSQL

  • Тип источника: Доклад

  • Рейтинг: 4/5. Если пропустить, то в высоконагруженных системах будете страдать и потеряете часть удобных инструментов.

  • Автор: Martin Fowler. Глыба.

  • Аннотация: Если у вас хайлоад — смотреть обязательно. Если у вас сложная доменная модель — тоже весьма полезно. Может спасти от кучи проблем с ORM.

  • Ссылка: https://www.youtube.com/watch?v=qI_g07C_Q5I

3. Про автоматическое тестирование

Хороший дизайн невозможен без рефакторинга, а рефакторинг - без автотестов.

3.1. TDD, Where Did It All Go Wrong

3.2. TDD Demo by Uncle Bob

  • Тип источника: Демо

  • Рейтинг: 5/5. Если пропустить, потеряете очень крутой инструмент тестирования и проектирования. А также целый мир TDD и BDD, который изменит ваш подход к разработке полностью

  • Автор: Robert "Uncle Bob" Martin. Глыба.

  • Аннотация: Очень интересная наглядная демонстрация TDD: лёгкая и с юморком. Но тут есть один негативный момент: двум моим знакомым демо не зашло, хотя оба из них теперь все равно пишут по ТДД и очень любят эту практику.

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

  • Ссылка: https://youtu.be/58jGpV2Cg50?si=3mv7i32yJYMe4_hY&t=2629

3.3. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

  • Тип источника: Книга

  • Рейтинг: 5/5. База, обязательно к изучению.

  • Авторы: Jez Humble, David Farley. Глыбы, экстремальщики. Jez Humble — соавтор исследований DORA и книги Accelerate. Dave Farley — автор youtube-канала Modern Software Engineering.

  • Аннотация: Абсолютная база по автотестам и релизным процессам. Вот сюда идти с вопросами: как правильно тестить, как правильно релизить, как правильно управлять инфраструктурой, как держать большую нагрузку. Именно эта книга даёт ответ на вопрос, почему самые крутые команды релизятся несколько раз в день, а от коммита до прода у них — всего 20 минут.

    Использовать как справочник. Читать в оригинале — перевод искажает многие важные идеи, пришедшие из экстремального программирования.

  • Ссылка: https://www.amazon.com/dp/0321601912?tag=contindelive-20

3.4. Continuous Integration Theatre

  • Тип источника: Статьи

  • Рейтинг: 4/5. Если пропустить, то с рефакторингом у вас в команде будут очень большие проблемы.

  • Авторы: ThoughtWorks, James Shore. ThoughtWorks — очень важная компания в мире Agile — настоящий метроном нашей индустрии, задающий темп всем остальным компаниям. Отсюда вышли такие глыбы, как: Martin Fowler, Eric Evans, Dave Farley, Jez Humble, Dan North, James Lewis. Почти все из них в этом списке авторов есть.

  • Аннотация: CI — одна из самых главных жертв карго-культа в нашей индустрии. Вроде бы "есть" у всех, но на деле нет почти ни у кого. А без настоящего CI настоящего рефакторинга вам в команде не видать.

  • Ссылки:

4. Про архитектуру и организационную топологию

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

4.1. "People Get Microservices Wrong All The Time!" | Dave, Simon Brown & Hannes Lowette On Microservices

  • Тип источника: Интервью

  • Рейтинг: 5/5. Если пропустить, то есть риск родить микросервисное чудовище, которое утянет ваш продукт на дно.

  • Автор: Dave Farley, глыба, автор CD. Simon Brown, крутой спец, автор C4 model.

  • Аннотация: Небольшая ремарка от Дейва Фарли про то, как не надо делать микросервисы.

  • Ссылка: https://youtu.be/Hybt9NdmsBw?si=G4YKABuLFE6yItI9&t=324

4.2. Microservices (Martin Fowler)

  • Тип источника: Доклад

  • Рейтинг: 4/5. Если пропустить, ничего страшного не будет, просто будет менее глубокое понимание предмета.

  • Автор: Martin Fowler. Глыба.

  • Аннотация: Обзор темы от Фаулера - как всегда, интересно и познавательно.

  • Ссылка: https://www.youtube.com/watch?v=wgdBVIX9ifA

4.3. Event-Driven Architecture

  • Тип источника: Доклад + Статья

  • Рейтинг: 4/5. Если пропустить, то в большинстве случаев ничего страшного не случится. Но вот в больших микросервисных архитектурах, в HighLoad, Low Latency, High Availability без этих вещей будет тяжело.

  • Автор: Martin Fowler. Глыба.

  • Аннотация: База по событийным архитектурам, на больших масштабах компаний такое понимать необходимо.

  • Ссылки:

4.4. Reactive Systems (Dave Farley)

  • Тип источника: Доклад

  • Рейтинг: 4/5. Если пропустить, то просто потеряете полезный инструмент.

  • Автор: David Farley. Глыба. Соавтор Continuous Delivery.

  • Аннотация: В целом, это развитие предыдущей темы, только уже идеологический, системный подход к вопросу. Реактивный взгляд на архитектуру больших систем позволяет решать очень нетривиальные задачи в области low latency, high load and availability очень просто.

  • Ссылка: https://youtu.be/tKRa0O7aepo?si=QLM7tTHvxCbH49Sf

4.5. Team Topologies

  • Тип источника: Книга + Доклад

  • Рейтинг: 5/5. Если пропустить, то риск накосячить с процессами и архитектурой продукта/подразделения/компании стремится к 100%.

  • Авторы: Matthew Skelton, Manuel Pais. Глыбы.

  • Аннотация: Про то, почему реорганизация компании — это архитектурное решение, а не административное. Эта книга - одна большая модель для понимания того, как правильно смотреть на орг. структуру компаний и их подразделений в контексте IT. Незаменимый источник для CTO, Архитекторов и Лидов.

  • Ссылки:

4.6. Про Complex Adaptive Systems

  • Тип источника: Доклад

  • Рейтинг: 5/5. Для разработчиков, лидов и архитекторов первая часть — обязательна к просмотру, для C-level руководителей вообще весь доклад — золото. Если пропустить, то можно очень быстро упереться в потолок рост�� компании.

  • Автор: James Lewis. Черный пояс по разработке ПО. Один из главных экспертов ThoughtWorks.

  • Аннотация: База про микросервисы, база про топологии организаций. Про то, почему одни компании, со временем теряют темпы роста, а другие — наоборот, набирают.

  • Ссылка: https://www.youtube.com/watch?v=TgFSdEP9gcce

5. Про культуру

Самый важный блок из предыдущих пяти. Вопреки интуиции.

5.1. Westrum Organizational Culture Model

  • Тип источника: Исследование + Доклады

  • Рейтинг: 5/5. Чрезвычайно важная тема, как для разработчиков, так и для руководителей всех уровней.

  • Автор: Ron Westrum. Легенда. Социолог, создатель модели организационной культуры, изменившей понимание безопасности и производительности в высокорисковых отраслях.

  • Аннотация: Почему в одних компаниях за ошибку наказывают, а в других — благодарят за обнаружение проблемы? Для разработчиков очень важно понимать эту тему, чтобы стремиться работать только во втором типе организаций. Для руководителей эта тема еще важнее: мы достоверно знаем из исследований, что культура важнее всех технических практик вместе взятых. Важнее архитектуры, важнее автотестов, важнее идеального релизного процесса. Последние две ссылки, подкасты с самим Доктором Веструмом - чистое золото.

  • Ссылки:

5.2. Project Aristotle (Google)

  • Тип источника: Исследование

  • Рейтинг: 5/5. Чрезвычайно важная тема, как для разработчиков, так и для руководителей всех уровней.

  • Автор: Google People Analytics.

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

  • Ссылка: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

5.3. Manifesto for Agile Software Development

  • Тип источника: Манифест

  • Рейтинг: 5/5. Манифест короткий, но вот мудрости в нём очень много.

  • Авторы: 17 программистов, включая Kent Beck, Martin Fowler, Robert Martin, Alistair Cockburn, Ward Cunningham.

  • Аннотация: Специально запихнул в культуру, чтобы напомнить первую ценность манифеста: Individuals and Interactions over Processes and Tools.

  • Ссылка: https://agilemanifesto.org/

6. Про Lean

В этом блоке про философию. Предыдущий блок был важнее всех других, но этот уделает даже его.

6.1. Triumph of the Lean Production System

  • Тип источника: Статья

  • Рейтинг: 3/5. Если пропустить, то ничего страшного не будет.

  • Автор: John Krafcik. Глыба. Автор термина "Lean".

  • Аннотация: Просто исторический обзор, чтобы понимать, откуда взялся Lean. Читать необязательно, только если интересно понимать, откуда все пошло.

    Про то, почему завод с меньшим количеством запасов, меньшим количеством людей и меньшим пространством производит больше и качественнее. Оригинальная статья, в которой впервые появился термин "Lean" — анализ превосходства японских автозаводов 70-х и 80-х над всеми остальными заводами мира.

  • Ссылка: https://ru.scribd.com/document/747116953/Triumph-of-the-Lean-Production-System

6.2. NUMMI

  • Тип источника: Исследование/Кейс

  • Рейтинг: 5/5. Если пропустить, ничего страшного не будет, но кейс — настоящая пушка, не могу меньше 5 поставить.

  • Аннотация: Крутейшая история о том, как Toyota взяла худший завод GM с худшими рабочими во всей США и превратила его в лучший завод в Америке, не меняя людей. Находится на пересечение этого и предыдущего блоков.

  • Ссылка: https://www.thisamericanlife.org/561/transcript

6.3. Gojko Adzic — Specification by Example / Impact Mapping

  • Тип источника: Видео

  • Рейтинг: 5/5. Важнейший доклад для лидов всех уровней.

  • Автор: Gojko Adzic. Черный пояс по разработке ПО.

  • Аннотация: Главный способ быстро разрабатывать софт кроется не в технологиях, не в архитектуре и не в тестах. Даже не в культуре и не в процессах. Главный способ ускориться — не делать лишнюю работу. .

    Вы можете делать фичу по привлечению новых клиентов 9 месяцев, и оно не сработает. А можете за неделю оптимизировать старую фичу и решить проблему. Разница в скорости — десятки раз. Ничто из вышеперечисленного не сравнится с этим по эффективности.

  • Ссылки:

6.4. The Lean Startup

  • Тип источника: Доклад, Книга

  • Рейтинг: 3/5. Если пропустить, ничего страшного. Но тем, кто хочет стартануть, будет очень полезно.

  • Автор: Eric Ries. Глыба. Предприниматель, популяризатор lean-подхода в стартапах.

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

  • Ссылки:

6.5. Твой пет-проект

  • Тип источника: Телеграм-канал / Сообщество

  • Рейтинг: 5/5, полезен всем, кроме упрямых карьеристов

  • Автор: Миша Табунов.

  • Аннотация: Развитие идей предыдущего автора. Философия построения прибыльных продуктов в одиночку, без инвесторов, с фокусом на скорость и итерации. Про то, как один разработчик с ноутбуком может зарабатывать больше, чем стартап с командой из 20 человек и миллионом инвестиций. Просто база для тех, кому уже совсем приелся найм.

  • Ссылка: https://t.me/your_pet_project

6.6. Accelerate

  • Тип источника: Книга / Исследование

  • Рейтинг: 5/5, одно из важнейших событий в индустрии в последние 15 лет

  • Автор: Nicole Forsgren, Gene Kim, Jez Humble. Глыбы.

  • Аннотация: Эта книга - обобщение выводов ежегодного исследования State of DevOps за несколько лет. По сути, это набор самых рабочих практик и идей в нашей области, провалидированных научными исследованиями. Без умозрительных заключений, только то, что реально работает.

  • Ссылка: https://itrevolution.com/product/accelerate/

6.6. NoEstimates

  • Тип источника: Видео

  • Рейтинг: 4/5. Крайне полезный доклад для лидов всех уровней.

  • Автор: Allen Holub. Черный пояс по разработке ПО.

  • Аннотация: Доклад про то, почему оценки в софте работают очень плохо, и как можно жить, в итоге, без них.

  • Ссылка: https://youtu.be/QVBlnCTu9Ms?si=JKTIj0N9eRjSXre4

7. Про вайб-кодинг

Похоже, оно нас догнало.

7.1. Vibe Coding (Gene Kim & Steve Yegge)

  • Тип источника: Книга, Подкаст

  • Рейтинг: 5/5. Бегом читать, главная книга индустрии в 2025.

  • Авторы: Gene Kim, Глыба (один из соавторов State of Devops и Accelerate); Steve Yegge, Черный пояс по разработке (легендарный блогер, бывший Senior Software Engineer в Amazon и Google).

  • Аннотация: Anthropic со своим ClaudeCode полностью меняет ландшафт разработки ПО. Нет, разработчики не устарели и нас не заменили. Без инженерной подготовки на этом все еще далеко не уедешь, однако профессия преображается радикально, а порог входа в нее снижается. Теперь один талантливый знающий разраб может достаточно быстро сделать то, что раньше другие компании делали месяцами. Поэтому не тормозите.

    Но учтите: нам дали не Теслу с автопилотом, а болид Формулы 1, на котором без должных навыков и знаний ты разобьёшься на первом же круге. Поэтому вам в помощь эта книжка и все остальные источники выше, которые теперь не просто не потеряли актуальность, а, наоборот, стали еще важнее.

  • Ссылки:

Меня зовут Саша Раковский. Работаю техлидом в расчетном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку очень дорого. Законченный фанат экстремального программирования, а значит и DDD, TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет, для этого я здесь - делюсь опытом. Если стало интересно, добро пожаловать в мой блог.