Глоссарий

Термины даются парой: русский + английский. Английский вариант используй в промптах ИИ-агенту – он понимает язык принципов. Номер рядом с термином – урок, где он разбирается.

Модуль 1Сложность – главный враг

Сложностьcomplexityурок 1

Всё в структуре системы, что мешает её понимать и изменять. Главный враг по Ousterhout. Накапливается мелкими порциями, а не приходит одним куском. Агенту: «this adds complexity – simplify» / «это усложняет – упрости».

Тактическое программированиеtactical programmingурок 1

Режим «лишь бы заработало побыстрее». Каждый шаг чуть-чуть ухудшает структуру. Так по умолчанию работают джуны – и ИИ-агенты без надзора.

Стратегическое программированиеstrategic programmingурок 1

Режим «рабочий код – не цель, а побочный эффект хорошей структуры». Небольшие постоянные вложения в дизайн (~10–20% времени), которые окупаются скоростью всех будущих изменений.

Технический долгtechnical debtурок 1

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

Изменение против шерстиchange amplificationурок 1

Симптом сложности №1: одно маленькое изменение требует правок во многих местах.

Когнитивная нагрузкаcognitive loadурок 1

Симптом сложности №2: сколько всего нужно держать в голове, чтобы безопасно сделать изменение.

Неизвестные неизвестныеunknown unknownsурок 1

Симптом сложности №3, самый опасный: непонятно даже, ЧТО нужно знать или менять, чтобы задача была выполнена корректно.

Модульmoduleурок 2

Относительно самостоятельная часть системы с чёткой зоной ответственности: платежи, авторизация, отчёты. У модуля есть интерфейс (что он умеет) и реализация (как он это делает внутри).

Интерфейсinterfaceурок 2

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

Глубокий модульdeep moduleурок 2

Много пользы за простым интерфейсом (пример: «сохрани файл» прячет тысячи деталей работы с диском). Противоположность – мелкий (shallow) модуль: сложный интерфейс при малой пользе. Агенту: «make this module deeper – simpler interface, more functionality inside».

Сокрытие информацииinformation hidingурок 2

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

Утечка деталейinformation leakageурок 2

Одно и то же знание расползлось по нескольким частям системы – менять придётся везде сразу.

Связанностьcouplingурок 3

Насколько части системы зависят друг от друга: поменял одну – придётся трогать другую. Чем ниже, тем лучше.

Связностьcohesionурок 3

Насколько содержимое одного модуля относится к одному делу. Правило сеньора: high cohesion, low coupling.

Неявная договорённостьimplicit contractурок 3

Части системы полагаются на нигде не зафиксированный формат или порядок – в одном месте поменял, в трёх сломалось.

Общие данныеshared global stateурок 3

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

Модуль 2Мышление требованиями

XY-проблемаXY problemурок 4

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

Пять почемуfive whysурок 4

Техника докапывания до реальной проблемы повторным вопросом «почему это нужно?».

Критерий успехаsuccess criteriaурок 4

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

YAGNIYou Aren't Gonna Need Itурок 5

Принцип «не строй под предполагаемое будущее – только под известное настоящее».

Стоимость ношенияcarrying costурок 5

Постоянная цена существования фичи в системе: она усложняет все остальные изменения, даже если ей не пользуются.

Расползание границscope creepурок 5

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

MVPminimum viable productурок 5

Минимальный эксперимент для проверки главной гипотезы о пользователе, а не урезанный продукт.

Счастливый сценарийhappy pathурок 6

Единственный путь, где всё идёт как задумано. Витрина продукта, а не весь продукт.

Краевой случайedge caseурок 6

Ситуация на границе нормальной работы (пусто, обрыв, повтор). Это требование, а не баг.

Правило «ноль – один – много»zero – one – manyурок 6

Проверять поведение при нуле элементов, одном и очень многих – три случая ломаются по-разному.

Модуль 3Архитектура и данные

Границаboundaryурок 7

Линия, отделяющая часть системы. Хорошая граница переживает замену того, что за ней.

Контрактcontract / APIурок 7

Договорённость о том, что проходит через границу между частями системы.

Граница доверияtrust boundaryурок 7

Линия между тем, что ты контролируешь, и внешним миром. Всё входящее снаружи проверяется на ней.

Модель данныхdata modelурок 8

Описание сущностей (entities) системы и связей (relations) между ними. Проектируется до кода: код меняется легко, схема данных – тяжело.

Миграция данныхdata migrationурок 8

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

Состояниеstateурок 9

Всё, что система помнит: платежи, доступы, настройки.

Единственный источник правдыsingle source of truth, SSOTурок 9

Ровно одно место, где факт хранится по-настоящему. Всё остальное – производные копии. Вопрос сеньора: «кто владелец этого факта?»

Производные данныеderived dataурок 9

Данные, вычисленные из источника правды. Их можно стереть и пересчитать без потерь.

Кэшcacheурок 9

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

Модуль 4Компромиссы и выбор технологий

