Тезис книги

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

1. Как вы меняете код — локально или каскадом по системе.
2. Как вы дублируете знание — правила бизнеса, схемы, договорённости.
3. Как вы проверяете гипотезы — план на бумаге против тонкого рабочего среза.
4. Как вы относитесь к «мелочам» — мелкий беспорядок как процент по техдолгу.

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

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

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

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

На практике ортогональность чувствуется так: вы можете объяснить зачем файл существует одним предложением; тест падает локально, а не «где-то в пайплайне»; новый человек находит место правки без археологии из пяти репозиториев.

Антиортогональность узнаётся по симптомам: «не трогай этот модуль — он священный»; правка флага в админке требует согласования с тремя командами; один и тот же смысл назван по-разному в трёх сервисах. Тогда сначала режут связи (адаптеры, явные контракты), а не добавляют ещё одну «временную» ветку if.

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

Классическая ошибка чтения DRY: «никогда не повторяй строки». Hunt и Thomas бьют точнее: опасно дублировать знание. Одна политика («клиент может отменить заказ за 24 часа») в трёх местах — фронт, API, отчёт — неизбежно разъедется. Две одинаковые строки цикла for могут быть случайным сходством и не стоить общей абстракции.

Практический тест: если меняется бизнес-правило, сколько мест придётся править и помнить? Если больше одного — знание размазано. Если абстракция «общая утилита» связывает несвязанные смыслы ради экономии строк — вы купили связанность, а не DRY.

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

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

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

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

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

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

Чем это не «прототип ради демо»: прототип часто врёт о интеграции («потом подключим»). Трассирующий срез врёт меньше: вы рано видите, что контракт API другой, что очередь теряет сообщения, что права доступа ломают сценарий. План уточняется фактами, а не слайдами.

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

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

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

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

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

Оценивайте сроки и риски, но не притворяйтесь пророком. Где можно — оставляйте решения обратимыми: feature flags, адаптеры к внешней системе, явные границы модулей, версионирование контрактов. Необратимый выбор (миграция данных без отката, публичный API без версий, «единственная» СУБД на десять лет) делайте редко и осознанно — с записью, почему.

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

Коммуникация, ответственность и «кот в мешке»

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

На практике

В код-ревью

Спрашивайте не только про стиль. Полезные вопросы в духе книги:

• Сколько мест теперь «знают» это правило бизнеса?
• Это изменение ортогонально или тянет скрытые оси?
• Есть ли здесь новое разбитое окно (проглоченная ошибка, TODO без владельца)?
• Можно ли откатить решение без миграции крови из носа?

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

Сначала трассирующий срез на один сценарий успеха и один явный отказ. Потом полировка UX, обобщение, «красота». Если срез нельзя провести за дни — вы не оценили неизвестность; режьте scope до того, что можно проверить.

На инциденте

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

В команде с легаси

Ортогональность и DRY не появляются указом. В монолите 2012 года начните с шва: тест вокруг опасного изменения, адаптер на границе, запрет новым кодом повторять старую связность. Здесь книга хорошо стыкуется с Feathers (Working Effectively with Legacy Code) и Fowler (Refactoring) — см. список лучших книг.

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

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

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

Книга афористична. Легко цитировать слоганы («будь прагматиком», «не оставляй разбитых окон») без дисциплины измерения и без договорённостей команды. Часть примеров и инструментов юбилейного издания всё равно стареет быстрее идей: конкретные редакторы, языки, «серебряные пули» экосистемы.

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

Наконец, книга слабее там, где нужны глубокие модели предметной области или формальные гарантии (DDD, формальные методы, серьёзная эксплуатационная устойчивость). Для этих зон смотрите соседние книги серии: Evans, Kleppmann, Nygard.

Кому читать

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

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

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