Тезис книги

Программная инженерия — ремесло с ответственностью за последствия. Мастерство растёт не от сертификатов и звёзд на GitHub, а от дисциплины в четырёх плоскостях: как вы меняете код; как дублируете знание; как проверяете гипотезы; как относитесь к «мелочам», которые учат команду плохим нормам.

Прагматик выбирает то, что работает в контексте — сроки, легаси, регуляторика, состав команды. Он не путает «модно на конференции» с «снижает риск поставки на этой неделе». И не прячет халтуру за словом «мы же прагматики»: здесь прагматизм — про честность и обратимость, а не про лень.

Ключевые идеи

Ортогональность: одно изменение — один смысл

Что говорит автор. Оси ответственности должны пересекаться реже. Хорошее изменение затрагивает один смысл: правило скидки, формат ответа, политику доступа. Плохое «маленькое» изменение тянет UI, SQL, очередь и отчёт, потому что слои уже склеены неявным контрактом.

Как это выглядит в Enterprise. Правка флага в админке требует согласования трёх команд. Один смысл назван по-разному в трёх сервисах. Модуль «священный» — «не трогай, упадёт всё». Типичная история: «добавим одно поле в заказ» превращается в неделю, потому что заказ уже знает про биллинг, склад, маркетинг и отчёт CFO.

Как это меняется с AI. Ассистент ускоряет набор текста и с радостью усиливает существующую склеенность: копирует тот же антипаттерн в соседний файл красивым стилем. Полезный запрос не «напиши функцию», а «вынеси смысл X за адаптер / не трогай оси Y». ИИ-ревью ловит стиль, но редко спрашивает: сколько осей задело это изменение?

Где совет может не работать. Преждевременные микросервисы «ради ортогональности» часто дают распределённый монолит. В жёстком легаси сначала нужен шов и тест, а не идеальная сетка модулей. Иногда временная связанность осознанна — если рядом лежит план разрезания и дата.

Что сделать уже сегодня. В следующем PR опишите одним предложением зачем существует каждый новый файл. Если не получается — оси уже перепутаны.

Мой опыт. Ортогональность окупается на втором и третьем изменении политики, а не на первом коммите. Я гонюсь за ней там, где правила бизнеса живут дольше фреймворка. Где код — одноразовый клей к вендору на квартал, платить полной «чистотой» не всегда разумно.

Если запомнить одну мысль — меняйте одно место смысла, не устраивая домино по репозиторию.

DRY — про знание, не про запрет копипаста

Что говорит автор. Опасно дублировать знание, а не любые две похожие строки. Политика «отмена заказа за 24 часа» во фронте, API и отчёте разъедется. Два одинаковых цикла for могут быть случайным сходством и не стоить общей утилиты.

Как это выглядит в Enterprise. Правило скидки «починили на сайте», а письмо клиенту и сверка бухгалтерии живут по старой логике. Или наоборот: «общая» библиотека связывает несвязанные домены ради экономии строк — и любое изменение ломает чужой квартальный отчёт.

Как это меняется с AI. Модель размножает одно правило в пяти файлах за минуту. Компилируется, выглядит умно, тесты зелёные на счастливом пути. Прагматик после генерации спрашивает не «красиво ли», а «где теперь единственная истина». Кодоген и шаблоны полезны, если источник знания один.

Где совет может не работать. Навязчивый DRY рождает преждевременные абстракции. «Не повторяй» без вопроса «это одно знание или два похожих случая?» — путь к Utils на тысячу строк.

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

Мой опыт. Я почти всегда разрешаю локальный копипаст на границе систем, пока контракт нестабилен. Зато внутри одного ограниченного контекста за дублирование политики бьюсь жёстко — там цена дрейфа измеряется инцидентами, а не эстетикой.

Если запомнить одну мысль — считайте стоимость смены правила, а не число совпавших строк.

Разбитые окна и культура «раз уж так»

Что говорит автор. Мелкий видимый беспорядок снижает порог следующего. Незакрытый TODO, проглоченная ошибка, тест «потом», кривое имя «как у соседа» — сигналы команде, что можно.

