zharkevich.ru
Как Windows сломала кнопку «Пуск»

Как Windows сломала кнопку «Пуск»

· 18 мин чтения

Операционная система, которая забыла, как запускать «Пуск»

Лето 2025-го. Обычный рабочий день. На очередном компьютере ставится «накопительное обновление безопасности» для Windows 11. Машина перезагружается, пользователь входит в систему и сразу понимает: что-то не так.

Меню «Пуск» не открывается. Панели задач нет. Проводник запускается через раз и иногда падает без объяснений. «Параметры» не стартуют вообще — как будто их никогда не существовало.

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

В ноябре появляется статья поддержки KB5072911: Microsoft признаёт, что после июльского накопительного обновления 2025 года (KB5062553) для Windows 11 версии 24H2 и новее «различные приложения, такие как StartMenuExperienceHost, поиск, системные настройки, панель задач или проводник, могут испытывать трудности» при инициализации.

Переведём на человеческий: обновление сломало базовые элементы оболочки системы. Пуск, панель задач, проводник, настройки — всё то, чем человек пользуется каждый день, может просто не подняться после входа. Особенно часто это случается в VDI-окружениях и непостоянных установках.

И да, есть «временное решение». Выглядит оно как заклинание для продвинутого администратора:

Add-AppxPackage -Register 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode
Add-AppxPackage -Register 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml' -DisableDevelopmentMode
Add-AppxPackage -Register 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode

Плюс логон-скрипт, который задерживает запуск проводника до тех пор, пока оболочечные пакеты не зарегистрируются.

Итак, в 2025 году, чтобы вернуть себе меню «Пуск», официально рекомендуют руками прогнать Add-AppxPackage. Не на форуме энтузиастов, а в документации Microsoft.

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

Оболочка как большой фронтенд

Под капотом Windows 11 давно нет одного «толстого» explorer.exe, как в старые времена. Оболочка — это мозаика из отдельных пакетов:

  • MicrosoftWindows.Client.CBS — часть клиентской оболочки,
  • Microsoft.UI.Xaml.CBS — XAML-библиотеки для отрисовки интерфейса,
  • MicrosoftWindows.Client.Core — ещё один фрагмент клиентской части.

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

  1. Зарегистрировать эти пакеты в его профиле,
  2. И только потом запускать StartMenuExperienceHost, панель задач, проводник, «Параметры» и прочие компоненты оболочки.

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

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

Разница лишь в том, что это не корпоративный портал, а операционная система, от которой ожидают эталонной надёжности.

И вот здесь где-то с обложек книг на нас укоризненно смотрят Вирт и Эдсгер Дейкстра. Их книги и статьи написаны десятилетия назад, но кажется, будто авторы видели этот баг заранее.

Когда программирование ещё было искусством думать

В 60–70-х годах программы писали медленно, машины стоили дорого, а сбой мог сорвать космический запуск или завалить ночной пакет расчётов. Отношение к коду было не «главное — выкатить фичу», а «мы обязаны понимать, что именно делает эта система».

Эдсгер Дейкстра и смирение программиста

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

В докладе «The Humble Programmer» он формулирует это так:

«Толковый программист осознаёт пределы собственного разума; поэтому он подходит к задаче со смирением и, в частности, избегает хитроумных трюков как чумы».

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

Никлаус Вирт и «стройный софт»

Никлаус Вирт в ETH Zürich шёл ещё более практическим путём. Он проектировал языки (Algol W, Pascal, Modula, Oberon), но не останавливался на этом. Вокруг этих языков он строил полный стек: рабочие станции Lilith и Ceres, операционные системы Medos-2 и Oberon System, компиляторы и среду разработки.

В книге «Project Oberon: The Design of an Operating System, a Compiler, and a Computer» он показывает, как выглядит система, которую один человек способен понимать целиком — от схемы процессора до кода сборщика мусора. Не абстрактная мечта, а работающий артефакт.

