Разбираем идеи Джона Оустерхута: наследие Tcl/Tk, спор «Оустерхут vs Брукс», и практические приемы, как снижать сложность в продуктах.
Джон Оустерхут — профессор Стэнфордского университета и практик, который одинаково уверенно чувствует себя и в исследованиях, и в индустрии. Он известен как создатель Tcl и Tk (языка и GUI-инструментария, на которых в 90‑е быстро строили инструменты и прототипы), а также как автор книги A Philosophy of Software Design. Если вам попадалось выражение «сложность — главный враг сопровождения», то с высокой вероятностью оно пришло из его школы мысли.
Важно, что подход Оустерхута сегодня снова становится прикладным: команды ускоряют разработку, используют автогенерацию и LLM‑инструменты, но именно в такие моменты архитектурная дисциплина определяет, станет ли продукт быстрее — или просто быстрее накопит хаос.
Оустерхут не предлагает «серебряную пулю» и не спорит о вкусах синтаксиса. Его фокус — на том, почему системы становятся тяжёлыми:
Он описывает сложность как накопленный долг в голове команды: сколько контекста нужно удерживать, чтобы безопасно что-то изменить. Из этого вытекают практические принципы: проектировать «глубокие» модули (много пользы при малом интерфейсе), прятать детали, делать API, которые трудно использовать неправильно, и постоянно отслеживать, где растёт когнитивная нагрузка.
Когда продукт растёт, растут и зависимости: больше команд, интеграций, сценариев, пользователей. Подход Оустерхута помогает заметить момент, когда скорость разработки падает не из‑за «лени» или нехватки людей, а из‑за архитектурной сложности — и начать лечить причину, а не симптомы.
Этот же принцип работает и в «быстрой» разработке через чат‑интерфейс и LLM: прототип можно собрать за часы, но без ясных границ модулей и аккуратных контрактов любой следующий шаг становится дороже. Поэтому правила «про глубину модулей» и «про дизайн интерфейсов» — хороший фундамент, даже если вы ускоряете цикл поставки с помощью платформ вроде TakProsto.AI.
Tcl (Tool Command Language) появился не как «еще один язык», а как практический ответ на боль больших систем: нужно было быстро настраивать и расширять сложное приложение без перекомпиляции, долгих циклов поставки и вмешательства в ядро. Оустерхут продвигал идею скриптового уровня как «клея»: ядро делает тяжелую работу, а сценарии связывают компоненты и задают поведение.
Ключевое наследие Tcl — не синтаксис, а модель «настраиваемости».
Скриптовый слой:
Сегодня эту роль выполняют Lua в играх, JavaScript в приложениях и автоматизации, Python в инструментах и пайплайнах — и везде повторяется тот же мотив: «ядро + сценарии» как способ отделить стабильную основу от частых изменений.
Tk показал, что графический интерфейс можно сделать расширяемым и переносимым, если:
С точки зрения дизайна ПО это ранний и очень наглядный пример того, как хорошо продуманный слой абстракции удерживает сложность внизу, а наверху оставляет «конструктор».
Сильная сторона — скорость изменений и модульность. Слабая — риск расползания логики в сценариях, если отсутствуют границы, соглашения и понятные интерфейсы. Без дисциплины «клей» превращается в ком грязных зависимостей.
Главное, что дошло до индустрии: проектируйте расширяемость заранее, делайте интерфейсы простыми, а поведение — настраиваемым. И еще: если API ядра удачно «нарезан», команды верхнего уровня остаются короткими и читаемыми — это напрямую бьется с темой борьбы со сложностью, к которой Оустерхут вернется в своих принципах дизайна.
Tcl/Tk часто вспоминают как «язык из 90‑х», но архитектурные идеи вокруг него удивительно современны: отделить стабильное основание системы от того, что меняется каждый день, и заставить эти части общаться через простые, понятные интерфейсы.
В экосистеме Tcl исторически сильна идея тонкого, надежного ядра и более гибкого слоя сценариев. Ядро делает тяжелую работу: обеспечивает производительность, работу с ресурсами, безопасность, предсказуемые правила.
Скрипты (или более высокоуровневый слой) отвечают за «поведение»: настройку, оркестрацию, бизнес-правила, быстрые эксперименты. Практический вывод: если продукт постоянно меняет правила — не стоит «впечатывать» их в низкоуровневую часть. Оставляйте изменяемое наверху.
Хорошая граница — это когда модуль можно улучшать внутри, не заставляя переписывать соседей. Проверка простая: можете ли вы заменить реализацию (хранилище, алгоритм, формат кэша), оставив интерфейс прежним?
Если любое изменение «протекает» наружу — граница нарисована по удобству команды, а не по смыслу. Частая ошибка: модуль экспортирует слишком много деталей (структуры данных, внутренние статусы, «служебные» флаги). В итоге каждое улучшение превращается в миграцию по всей системе.
Оустерхут подчеркивает: сложность часто живет в интерфейсах, а не в коде. Плохой интерфейс заставляет каждого пользователя модуля держать в голове исключения и «особые случаи».
Хороший интерфейс делает наоборот: прячет вариативность внутрь, предлагает один-два очевидных пути, имеет ясные ошибки и предсказуемые значения по умолчанию.
Для сервисов: отделяйте стабильные «платформенные» компоненты (авторизация, лимиты, наблюдаемость) от слоя правил.
Для библиотек: не экспортируйте внутренние структуры; лучше дайте функции более высокого уровня.
Для платформ: думайте как Tcl — расширяемость через ограниченный, хорошо продуманный контракт, а не через бесконечные точки «настроек», которые никто не понимает.
Отдельно стоит отметить: если вы используете инструменты, где значительная часть логики создаётся через диалог (например, в vibe‑coding), границы модулей и контракты важны вдвойне. В TakProsto.AI удобно фиксировать эти договорённости заранее в planning mode, а затем проверять, что реализация следует выбранным контрактам, а не разрастается опциями «по ходу дела».
Спор между Джоном Оустерхутом и Фредом Бруксом часто пересказывают упрощенно: «Один за переписывание, другой против». На практике это дискуссия о том, как управлять сложностью, рисками и скоростью эволюции продукта.
Брукс предупреждал: переписывание системы почти всегда дороже, чем кажется. Пока команда заново набирает функциональность, продукт теряет время, а пользователи — терпение. Параллельно растет риск регресса: старый код накопил массу мелких исправлений и знаний о реальных кейсах, которые редко отражены в спецификациях.
Еще одна типичная проблема — «вторая система»: желание сделать идеально ведет к усложнению и затягиванию сроков.
Оустерхут не призывает переписывать все подряд. Его мысль ближе к такой: если накопленная сложность стала настолько большой, что любые изменения требуют непропорциональных усилий, то контролируемое переписывание части системы может быть самым быстрым способом вернуть управляемость.
Ключевое условие — цель не «переписать красиво», а радикально упростить архитектуру: убрать кривые абстракции, распутать зависимости, сделать интерфейсы понятными. И часто речь не о «big bang», а о замене по модулям, с четкой границей и планом миграции.
По сути, это спор о методе контроля сложности:
Оба правы в разных ситуациях: проблема не в выборе «переписывать/не переписывать», а в диагностике того, где именно система стала слишком сложной и какой путь дешевле по сумме затрат.
Ответы обычно подсказывают, что нужнее: хирургическое упрощение, эволюция с рефакторингом или ограниченное переписывание там, где оно реально снижает сложность.
Желание «переписать с нуля» почти всегда рождается из боли: система медленно меняется, качество падает, а команда устала от сюрпризов. Оустерхут бы сказал: сначала разберите, какая сложность реально мешает, и где она живёт — в архитектуре, в API, в процессах или в накопленных обходных путях.
Эволюция (развитие текущей системы) обычно выигрывает, если:
Полный перепис оправдан, когда:
Самая практичная стратегия — инкрементальная замена:
Похожая логика полезна и при быстрых итерациях в vibe‑coding: возможность делать снимки и откатываться к стабильному состоянию (snapshots и rollback в TakProsto.AI) снижает стоимость экспериментов и помогает не «дожимать» сомнительные решения.
Заранее задайте метрики: доля трафика на новой части, время разработки фич, число инцидентов, скорость релизов. Если 2–3 итерации подряд метрики не улучшаются — пересматривайте план, а не «дожимайте перепис». Иногда правильный итог — гибрид: перепис только ядра, а вокруг — аккуратная эволюция.
Оустерхут предлагает смотреть на сложность не как на «много кода» или «умные алгоритмы», а как на то, что делает систему трудной для понимания и изменения. Если каждое исправление требует держать в голове слишком много деталей, вы уже платите налог сложностью — даже если продукт работает.
Неизбежная (essential) сложность продиктована самой задачей: например, расчеты налогов, работа с разными способами оплаты, требования безопасности. Убрать ее нельзя — можно только аккуратно упаковать в хорошие абстракции.
Случайная (accidental) сложность появляется из-за решений команды: лишние уровни, запутанные зависимости, «временные» костыли, неудачные имена, дублирование логики. Она не помогает пользователю, но постоянно мешает разработке.
Сложность редко ощущается как один большой провал. Обычно она заметна по симптомам:
Если для добавления маленькой функции нужно согласовать десяток деталей и перепроверить пять мест, это и есть практическое определение сложности.
Сложность растет постепенно: каждая отдельная уступка кажется рациональной («быстрее выпустить», «потом причешем»), но эффекты суммируются. Платят за это не авторы компромисса, а будущие исполнители задач: новые сотрудники, дежурные инженеры, команда поддержки и, в итоге, пользователи — через более медленные релизы и нестабильность.
Не нужны сложные KPI, достаточно регулярных «термометров»:
Замечать сложность — значит измерять трение. Если трение растет, пора разбираться с причинами, пока система не стала неподъемной.
Сложность редко исчезает «сама». Ее либо прячут в правильном месте, либо размазывают по системе так, что каждый новый запрос требует раскопок. У Оустерхута ключевой инструмент — абстракции, поддержанные хорошо нарезанными модулями.
Хорошая абстракция делает использование простым, а сложность — внутренним делом реализации. Снаружи у вас короткий список операций и ясные правила: какие входы допустимы, что гарантируется на выходе, какие ошибки возможны.
Практический тест: может ли разработчик, не читая исходники, правильно применить модуль после просмотра API и примеров? Если нет — абстракция не снижает сложность, она перекладывает ее на пользователя.
Протекающая абстракция заставляет знать «как там внутри устроено», иначе все ломается. Типичный признак — внезапные исключения из правил: «в целом работает, но только если…». Еще хуже — двусмысленные контракты, когда модуль вроде бы обещает одно, но в частных случаях ведет себя иначе.
Чтобы не допускать утечек, полезно:
Оустерхут подчеркивает: у модуля должен быть один «ответственный» владелец идеи — цельная концепция, ради которой модуль существует. Это не про оргструктуру, а про дизайн: модуль отвечает за одну понятную область и скрывает ее сложность целиком.
Если модуль решает две несвязанные задачи, пользователю приходится держать в голове две модели одновременно — сложность растет.
«Слой ради слоя» добавляет абстракцию без выигрыша: интерфейс становится длиннее, а понимание — не проще.
«Общие утилиты без границ» — папка utils, куда складывают все подряд. Такие функции быстро превращаются в глобальную зависимость и размывают ответственность: никто не знает, что можно менять безопасно, а что поломает полсистемы.
Лучшее правило на практике: если вы не можете одним предложением объяснить, за что модуль отвечает и что он гарантирует, — он уже начал увеличивать сложность.
API — это контракт между командами, модулями и будущими версиями продукта. Плохой контракт создает «невидимую» сложность: каждое использование требует догадок, чтения исходников и уточнений в чате. Хороший API, наоборот, снижает когнитивную нагрузку: его можно применять уверенно и одинаково.
Очевидность начинается с имен. Названия должны отвечать на вопрос «что делает» и «на чем работает», а не «как устроено внутри». Избегайте двусмысленностей (например, update — что обновляет?) и сокращений, понятных только авторам.
Параметры — это тоже часть интерфейса. Лучше меньше, но точнее: один параметр — одна ответственность. Если аргументы неизбежно многочисленны, используйте именованные параметры/опции и единый стиль по всему модулю (одинаковые названия для одинаковых вещей, одинаковый порядок, одинаковые единицы измерения).
Хороший дефолт делает частый сценарий простым, а редкие — настраиваемыми. «Без сюрпризов» означает:
Правило: изменения интерфейса дороже изменений реализации. Планируйте версионирование (хотя бы MAJOR/MINOR), вводите деприкации заранее и давайте путь миграции: предупреждение, период сосуществования, автоматический перевод (скрипт/линтер), четкие заметки о релизе. Если нужна «ломающая» версия — объясните, какую сложность она снимает и почему иначе нельзя.
Сложность редко появляется как «большая ошибка». Чаще она накапливается из сотни мелких решений: непрояснённых контрактов, неочевидных зависимостей, «временных» костылей, которые пережили автора. Инженерные привычки — это не бюрократия, а регулярные механизмы, которые не дают системе деградировать.
У Оустерхута хороший принцип: если вы не можете коротко объяснить, как модуль используется и что гарантирует, значит дизайн ещё сырой. Документация здесь не «после релиза», а способ обнаружить скрытую сложность.
Практика: перед реализацией написать 10–15 строк про API модуля (назначение, входы/выходы, ошибки, примеры). Если текст получается длинным, полным оговорок и исключений — это сигнал упростить интерфейс.
Тесты важны не количеством, а тем, что они фиксируют поведение, которое команда считает обещанием. Именно «неявные контракты» чаще всего ломаются при рефакторинге.
Фокус:
Когда тест сложно написать, это тоже диагностика: вероятно, модуль слишком связан с окружением или делает слишком много.
Полезное ревью ищет не «правильный стиль», а источники будущей сложности:
Хороший вопрос на ревью: «Какой самый простой способ использовать этот код через полгода человеку, который его не писал?»
Линтеры и статанализ полезны тем, что снимают спорные мелочи и освобождают ревью для смысла. Ещё сильнее работают шаблоны PR: краткое описание изменения, риск, план отката, какие тесты добавлены/обновлены.
Если вы поставляете продукт через платформу с быстрыми итерациями и автосборкой, дисциплина отката и повторяемости становится частью инженерной гигиены. В этом смысле полезны функции деплоя и хостинга, кастомные домены, а также снапшоты с rollback — чтобы экспериментировать быстро, но без необратимых последствий.
Сложность — это не «красиво/некрасиво в коде». Это скрытые издержки, которые делают продукт медленным: функции выходят реже, ошибки чинятся дольше, а команда начинает избегать изменений. В результате рынок уходит к тем, кто быстрее учится на обратной связи и быстрее доставляет ценность.
Когда поведение системы трудно предсказать, каждое изменение требует «раскопок»: понять контекст, проверить побочные эффекты, согласовать детали между командами. Релиз превращается в череду «починили одно — сломали другое». Чтобы снизить риск, добавляют больше согласований и ручных проверок — и цикл поставки удлиняется.
Пока вы выпускаете улучшение раз в квартал, конкурент выпускает три небольших обновления в месяц. Даже если у вас сильнее идея, вы теряете темп обучения: меньше экспериментов, меньше данных, больше ставок «ва-банк».
Чаще всего она накапливается не в «умных алгоритмах», а в интерфейсах и связях:
Любая правка тянет цепочку изменений, которую невозможно оценить заранее.
Непрозрачность рождает противоречивые ожидания. Один клиент считает, что система «должна» вести себя так, другой — иначе, и оба по‑своему правы, потому что правила нигде четко не зафиксированы.
Поддержка получает больше тикетов «не работает» вместо конкретных дефектов. Продажи сталкиваются с вопросами «а как точно это будет в нашем случае?» — и вынуждены обещать, что «скорее всего да», увеличивая риск разочарования после покупки.
Говорите не про рефакторинг, а про управляемость:
Полезная формула для разговора: «Мы убираем неопределенность, чтобы быстрее и безопаснее поставлять изменения — это напрямую влияет на скорость роста и удержание клиентов».
Ниже — план на 1–2 недели, который помогает «приземлить» идеи Оустерхута в реальную работу команды. Цель не в большом переписывании, а в снижении ежедневных потерь на понимание, правки и согласования.
Аудит модулей (2–3 часа на команду). Выпишите 10–20 мест, где чаще всего «больно»: много вопросов к коду, частые баги, сложные правки, неоднозначное поведение.
Чистка API (точечно). Выберите 2–3 самых используемых интерфейса и:
Если вы создаёте приложение в TakProsto.AI (веб, серверное или мобильное), этот список можно держать прямо в формате «контрактов» для ключевых частей: UI (React), backend (Go + PostgreSQL), интеграции и доменная модель. Такой формат помогает избегать ситуации, когда ускорение разработки превращается в ускорение накопления случайной сложности.
«Бюджет сложности». В каждой задаче фиксируйте, сложность растет или падает. Если растет — что компенсирует (упрощение в другом месте, удаление старого пути, улучшение доков).
Правила добавления опций. Новая опция появляется только если:
Короткие дизайн‑доки. Для изменений, которые трогают интерфейсы или границы модулей: 1–2 страницы «проблема → варианты → выбранный вариант → последствия». Это дисциплинирует API.
Соберите внутреннюю подборку правил и примеров в базе знаний, а для регулярного чтения и обсуждения — заведите рубрику в /blog.
Если вы внедряете процесс в компании и нужно понять, как это повлияет на стоимость и формат работы (например, обучение, консультации, аудит), вынесите опции в отдельную страницу вроде /pricing — так решения будет проще согласовывать.
И полезное «прикладное продолжение» темы: попробуйте зафиксировать принципы Оустерхута как часть вашего рабочего потока — от планирования контрактов до деплоя. В TakProsto.AI это удобно делать на практике: быстро собирать продуктовые гипотезы через чат, экспортировать исходники, а затем доводить архитектуру до «глубоких модулей» и понятных API, сохраняя скорость без потери управляемости.
Лучший способ понять возможности ТакПросто — попробовать самому.
