John Ousterhout: практический дизайн, Tcl и цена сложности

Почему послание Оустерхаута всё ещё важно

John Ousterhout — учёный и инженер, чья работа охватывает как исследования, так и реальные системы. Он создал язык программирования Tcl, помог сформировать современные файловые системы и затем свёл десятилетия опыта к простой, немного неудобной идеи: сложность — главный враг софта.

Это послание остаётся актуальным, потому что большинство команд терпят не из‑за недостатка фич или усилий, а потому что их системы (и организации) становятся трудными для понимания, изменения и надёжного изменения. Сложность замедляет не только инженеров. Она просачивается в продуктовые решения, уверенность в роадмапе, доверие клиентов, частоту инцидентов и даже найм — потому что адаптация новых сотрудников превращается в месячную эпопею.

Главная мысль: сложность обременяет всё

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

Речь не про академическую чистоту. Это напоминание о том, что у каждого упрощения есть процентные платежи — а сложность это долг с самым высоким процентом.

Три ракурса в этой статье

Чтобы идея стала конкретной, мы посмотрим на послание Оустерхаута через три угла:

• Наследие Tcl: что Tcl угадал в плане простоты, композиции и «клея», и почему эти идеи распространились далеко за пределы языка.
• Связь с Бруксом: как «No Silver Bullet» соотносится с взглядом Оустерхаута, где они сходятся и чему это учит команды, которые хотят выпускать продукт.
• Практические правила дизайна: особенно «глубокие модули» и техники проектирования API, которые снижают когнитивную нагрузку для следующего человека, кто будет менять систему (обычно — вы).

Что вы сможете унести с собой

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

Что «сложность» значит для повседневных команд

Сложность — это не «много кода» или «сложная математика». Это разрыв между тем, что вы думаете система сделает при изменении, и тем, что она фактически делает. Система сложна, когда мелкие правки кажутся рискованными — потому что вы не можете предсказать радиус поражения.

Как сложность проявляется в повседневной работе

В здоровом коде вы можете ответить: «Если мы это поменяем, что ещё может сломаться?» Сложность делает этот вопрос дорогим.

Она часто скрывается в:

• Скрытых зависимостях: фича тихо опирается на колонку в базе, фоновой джоб или флаг конфигурации, которые не очевидны в редактируемом коде.
• Особых случаях: «Кроме enterprise‑клиентов», «Кроме пользователей, зарегистрировавшихся до 2021», «Кроме если запрос пришёл с мобильного». Эти исключения накапливаются, пока «нормальный путь» не станет неясным.
• Неясной ответственности: никто не ощущает себя владельцем области, поэтому исправления превращаются в осторожные заплатки вместо чётких улучшений. Со временем безопасный путь — «добавить ещё один обходной путь».

Цена: скорость, качество и уверенность

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

Существенная vs случайная сложность

Часть сложности существенна: бизнес‑правила, требования соответствия, пограничные сценарии реального мира. Их нельзя удалить.

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

Наследие Tcl: правильные идеи, которые распространились повсюду

Tcl родился с практической целью: упростить автоматизацию ПО и расширение приложений без переписывания. John Ousterhout спроектировал его так, чтобы команды могли добавить «ровно столько программируемости», сколько нужно — и дать эту мощь пользователям, операторам, QA или всем, кто должен скриптовать рабочие процессы.

Идея «glue language»

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

Эта модель оказалась влиятельной, потому что соответствовала тому, как реально делается работа. Люди не только строят продукты; они создают билд‑системы, тест‑хорнесс, админ‑инструменты, конвертеры данных и одноразовые автоматизации. Лёгкий скриптовый слой превращает эти задачи из «заведи задачу» в «напиши скрипт».

Что Tcl сделал правильно (и что разошлось по экосистемам)

Tcl сделал встраивание первостепенным: интерпретатор можно было интегрировать в приложение, экспортировать чистый командный интерфейс и мгновенно получить конфигурируемость и быструю итерацию.