В 1995 году Вирт публикует эссе «A Plea for Lean Software» — буквально «Мольба о стройном софте». Там он формулирует наблюдение, которое с тех пор часто называют «законом Вирта»:

«Программы становятся медленнее быстрее, чем железо — ускоряется».

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

Если взглянуть на историю с Windows 11 его глазами, картинка получается почти гротескной: оболочка ОС зависит от цепочки XAML-пакетов, которые должны успеть зарегистрироваться «в нужное окно» между установкой обновления и первым входом пользователя. Не успели — до свидания, Пуск и панель задач.

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

От Unix с трубами к npm с тысячей зависимостей

В разработке ПО был короткий «золотой» период относительной простоты. Классический Unix с его философией «делай одну вещь и делай её хорошо» давал ощущение системы как набора маленьких ясных программ, которые общаются друг с другом файлами и пайпами. Структура прозрачна, границы понятны.

Потом начался долгий роман индустрии со сложностью:

  • корпоративные монолиты росли и обрастали «бизнес-логикой»;
  • ядра ОС наполнялись драйверами, подсистемами, костылями совместимости;
  • веб-стек обрастал фреймворками, надстройками, утилитами «для удобства».

С появлением JavaScript/Node.js и npm стало нормой жить в мире, где пакет из 11 строк кода (left-pad) оказывается критической зависимостью для Babel, React и множества других популярных инструментов. И когда однажды обиженный автор удалил его из npm — пол-интернета в течение нескольких часов не могло собрать свои проекты.

Эта история не про один пакет. Она про культурную норму:

Если можно не писать код самому, а подключить ещё одну зависимость — подключим зависимость.

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

Когда один баг выключает половину мира

В 2014-м мир узнал слово Heartbleed. Несколько неприметных строк в реализации heartbeat-расширения OpenSSL позволяли злоумышленнику читать память сервера блоками по 64 КБ. В этих блоках могло оказаться всё: приватные ключи, пароли, фрагменты сессий. Уязвимость появилась в коде в 2012-м, а обнаружили её только в 2014-м — два года открытых дверей.

Проблема была не только в баге, но и в том, что OpenSSL встроен практически во всё: от банковских сайтов до домашних роутеров. Один дефект — миллионы затронутых систем по всему миру.

В июле 2024-го похожий по масштабу пример, но другого рода, дала компания CrowdStrike. Обновление конфигурации для агента безопасности Falcon на Windows содержало ошибку, приводившую к падению в синий экран. По оценкам, около 8,5 миллиона устройств по всему миру дружно ушли в BSOD, а аэропорты, клиники, банки и бизнесы срочно занимались ручным восстановлением инфраструктуры.

Здесь тоже не было никакой изощрённой хакерской атаки. Обычная инженерная ошибка в одном обновлении — и мир на несколько часов частично встал.

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

Альтернативная ветка эволюции: микроядра и маленький код

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

Микроядро как «клетка для ошибок»

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

  • планирование процессов;
  • управление памятью;
  • межпроцессное взаимодействие (IPC).

Всё остальное — драйверы, файловые системы, сетевой стек, службы — живёт в отдельных процессах в пользовательском пространстве. Упал драйвер? Перезапустим. Глючит сетевой стек? Он не утащит за собой всё ядро.

В 80-х в Carnegie Mellon создаётся микроядро Mach. Идея была красивая, реализация — тяжёлая: много переключений контекста, дорогостоящий IPC, потери производительности. Многие после этого решили, что «микроядра медленные, идея провалилась».

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

В 90-х появляется семейство L4. Его автор Йохен Лидтке поставил цель показать, что микроядро можно сделать быстрым. Первые реализации L4 демонстрировали выигрыш в производительности примерно на порядок по сравнению с Mach.

А позже из этой линии вырастает микроядро seL4 — маленькое ядрышко, для которого выполнена полная формальная верификация: математическое доказательство соответствия реализации на C абстрактной модели. Не тестирование, не «вроде работает» — а именно доказательство.

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

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

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