Как это выглядит в Enterprise. Один раз «заглушили алерт на пятницу» — и через квартал мониторинг молчит системно. Или: в модуле уже пять # noqa и три ignore в линтере; новый человек добавляет шестой без угрызений. Код редко разваливается мгновенно. Обычно он медленно гниёт, пока команда перестаёт замечать запах.

Как это меняется с AI. Генерация легко оставляет «почти правильный» код: пустой catch, магические числа, комментарий «потом». Ревьюер устал — принял. Ассистент не стыдится разбитых окон; стыдиться должна культура слияния.

Где совет может не работать. Косметика ради косметики в горящем инциденте — вред. Не всё серое в диффе — окно. Окно — то, что учит плохой норме. Первое можно отложить явно; второе лучше закрыть в том же PR или завести долг с владельцем и сроком.

Что сделать уже сегодня. В файле, который уже трогаете, закройте одно настоящее окно — или назовите владельца долга в тикете, не в воздухе.

Мой опыт. Самый дешёвый ремонт — «раз уж я здесь». Самый дорогой — геройский рефакторинг половины системы под соусом «разбитые окна». Я предпочитаю маленькие видимые победы, которые меняют норму команды.

Если запомнить одну мысль — беспорядок заразен; чините сигнал, а не только симптом.

Трассирующие пули против бесконечного прототипа

Что говорит автор. Трассирующая пуля — тонкий сквозной срез от входа пользователя (или события) до наблюдаемого результата. Он не обязан быть красивым. Он обязан быть реальным: настоящий канал данных, настоящая граница, настоящая ошибка на стыке.

Как это выглядит в Enterprise. Полгода «идеальной платформы» на слайдах, потом две недели паники на первом пользовательском пути. Или наоборот: демо на моках, где «потом подключим» очередь, SSO и биллинг — и правда всплывает за неделю до релиза.

Как это меняется с AI. Легко получить красивый прототип интерфейса и даже «рабочий» счастливый путь из чата. Интеграционная правда по-прежнему дорогая. Используйте ИИ, чтобы быстрее собрать срез — но мерилом оставляйте реальный стык систем, а не снимок экрана.

Где совет может не работать. Вечный «тонкий срез» без обобщения тоже долг: десять временных путей, ноль платформы. После того как знание оплачено болью — обобщайте. В регулируемых контурах срез всё равно должен уважать аудит и доступ; «лишь бы стрельнуло» недостаточно.

Что сделать уже сегодня. Для текущей фичи запишите один сценарий успеха и один явный отказ, которые можно провести насквозь на этой неделе. Остальное — после фактов.

Мой опыт. Трассирующие пули спасали сроки чаще, чем идеальные ADR. Но я видел и злоупотребление: «мы прагматики» как отказ проектировать контракты вообще. Срез — инструмент обучения, не культ хаоса.

Если запомнить одну мысль — сначала путь, который врёт меньше слайда; красота — потом.

Инструменты, автоматизация боли и «сборка у Ивана»

Что говорит автор. Если шаг болезненный и повторяется — автоматизируйте, удалите или сделайте ошибку невозможной. Ручные ритуалы на проде и сборка на одной машине — фабрики инцидентов.

Как это выглядит в Enterprise. Релиз «по инструкции из Confluence на 40 шагов». Секреты в личном менеджере. Тесты, которые гоняют только один человек. Боль стоит часа скрипта, если она еженедельная; стоит дня пайплайна, если блокирует поставку.

Как это меняется с AI. Ассистент пишет скрипты и CI-конфиги быстро — и так же быстро оставляет хрупкую магию. Проверяйте идемпотентность, секреты, права. ИИ-агент в CI без ограждений — новое разбитое окно корпоративного масштаба.

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

Что сделать уже сегодня. Назовите один ручной шаг в поставке, который бесил вас в последнем месяце. Оцените: удалить, упростить или автоматизировать?

