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

Преподаю и много пишу код, который потом нужно красиво показать — в документах, статьях и особенно в презентациях для занятий. И на днях я случайно наткнулся на то, что мой давно любимый инструмент — надстройка Code Blocks для Google Docs — просто перестал работать.

Маленький инструмент, который экономил часы

Если вы хоть раз вставляли код в Google Docs или в слайды, то знаете эту боль: вставляешь — и получаешь бесформенную серую массу без подсветки синтаксиса, со съехавшими отступами и пропавшими моноширинными шрифтами. Code Blocks решал это в два клика: выделяешь фрагмент, выбираешь язык и тему — и получаешь аккуратно оформленный, подсвеченный блок, который не стыдно показать студентам или вставить в презентацию.

Для меня это была не просто «приятная мелочь». Когда готовишь десятки слайдов с примерами кода, каждая такая экономия в пару минут складывается в реальные часы. И вот однажды я открываю документ, иду в меню «Расширения → Code Blocks» — а кнопки «Start» там просто нет. Вместо привычного запуска панели в подменю осталась одна-единственная строчка — «Справка». Инструмент будто испарился.

Что именно случилось

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

И только потом, забив текст ошибки и название расширения в поиск Google, я увидел, что проблема не только у меня одного: на GitHub за пару дней набежала целая волна одинаковых жалоб. Значит, причина — не в моём браузере, а где-то глубже.

Дело в том, что Code Blocks под капотом работал на старом движке Google Apps Script — Rhino. А Google объявил его устаревшим и прекратил поддержку. В результате надстройка стала падать с характерной ошибкой о том, что «среда выполнения Rhino больше не поддерживается». То есть сломал её не автор расширения и не пользователи, а изменение на стороне самой платформы.

Как вообще устроены такие расширения — и при чём тут Rhino

Чтобы понять, почему всё сломалось, стоит на минуту заглянуть под капот. Code Blocks — это не классическое расширение Chrome, а надстройка (add-on) для Google Docs, написанная на Google Apps Script. Apps Script — это «облачный» язык на основе JavaScript, который Google придумал, чтобы автоматизировать Документы, Таблицы и почту прямо внутри своей экосистемы. Вы пишете функцию, она получает доступ к содержимому документа через специальные сервисы Google — и может, например, выделить ваш код и раскрасить его по правилам синтаксиса.

Долгие годы Apps Script исполнялся на движке Rhino — это реализация JavaScript на Java, созданная ещё в конце 1990-х в Netscape. Rhino был добротным рабочим инструментом своего времени, но он застрял на старом стандарте языка (фактически ES5) и не понимал современный синтаксис. Поэтому Google ещё несколько лет назад представил новую среду выполнения на движке V8 — том самом, что крутится в Chrome и Node.js. V8 быстрее, поддерживает современный JavaScript и активно развивается.

Какое-то время оба движка существовали параллельно, и старые проекты на Rhino продолжали работать «как есть». Но всё «временное» однажды заканчивается: Google объявил Rhino устаревшим и в какой-то момент окончательно убрал поддержку. Для проектов, которые так и не мигрировали, это означало мгновенную остановку — что мы и наблюдаем на примере Code Blocks.

Насколько сложно переехать на V8 — и что делать авторам

Может показаться, что миграция — дело пары часов: движки-то оба про JavaScript. На практике всё интереснее. Rhino и V8 по-разному обрабатывают ряд вещей: порядок и область видимости переменных, поведение for...in, работу с датами и строками, нюансы глобального контекста. Код, годами работавший на Rhino, может опираться на его особенности — и на V8 повести себя иначе или просто упасть. Поэтому переезд — это не «щёлкнуть переключателем», а вычитать проект, прогнать его и поправить все места, где старое поведение больше не действует.

И здесь всплывает типичная для open-source история. Многие подобные надстройки — это проекты энтузиастов, которые автор когда-то сделал и выложил бесплатно. У него может банально не быть времени оперативно реагировать на изменения платформы. Зато есть сообщество: в случае Code Blocks нужный фикс — миграцию с Rhino на V8 — оформил не сам автор, а другой разработчик, прислав pull request. Это и есть нормальный механизм поддержки таких проектов в 2026 году: платформа меняется, автор не успевает, а сообщество подхватывает и чинит. Вопрос лишь в том, как быстро правку примут и выкатят.

Маленький урок про зависимости

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

Хорошая новость в том, что сообщество отреагировало быстро: в репозитории уже появился pull request с миграцией со старого Rhino на современный движок V8. Так что у истории, скорее всего, будет счастливый конец — нужно лишь дождаться, пока фикс примут и раскатают.

Что делать прямо сейчас

Если вы, как и я, зависели от Code Blocks, то вариантов несколько. Можно подождать обновления — судя по активности в репозитории, оно не за горами. Можно поставить альтернативную надстройку с подсветкой синтаксиса из Google Workspace Marketplace. А можно временно пользоваться внешними сервисами вроде онлайн-конвертеров кода в картинку и вставлять результат как изображение.

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

А вы сталкивались с тем, что привычный инструмент ломался не по вашей вине? Расскажите в комментариях — интересно, у кого какие запасные варианты.