Хороший пример того же подхода — VPN-протокол WireGuard. Его автор сознательно стремился к минимальному коду:

  • только современная криптография;
  • никаких исторических режимов и экзотических опций;
  • компактная реализация, которую можно прочитать глазами за разумное время.

В результате кодовая база невелика, реализацию проще просматривать и аудировать. WireGuard включён в ядро Linux, его используют многие дистрибутивы и сервисы — во многом потому, что он проще для понимания и проверки, чем монструозные конфигурации OpenVPN или IPsec с их бесконечными опциями.

systemd против OpenRC: маленький init и «сердце современного Linux»

В мире Linux давно идёт ещё одна тихая война — вокруг системы инициализации.

С одной стороны — компактные системы вроде OpenRC. Это классический пример «стройного» подхода:

  • зависимостно-ориентированный init, изначально разработанный для Gentoo;
  • написан на C и sh; размер самого демона — порядка мегабайта;
  • использует понятные текстовые скрипты с явным описанием зависимостей;
  • применяется в Gentoo, Alpine Linux и ряде дистрибутивов, где ценят простоту и контроль.

OpenRC по духу ближе к старому Unix-подходу: есть init, есть набор скриптов; ядро инициализации не пытается быть всем сразу — логгером, DHCP-клиентом, менеджером сессий и бог знает чем ещё.

С другой стороны — systemd: «комплект системных компонентов для управления системой и службами», как честно написано в описании проекта. Это целый набор:

  • init (PID 1),
  • менеджер служб,
  • логгер (journald),
  • менеджер устройств, логинов, сети, таймеров, cgroups и много чего ещё.

systemd появился в 2010-м как попытка «переосмыслить PID 1» — сделать инициализацию быстрой, управляемой и знающей о зависимостях, вместо набора shell-скриптов. Fedora первой включила его по умолчанию, затем подтянулись Arch, openSUSE, Debian 8, Ubuntu 15.04, RHEL 7, SLES 12 и практически все крупные дистрибутивы.

Аргументы сторонников были понятные и во многом честные:

  • параллельный старт служб и более быстрый boot;
  • чёткая модель зависимостей и перезапуска сервисов;
  • интеграция с cgroups: можно ограничивать ресурсы, отслеживать «поддеревья» процессов;
  • единые инструменты (systemctl, journalctl) вместо зоопарка утилит;
  • проще сопровождать один «современный» стек, чем костылить устаревший SysVinit.

Но вместе с этим systemd принёс и то, что многим не даёт спокойно спать:

  • ощущение монолита, который лезет всюду: от init до DNS, логина и сети;
  • бинарный формат журналов (journald), который плохо вписывается в классическую идею «всё — текст»;
  • жёсткую привязку многих десктопных компонентов (например, logind) к systemd — так, что альтернативным init-системам приходится эмулировать его интерфейсы;
  • и в целом отход от классического Unix-way: маленькие утилиты, слабые связи, модульность.

Неудивительно, что в BSD-сообществах появились доклады с заголовками вроде «The Tragedy of systemd», а в Linux-мире — дистрибутивы, принципиально избегающие его (Artix, Void, часть пользователей Gentoo).

С точки зрения человека, воспитанного на идеях Вирта и Дейкстры, картина довольно понятная:

  • OpenRC — небольшой, прозрачный init, который делает свою работу и не притворяется, что он весь мир;
  • systemd — мощный интегрированный комбайн, который решает сразу много задач, но ценой возросшей сложности и зависимости от единого «центра».

Почему же победил systemd?

Почему почти все крупные дистрибутивы выбрали именно systemd, а не что-то вроде OpenRC?