Мой опыт. Лучшие инвестиции — сокращение времени «от красного до зелёного» и снятие человека с критического пути релиза. Худые — генераторы обёрток ради галочки «удобства для разработчика».

Если запомнить одну мысль — боль, которая повторяется, — баг процесса, не черта характера команды.

Оценка, неопределённость и обратимость

Что говорит автор. Оценивайте сроки и риски, но не притворяйтесь пророком. Где можно — оставляйте решения обратимыми: флаги, адаптеры, границы модулей, версии контрактов. Необратимое (миграция без отката, публичный API без версий) — редко и с записью почему.

Как это выглядит в Enterprise. Спор недели о гипотетическом будущем вместо дня эксперимента. Или «единственная СУБД на десять лет» без адаптера — и смена вендора становится проектом года.

Как это меняется с AI. Легко нагенерировать три архитектуры за вечер. Сложнее оставить дверь назад. Просите у модели не только «как сделать», но и «как откатить» и «что станет необратимым».

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

Что сделать уже сегодня. В текущем дизайн-доке пометьте решения: обратимо / дорого откатить / почти навсегда. Хотя бы три пункта.

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

Если запомнить одну мысль — пишите код (и контракты), который завтра проще изменить.

На практике

На проверке кода

Спрашивайте не только про стиль:

• Сколько мест теперь «знают» это правило?
• Изменение ортогонально или тянет скрытые оси?
• Появилось ли новое разбитое окно?
• Можно ли откатить решение без «миграции крови из носа»?

В планировании фичи

Сначала трассирующий срез: один успех, один явный отказ. Потом полировка интерфейса и обобщение. Если срез нельзя за дни — вы не оценили неизвестность; режьте объём.

На инциденте

Ищите окна рядом с багом: почему мониторинг молчал, почему ретраи были бесконечными, почему конфиг правили руками. Инцидент без ремонта окна — приглашение к повтору.

В легаси

Ортогональность указом не появляется. Начните со шва: тест вокруг опасного изменения, адаптер на границе, запрет новым кодом повторять старую связность. Здесь книга хорошо стыкуется с Feathers и Fowler — см. список лучших книг.

С ИИ-ассистентами

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

Кому какая идея полезнее

Оценки — редакционные, не «наука»: ориентир, с чего начинать разговор в команде.

Ограничения и критика

Книга афористична. Легко цитировать слоганы без измерения и без договорённостей команды. Конкретные инструменты издания стареют быстрее идей.

В жёстких корпорациях «просто сделай ортогонально» упирается в политику владения, аудит и вендоров. Тогда прагматизм — в наименее вредном следующем шаге, а не в идеале из учебника.

Короткое сравнение. The Pragmatic Programmer ближе к разговору с сильным сеньором о привычках, чем к учебнику. Clean Code сильнее давит на локальную эстетику кода и ритуалы — и чаще вызывает религиозные войны. DDD (Evans) копает модель предметной области глубже, чем прагматик-афоризмы. XP сильнее про командную инженерию и обратную связь цикла. Берите «Прагматика» за словарь ремесла; не ждите от него ни полной модели домена, ни формальных гарантий устойчивости — для этого соседние книги серии (Evans, Kleppmann, Nygard).

Кому читать

Стоит начать здесь, если вы junior→middle и устали от хаотичных правок; если тимлид хочет общий язык о качестве изменений; если команда спорит о фреймворках и молчит о связности знания.

Можно отложить как первую книгу, если вы уже живёте непрерывной поставкой и культурой «срез раньше слайда» — но словарь всё равно полезен для онбординга.

Читайте критично, если ищете курс языка или справочник паттернов предприятия: это книга привычек.

Что сделать сегодня

Попробуйте один-два пункта на этой неделе:

1. Закройте одно настоящее разбитое окно в файле, который уже трогаете — или назначьте владельца долга.
2. Для текущей фичи проведите (или запланируйте на дни) один сквозной сценарий успеха и один отказ.
3. Найдите одно бизнес-правило и посчитайте, в скольких местах оно «живет».
4. Один раз на ревью спросите вслух: «можно ли проще / обратимее?»