Та же идея проявляется сегодня в системах плагинов, языках конфигурации, API расширений и встроенных рантаймах — вне зависимости от синтаксиса скриптов.

Она также укрепила полезную привычку дизайна: отделять стабильные примитивы (ядро хост‑приложения) от меняемой композиции (скрипты). Когда это работает, инструменты эволюционируют быстрее, не дестабилизируя ядро.

Ограничения и почему популярность ушла дальше

Синтаксис Tcl и модель «всё — строка» могли быть неинтуитивными, и большие Tcl‑базы порой тяжело понимать без строгих соглашений. По мере появления более богатых стандартных библиотек, лучшего инструментария и больших сообществ многие команды естественно мигрировали.

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

Уроки дизайна, скрытые в философии Tcl

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

Маленькое ядро, стимулирующее композицию

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

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

«Просто в использовании» vs «просто в реализации»

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

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

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

Маленькие примитивы могут успокаивать — или быть опасно острыми

Минимализм помогает только если примитивы согласованы. Если две похожие команды ведут себя по‑разному в пограничных случаях, пользователи начинают зубрить трюки. Набор маленьких инструментов превращается в «острые края», когда правила варьируются тонко.

Композиция vs одноразовые фичи (не только технически)

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

Философия Tcl за нож и сковороду: общие инструменты, которые чисто компонуются, чтобы не требовался новый гаджет для каждого рецепта.

Брукс в одной странице: «No Silver Bullet» и его посыл

В 1986 году Фред Брукс написал эссе с провокационным выводом: нет единственного прорыва — «серебряной пули», которая в один прыжок сделает разработку софта в разы быстрее, дешевле и надёжнее.

Его мысль не в том, что прогресс невозможен. Он в том, что программирование — среда, где мы можем делать почти всё, и эта свобода несёт уникальную ношу: мы постоянно определяем вещь по ходу её создания. Лучшие инструменты помогают, но они не стирают самую трудную часть работы.

Существенная vs случайная сложность

Брукс разделил сложность на две корзины:

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

Инструменты могут раздавить случайную сложность. Подумайте о том, что мы получили с уровнями выше: высокоуровневые языки, контроль версий, CI, контейнеры, управляемые БД и хорошие IDE. Но по Бруксу сущностная сложность доминирует, и она не исчезнет просто потому, что инструменты стали лучше.

Почему это важно и сейчас

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

Это задаёт напряжение, на которое делает упор Оустерхаута: если сущностную сложность нельзя удалить, может ли дисциплинированный дизайн существенно уменьшить утечку этой сложности в код — и, соответственно, в головы разработчиков каждый день?

«Ousterhout vs Brooks» без эмоций

Люди часто рисуют «Ousterhout vs Brooks» как битву оптимизма и реализма. Полезнее читать это как двух опытных инженеров, описывающих разные аспекты одной и той же проблемы.

Контраргумент Оустерхаута: дизайн даёт больше, чем кажется

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

Его практический контраргумент уже уже: команды часто считают сложность неизбежной, тогда как большая её часть самопорождена.

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

Предупреждение Брукса: часть сложности встроена

Брукс фокусируется на сущностной сложности: софт должен моделировать запутанную реальность, изменяющиеся требования и пограничные случаи вне кода. Даже с отличными инструментами это не исчезнет. Можно только управлять этим.

Где они согласны

Они куда ближе, чем кажется:

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

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

Вместо вопроса «Кто прав?», спрашивайте: Какая сложность под нашим контролем в этом квартале?

Команды не могут контролировать рыночные изменения или фундаментальную сложность домена. Но они могут контролировать, добавляют ли новые фичи особые случаи, заставляют ли API запоминать скрытые правила, и протекают ли модули внутрь вызывающих.

Это действие посередине: принимать сущностную сложность и бескомпромиссно сокращать случайную.

Глубокие модули: прятать сложность правильно

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

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

Глубокий vs поверхностный: аналогия из реальной жизни

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