Ответ, к сожалению, приземлённый:

  1. SysVinit объективно устарел. Сценарии на shell с ручным описанием порядка запуска, без нормальных зависимостей и параллелизации — это было узким местом. systemd принёс ощутимое ускорение и удобство.

  2. Нужна была стандартизация. Большим вендорам и авторам десктопов проще ориентироваться на одну мощную платформу, чем поддерживать N вариантов init, логгеров, менеджеров сессий. GNOME, KDE и прочие стали активно использовать возможности systemd (logind, timers, cgroups).

  3. Эффект сети и инерция. Как только критическая масса дистрибутивов и приложений выбрала systemd, альтернативы оказались в положении «подстраивающихся». Появились пакеты, которые просто предполагают наличие systemd; поддержка других init-систем стала задачей меньшинства.

  4. Администраторам понравился комфорт. Единый systemctl, единый journalctl, единая модель юнитов, таймеров и сокет-активации во многом удобнее, чем зоопарк разрозненных инструментов.

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

С точки зрения классического Unix-way systemd действительно выглядит чужеродным организмом. Но если смотреть глазами производителя дистрибутива, это «пакетное предложение»: вместе с init приходят службы, мониторинг, логирование, cgroups. И отказаться от него теперь означает не просто сменить init, а вырвать из экосистемы целый пласт.

Формальная верификация: когда программу доказывают, а не только тестируют

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

seL4: ядро с математическим доказательством

В случае seL4 команда написала формальную спецификацию микроядра в логике высшего порядка и в системе Isabelle/HOL доказала, что реализация на C ей соответствует:

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

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

CompCert: компилятор, который не «оптимизирует» в баг

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

Криптография под надзором математики

В криптографии ошибки особенно болезненны — они могут годами оставаться незамеченными, как тот же Heartbleed. Проект Everest создаёт формально проверенные реализации TLS и криптобиблиотек:

  • miTLS — проверенная реализация TLS 1.2, совместимая с реальными браузерами и серверами;
  • HACL* и EverCrypt — библиотеки с формально проверенными реализациями Curve25519, Ed25519, AES-GCM, SHA-2/3 и других алгоритмов, уже используемые в Linux, Firefox, Tezos, ElectionGuard.

А Isabelle/HOL — это вообще что?

Isabelle — интерактивный доказатель теорем, а HOL — логика высшего порядка (Higher-Order Logic), в которой формулируются свойства системы.

Схема работы примерно такая:

  1. Формулируется спецификация: какие состояния допустимы, какие переходы возможны, какие инварианты должны держаться всегда.
  2. Реальная программа отображается в эту модель.
  3. В Isabelle/HOL строится цепочка рассуждений, показывающая, что все исполнения программы удовлетворяют спецификации.
  4. Каждое рассуждение проверяется машиной — не человеком с усталыми глазами, а алгоритмом.

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

Память под охраной: Rust и уход от «диких указателей»

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

Google несколько лет подряд публикует в отчётах по Android: по мере переноса компонентов с C/C++ на Rust доля уязвимостей, связанных с управлением памятью, сначала резко падает, а затем опускается ниже 20% от общего количества найденных багов.

Ядро Linux тоже официально поддерживает Rust-код; всё больше драйверов и подсистем пишется на языке, который не позволяет скомпилировать программы с целым классом типичных ошибок C/C++: use-after-free, buffer overflow, двойное освобождение памяти и тому подобное.

NSA в документе «Software Memory Safety» прямо рекомендует стратегически уходить от C/C++ к языкам с безопасной памятью — Rust, Go, Java, C#, Swift, Ada — там, где это возможно.

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

ИИ-ассистенты: ускоритель хаоса или помощник дисциплины?

На всё это накладывается ещё один тренд — ИИ-ассистенты, встроенные в IDE.

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

Исследование «Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions» показало, что около 40% примеров кода, которые Copilot сгенерировал для задач, связанных с безопасностью, содержали уязвимости: SQL-инъекции, проблемы с памятью, неправильную криптографию.

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

