«👋».length === 2 — это знают все. Дальше все пишут честную функцию, которая ходит по строке по символам, а не по кодовым единицам UTF-16. И почти всегда она получается квадратичной: и длина, и обращение по индексу проходят строку с начала, поэтому обычный цикл по ним — это n²/2 шагов без единого вложенного цикла в коде.

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

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

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

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

Не сломал. Полная перестройка ядра — 350 строк — прошла все 444 проверки, и ни один эталон не пришлось трогать.

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

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

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

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

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

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

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

Три результата, ради которых стоит читать дальше:

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

Я писал реализацию Raft на TypeScript и построил вокруг неё музей багов: семь экспонатов, каждый выключает ровно одно правило алгоритма и требует, чтобы харнесс поймал это — с сидом и с именем нарушенного свойства.

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