Поверхностный модуль — это «кухня», которая выдаёт вам сырые ингредиенты с 12‑шаговой инструкцией и просит принести свою сковороду. Работа всё ещё выполняется — но её переложили на клиента.

Когда добавление уровней помогает (и когда вредит)

Дополнительные слои полезны, если они сводят множество решений в один очевидный выбор.

Например, слой хранилища, который предоставляет save(order) и внутри обрабатывает повторы, сериализацию и индексирование, — это глубокий модуль.

Слои вредят, когда они в основном переименовывают вещи или добавляют опции. Если новая абстракция вводит больше конфигурации, чем убирает — например save(order, format, retries, timeout, mode, legacyMode) — вероятно, она поверхностна. Код может выглядеть «организованным», но когнитивная нагрузка проявится во всех местах вызова.

Короткий чеклист: как заметить поверхностные модули

• API имеет много параметров, особенно булевых: useCache, skipValidation, force, legacy.
• Вызывающим нужно соблюдать специфическую последовательность («сначала A, потом B»), чтобы избежать тонких багов.
• Модуль протекает внутренние концепции (пути файлов, имена таблиц, правила потоков) в интерфейс.
• Большинство изменений требует правок в множестве мест, потому что абстракция не стабилизирует поведение.
• Документация читаетcя как предупреждение, а не как обещание («Не используйте X, когда Y, если не Z»).

Глубокие модули инкапсулируют не просто код — они инкапсулируют решения.

Дизайн API, который снижает когнитивную нагрузку

«Хороший» API — это не только тот, который многое может сделать. Это тот, который человек может удержать в голове, пока работает.

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

Что делает API удобным для людей

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

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

Почему «больше опций» повышает стоимость для всех

Каждый дополнительный флаг, режим или «на всякий случай» конфигурация становится налогом для всех пользователей. Даже если только 5% вызывающих нуждаются в нём, 100% теперь должны знать о его существовании, задумываться, нужен ли он им, и интерпретировать поведение при взаимодействии с другими опциями.

Так API накапливают скрытую сложность: не в одном вызове, а в комбинаторике.

Значение дефолтов, соглашений и нейминга

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

Ещё одно напоминание: внутренние API так же важны, как публичные. Большая часть сложности продукта живёт за кулисами — на границах сервисов, в общих библиотеках и «хелпер» модулях. Обращайтесь к этим интерфейсам как к продуктам: ревью и дисциплина версионирования (см. также /blog/deep-modules).

Где сложность проскальзывает: тактические фиксы и особые случаи

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

Распространённые ловушки, которые тихо накапливают сложность

Одна ловушка — флаги функций везде. Флаги полезны для безопасных выкатываний, но когда они затягиваются, каждый флаг умножает число возможных поведений. Инженеры перестают думать о «системе» и начинают думать о «системе, кроме когда флаг A включён и пользователь в сегменте B».

Другая — логика особых случаев: «Enterprise‑клиенты нуждаются в X», «Кроме в регионе Y», «Если аккаунт старше 90 дней». Эти исключения часто расползаются по коду, и через несколько месяцев никто не знает, какие ещё нужны.

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

Тактическое vs стратегическое программирование (по‑простому)

Тактическое программирование оптимизирует на эту неделю: быстрые фиксы, минимальные изменения, «залатать».

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

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

Простые ограничители, которые реально помогают

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

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

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

Сложность не остаётся в инженерии. Она просачивается в графики, надёжность и опыт клиентов.

Стоимость на уровне продукта: скорость, стабильность и онбординг

Когда система тяжела для понимания, любое изменение занимает дольше. Time‑to‑market соскальзывает, потому что каждый релиз требует больше координации, больше регрессионного тестирования и более «на всякий случай» этапов проверки.

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

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

Сложность проявляется как путаница у клиентов

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

Доверие падает, отток растёт, принятие замедляется.

Налог сложности для поддержки и операций