Добавим сюда явление slopsquatting: модели иногда придумывают правдоподобные, но несуществующие имена пакетов. Злоумышленники отслеживают такие «галлюцинации», регистрируют пакеты с этими именами в npm/PyPI и наполняют их вредоносным кодом. Разработчик копирует пример из чата с ИИ, ставит пакет — и получает троян «в комплекте».

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

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

ИИ не меняет культуру — он её усиливает. Там, где есть дисциплина — усиливает дисциплину. Там, где царит подход «как-нибудь заработает» — ускоряет движение к новым Heartbleed и KB5072911.

Как выглядит надёжное ПО без романтики

Если убрать пафос, у надёжного и безопасного ПО есть несколько приземлённых свойств.

  1. Оно проще, чем могло бы быть. Не беднее по возможностям, а проще по архитектуре: минимум доверенного кода, минимум состояний, минимум двусмысленных мест. Микроядро вместо монолита; WireGuard вместо чудовищных конфигураций; OpenRC вместо огромного комбайна в PID 1.

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

  3. Критичные части описаны формально. Ядро, компилятор, криптопримитивы, протоколы — там, где цена ошибки максимальна, есть формальная спецификация, а иногда и доказательство корректности.

  4. Память и ресурсы управляются не «по совести», а по правилам языка. Rust и другие memory-safe языки снижают риск целого класса багов; статистика Android и рекомендации NSA это подтверждают.

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

Во всём этом нет ничего принципиально нового для Вирта и Дейкстры. Это просто поздний, дорогой и болезненный возврат к их старым идеям.

Почему индустрия всё равно едет в другую сторону

И здесь напрашивается очевидный вопрос: если всё это известно десятилетиями, почему вокруг так много кода-лапши, хрупких цепочек зависимостей и systemd-подобных комбайнов?

Ответ не особенно красив, но честен.

  • Рынок плохо вознаграждает внутреннюю чистоту. Пользователь видит новые фичи и удобные кнопки. Отсутствие катастроф воспринимается как фон, а не как результат работы. «Всё просто работало» — это не строчка в пресс-релизе.

  • Крупные кодовые базы живут десятилетиями. Переписать Windows, Chromium или ядро банковской системы «с нуля и правильно» почти нереально. Гораздо проще наращивать сверху новые слои, постепенно увеличивая технический долг.

  • Образование учит «делать приложения», а не строить системы. Курсы часто крутятся вокруг фреймворков и «современного стека», а не вокруг архитектуры, инвариантов и строгих спецификаций. Вирт и Дейкстра остаются где-то в исторической части, если вообще упоминаются.

  • Пакетные менеджеры и дешёвое железо делают лёгким путь «подключить ещё одну библиотеку». Потянуть код из npm/PyPI проще, чем задуматься: «а действительно ли мы хотим ещё одну зависимость в дереве?»

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

Есть ли надежда?

Короткий ответ: да, но не в том смысле, что всё вдруг станет идеальным.

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

Но в нескольких областях поворот уже начался:

  • критичная инфраструктура (финансы, энергетика, транспорт, медицина);
  • государственные сервисы и оборона;
  • всё, где сбой — это не только «неудобно», но и дорого или опасно.

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

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

Насколько индустрия в целом на это способна — отдельный вопрос. Но локально, в конкретных командах и проектах, это вполне реальная цель.

Вместо заключения

История с Windows 11, потерявшей «Пуск» после очередного Patch Tuesday, — не уникальная катастрофа и не «особый позор Microsoft». Это яркий симптом времени.

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

Где-то на полке лежат «The Humble Programmer» и «A Plea for Lean Software». Их авторы ушли, но идеи, которые они сформулировали — про пределы человеческого разума, про стройный софт и про программирование как способ думать, — звучат сегодня даже актуальнее, чем полвека назад.

За прошедшие десятилетия появились новые языки, фреймворки, облака, нейросети. Но базовый выбор остался прежним:

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

Для дальнейшего чтения

Чтобы всё это не осталось просто рассказом, вот подборка материалов, по которым можно углубиться в тему:

Предыдущий пост Следующий пост
Наверх