Компромиссtrade-offурок 10

Инженерное решение как обмен: что-то получаешь, чем-то платишь. «Лучшего» варианта нет, есть подходящий под контекст. Агенту: «дай 2 варианта с плюсами, минусами и ценой ошибки».

Цена ошибкиcost of failureурок 10

Что случится с продуктом и бизнесом, если решение откажет. Главный критерий выбора между вариантами.

Жетоны инновацийinnovation tokensурок 11

Ограниченный запас нового и рискованного, который проект может себе позволить (~3 штуки, по Маккинли). Тратить на уникальность продукта, а не на модный стек.

Известные способы отказаknown failure modesурок 11

Главная ценность зрелой «скучной» технологии: известно не только что она умеет, но и как ломается и чинится.

Ядро против обвязкиcore vs commodityурок 12

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

Односторонняя дверьone-way doorурок 12

Необратимое решение (выбор БД, формат данных) – думай долго. Двусторонняя дверь (two-way door) – легко откатить, решай быстро.

Стоимость владенияcost of ownershipурок 12

Полная цена «своего» решения: не написание (агент сделал его дешёвым), а поддержка, безопасность и отказы – навсегда.

Модуль 5Надёжность и риски

Режим отказаfailure modeурок 13

Конкретный способ, которым часть системы перестаёт работать: сеть, внешний API, ресурсы, ключи. Агенту: «что увидит пользователь, когда этот сервис упадёт?»

Деградация с достоинствомgraceful degradationурок 13

При отказе части система теряет возможности постепенно, а не молчит и не падает целиком.

Радиус пораженияblast radiusурок 13

Насколько далеко разлетаются последствия одного отказа. Сбой второстепенного не должен трогать критичное.

Определить ошибки прочьdefine errors out of existenceурок 14

Изменить дизайн операции так, чтобы целый класс ошибок стал невозможен (Ousterhout, глава 10).

Падать громко и раноfail fastурок 14

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

Проглоченная ошибкаswallowed errorурок 14

Ошибка перехвачена и молча проигнорирована: ни пользователю, ни в лог. Любимый паттерн ИИ-агентов – проверяй.

Аутентификацияauthenticationурок 15

Проверка «кто ты». Сама по себе не защищает данные от других залогиненных пользователей.

Авторизацияauthorizationурок 15

Проверка «что тебе можно» на каждом действии. Её отсутствие – дыра номер один по OWASP.

Минимальные праваleast privilegeурок 15

Каждому ключу и сервису – ровно столько прав, сколько нужно для работы.

Инъекцияinjectionурок 15

Внедрение команды через внешний ввод. Любой ввод извне проверяется и не подставляется «как есть».

Модуль 6Качество и обратная связь

Регрессияregressionурок 16

Новое изменение ломает старое поведение, которое раньше работало. Проблема №1 при ИИ-разработке: агент правит смело и широко.

Пирамида тестовtest pyramidурок 16

Стратегия: много быстрых мелких тестов в основании, мало медленных сквозных наверху.

Юнит-тестunit testурок 16

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

Сквозной тестend-to-end testурок 16

Прогон целого пользовательского сценария через всю систему, от клика до результата.

Ревью кодаcode reviewурок 17

Проверка изменения перед приёмкой: в первую очередь дизайна и уместности, а не строк. Агенту: «сделай ревью собственного кода как строгий сеньор».

Магические значенияmagic numbersурок 17

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

Наблюдаемостьobservabilityурок 18

Способность системы сообщать о своём состоянии самостоятельно – раньше жалоб пользователей.

Проверка здоровьяhealth checkурок 18

Страница-«пульс» приложения, которую внешний сервис опрашивает и поднимает тревогу при молчании.

Алертalertурок 18

Правило «разбуди меня, если…»: автоматическое уведомление при выходе метрики за порог.

Модуль 7Senior + ИИ-агент

Сверхуверенный напарникoverconfident pair programmerурок 19

Ментальная модель ИИ-агента по Willison: быстрый и начитанный, но одинаково уверенно выдаёт верные и неверные решения.

Контекст агентаcontext windowурок 19

Оперативная память агента: весь разговор и прочитанные файлы. При переполнении агент забывает инструкции и ошибается – дели работу на сессии.

Спецификацияspecурок 20

Записанные до старта решения: проблема, границы, модель данных, краевые случаи, критерии приёмки.

Критерии приёмкиacceptance criteriaурок 20

Проверяемый список «фича готова, когда…» – планка для агента и чек-лист на приёмке.

Память проектаproject memoryурок 20

Файл правил проекта (CLAUDE.md и аналоги), который агент читает каждую сессию: стек, принципы, запреты.

Цикл работы с агентомresearch → plan → execute → reviewурок 21

Рабочий процесс сеньора: исследование, план, ревью плана, стройка малыми шагами с проверкой.

Контрольная точкаcheckpointурок 21

Зафиксированное работающее состояние (обычно коммит), к которому можно откатиться после неудачной итерации.