Саппорт платит через длинные тикеты и много переписок, чтобы собрать контекст. Операции платят через больше оповещений, больше ранбуков и более осторожные выкаты. Каждое исключение — это то, что нужно мониторить, документировать и объяснять.

Практический пример: ещё одна фича vs упрощённые потоки

Представьте запрос на «ещё одно правило уведомления». Добавить его кажется быстрым, но он вводит ещё одну ветвь поведения, больше копии в UI, больше тесткейсов и больше способов, как пользователи могут неправильно настроить систему.

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

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

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

Введите «бюджет сложности» в роадмап

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

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

Лёгкие метрики, которые команды реально могут поддерживать

Не нужны идеальные числа — достаточно сигналов, которые показывают тренд:

• Поверхность модуля: число публичных методов/эндпойнтов, флагов или полей конфигурации.
• Число концепций: сколько идей нужно изучить пользователю или новому инженеру, чтобы успешно работать.
• Change failure rate: как часто деплои требуют отката, хотфикса или срочной доработки.

Отслеживайте это по релизам и связывайте с решениями: «Мы добавили две публичные опции; что мы удалили или упростили в компенсацию?».

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

Прототипы часто оценивают по вопросу «можем ли мы это собрать?» Вместо этого используйте их, чтобы ответить: «Кажется ли это простым в использовании и трудным для неправильного применения?»

Попросите кого‑то незнакомого с фичей выполнить реалистичную задачу с прототипом. Измерьте время до успеха, вопросы и места неправильных предположений. Это «горячие точки» сложности.

Здесь современные рабочие процессы могут снизить случайную сложность — если они поддерживают быструю итерацию и лёгкий откат. Например, когда команды используют платформу вроде Koder.ai чтобы набросать внутренний инструмент или новый флоу через чат, функции как planning mode (чтобы прояснить намерение до генерации) и snapshots/rollback (чтобы быстро отменять рискованные изменения) делают ранние эксперименты безопаснее — без накопления полуброшенных абстракций. Если прототип проходит, вы всё ещё можете экспортировать исходники и применить те же принципы «глубоких модулей» и дисциплины API, описанные выше.

Планируйте чистки сложности с явными критериями успеха

Задайте работу «очистки сложности» периодически (ежеквартально или после большого релиза) и определите, что значит «готово»:

• Удалить опцию или особый случай (не просто рефакторить).
• Уменьшить шаги онбординга или требуемую конфигурацию.
• Слить два пересекающихся API в один.
• Улучшить показатель change failure rate для целевой области.

Цель — не «красивый код», а меньше концепций, меньше исключений и более безопасные изменения.

Практические выводы для команд на этот квартал

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

5–7 ёмких выводов

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

Короткий план действий (1–2 недели)

Выберите подсистему, которая регулярно вызывает путаницу (проблемы онбординга, повторяющиеся баги, много вопросов «как это работает?»).

1. Смоделируйте интерфейс: перечислите публичные функции/эндпойнты/флаги конфигурации и то, что вызывающие должны знать.
2. Упростите контракт: консолидируйте параметры, удалите режимы, запишите 2–3 инварианта, которые гарантирует модуль.
3. Удалите особые случаи: уберите ветви, добавленные для одного клиента, одной среды или исторического бага — замените общей политикой.
4. Добавьте лёгкий шлюз: новые флаги и исключения требуют короткой заметки с дизайном и одного ревьюера, который спросит: «Можно ли обойтись без особого случая?».

Дополнительные материалы и продолжение

• John Ousterhout, A Philosophy of Software Design
• Fred Brooks, “No Silver Bullet”
• Fred Brooks, The Mythical Man‑Month (особенно про концептуальную целостность)

Внутренние продолжения, которые вы можете запустить: «review сложности» при планировании (/blog/complexity-review) и быстрая проверка, уменьшает ли ваш тулкит случайную сложность или добавляет новые слои (/pricing).

Что бы вы удалили первым, если могли убрать только один особый случай на этой неделе?