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

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

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

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

Вежливый тест, который шлёт запрос и ждёт ответа, скрывает целый класс ошибок пакетирования. Пачечный тест их обнажает.

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

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

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

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

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

Почему он не поддавался обычным приёмам

Дефект сопротивлялся всем стандартным подходам сразу:

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

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

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

Улика: транзакция, которой не стало

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

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

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

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

Шестнадцатилетняя гонка

SQLite с журналом предзаписи работает с двумя файлами. База — это набор страниц; при изменении данных новые страницы пишутся не в основной файл, а сначала в журнал. Позже контрольная точка переносит их в базу. Обычно момент переноса SQLite выбирает сам, но Tailscale управляла контрольными точками вручную, чтобы снимать быстрые согласованные копии. Именно этот нестандартный, хотя и полностью документированный выбор и вывел их на дефект.

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

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

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

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

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

Разбирали это с трёх сторон сразу. Разработчики SQLite отозвали версию целиком и выпустили 3.51.3, содержавшую только исправление гонки. Tailscale перешла на хранение меток времени целыми секундами, поскольку перевод текста в целое число однозначен. А в 3.53.0 появилось автоматическое восстановление таких индексов, чтобы проблема не возникала впредь.

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

Как доказали, что дефект действительно исправлен

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

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

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

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

Сменить машину раньше, чем код

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

Считать, а не логировать

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

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

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

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

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

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

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

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

Классический двойной расход

Наивная версия, которую пишут первой:

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

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

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

Вебхук, доставленный дважды

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

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

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

Что из этого складывается

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

Что забрать с собой

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

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

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

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

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

Сервис Images, написанный на Rust и работающий в Workers, запущен на каждой машине в edge-сети Cloudflare. Чтобы обрабатывать клиентские соединения, мы используем hyper — открытую HTTP-библиотеку для Rust.

В прошлом году мы представили Images binding — он позволяет создавать кастомные программные сценарии обработки удалённых изображений в Workers. В конце 2025 года мы перестроили binding, чтобы сделать связь между Workers runtime и сервисом Images более прямой и локальной.

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

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

Cloudflare Images binding перешёл на прямое локальное соединение через Unix-сокеты в декабре 2025 года.

После выкатки большие изображения стали иногда возвращаться обрезанными: HTTP 200, но тело ответа короче Content-Length.

Причина — состояние гонки в hyper: цикл poll_loop отбрасывал результат poll_flush, даже если тот возвращал Poll::Pending.

Баг существовал в hyper 0.14.x, 1.7 и 1.8; прежний посредник FL читал данные достаточно быстро, чтобы он не проявлялся.

Исправление заняло четыре строки кода: flush теперь выполняется перед shutdown.

Прыжки, передачи и hyper

Когда разработчики создают приложения на Cloudflare, они собирают full-stack приложения из набора платформенных сервисов, доступных Workers через bindings. Bindings предоставляют прямые API к ресурсам Developer Platform: вычислениям, хранилищам, ИИ-инференсу и обработке медиа.

Images binding отделяет оптимизацию изображений от доставки: вы можете транскодировать, компоновать или изменять изображения, не возвращая результат в виде HTTP-ответа. Также он позволяет применять параметры оптимизации в любом порядке, а не в фиксированной последовательности, которую навязывает URL-интерфейс. Вот пример: воркер передаёт данные изображения напрямую в Images API, объединяет операции в цепочку и получает обработанный результат в виде потока:

На высоком уровне так выглядит движение данных через наши сервисы:

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

Binding взаимодействует с Images через сокетное соединение, управляемое Workers runtime. Сокет — это канал связи между двумя процессами. У каждого конца сокета есть буферы, управляемые ядром операционной системы; эти буферы — временные области, где данные остаются после записи одной стороной, но до чтения другой.

Hyper управляет соединением на стороне сервиса Images: читает входящие запросы из сокета и пишет ответы обратно в него.

Когда запрос использует Images binding, сервис Images читает входные данные, выполняет запрошенные операции оптимизации и кодирует результат. Затем он передаёт всё закодированное изображение hyper как один непрерывный блок в памяти.

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

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

Локальное соединение

Весь входящий трафик в сети Cloudflare проходит через FL — внутренний сервис-посредник, который включает функции безопасности и производительности и маршрутизирует запросы к нужному бэкенду. Когда мы только запустили binding, данные изображений шли из Workers runtime через FL в сервис Images.

Этот путь хорошо подходил для первого релиза и повторял архитектуру URL-интерфейса. Но со временем связь с FL стала ограничением: любое изменение binding приходилось согласовывать с циклом релизов FL.

В декабре 2025 года команда Images заменила FL новым посредником — внутренним worker binding, который работает на той же машине. В исходной архитектуре данные шли через FL по сетевым сокетам; этот путь нёс накладные расходы полного конвейера обработки FL, такие как DNS-lookup'ы и маршрутизация.

Внутренний binding заменил их на Unix-сокеты, чтобы напрямую соединить сервисы на одной машине, минуя FL и накладные расходы сетевого стека. Это ускорило путь запроса к Images и дало команде независимый контроль над релизами binding.

В течение нескольких дней после выкатки мы получили первый отчёт от клиента.

200 OK (не OK)

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

Сначала их воркер с помощью Images binding компоновал несколько больших исходных изображений из R2 — JPEG-фон и PNG-оверлеи — в один объединённый JPEG. Затем результат дополнительно сжимался, транскодировался и изменялся размер через URL-интерфейс.

Баг возникал на обратном пути внутреннего pipeline, где ответ обрезался до того, как достигал внешнего.

Внутренний pipeline (transformation binding) отвечал за компоновку. Внешний pipeline (transformation URL) отвечал за оптимизации доставки: масштабирование и конвертацию формата. Такая многоуровневая схема означала, что когда внутренний pipeline молча возвращал обрезанный ответ, видимая ошибка появлялась на уровень выше:

Внешний pipeline получал от внутреннего HTTP 200 с заголовком Content-Length, который обещал несколько мегабайт. Фактическое тело было лишь частью от этого: в одном запросе из ожидаемых 3,3 МБ пришло всего около 200 КБ. Ошибка всплывала во внешнем pipeline, но обрезка могла произойти в binding, посреднике, сервисе Images или где-то между ними.

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

Отладка вслепую

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

• Сборка репродукции. Мы собрали воркер, повторяющий вложенную схему клиента, и постепенно убирали уровни, пока не смогли воспроизвести баг только с binding. Небольшой скрипт отправлял запросы пачками. На одном из первых прогонов 19 из 25 запросов упали. Объём данных, которые всё-таки приходили, — примерно 200 КБ — настораживающе близко к размеру сокетного буфера в продакшене. Это подтвердило, что проблема не связана с конфигурацией клиента, и дало надёжный способ воспроизводить баг по запросу.
• Проверка таймаутов. Сначала мы подозревали, что обрезка связана с поведением таймаутов (то есть соединение закрывалось по истечении лимита времени). Эта теория не подтвердилась: обрезка не коррелировала с длительностью запроса.
• Обновление версии hyper. Когда баг впервые зарепортили, мы использовали 0.14.x, а последняя версия hyper была около 1.8.x. Мы протестировали версии 0.14, 1.7 и 1.8 — на случай, если самый очевидный ответ окажется правильным (и самым простым). Но баг проявлялся в каждой версии, значит, upstream-исправления не было.
• Локальное воспроизведение. Мы запускали интеграционные тесты на macOS и Debian-виртуалке. Даже под значительной нагрузкой локальные запросы никогда не падали. Прямые curl-запросы к сокету binding и повтор отловленных запросов всегда работали. Баг проявлялся только на полном продакшен-пути при реальной конкурентности и реальном клиенте Workers runtime на другом конце сокета. Это натолкнуло нас на подозрение, что виноват сам runtime.
• Исключение Workers runtime. Мы изучили HTTP-клиент, который Workers runtime использует для связи с Images через сокет binding. Ни на одной из сторон соединения в трассировках не было системных вызовов, указывающих на неожиданное закрытие или преждевременное завершение. Клиент вёл себя корректно, и несколько других сервисов использовали того же клиента без проблем.
• Распределённая трассировка. Изучив сквозные трассировки запросов, мы подтвердили, что обрезанное тело уже присутствовало до того, как достигало внешнего уровня трансформации в схеме клиента. Это сузило проблему до внутреннего pipeline — пути binding через сервис Images.
• Инструментирование посредника. Мы добавили инструментирование в посредник, чтобы измерять размеры тел перед пересылкой ответа. Тела уже были обрезаны к моменту выхода из сервиса Images, так что посредник был исключён.
• Углублённая трассировка внутри Images. На уровне сервиса запрос обрабатывался, изображение корректно кодировалось, и ответ отправлялся с HTTP 200.

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

Зерно истины

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

Чтобы увидеть, что система делала на самом деле, мы подключили strace к сервису Images. strace записывает системные вызовы, которые процесс делает ядру; это позволило показать, какие именно байты были записаны, когда вызывался shutdown и посылал ли клиент сигнал завершения.

Настройка трассировки была деликатной. strace работает, перехватывая системные вызовы по мере их выполнения, что добавляет небольшие накладные расходы по времени к каждому вызову. Фильтрация узкого набора системных вызовов держала эти накладные расходы минимальными. Однако расширение фильтра замедляло процесс ровно настолько, чтобы сдвинуть тайминг между flush и проверкой shutdown — и баг полностью исчезал. Одно это уже подкрепляло теорию о тайминг-зависимости проблемы.

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

При успешном запросе ответ пишется кусками по мере освобождения сокетного буфера, а shutdown вызывается только после отправки всех данных. Например, это может выглядеть так:

Когда мы воспроизвели баг, упавший запрос выглядел так:

Здесь есть только одна запись — лишь заголовки и крошечная часть тела — перед немедленным вызовом shutdown. Из ответа в 14,9 МБ было отправлено около 219 КБ. Оставшиеся ~14,8 МБ данных изображения никогда не покидали внутренний буфер hyper, и не было никакого сигнала завершения от клиента между записью и shutdown. Вместо этого сервис Images преждевременно закрывал соединение самостоятельно, искренне полагая, что работа завершена.

Упавшие запросы подтвердили, что баг — состояние гонки, которое срабатывало непостоянно. Успех или провал зависели от того, перекрывались ли операции flush и shutdown, и это менялось от запроса к запросу. Когда буфер был полон в тот самый момент, когда hyper решил, что соединение завершено, данные терялись.

Когда читатель потребляет медленнее, чем hyper пишет, исходящий буфер заполняется. Если hyper закрывает соединение до того, как буфер опустеет, то лишь часть ответа попадает к посреднику; эти неполные данные пересылаются обратно в Workers runtime и клиенту.

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

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

Внутри цикла dispatch

Жизненный цикл HTTP/1-соединения в hyper управляется конечным автоматом в файле под названием dispatch.rs. Он выполняет цикл, который читает запросы, пишет ответы, сбрасывает буфер записи в сокет и решает, когда закрываться. В упрощённом виде:

Точнее, именно let _ перед poll_flush — это место, где живёт баг.

В Rust let _ = expr отбрасывает результат выражения, включая Poll::Pending — сигнал о том, что flush ещё не завершён. В буфере flush может остаться несколько мегабайт, но цикл об этом никогда не узнаёт.

Когда запрос падает, последовательность событий выглядит так:

1. Сервис Images завершает кодирование изображения и передаёт весь ответ hyper как один блок в памяти.
2. Hyper записывает блок во внутренний буфер и помечает состояние записи как Writing::Closed. С точки зрения кодирования работа сделана — кодировать больше нечего.
3. Hyper вызывает poll_flush, чтобы перенести буферизованные данные в сокет. В нашем примере сокет принял около 219 КБ. Оставшиеся ~14,8 МБ остаются в буфере hyper. Сокет полон, поэтому ядро возвращает Poll::Pending.
4. poll_loop отбрасывает Poll::Pending с помощью let _.
5. Он проверяет wants_read_again(). Полный запрос уже получен, поэтому возвращается false.
6. poll_loop возвращает Poll::Ready(Ok(())), сигнализируя, что цикл завершён, хотя flush ещё не сделан.
7. Срабатывает poll_shutdown(). Выполняется системный вызов SHUT_WR.
8. Клиент получает 219 КБ и EOF (end-of-file), указывающий, что соединение закрыто, хотя он ожидает 14,9 МБ.

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

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

Не забывайте сбрасывать буфер

После недель расследования само исправление было концептуально простым. Hyper должен был проверять, завершён ли flush, прежде чем двигаться дальше.

Наш reproduction-воркер подтвердил, что баг существует, но не мог объяснить, почему падает конкретный запрос. Прежде чем писать исправление, нам нужен был тест, который мог бы спровоцировать точные сокетные условия внутри hyper.

Мы знали условия, вызывающие баг: сокет, который принимает один кусок данных, а затем блокируется. Для контролируемого сценария мы построили обёртку вокруг TCP-потока, имитирующую полный сокетный буфер. Обёртка принимала 8 КБ при первой записи, а затем возвращала Poll::Pending на каждой последующей записи, имитируя читателя, который перестал опустошать буфер.

Тест отправлял 500 КБ ответа через этот ограниченный сокет и проверял, вызывает ли hyper shutdown, пока в буфере остаётся 492 КБ. Без исправления — вызывал. С исправлением — ждал.

Сначала мы применили исправление в цикле dispatch hyper. Вместо отбрасывания результата poll_flush мы проверяли, завершён ли flush на самом деле:

Если flush не завершён, цикл возвращает Poll::Pending асинхронному runtime. Runtime ждёт, пока сокет не станет доступен для записи, а затем будит задачу, чтобы продолжить flush. Соединение закрывается только после того, как все данные отправлены.

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

Хотя первоначальное решение работало, цикл dispatch был неправильным местом для исправления. Ранний возврат Poll::Pending мог замедлять другие операции на том же соединении, уменьшая частоту опроса чтения и вызывая нежелательное обратное давление. Также это корректно не обрабатывает keepalive-соединения, где одно соединение обрабатывает несколько запросов подряд — они должны оставаться пригодными к использованию, даже пока предыдущий ответ всё ещё сбрасывается. Ни одна из этих проблем не затрагивала наш сервис (где keepalive отключён), но обе могли повлиять на других пользователей hyper, если бы исправление было предложено upstream.

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

Это оставляет цикл dispatch без изменений. Flush добавляется только в тот точный момент, где иначе произошла бы потеря данных — непосредственно перед shutdown.

Что осталось с нами

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

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

Прорыв случился благодаря инструментарию уровня ядра — strace, единственному слою, который фиксирует, что на самом деле происходило на сокете. Базовый баг жил в нескольких миллисекундах между частичным flush и преждевременным shutdown — окне, которое открылось только после того, как мы ускорили систему.

Мы влили исправление и детерминированный тест в hyperium/hyper через PR #4018. Оно появится в будущем релизе hyper, гарантируя, что любой сервис, использующий HTTP/1-реализацию hyper, не потеряет данные ответа из-за того же состояния гонки.

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

Изначально Images binding покрывал только трансформации удалённых изображений. В начале этого месяца мы объявили, что Images binding теперь поддерживает операции для hosted-изображений, давая разработчикам единый способ строить медиа-насыщенные приложения на Cloudflare.

Подробнее о том, как работает binding, — в нашей документации.

В Centicore Group разобрали несколько кейсов из практики мобильного тестирования: промокоды, которые нельзя активировать, рейтинг, который считал лишнюю звезду, пуши на iPad, UI, который ломал рабочий сценарий, и WebSocket, который оставался висеть после выхода из чата.

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

Медицинское приложение: есть врачи, пациенты и записи на услуги. В какой-то момент понадобились промокоды. Механика простая: пациент активирует промокод — подключается подписка на мониторинг, например, по гипертензии на месяц или три. Аналитик написал спецификацию, разработчики сделали ровно то, что написано. Фичу разбили на две итерации: сначала создание промокодов в вебе, потом активация в мобилке.

Проблема была в том, что требования к двум частям фичи никто не сравнивал между собой. Поле для активации в мобилке покрыто валидацией: максимум 20 символов, только латиница, никаких пробелов и спецсимволов. А форма создания в вебе — без каких-либо ограничений. Врач или администратор клиники мог написать в префиксе что угодно: кириллицу, кавычки, восклицательный знак, теоретически SQL-инъекцию (на боевом сервере не проверяли). Промокоды выпускались пачками и уходили пациентам.

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

Фиксить нужно мобилку, потому что генерация уже работает. А мобилка на тот момент полностью нативная, без динамических обновлений, значит полный цикл хотфикса: собрать сборку, отправить на ревью в App Store и Google Play, дождаться одобрения, выпустить. Многие крупные игроки к тому времени уже работали с динамическими обновлениями, это приложение нет.

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

Samsung, одна звезда и RatingBar

В финтех-приложении стандартная функция обратной связи — Voice of Client: пользователь оценивает консультацию в чате звёздами. Тестировщик нажимает на первую звезду — выбираются две. Нажимает на вторую — выбирается третья.

Первая гипотеза — кривой экран. Проверили на других устройствах: у коллег всё работает нормально. Версия ОС у всех Android 15, тестовый пользователь один и тот же, сборка идентичная. Добавить тестовое устройство в изолированную сеть банковского приложения непросто, но сделали. После нескольких итераций проверок выяснили, что баг воспроизводится только на живом железе Samsung — на эмуляторах и других производителях чисто.

Причина нашлась в устройстве компонента: Android RatingBar глубоко в иерархии наследует ProgressBar, а звёзды в нём скорее декоративный слой. Когда пользователь касается звезды, компонент вычисляет рейтинг через округление на основе параметра stepSize. На Samsung это округление стабильно уходило в большую сторону: касание по краю четвёртой звезды давало рейтинг 5. Фикс простой — stepSize выставляется в 0.01, а итоговое округление до целого числа делается вручную в листенере. После этого поведение стало одинаковым на всём железе.

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

iPadOS, которого не существовало

На iOS тестировать одно удовольствие: Apple настолько плотно контролирует железо, что ситуация, когда баг есть на iPhone 13, но нет на iPhone 15, практически невозможна. Граница, на которой что-то ломается в яблочной экосистеме, проходит между iPhone и iPad.

В финтех-приложении перестали работать пуш-уведомления на iPad. Сборка идентичная с iPhone, версия та же, настройки одинаковые. На iPhone регистрация в пуш-сервисе проходила штатно: приложение отправляло запрос на регистрацию устройства и получало подтверждение. На iPad в ответ прилетал код 400 с ошибкой «Provider UUID not found».

Первое подозрение было на заголовки запроса, но заголовки оказались чистыми. Причина нашлась в теле JSON-запроса: iPad и iPhone используют разные названия операционной системы: на телефоне это iOS, на планшете — iPadOS. Приложение передавало это название через атрибут OSName как есть, без нормализации. Бэкенд знал только «iOS» — при получении «iPadOS» возвращал ошибку, потому что такого значения в его словаре не существовало. Одна строка в JSON оставила целую категорию устройств без уведомлений.

Пофиксили на бэке: при получении значения «iPadOS» оно автоматически заменялось на «iOS» перед любой дальнейшей обработкой. Решение в лоб, зато надёжное. Могло быть значительно сложнее: Huawei без Google-сервисов с пуш-уведомлениями это отдельный класс проблем, где просто заменить одну строку — не получится.

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

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

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

В том же финтех-приложении чат поддержки работал через WebSocket: одно соединение на сессию, весь обмен сообщениями через него. По стандарту при выходе из чата соединение закрывается кодом «1000», при следующем входе открывается новое. В этом приложении соединение не закрывалось: код не отправлялся, сокет оставался активным. При повторном входе открывалось второе соединение, потом третье. Висящие сокеты начали копиться, а приложение падало.

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

Где прячутся баги, которых нет в документации

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

Баги появлялись только тогда, когда две части системы впервые встречались в реальных условиях — с реальными данными, железом и пользователем.

• За 20 дней до утечки в баг-трекере Bun зафиксирован баг #28001: source maps отдаются в production mode, хотя документация утверждает обратное.
• Claude Code собирается и работает на Bun — рантайме, который Anthropic приобрела в декабре 2025 года.
• Утечка произошла через файл source map размером 59,8 МБ, попавший в npm-пакет @anthropic-ai/claude-code версии 2.1.88.
• Anthropic назвала инцидент «ошибкой при упаковке релиза, вызванной человеческим фактором». Формальный постмортем не опубликован.
• Прямого подтверждения связи между багом #28001 и утечкой нет, но техническое совпадение слишком точное, чтобы его игнорировать.

Хронология: от покупки Bun до утечки

2 декабря 2025 — Anthropic объявляет о покупке Bun, JavaScript-рантайма, на котором работает Claude Code. Создатель Bun Джаред Самнер (Jarred Sumner) переходит в Anthropic. Компания обещает сохранить Bun как open-source проект с MIT-лицензией. К этому моменту Claude Code уже приносит $1 млрд годовой выручки.

11 марта 2026 — в баг-трекере Bun появляется issue #28001: при использовании Bun.serve() с параметром development: false source maps всё равно генерируются и отдаются клиенту. Документация Bun явно указывает, что в production mode source maps должны быть отключены. Баг зафиксирован на версии 1.3.10.

31 марта 2026 — разработчик Чаофан Шоу (Chaofan Shou, @shoucccc) обнаруживает, что в npm-пакете @anthropic-ai/claude-code версии 2.1.88 лежит файл cli.js.map размером 59,8 МБ. Внутри — полный исходный код: более 500 000 строк TypeScript в ~1900 файлах. Твит набирает более 21 миллиона просмотров.

Что за баг в Bun

Баг #28001 зафиксирован в подсистеме Bun.serve() — встроенном HTTP-сервере Bun с функцией бандлинга. Суть проблемы: даже когда разработчик явно задаёт development: false, source maps всё равно генерируются и включаются в собранные файлы. Это противоречит документации Bun.

Claude Code собирается в один файл для публикации в npm через бандлер Bun. Формально баг #28001 описывает проблему в Bun.serve(), а не в автономном бандлере bun build. Однако обе подсистемы используют один и тот же механизм генерации source maps, и сообщество считает вероятным, что проблема затрагивает обе. На момент утечки issue оставался открытым и без фикса.

Само по себе наличие source map в сборке — ещё полбеды. Проблема в том, что в конвейере публикации Claude Code не было ни записи *.map в .npmignore, ни ограничения поля files в package.json. Если бы любой из этих защитных механизмов работал, source map не попала бы в npm-пакет даже при наличии бага. Сочетание двух факторов — баг в рантайме и отсутствие фильтрации при публикации — привело к утечке.

Почему сообщество обратило на это внимание

На Reddit и Hacker News историю обсуждают не столько из-за технической сложности бага — он тривиален. Внимание привлекла ирония ситуации:

• Anthropic купила Bun в декабре 2025 года. Claude Code — главный продукт компании, и он работает именно на Bun.
• Баг в Bun, связанный с source maps, был известен за 20 дней до утечки, но не был исправлен.
• Anthropic позиционирует себя как «safety-first» ИИ-компанию — и при этом допустила два инцидента с утечками за одну неделю: утечка черновиков блога о модели Mythos 26 марта и source map 31 марта.
• Компания активно рассказывает, что её ИИ пишет значительную часть кода Bun — и именно в этом коде нашёлся баг, приведший к утечке кода ИИ.

Случайно отправить source map в npm — ошибка, которая кажется невозможной, пока не вспомнишь, что значительная часть кодовой базы, вероятно, была написана тем самым ИИ, которого ты релизишь.

Что нашли внутри: краткая сводка

Мы подробно разбирали содержимое утечки в предыдущем материале. Ключевые находки:

• KAIROS — нерелизованный режим автономного фонового агента, который работает как демон, подписывается на GitHub-вебхуки и «видит сны» ночью, консолидируя память.
• Undercover Mode — режим, при котором Claude скрывает свою природу ИИ и убирает атрибуцию Co-Authored-By в коммитах. Принудительного отключения нет.
• ANTI_DISTILLATION — внедрение фейковых инструментов в API-запросы для отравления обучающих данных конкурентов.
• BUDDY — тамагочи в терминале с 18 видами существ, уровнями редкости и RPG-характеристиками.
• Внутренние бенчмарки, кодовые имена моделей (Capybara, Fennec, Numbat) и 44 фича-флага.

Реакция Anthropic

Anthropic удалила npm-пакет в течение нескольких часов и заявила, что утечка — «ошибка при упаковке релиза, вызванная человеческим фактором, а не брешь в безопасности». Пользовательские данные, ключи API и учётные записи не были скомпрометированы. Компания начала рассылать DMCA-уведомления зеркалам на GitHub, но формальный постмортем не опубликовала.

Тем временем корейский разработчик Сигрид Джин (Sigrid Jin) создал clean-room переписку архитектуры Claude Code на Python под названием claw-code. Репозиторий набрал 50 000 звёзд за два часа — по заявлению авторов, это рекорд GitHub. Сейчас проект переписывается на Rust.

Что это значит для разработчиков

Если вы используете Bun для сборки production-кода, стоит проверить свой конвейер публикации:

1. Проверьте, не попадают ли файлы .map в ваши npm-пакеты. Используйте npm pack --dry-run для аудита содержимого перед публикацией.
2. Добавьте *.map в .npmignore или явно перечислите разрешённые файлы в поле files в package.json. Второй вариант надёжнее — вместо списка исключений вы задаёте список включений.
3. Следите за issue #28001 в репозитории Bun — на момент публикации баг не исправлен.
4. Если публикуете пакеты через CI/CD — добавьте шаг валидации, который проверяет отсутствие source maps в артефакте.

Итог

История с утечкой Claude Code — наглядный пример того, как цепочка мелких упущений приводит к масштабному инциденту. Возможный баг в рантайме, отсутствие фильтрации при публикации, недостаточный аудит CI/CD-пайплайна — по отдельности каждая из этих проблем тривиальна. Вместе они обнажили более 500 000 строк проприетарного кода компании с оценкой выше $100 млрд.

Для разработчиков урок простой: не доверяйте дефолтам инструментов сборки и всегда проверяйте, что именно попадает в ваши пакеты. Команда npm pack --dry-run занимает секунды и может предотвратить утечку, которая изменит историю вашего продукта.

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

Что происходит с системой

Речь идет об обновлении, начиная с KB5074109, выпущенного 13 января 2026 года, а также о более поздних внеплановых патчах. После установки апдейта, система может не дойти до рабочего стола и показать черный экран с сообщением:

Your device ran into a problem and needs a restart.

Дальше — тупик. Windows не может завершить загрузку и требует ручного восстановления.

Microsoft подтверждает проблему

Информация появилась в Microsoft Admin Center, где компания сообщила, что получила «ограниченное число отчетов» о сбое загрузки:

Устройства не могут загрузиться из-за ошибки “UNMOUNTABLE_BOOT_VOLUME” после установки январского обновления безопасности Windows 11 и последующих апдейтов. На текущий момент система не может завершить запуск и требует ручных шагов восстановления.

Какие версии Windows 11 затронуты

По данным Microsoft, проблема касается:

• Windows 11 24H2;
• Windows 11 25H2;
• локальных клиентских ПК (не серверов).

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

Что делать пользователям

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

На практике это означает:

• загрузку в WinRE;
• попытки восстановления загрузочного раздела;
• откат обновлений или ручной ремонт системы — для опытных пользователей и администраторов.

Ирония ситуации: Quick Machine Recovery не спасает

Особенно иронично это выглядит на фоне того, что еще в 2024 году Microsoft анонсировала механизм Quick Machine Recovery. Это система экстренного восстановления Windows через WinRE для таких вот критических сбоев. Тогда же компания даже «переосмыслила» легендарный BSOD.

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

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

«Смерть от тысячи слопов»

Мейнтейнер cURL Дэниел Стенберг еще в прошлом году описал ситуацию формулой Death by a thousand slops. ИИ-инструменты сделали подачу баг-репортов дешевой и массовой. Но от того глупой и зачастую пустой.

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

За все время существования программы было выплачено около $101 000 за 87 отчетов. Сумма скромная, но достаточная, чтобы создать неправильные стимулы у любителей халявы.

Не весь ИИ — мусор, но проверять приходится все

Важный момент: Стенберг подчеркивает, что ИИ-помощь сама по себе не зло. Он знает более сотни полезных баг-репортов, где ИИ действительно помог найти реальные проблемы.

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

Неожиданный союзник: охотник за уязвимостями

Любопытно, что решение cURL поддержал известный исследователь безопасности Джошуа Роджерс, который сам активно использует ИИ для поиска багов. Правда, он делает это успешно.

При этом есть ключевое отличие его от тех, из-за кого cURL свою программу сворачивает — Роджерс не отправляет отчеты вслепую. ИИ для него — инструмент анализа, а не автоматический генератор тикетов.

По его мнению, отключение выплат — давно назревший шаг:

Деньги — не главный стимул

Роджерс также считает, что исчезновение наград не приведет к катастрофе. Для серьезных исследователей главная награда — репутация, а не $5000 – $10 000.

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

Последнее октябрьское обновление системы — KB5066835 — нарушило работу localhost, что фактически лишило разработчиков возможности тестировать веб-приложения локально.

Проблему активно обсуждают на Microsoft Support Forums, Stack Overflow и Server Fault: серверы перестали отвечать на запросы, отвалилась отладка в Visual Studio, а ASP.NET-приложения не компилируются.

По оценкам экспертов, сбой затронул миллионы веб-разработчиков и инженеров, использующих Windows 11 в качестве локальных серверов и рабочих станций.

Что пошло не так

Пакет KB5066835 был задуман как обновление безопасности, улучшавшее сентябрьский релиз KB5065789, но именно он привел к поломке HTTP.sys — системного компонента ядра Windows, отвечающего за маршрутизацию локального HTTP-трафика.

После установки апдейта, localhost перестал отвечать на запросы, а соединения по HTTP/2 начали обрываться.

Как временно исправить

Microsoft пока официально не подтвердила проблему, но сообщество уже нашло обходное решение:

1. Удалить октябрьское обновление KB5066835.
2. Если не помогло — удалить и предыдущее KB5065789.
3. После этого localhost начинает работать штатно. Однако это временная мера и пользователи рискуют остаться без последних исправлений безопасности.

Неудачи Microsoft продолжаются

Это уже второй крупный сбой за неделю. В понедельник компания случайно «сломала» Media Creation Tool — утилиту для установки Windows — всего за день до окончания поддержки Windows 10.

А на прошлой неделе Microsoft окончательно обязала пользователей входить в Windows 11 только через онлайн-аккаунт, что вызвало волну критики.

Cloudflare связала учащение «фатальных паник» на arm64 с кодом, где выполнялась работа с Netlink, но корневая причина оказалась глубже — в связанке компилятор ↔ ассемблер Go для arm64 и в том, как разбивалось большое смещение стека на две инструкции ADD со «сдвигом на 12 бит». Если прерывание попадало между этими двумя ADD, стековый указатель оказывался «наполовину скорректирован», и трассировщик стека считывал нерелевантные данные как адрес возврата, что заканчивалось segfault/фатальной паникой. Схожие аварии ранее отмечали и другие команды, в частности Datadog: именно в runtime.(*unwinder).next на Linux/arm64 (Go 1.23.x/1.24.x).

Что именно ломалось

• Сценарий сбоя: асинхронная предвыборка (preemption) попадает между двумя инструкциями корректировки SP (split ADD), после чего GC/трассировка начинают разворачивать некорректный фрейм, обращаясь по невалидному SP. Итог — падение в (*unwinder).next.
• Подтверждение на практике: сходные трассы стеков и «рандомные» крэши на arm64 фиксировались у сторонних команд; проблема оформлена в ишью #73259 в репозитории Go и была признана кандидатом на бэкпорт.

Как починили (и какие версии содержат фикс)

Исправление прошло через бэкпорт и доступно в поддерживаемых ветках Go:

• Go 1.24.6 — явное упоминание бэкпорта по ишью #73259.
• Go 1.23.12 — минор с правками рантайма (включая бэкпорт по связанным arm64-сбоям).
• Go 1.25.0 и новее — фиксация на мажорной ветке.

Суть изменения: вместо двух поочерёдных ADD для большого смещения теперь собирают оффсет в временный регистр и выполняют одну атомарную корректировку SP.

Это исключает «окно» между ADD-инструкциями и делает разворачивание стека предсказуемым даже при async preemption. (Подробные обсуждения и сопутствующие arm64-проблемы рантайма см. также в #63830, #65449, #73413.)

Кому это важно

• Все сервисы Go на arm64, где возможны большие стековые фреймы и активна асинхронная предвыборка (по умолчанию с Go 1.14+). В условиях продакшн-нагрузок редкая гонка становится статистически вероятной. Читайте подробнее: https://unskilled.blog/posts/preemption-in-go-an-introduction/

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

1. Обновиться до: Go 1.25.x или минимум до 1.24.6 / 1.23.12 (если «зажаты» веткой).
2. Пересобрать сервисы, критичные по доступности, и раскатить обновления в первую очередь на arm64-инфраструктуру.
3. Если апгрейд временно невозможен — минимизируйте большие стек-фреймы (вынос больших буферов в heap), снизьте вероятность попадания preemption в эпилог и проверьте зависимости на предмет собственного asm/unsafe-кода.
4. Отслеживайте релизы Go и связанные тикеты об unwinding/arm64 (см. #73259 и бекпорт #74694).

Источники и материалы:

• Обсуждение с примерами падений: runtime: segfaults in runtime.(*unwinder).next (GitHub, #73259).  https://github.com/golang/go/issues/73259
• Бэкпорт фикса в ветку 1.24: (GitHub, #74694) — релиз Go 1.24.6. https://github.com/golang/go/issues/74694
• История релизов, минор Go 1.23.12 с правками рантайма. https://go.dev/doc/devel/release
• Release notes Go 1.25 (фикс присутствует в мажорной ветке).  https://tip.golang.org/doc/go1.25
• Ранние разборы проблем разворачивания стека/прерываний на arm64 https://github.com/golang/go/issues/63830

Эти проблемы затрагивают даже топовые модели с RTX 4080 и Core i9. Обновления драйверов, переустановка Windows и переход на Linux — ничего не помогает.

Профилировщик LatencyMon показывает конкретного виновника: ACPI.sys — компонент Windows, который исполняет код из BIOS. И именно этот код, как показало расследование, устроен катастрофически неправильно.

Что не так: прерывания, которые засыпают

Расследование показало, что примерно каждые 30–60 секунд BIOS запускает метод _GPE._L02, вызываемый при аппаратных событиях. Его задача — опросить статус батареи и питания.

Но он делает это внутри обработчика прерывания, вызывая Sleep() прямо в контексте ядра. То есть прошивка буквально приказывает процессору «поспать» на 25–100 мс — в момент, когда он должен работать максимально быстро.

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

Вишенка на торте: попытка отключить единственный активный GPU

Еще один баг прошивки: она регулярно пытается отключить дискретную видеокарту (dGPU), даже когда та — единственный источник вывода изображения (в режиме MUX/Ultimate).

Это приводит к циклическим попыткам «погасить» и «включить» видеокарту, на что драйвер NVIDIA отвечает зависанием, а в худшем случае — синим экраном (WIN32K_POWER_WATCHDOG_TIMEOUT).

Что говорит код

Декомпиляция ACPI-таблиц BIOS показала:

• Код нарушает базовые принципы: использует Sleep() внутри прерываний.
• Метод ECLV не завершает прерывание быстро, а задерживает его до 100 мс.
• Система искусственно переинициирует прерывания, создавая бесконечный цикл.
• Нет проверки текущего состояния MUX-переключателя — прошивка не понимает, что dGPU нельзя выключать.

Масштаб: страдают миллионы устройств

Симптомы описаны в сообщениях пользователей с 2021 года. Проблема затрагивает десятки моделей ROG и TUF: от G15 до Zephyrus M16.

Даже на свежих моделях 2023–2024 года пользователи фиксируют те же баги, и они документированы в логах LatencyMon и трассировках Windows Performance Analyzer.

ASUS пока молчит

На момент публикации ASUS не прокомментировала результаты технического расследования. Ошибка, по сути, заключается в одной строке кода, и легко исправляется в будущих версиях BIOS.

Однако пока производитель не признает проблему официально, пользователи остаются один на один с нерешаемыми фризами.

Когда проект выглядит максимально понятным — например, «расширить дисковое пространство» или «заменить ИБП в филиале», — именно здесь большинство команд и заказчиков расслабляются. Но опыт снова и снова доказывает: даже простейший ИТ-проект способен превратиться в настоящий квест, где исправленный баг моментально оборачивается двумя новыми. Позвольте рассказать на собственных примерах, как это работает в реальности, и главное — что с этим делать.

Кейс первый: СХД, гипервизор и эффект домино

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

На первый взгляд, задача элементарная: подготовить оборудование, доставить, смонтировать и «прикрутить» к существующей виртуализации. Но уже на этапе подключения стало ясно: всё идет не по сценарию. Гипервизор просто не видит новые тома. Операционная система выдает сбои на уровне multipath — механизма многопутевого доступа, который в теории должен обеспечивать отказоустойчивость, а на практике создает непредсказуемые задержки и зависания. Производительность хранилища оказалась в два раза ниже обещанных показателей, а отдельные LUN работали с такой задержкой, что у нас складывалось ощущение: кто-то поставил лимит на скорость «черепахой».

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

Победа? В какой-то мере. Потому что как только мы закрыли первый блок проблем, тут же «выстрелили» новые. Например, вдруг выяснилось, что лицензии на ряд функций должны были идти в комплекте, но по какой-то причине отсутствуют в поставке. Параллельно отвалилась система оповещений: email-уведомления и SNMP больше не доставляли критические алерты. Мониторинг оказался «слепым» в тот самый момент, когда риски были максимальны. Добавьте к этому периодические зависания контроллеров и проблемы с FC-коммутаторами — и стандартное расширение дискового пространства превращается в длинную череду непредвиденных доработок.

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

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

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

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

Кейс второй: «Элементарный» проект с ИБП, сервером и байпасом

Второй кейс — классика жанра для любого интегратора. Задача выглядит просто: поставить в стойку один ИБП, сервер и байпас. Всё оборудование приехало в срок, инженеры тоже — что может пойти не так?

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

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

Дальнейшие события напомнили бюрократический квест. Заказчик оказался «раздроблен»: сотрудники, участвующие в закупке, были совсем не теми, кто будет принимать объект в эксплуатацию. Каждый стейкхолдер предъявлял свои требования и не был готов брать на себя ответственность за компромисс. В результате, чтобы согласовать решение, ушло больше двух недель переписки, эскалаций, согласований с руководством — и только после долгих переговоров удалось закрепить технически и юридически корректное решение.

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

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

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

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

Несколько экспертных выводов — из практики и личного опыта

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

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

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

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

Итог

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

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

Что произошло

Журналист Джек Поулсон, пишущий о технологиях и национальной безопасности, заметил, что две его публикации исчезли из поиска Google, даже если вводить точные заголовки в кавычках. Оба материала касались генерального директора Premise Data Делвина Мориса Блэкмана, арестованного в 2021 году по обвинению в домашнем насилии.

Поулсон обратился в Фонд свободы прессы (Freedom of the Press Foundation, FPF). Там выяснили, что исчезновение связано с неизвестной ранее ошибкой в инструменте Google «Обновить устаревший контент». Об этом написал Techspot.

«Хитрый» трюк с URL

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

Манипуляцию повторяли до полного исчезновения оригинальных публикаций из поиска.

Реакция Google

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

«Мы хотели бы, чтобы Google и другие платформы были более прозрачны в диалоге с организациями, защищающими свободу прессы и права человека», — заявил Ахмед Зидан, заместитель директора FPF.

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

Сегодня под «багами» понимают уже не насекомых, а любые ошибки в работе систем. Этот термин прочно вошёл в обиход, давно выйдя за пределы IT.

Ошибки в программах неизбежны, но ключ к качественной разработке — умение быстро их находить и исправлять. Исследования показывают, что разработчики тратят 35–50% рабочего времени на тестирование и отладку, а эти этапы поглощают 50–75% бюджета проекта.

В этой статье мы разберем современные инструменты и подходы к поиску и устранению багов.

1. Трекеры багов

История инструментов для отслеживания ошибок уходит корнями в прошлое. Ещё в 1970-х разработчики Bugtraq в AT&T Bell Labs использовали физические баг-тикеты, прикрепляя их к пробковым доскам. Знаковый скачок произошёл в 1998 году, когда Mozilla открыла доступ к первому веб-трекеру — Bugzilla. Дальнейшая эволюция привела к появлению Jira от Atlassian в 2002 году и прототипа Sentry на GitHub в 2008-м.

Зачем нужен баг-трекер ?

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

• Что пошло не так?
• Что должно было происходить?
• Как вызвать ошибку?
• Какой контекст у ошибки ?

Баг-трекеров существует великое множество, ведь по сути это автоматизированные цифровые записные книжки. Баги можно отслеживать с помощью Jira, Redmine, Битрикса, Yandex Tracker, GitHub Issues, Sentry, BugHerd и др.

Баг-трекеры выбираются исходя из потребностей команды. В больших компаниях популярны решения внутри их корпоративного трекера; часто в open-source проектах баг-трекером для комьюнити выступает GitHub Issues, а в небольших командах таковым выступает закреп в чатах TG-группы.

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

2. Отладчики

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

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

Основная задача отладчика — это предоставить информацию о ходе выполнения программы.

Как эффективно использовать ?

Сформулируйте гипотезу и не одну

Подумайте, какую информацию вам нужно получить, предположите, с какой строчки ход исполнения идёт неверно.

Расставьте точки останова для проверки гипотезы

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

Идите по шагам и следите за переменными с неправильными значениями

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

Меняйте значения переменных по ходу выполнения

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

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

3. Профилировщики

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

Как эффективно использовать ?

Определите метрики и точки измерения

Подумайте и поймите, какой именно показатель у вас проблемный (тестировать загрузку CPU, искать утечку памяти, следить за нагрузкой на процессор) и какие процессы вам нужно контролировать.

Воссоздайте проблемную ситуацию

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

Оцените вызываемую нагрузку

Не пытайтесь оптимизировать всё сразу. Начните с 1–2 самых проблемных функций или процессов, дающих наибольший выигрыш. Используйте принцип Парето, т.е. сначала займитесь проблемами, у которых соотношение улучшение производительности/время на починку самое лучшее.

Изучите алгоритмы и структуры данных

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

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

4. Логгеры

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

Как правило, это первый инструмент поиска ошибок у всех разработчиков, который они реализуют через функции типа print().

Как эффективно использовать ?

Структурируйте логирование

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

Выстройте иерархию логирования

Стандартная такая: DEBUG, INFO, WARN, ERROR, FATAL.

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

Добавляйте в логи контекст

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

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

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

Пользуйтесь ИИ

Все современные популярные модели достаточно умны, чтобы проанализировать код и добавить в него логи. Главное — заранее объяснить ей стратегию логирования. Воспользуйтесь для этого Cursor, WindSurf, Codex и иными ИИ-ориентированными IDE, чтобы они знали контекст.

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

5. Авто-тесты

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

Даже если вы не тестировщик — пишите автотесты. Вы значительно сократите себе часы жизни на ручной проверке результатов. Чем больше проект, тем важнее писать автотесты, чтобы избежать фразы: «А раньше работало?».

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

Какие бывают тесты ?

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

Модульные тесты (Unit Tests)

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

Интеграционные тесты (Integration Tests)

Проверяют взаимодействие нескольких модулей, компонентов или систем (например, проверить доступность API или успешное чтение/запись в БД). Нужны, чтобы убедиться, правильно ли соединённые части работают вместе, а также выявить проблемы взаимодействия.

Сквозные тесты (End-to-End / E2E Tests):

Тестируют всю систему целиком с точки зрения пользователя, имитируя его действия в реальной среде (браузер, мобильное приложение). Воспроизводят сценарии использования, например, покупку товара или загрузку Excel-файла из БД. Нужны, чтобы проверить работоспособность всей системы. Могут быть очень затратны.

Как эффективно использовать ?

Пишите тесты по принципам FIRST

• Fast – тесты должны быть быстрые, иначе замедлят разработку.
• Independent – тесты должны быть изолированы друг о друга, чтобы не падать, как домино.
• Repeatable – воспроизводимые, при одинаковых вводных давать одинаковый результат.
• Self-Validating – результат строго бинарный: успех/не успех.
• Timely – тест нужно писать заранее, чтобы сэкономить себе часы жизни в будущем, а не писать их после того, как тысячу раз рукам сам проверял, что всё ок.

Следуйте Пирамиде тестирования

Тесты должны выполняться в порядке от простых и быстрых к наиболее сложным и долгим, так, чтобы 90% ошибок попадали в первые и быстрые тесты, экономя вам время в ожидании окончания тестирования.

Следите за покрытием тестов

Отслеживайте, насколько ваш код покрыт тестами — так, чтобы минимальным количеством тестов покрыть максимальное количество кода.

Настройте CI/CD сами или попросите вашего DevOps

Интегрируйте запуск тестов в процесс сборки (CI/CD-пайплайн). Тесты должны запускаться автоматически при каждом коммите и пулл-реквесте. Это же всё-таки АВТО тесты.

Даже если вы не тестировщик, то неработающие функции исправлять придётся вам же.

6. Статический анализ кода

Статический анализ кода — это процесс автоматической проверки исходного кода без его выполнения. Инструменты статического анализа (линтеры, SAST — Static Application Security Testing) сканируют код, ищут потенциальные ошибки, уязвимости безопасности, нарушения стиля кодирования, сложные для понимания конструкции.

По умолчанию есть во всех популярных IDE.

Как эффективно использовать ?

Изучите их

Изучите, какие анализаторы кода бывают, зачем они нужны и как работают. После чего принимайте решение: нужны ли они вам в проекте или будут только замедлять процесс CI/CD.

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

Настройте их

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

Запускайте их как авто-тесты

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

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

Итог

Баги — неизбежные спутники разработки, но их цена растет как снежный ком с каждым этапом жизненного цикла ПО.

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

Речь идет о параметре reloadOnChange, который отвечает за автообновление настроек из файла конфигурации.

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

Что делает reloadOnChange

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

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

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

Как Microsoft нашла баг

Хэмрик обнаружил проблему, анализируя дампы памяти .NET, снятые через WinDbg и другие инструменты. Он увидел, как объект конфигурации разрастается в памяти — и каждый экземпляр привязан к новой копии FileSystemWatcher, который отслеживает изменения одного и того же файла.

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

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

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

Инженеры Microsoft советуют использовать reloadOnChange осознанно и только там, где это действительно необходимо. Особенно в продакшене.

Разработчики против пользователей

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

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

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

Массивы и слайсы

Начнём с базовых концепций:

• Массив — последовательность элементов определённого типа и фиксированной длины. Это неизменяемая структура данных и его capacity всегда равна его длине.
• Слайс — своеобразная надстройка поверх массива с возможностью изменения длины.

Распространённые ошибки при работе со слайсами

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

Про длину и capacity слайсов стоит помнить две вещи:

1. Когда мы создаём новый слайс, его длина равна его capacity, если не указано другое.
2. Как именно растет вместимость слайса начиная с версии go 1.20.

Поскольку в Go все аргументы передаются в функции по значению, то при передаче слайсов в качестве аргумента передаётся значение его структуры. Иными словами, копируется только ссылка на массив, на основе которого построен слайс. Сам массив со всеми содержащимися в нём данными не копируется. Если этого не знать, можно получить неожиданный результат.

Дальше рассмотрим примеры.

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

Здесь в main объявлен слайс, состоящий из одного нуля. После чего этот слайс передаётся в функцию с говорящим названием changeSliceValues. Там с ним происходят некие действия, в текущем примере в нулевой индекс записывается единица. Если в main вывести слайс на экран до и после вызова функций, то ожидаемо увидим [0] и [1] соответственно.

Теперь немного изменим пример — в changeSliceValues после записи в нулевой индекс с помощью append добавим в конец слайса 2, после чего запишем в нулевой индекс 3. И несмотря на применённые нами изменения, принты в main все так же выведут [0] и [1]. Размер слайса не изменился, несмотря на то, что мы добавили append. Вторая запись тоже не применилась.

На самом деле всё станет понятно, если вспомнить озвученные ранее факты о слайсах и структуру слайса. В самом начале мы создали слайса с длинной, которая равна его capacity, то есть единице.

В момент вызова changeSliceValues в качестве аргумента передаётся значение структуры слайса. Он указывает на тот же самый нижележащий массив, что и слайс в main. По этой причине первая запись на нулевом индексе применяется на изначальном массиве, который был создан при инициализации слайса в main.

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

Следующая запись в нулевой индекс происходит опять же на новый массив. На изначальный массив, который был создан при объявлении слайса в main, это никак не влияет.

Копирование слайсов

С этой же проблемой можно столкнуться, если попытаться скопировать слайс.

В примере в переменную newSlice с помощью слайсинга копируются данные из оригинального слайса, в том числе и указатель на массив с данными. При выполнении append данные перетираются в оригинальном массиве, потому что newSlice указывает на оригинальный массив из первого слайса.

В Go есть специальная встроенная функция copy, которая позволит безопасно копировать любые слайсы.

На картинке выше видно, что, использовав copy, мы перенесли элементы из исходного слайса в новый. Теперь можно безопасно делать append, не боясь перетереть изначальные данные.

Работа со строками и рунами

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

В бесконечном цикле мы получаем новые новости, после берём первые сто рун и отдаём в некую функцию storeArticlePreview, которая заботится о том, чтобы сохранить руны в кэш.

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

Кстати, почему в этом примере мы скастили строку к массиву рун, прежде чем брать от неё первые 100 символов? Покажу на примере, чем отличаются руны от байтов.

Берём стандартную строку Hello World и делаем отдельную переменную с рунами. По задумке хотим запринтить первые пять символов, то есть слово Hello.

Если посмотреть на вывод, то не в нем не будет ничего необычного. Сначала принтятся сами руны, потом, когда мы конвертируем это в строку, выводится слово Hello. Когда берём первые пять элементов от строки, снова выводится Hello.

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

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

Помним, что строки в Go состоят из UTF-8 символов, каждый из которых может быть представлен более чем одним байтом. Если взять слайс по строке, то работать мы будем с байтами, а не с её символами. Поэтому когда мы пытаемся взять первые два символа от строки, мы берём первые два байта.

Большинство операций со строками работает с их байтами, но есть и исключения.. Слайсинг строки отдаёт байты, метод len также покажет длину в байтах. Цикл for range в качестве индекса берёт индекс байта, с которого начинается символ, но в значении будет лежать не байт, а руна, которая начинается в этом индексе.

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

Каналы

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

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

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

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

Здесь есть говорящая функция writeToChan, в которой происходит запись в канал и в main цикл по этому каналу — в нём мы высчитываем значения. Если не закрыть канал, цикл никогда не закончится и случится deadlock. Если закрыть — for range успешно завершается и логика программы идёт дальше.

Закрывать канал стоит только в тех ситуациях, когда читатель никак не должен реагировать. Ничего страшного, если канал не закрыт. Сборщик мусора сможет от него избавиться даже в таком состоянии.

time.After

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

Вот пример, где мы обрабатываем какие-то события, которые поступают из некой очереди. Если за 15 минут мы не встретили ни одного события в канале, то кинем warning, что что-то случилось.

Если запустить код, он будет рабочим. Но если вдруг есть какой-то дашборд, в котором мы измеряем потребление памяти и событий большое число, то мы легко обнаружим, что есть утечка памяти. При среднем потоке в миллион сообщений в 15 минут утечка составит порядка 200 Мб. Один канал Go весит около 200 байт. Получается, что на каждое событие убегает новый канал.

Почему это происходит, если сборщик мусора сможет удалить и не закрытый канал, а канал, созданный time.after, выходит из зоны видимости после каждого нового события?

Обращаемся к документации: «таймер не будет собран сборщиками мусора до тех пор, пока он не отработает». То есть time.after, который мы ставили на 15 минут, на это время остаётся висеть мертвым грузом, даже если он уже не находится в области видимости.

Горутины

Горутина — это лёгкий поток выполнения в userspace, пока потоки операционной системы живут в kernel space. Горутины управляются средствами Go, а потоки — средствами операционной системы.

Горутины спроектированы так, чтобы быть более эффективными, чем традиционные потоки операционной системы. Но у них тоже есть несколько ловушек, в которые можно попасть при работе.

В примере ниже мы создаём слайс из цифр от 1 до 5 и горутины в цикле, и в каждой из них прибавляем своё число из слайса к переменной sum. Можно подумать, что в выводе будет число 15, то есть сумма чисел от 1 до 5 — однако это не так.

Здесь проблема состоит в замыканиях — функциях, которые захватывают переменные из внешней области видимости. В примере анонимная функция, которая создаётся в цикле, является замыканием, потому что она захватывает переменную value из внешней области видимости.

Особенность их работы в том, как используется захваченная переменная. Горутины не захватывают значения переменных на момент их создания — они захватывают ссылку на переменную. Поэтому, когда горутины начинают выполняться, цикл зачастую уже прошёл, и переменная value имеет последнее значение из слайса. По нему мы итерируемся, хотя гарантии того, что цикл завершится раньше, чем начнёт работу одна из горутин — нет. Это приводит к тому, что в переменной sum оказывается не значение 15.

Это настолько распространённая проблема, что мейнтейнеры Go решили изменить семантику переменных цикла for, чтобы предотвратить их непреднамеренное использование в замыканиях и горутинах на каждой итерации. В версии 1.21 появился соответствующий эксперимент, а с версии 1.22 эта проблема уже полностью перестала воспроизводиться. Но, поскольку версия 1.22 свеженькая, и ещё не все успели обновиться, берите себе на заметку эту особенность работы замыканий.

Пакеты sync и atomic

В примерах выше мы использовали sync WaitGroup, чтобы дождаться выполнения горутин и, кстати, сделали это неправильно. Признавайтесь, кто не заметил?) Стоит обратить внимание на то, где мы делаем wg.Add, и подумать, чем это черевато.

Давайте разбираться. Посмотрим на устройство wait group:

В структуре WaitGroup из интересного мы видим семафор и некий noCopy. Сначала поговорим про семафор, а точнее про то, что по сути WaitGroup — это простенькая обёртка над семафором с тремя методами:

1. .Add(delta int) увеличивает значение семафора на переданное значение.
2. .Done() уменьшает значение семафора на единицу.
3. .Wait() блокирует выполнение до тех пор пока значение семафора не станет равно 0.

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

Теперь вернёмся к структуре WaitGroup и присмотримся к полю noCopy, с таким же типом noCopy — что же это такое? По названию можно догадаться, что это что-то, что нельзя копировать, подобное поле есть в большинстве структур пакета sync. Давайте посмотрим, что же произойдёт, если всё же скопировать структуру с этим полем. Для примера будем использовать мьютекс, в нем также есть поле noCopy с типом noCopy.

В этой программе у нас есть структура Counter, которая хранит в себе мапу, а также мьютекс, который должен по задумке защищать мапу от параллельной записи. В мьютексе так же, как в waitGroup, присутствует noCopy.

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

Проблема с кодом в том, что всякий раз, когда вызывается increment, в него копируется наш Counter c, поскольку increment определён на типа Counter, а не на *Counter. Другими словами, это value receiver, а не pointer receiver. Следовательно, increment не может изменять оригинальную переменную типа Counter, которую мы создали в main. Поэтому при каждом вызове increment происходило копирование счётчика со всем его содержимым, в том числе и мьютексом.

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

Так вот, за счет того самого noCopy есть возможность пометить любую структуру как невозможную к копированию (многие структуры из пакета sync так и отмечены). Тогда с помощью команды go vet можно будет обнаружить места, в которых отмеченная структура копируется, и найти потенциальную проблему в коде своего приложения.

Atomic

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

В этой программе запускается горутина, которая постоянно в бесконечном цикле увеличивает на единицу значение переменной num. В то же время, в main находится бесконечный цикл, который проверяет, чётное ли число, и если это условие выполняется — выводит его на экран. Однако мы видим, что при запуске вывелось число 287, а оно, как ни странно, нечётное. Это происходит из-за того, что после прохождения num проверки на чётность его значение никак не защищено от изменений, и горутина, инкрементирующая num, успевает изменить его значение до того, как число выводится на экран.

defer

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

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

И в результате добавленного нами лога мы всегда будем видеть запись «profile balance: 0». Почему так?

Давайте внимательнее посмотрим на то, что написано про defer в документации языка: «The arguments to the deferred function (which include the receiver if the function is a method) are evaluated when the defer executes, not when the call executes». Значение аргументов для функции в defer (в том числе и ресивер метода) вычисляются в момент исполнения defer, а не в момент исполнения функции. В нашем примере на момент исполнения defer в переменной balance у нас по дефолту лежит 0 — вот с этим значением наш принт и выполняется. А для того, чтобы достичь результата, который мы и хотели получить, то есть для того, чтобы в принте фигурировала итоговая сумма расчета, можно использовать концепцию, с которой мы уже встречались — замыкания.

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

Интерфейсы

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

У нас есть интерфейс реквестера, который делает какой-то запрос и в респонсе отдает int — допустим, статус-код нашего запроса. Есть конкретный тип concrete requester, который реализует интерфейс реквестера. Ещё для интерфейса реквестера есть функция, которая позволяет его инициализировать в зависимости от переданного значения value.

Если оно больше нуля, то мы возвращаем instance concret requester’а. Если оно меньше или равно нулю — просто возвращаем не проинициализированную переменную. В main есть логика, которая сначала принтит реквестер, а затем делает ещё один принт в зависимости от того, nil он или нет.

Если запустить программу, то мы увидим забавный вывод:

Мы получили реквестер nil, но при этом он не nil.

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

Под капотом есть две структуры для интерфейсов: eface для пустого и iface, если определён набор методов, которым должен соответствовать тип. Сейчас нас интересуют общие для них поля — а именно тип данных, которые реализует интерфейс, и ссылка на область в памяти, где находится его значение. Для того, чтобы две переменные интерфейс-типа были равны, нужно чтобы у них были равны оба этих поля.

Теперь посмотрим

что именно лежит в этих полях для нашей переменной requester:

Ага! Вот отсюда ноги и растут. Несмотря на то, что фактическое значение у переменной — это nil, тип таковым не является, что и приводит к тому, что сравнение requester == nil — это false.

Это поведение связано с так называемым value boxing и заслуживает отдельной статьи, которая уже в общем-то и так любезно написана здесь.

Особенности вендоринга

Представим, что вы завели библиотеку на Go, в которой должны происходить какие-то сетевые запросы. Внутри этой библиотеки вы реализовали некий клиент, который умеет делать запросы, получать в респонсе какие-то данные и отдавать их в виде структур, описанных в папке models.

Теперь попробуем использовать эту библиотеку в каком-нибудь сервисе. Добавили её в go.mod, прописали в консоли go mod tidy, go mod vendor, решили заглянуть в vendor, а там, неожиданно лежит только часть файлов и папок вашей библиотеки.

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

“The go mod vendor command constructs a directory named vendor in the main module”s root directory containing copies of all packages needed to build and test packages in the main module.”

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

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

На этом все! Напишите в комментариях, есть ли ещё какие-то ошибки, о которых не рассказал в статье? Обсудим их в следующий раз!

Ошибка 1: Вы зависите от одного провайдера облачных услуг

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

Реальные примеры ошибки

1. AWS Outage в 2017 году:

В феврале 2017 года Amazon Web Services (AWS) испытал длительное отключение в одном из своих дата-центров, что повлияло на множество приложений и сервисов, зависящих от их облачных услуг. Многие компании — Slack, Trello и Airbnb, столкнулись с проблемами, что привело к сбоям в их сервисах. Этот случай продемонстрировал уязвимость зависимых систем.

2. Опасности «lock-in» в облачных платформах:

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

Как командам избежать этой ошибки

1. Используйте многооблачную стратегию:

Многооблачная архитектура позволяет распределить ресурсы между несколькими провайдерами (например, AWS, Google Cloud, Microsoft Azure). Это снизит зависимость от одного поставщика и сделает систему более устойчивой и гибкой.

2. Стандартизуйте API и интерфейсы:

Проектирование системы с использованием стандартных интерфейсов (например, RESTful API) позволяет легче менять облачные услуги без значительных нововведений в коде.

3. Обрабатывайте данные в гибридной модели:

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

4. Используйте контейнеризацию:

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

Ошибка 2: У вас нет кэширования

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

Реальные примеры ошибки

1. Netflix:

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

2. Pinterest:

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

Как командам избежать этой ошибки

1. Выбирайте подходящий механизм кэширования:

Команда должна определить, какой тип кэширования лучше всего подходит для их приложения: кэш на уровне сервера (например, Memcached, Redis) или кэширование на стороне клиента (например, браузерное).

2. Кэшируйте часто запрашиваемые данные:

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

3. Используйте HTTP-кэширование:

Здесь помогут заголовки HTTP Cache-Control, ETag и Last-Modified, чтобы управлять кэшированием на уровне сервера и клиента.

4. Обновляйте кэш:

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

Ошибка 3: Вы неправильно структурировали базу данных

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

Реальные примеры ошибки

1. Delta Airlines:

Delta Airlines столкнулась с проблемами производительности своей базы данных. Причиной стало плохое проектирование, что замедлило обработку онлайн-бронирований. Для решения проблемы компании пришлось значительно переработать архитектуру базы данных — оптимизировать структуру таблиц и индексов.

2. Facebook*:

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

*Компания Meta признана экстремистской на территории РФ

Как командам избежать этой ошибки

1. Проектируйте БД на основе требований:

Это база! (данных). Перед началом проектирования важно анализировать бизнес-требования, чтобы понять, как данные будут использоваться. Это поможет определить, какие таблицы и связи необходимы.

2. Следуйте правилам нормализации:

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

3. Используйте индексы:

Установка индексов на поля, которые часто используются в условиях WHERE и JOIN, может значительно улучшить производительность запросов. Но следует также осторожно подходить к индексированию, чтобы не перегружать систему.

4. Поддерживайте архивирование и шардирование данных:

Если БД становится слишком большой, следует рассмотреть возможность шардирования (разделение базы на части) или архивирования старых данных.

5. Используйте инструменты моделирования баз данных:

Применение инструментов по типу ER-диаграмм для визуализации структуры базы данных может помочь лучше понять связи между данными и выявить потенциальные проблемы до их реализации.

Ошибка 4: Вы не используете микросервисную архитектуру для масштабируемых систем

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

Реальные примеры ошибки

1. Spotify:

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

2. PayPal:

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

Как командам избежать этой ошибки

1. Определите границы сервисов:

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

3. Используйте API для взаимодействия:

Микросервисы должны общаться друг с другом через API. Что важно, это способствует независимости одного сервиса от другого и делает каждый более масштабируемым.

4. Внедряйте DevOps и CI/CD:

Для успешного развертывания и управления микросервисами необходимо внедрить практики DevOps и непрерывной интеграции и доставки (CI/CD). К ним относится автоматизация тестирования, деплоймента и управления версиями.

5. Переходите к микросервисам постепенно:

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

Ошибка 5: Вы игнорируете принцип единственной ответственности (Single Responsibility Principle)

Принцип единственной ответственности (SRP) предполагает, что каждый класс или модуль должен выполнять одну функциональную задачу. Игнорирование этого принципа может привести к чрезмерной связности и сложности кода, что затрудняет его тестирование, отладку, модификацию и поддержку.

Реальные примеры ошибки

1. Одна из E-commerce платформ

В ранней версии e-commerce платформы класс Order обрабатывал и управление заказами, и логику расчёта налогов, и взаимодействие с платёжным процессором. Это усложняло управление кодом и добавляло риски при любых изменениях. После переработки системы с использованием SRP была создана отдельная служба расчёта налогов и платёжная служба, что значительно упростило код и улучшило его тестируемость.

Как командам избежать этой ошибки

1. Определите задачи каждого модуля или класса:

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

2. Используйте абстракции и интерфейсы:

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

3. Применяйте паттерны проектирования:

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

Ошибка 6: У вас нет системы мониторинга и логирования

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

Реальные примеры ошибки

1. Uber:

В начале своего развития Uber сталкивался с проблемами, связанными с отслеживанием производительности своей системы. Отсутствие эффективного мониторинга привело к тому, что команда долго не могла выяснить причины нестабильной работы приложения.

2. LinkedIn:

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

Как командам избежать этой ошибки

1. Используйте мощные фреймворки логирования:

Использование мощных фреймворков логирования по типу Log4j или Serilog позволяет эффективно записывать важную информацию о работе приложения.

2. Мониторьте в реальном времени:

Необходимо использовать инструменты мониторинга — Prometheus, Grafana или New Relic для наблюдения за производительностью серверов, баз данных и приложений в реальном времени

3. Определите ключевые показатели производительности (KPI):

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

4. Анализируйте логи:

Создание процессов для анализа логов поможет командам выявлять паттерны ошибок, а не лишь быстро решать точечные проблемы. Для этого можно использовать решения, такие как ELK Stack (Elasticsearch, Logstash, Kibana).

5. Настройте уведомления и алерты:

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

6. Тестируйте с нагрузкой:

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

Ошибка 7: У вас есть заблуждение о «сделай всё сразу» и нет итеративного подхода

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

Реальные примеры ошибки

1. Microsoft:

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

2. Volkswagen:

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

Как командам избежать этой ошибки

1. Планируйте и приоритезируйте задачи:

Необходимо четко определить основные требования и приоритизировать задачи. Используйте методики, например, MoSCoW (Must have, Should have, Could have, Won't have), чтобы определить важность функционала.

2. Не забывайте про итеративную разработку:

Внедряйте циклы разработки, основанные на итеративных подходах, по типу Scrum или Kanban. Это позволит командам адаптироваться и быстро реагировать на изменения в требованиях.

3. Управляйте изменениями:

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

4. Используйте подход Lean:

Рассмотрите внедрение Lean-подхода, который акцентирует внимание на устранении потерь в процессе разработки и оптимизации всех этапов создания продукта.

Ошибка 8: Вы неправильно обрабатываете ошибки

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

Реальные примеры ошибки

1. NASA:

Проект Mars Climate Orbiter был потерян из-за ошибки в обработке данных, связанной с несоответствием единиц измерения. В то время как одни команды использовали метры, другие работали в дюймах. Эта ошибка не была должным образом обработана, что привело к тому, что аппарат вошёл в атмосферу Марса под неправильным углом и сгорел. Неправильная обработка ошибок ввела в заблуждение команду, которая не могла вовремя диагностировать проблему.

2. Knight Capital Group:

В 2012 году трейдинговая компания Knight Capital Group потеряла 440 миллионов долларов за 45 минут из-за ошибки в коде. Ошибка, которая была вызвана неправильной обработкой исключений, привела к некорректным трейдам. Система продолжала работать, не показывая значительных признаков сбоя, что усложняло реакцию команды и в итоге привело к коллапсу.

Как командам избежать этой ошибки

1. Единообразно обрабатывайте ошибки:

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

2. Разделяйте ошибки на категории:

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

3. Используйте адаптивное логирование:

Логирование должно фиксировать не только ошибки, но и контекст их возникновения. Используйте уровни логирования (DEBUG, INFO, WARN, ERROR) для записи информации, которая может помочь в диагностике.

4. Настройте грацию исключений:

Научите команду правильно использовать и обрабатывать исключения с помощью конструкций try/catch/finally. Проверяйте, чтобы исключения не просто «гасились», но также создавались и корректные сценарии обработки.

5. Тестируйте сценарии ошибок:

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

Ошибка 9: Вы игнорируете кроссбраузерность и мобильную адаптивность

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

Реальные примеры ошибки

1. Expedia:

В 2018 году, после неудачного редизайна своего сайта, Expedia заметила значительное снижение конверсий, особенно на мобильных устройствах. Дополнительные тесты показали, что новый интерфейс выглядел и работал плохо в определённых мобильных браузерах. Отказ от полноценной поддержки мобильной адаптивности привёл к значительным финансовым потерям.

2. BBC:

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

Как командам избежать этой ошибки

1. Используйте фреймворки и библиотеки:

Рассмотрите использование популярных фреймворков и библиотек по типу Bootstrap или Foundation, которые включают встроенные механизмы для кроссбраузерности и мобильной адаптивности.

2. Проводите автоматизированное тестирование:

Внедрите автоматическое тестирование с помощью инструментов, например, Selenium или BrowserStack, чтобы проводить кроссбраузерное тестирование на различных устройствах и платформах.

3. Изучайте стандарты и спецификации:

Ознакомьтесь со стандартами W3C и другими рекомендациями по веб-разработке, чтобы убедиться, что ваш код соответствует современным требованиям и легко адаптируется к различным браузерам.

Ошибка 10: Вы оптимизируете на ранних стадиях разработки

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

Реальные примеры ошибки

1. NASA:

В проекте Mars Climate Orbiter обнаружили, что разработчики слишком увлеклись оптимизацией кода обработки данных. Это привело к потере фокуса на основном функционале и неправильным единицам измерения. Результатом стало то, что не было видно проблемы, когда аппарат не вошел в атмосферу Марса, что обернулось его разрушением. Позже NASA поняла, что важнее сосредоточиться на правильной реализации основных функций, прежде чем наносить на них оптимизацию.

Как командам избежать этой ошибки

1. Возводите функционал в приоритет:

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

2. Развивайте продукт итеративно:

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

Поделитесь вашим опытом в комментариях!

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

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг-репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Заголовок

Старайтесь ответить в названии тикета на три вопроса:

1. Где происходит?
2. Что происходит?
   
3. При каких условиях?
   

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

Страница Входа: Не подсвечивается поле при вводе неверного пароля

Окружение

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

Войти на стейдже под аккаунтом админа.

К слову о шагах.

Шаги воспроизведения

Один из главных разделов, инструкция по воспроизведению бага. Я выделю два подраздела, на которые обратим внимание. Это оформление шагов (визуальное) и наполнение (данные внутри).

Визуальная часть

Сохраняйте структуру

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

1. Шаги
2. Ожидаемый результат
   
3. Фактический результат
   

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

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

Разделяйте шаги через нумерованный список. Иногда тестировщики пишут подробно, но одним сплошным текстом. Не будьте такими. Всем будет гораздо проще читать с разделением.

По возможности, пишите без грамматических ошибок.

А теперь к наполнению этих шагов.

Наполнение

Здравый смысл при описании

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

Плохо:

1. Зайти на test.com/login
2. Кликнуть в поле login
   
3. Ввести логин
   
4. Кликнуть в поле password
   
5. Ввести пароль
   

Хорошо:

1. Перейти на test.com/login и войти под любой учетной записью

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

Избегайте неоднозначности

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

Добавляйте тестовые данные

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

Пройдите по созданным шагам еще раз

Бывает, что вы укажете шаги сразу после появления бага, но может оказаться, что не хватает какого-то шага для полного понимания, или баг не воспроизведется еще раз, и нужно будет искать более точные шаги.

Ожидаемый результат

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

Фактический результат

Здесь мы пишем, а что произошло на самом деле, когда прошлись по шагам. Здесь тоже важна конкретика. Не стоит писать, что все поломалось (хотя наверное так оно и было). Стоит описать, что за индикаторы говорят, что все сломалось. Например:

Возвращается 500 ошибка по запросу GET /accounts и блокируется UI. Пользователь не может выйти со страницы или кликнуть на элементы. Обновление страницы приводит к повторному запросу и ошибке.

То есть описываем реальный эффект и его влияние на флоу юзера.

Дополнительные файлы

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

Скриншоты ошибки

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

Запрос

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

URL ошибки

Собственно сам запрос, можете взять из раздела Network в браузере, котором проходит тестирование.

Метод

GET, POST, TRACE, OPTION и так далее — методов немало, как и запросов с одинаковым URL, но разными методами. Не забудьте указать его в тикете.

Код ошибки

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

Payload

Это полезная нагрузка запроса, то есть данные, что мы отправили в нашем запросе на сервере. Это есть не в каждом запросе (например, HEAD или GET ими не обладают), но там могут быть причины ошибки.

Response

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

Логи из консоли

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

Это все хорошо, но...

Это все хорошо, но где у нас столько времени, чтобы все это красиво оформлять? Сроки горят, менеджер ругается, на проде блокер, а мне предлагается сидеть и еще расписывать все? Просто напишу разрабу в ЛС и все.

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

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

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

Если у вас есть вопросы, предложения, несогласия, возмущения — пишите в комментарии, интересно услышать мнение!

Теперь пользователи больше не могут загрузить и накатить этот апдейт, пока компания не устранит возникшую проблему.

Как мы и говорили в своем недавнем материале, не стоит торопиться — первые версии свежих iOS (и, видимо, iPadOS) очень часто бывают с багами и дырами.

Массовые сбои устройств

Причиной остановки стали многочисленные жалобы владельцев iPad Pro, чьи устройства были повреждены после обновления.

На Reddit появилось множество сообщений от тех, чьи планшеты перестали включаться. В том числе из-за сбоев в процессе установки iPadOS 18. В некоторых случаях проблему можно было решить только полной заменой устройства.

Возможные причины проблемы

Интересно, что проблема коснулась не всех владельцев iPad Pro.

Некоторые эксперты считают, что сбой может быть связан с предварительной установкой обновления iPadOS 17.7 перед обновлением на iPadOS 18.

Как бы то ни было, пока Apple не устранит эту проблему, загрузка свежего обновления системы на iPad остается недоступной.

Официальный комментарий Apple

Apple уже дала официальный комментарий порталу MacRumors:

«Мы временно сняли обновление iPadOS 18 для моделей iPad Pro с чипом M4, так как работаем над устранением проблемы, которая затрагивает небольшое количество устройств».

Об этом случае вспомнил Теодор Смит из PHP Experts.

Как это случилось

Разработчики Knight Capital срочно переносили своего высокочастотного торгового бота на новый сервис NYSE, который должен был запуститься через 33 дня.

Они работали по 80 часов в неделю, чтобы успеть к дедлайну. В коде бота они оставили старые методы и классы, чтобы избежать необходимости пересборки.

Также разработчики убрали старый тестовый код и вставили новый рабочий. Тесты прошли успешно, и утром 1 августа в 8:00 код развернули в продакшн. Всё выглядело отлично.

Катастрофа

Во время утреннего совещания в 9:30 рынок открылся и бот начал безудержно покупать акции по самым высоким ценам. За две минуты системы Knight Capital обнаружили, что деньги компании стремительно исчезают.

Связаться с разработчиками не удавалось, так как они находились в удаленном офисе и оставили свои телефоны на столах.

Через 11 минут боты уже скупили акции на сумму свыше $3 млрд, а компания оказалась на грани краха.

Единственным решением оказалось физическое уничтожение серверов в дата-центре с помощью топоров. Торги прекратились через 28 минут, оставив бумажные убытки в $10.8 млрд.

Почему это произошло

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

После выявления ошибки разработчики решили откатиться к предыдущему релизу, что лишь усугубило ситуацию. В итоге за 28 минут было потеряно $8.65 млрд.

Последствия

Эта катастрофа привела к потере всех корпоративных клиентов Knight Capital и компания закрылась через несколько недель.

Дэйв Пламмер, бывший инженер-программист из Microsoft, объяснил на своем YouTube-канале, как именно произошел этот сбой.

Причины сбоя

По словам Пламмера, операционная система использует кольцевую систему для разделения кода на два типа: Ring 0 (ядро) и Ring 1 (пользовательский режим).

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

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

Ошибка в драйвере CrowdStrike

Проблема возникла из-за обновления программного обеспечения Falcon от CrowdStrike, которое работает на уровне ядра.

Falcon отслеживает и идентифицирует новые атаки через мониторинг приложений, что требует привилегированного доступа.

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

Недостаточная проверка и последствия

Как отметил Пламмер, проблемный драйвер CrowdStrike не был должным образом проверен на наличие возможных ошибок перед выпуском.

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

Восстановление работы систем

Для исправления проблемы пользователи должны были загрузить систему в безопасном режиме Windows, удалить проблемные драйверы CrowdStrike и перезагрузить компьютер.

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

« from main.tasks import task »

Это не только код по PEP, сколько отсутствие видимой логики и структуры в коде.

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

По тексту я использую синтаксис Django ORM, так как он визуально проще, чем тот же SQL, и его можно представить как псевдокод для SQL.

Давайте понятные имена функции и переменным

Вместо c = count()

Вместо q = Model.objects.all()

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

Вместо for x, y in _dict.items()

Вместо count = User.objects.count()

Кто-то решит, что лучше count_user, но я думаю, это индифферентно, главное, чтобы было понятно.

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

может быть существенно упрощена несколькими способами.

Нормально:

Здесь у нас «хардкод», который лучше избегать всегда, кроме сonst-значений. Тем не менее, в отличие от довольно спорной оригинальной функции, эти имеют шанс на переиспользование.

Хорошо:

Теперь функция не привязана к конкретным типам покемонов, мы можем переиспользовать ее много раз. Жаль только, что в случае, если нам нужно посчитать в целом несколько типов за раз.

Отлично:

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

Поэтому я бы использовал окончательно вот такой вариант:

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

Если не получается вложить весь смысл в наименование функции или переменной, не пишите «x = » или «def func», а попробуйте разнести логику.

2. Отсутствие базовых знаний Linux/Unix

Наверняка в англоязычных зарубежных компаниях встречается разработка на Windows, но все же Python, как скриптовый язык, работает на Unix и Linux.

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

Утилиты которые точно пригодятся в использовании

Supervisor

Позволяет запускать и отслеживать процессы. Например, чтобы при перезапуске системы у вас всегда запускался проект.

Cron

Утилита, которая позволяет выполнять команды стартуя их в конкретный момент времени, например, парсить сайт каждый понедельник, в два часа ночи.

Nginx

Широко используемый веб-сервер. Если у вас веб-проект, без него практически не обойтись.

3. Слабые знания СУБД

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

Нереляционные СУБД

С нереляционными попроще, мы вот используем Redis, MongoDB и Clickhouse.

Redis — это key-value хранилище. Если провести аналогию с питоновскими типами — словарь, который отлично подходит для хранения кэша. Удобно использовать для межкомпонентного взаимодействия.

MongoDB — это хранилище JSON-документов, по такой же аналогии — список json’ов. Отлично подходит, если у вас где-то генерируется большое количество данных, которые вы не хотели бы терять. Например, если бы все эти данные писали в реальном времени в реляционную: это долго, могут случится ошибки записи, плюс нужна валидация и прочее. Mongo же пишет эти данные как есть, а в соседнем сервисе вы можете спокойно загрузить все данные в реляционную базу в своем темпе, пройдя все нужные валидации и проверки.

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

Подойдет, чтобы смотреть статистику, основанную на больших объемах данных.

Реляционные СУБД

Это, в первую очередь, MySQL и Postgres. Скорее всего, разработка на Python при участии БД будет проходить с помощью ORM, Django ORM или SQLAlchemy. Если это SQLAlchemy, это не так страшно, так как написание запросов в этой ORM так или иначе следует логике SQL. Django ORM максимально своеобразный.

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

• в Django ORM:

• в SQLAlchemy:

• чистый SQL:

В «Алхимии» видно, что мы что-то все-таки присоединили, Django ORM же работает с другими абстракциями. Надо понимать, как работают запросы и чистый SQL. Например, в случае профилирования, если тормозит страница, и экран профилирования покажет некий запрос, который вызывается либо несколько раз, либо отъедает время загрузки. Тогда нужно этот запрос отыскать в коде. Опять же, если SQL из примера будет съедать 10 секунд загрузки, выше видно, как он будет выглядеть в «Алхимии» или в «Джанго ОРМ».

4. Забивание на чистоту GIT

Частая проблема, которая не просто запускается, но еще и поддерживается коллективом. У вас мастер-ветка выглядит как

«fix -> fix -> fix -> try -> featyre -> fix -> revert» ?

Самое популярное оправдание, которое я слышал на эту тему, мол, что привязался, работает же. Фактически да, так оно и есть, но код это не только про «работает же». Это еще и его сопровождение в будущем. Представьте, вас просят что-нибудь найти или пофиксить спустя кучу времени, а вы натыкаетесь на странный кусок кода. В истории GIT одно «feature-> feature -> feature»? И коллега, судя по аннотации GIT, даже работает, но тоже не может вспомнить, в каком бреду это было написано и по чьей просьбе.

Поэтому, как по мне, близкое к идеалу ведение коммитов:

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

Помимо самих коммитов, есть еще использование rebase и merge.

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

Начинаете работу над задачей? Делаете новую ветку от мастера (или как скажет тимлид).

Заканчиваете работу над задачей? Делайте финальный ребейз на мастер и посквошьте коммиты. Работаете с коллегой в одной ветке? Вместо мержа origin-ветки в локальную, делайте ребейз на ориджин-ветку. История коммитов будет чище, сложно будет в ней теряться.

5. Написание тестов

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

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

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

Зачем нужны отчёты

Зачем менеджеру составлять какой-то отчёт об ошибке и тратить на него своё время, а не просто написать о проблеме?

Дело в том, что исправление ошибки напрямую зависит от того, кто с ней пришёл, и насколько эффективно он про неё сообщит. Если отчёт описан максимально корректно, то и шансы на исправление ошибки становятся больше, а времени, соответственно, меньше.

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

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

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

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

Пример того, как зачастую происходит коммуникация между разработчиками и менеджерами при неотлаженных процессах:

Эй, разработчик, у нас не работает кнопка для формирования отчета!

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

1. Проверяет работу кнопки, пытаясь опытным путём повторить ошибку.
2. Находит ошибку, описывает спецификацию, оценивает сроки.
3. Ошибка берется в работу.

Когда ошибка пойдет в работу, зависит от её сложности, приоритета и того, как она влияет на работу продукта.

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

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

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

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

Рекомендации написания отчёта об ошибке

1. Воспроизведение: прежде чем передать ошибку в разработку, убедиться, что она повторяется, желательно несколько раз. Воспроизвести процесс и описать действия шаг за шагом.
2. Проверка на существование: перед созданием отчёта поищите в бэклоге. Возможно, кто-то уже нашел ошибку, и разработчики уже знают о ней.
3. Краткое описание: минимум слов, только по делу. Одна проблема, один отчёт. По краткому описанию удобно вести навигацию среди большого бэклога.
4. Полное описание: описать ошибку и путь её достижения. Чем подробнее будет описан путь, тем легче будет повторить ошибку, найти и исправить.
5. Окружение: ОС, браузер, устройство, иные технические моменты, которые могли повлиять на баг (VPN, режим Инкогнито, Adblock и прочее).
6. Вместо тысячи слов: приложить к отчёту скриншоты или запись с экрана. Зачастую такая информация содержит больше полезной информации, нежели текстовое описание.
7. Ожидание и результат: описать, как все должно работать, какое поведение и результат были получены, какой ожидаемый результат и путь к нему.
8. Место происшествия: указать источник ошибки. Если это веб-приложение, указать полный url. Если иное, указать окно\вкладку и т.д.
9. Журналы ошибок: любые локальные логи помогут быстрее разобраться в ошибке. Сообщения в консоли браузера, ошибки в системе, любые alert’ы.
10. Приоритет: указать, насколько ошибка влияет на работу продукта. Исходя из приоритета, команда разработки сможет принять решение, как быстро приступить к её исправлению.

Плохой пример:

• Не могу подписаться на тег.
• Нужно срочно починить.

Хороший пример:

• Убедился несколько раз в ошибке, смог повторить.
• В беклоге не нашел ничего похожего, можно создавать.
• Не могу подписаться на тег java.
• Залогинен, открываю любую статью с тегом java, кликаю на тег для подписки, но ничего не происходит. При этом на остальные теги могу подписаться без ошибок.
• ОС linux mint, Google Chrome Версия 112.0.5615.165 (Официальная сборка), (64 бит), Адблок был и включен, и выключен.
• Скриншот или видео.
• Ожидаю, что после клика смогу подписаться на тег java и получать уведомления о выходе новых постов на сайте с этим тегом.
• Статья с тегом java.
• Failed to load resource: the server responded with a status of 404 ()
• Баг очень важный, его нужно сделать вчера.

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

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

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

В этой статье мы разберем несколько историй, с которыми столкнулись разработчики с The Daily WTF.

Ручная база данных

Разработчик С. Уайлс работает в крупной компании, которая занимается медицинским страхованием. Он разрабатывает SAS-приложение для своего работодателя.

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

Итак, Уайлс открывает базу данных и видит в ней это:

Оказалось, что все данные об обновлениях дат вносятся в БД вручную для составления запроса. Форматирование даты не было сделано на уровне БД, и для неё не была написана отдельная функция. Однако вместо этого скрипт обновляется вручную. Каждый год.

Сломанная валидация данных

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

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

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

Вот, какой код достался Кэрол:

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

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

Когда это не сработало, они удалили вызов Promise.all, но не удалили async.

Раньше функция выбрасывала ошибки по цепочке (хотя возврат значения имел бы больше смысла), но при отладке другой разработчик обернул все это в try/catch. После этого отладочный код не был удалён, а функция сломалась.

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

Нерабочий код, который сработал

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

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

Если присмотреться, можно заметить, что оператор ++ появляется три раза, а не два, как следовало бы. Однако код работает!

Оказалось, что разработчик допустил ошибку, но при этом получил рабочее решение. i = i++ выполняет постинкремент. Он устанавливает i равным значению, хранящемуся в i, а затем инкрементирует значение, которое раньше хранилось в i. Это то же самое, что и i=i. Получилось что-то вроде тавтологии.

Кажется, разработчик написал код и обнаружил, что тот не работает. Затем он стал добавлять случайные символы и всё же сделал так, чтобы код заработал. Он писал код как ChatGPT, только менее осознанно.

Заключение

От ошибок никто не застрахован. Это нормально: люди учатся на ошибках. Но куда проще, интереснее и безболезненнее учиться на чужих ошибках, а не на собственных, и The Daily WTF поможет вам в этом.

Сталкивались ли вы с такими же глупыми ошибками? Напишите об этом в комментариях или напишите для нас статью! 🙂

Все проходили через это — и проводили часы на StackOverflow из-за неправильных отступов, двоеточий и других банальных опечаток.

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

1. Неправильные отступы

В Python отступы используют не только для улучшения читаемости кода, но и чтобы обозначить, что к чему относится. Например, ниже можно увидеть два цикла. В первом случае print c текстом сработает после завершения цикла, а во втором, благодаря отступу, — на каждой итерации.

Здесь текст End of the cycle мы увидим при завершении работы цикла:

А тут — на каждой итерации цикла:

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

2. Зарезервированные слова для имён переменных

В Python есть список ключевых (или зарезервированных) слов, которые нельзя использовать в качестве имён переменных.

Если нарушить это правило, вы получите сообщение об ошибке SyntaxError: invalid syntax. Например, вот так делать нельзя:

3. Лишняя точка с запятой

В отличие от JavaScript, где точка с запятой используется для
отделения инструкций друг от друга, в Python она просто не нужна.

Это настолько частая ошибка, что многие интерпретаторы игнорируют «;» и выполняют код так, как будто её нет. Например, ниже можно
увидеть, что VS Code просто подсветил точки с запятой красным цветом.

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

4. Операторы «++» и «—»

Если вы начали учить Python после других языков программирования, можете удивиться, что в нём нет привычных операторов инкремента «++» и декремента «—». При их использовании вы увидите ошибку SyntaxError: invalid syntax.

Вместо этого для приращения значения переменной можно использовать оператор «+=» или просто переназначить её через «x=x+1».

Аналогично всё работает и при уменьшении значения переменной:

5. Отсутствие двоеточия

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

6. Неправильное копирование словарей и списков

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

Проблема в том, что благодаря оператору присваивания теперь
при изменении dict_b словарь dict_a тоже будет изменён.

Чтобы такого не происходило, нужно использовать методы copy()
или deepcopy().

Теперь мы видим, что изменения вносятся только во вторую
библиотеку.

7. Оператор «+» для конкатенации

«+» — простой и понятный для новичков оператор, но он не
всегда является самым эффективным решением для конкатенации. Чем больше строк вам нужно соединить в одну, тем больше плюсов придётся добавить, а это засоряет код. Поэтому для конкатенации лучше использовать f-строки.

Сравним два варианта на примере:

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

8. Злоупотребление импортом

Начинающие разработчики часто импортируют все имена из
модулей. Например, вот так:

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

Советуем импортировать конкретные имена, например, так:

9. Непонимание правил области видимости в Python

Работа областей видимости в Python основывается на правиле
LEGB (Local, Enclosing, Global и Built-in). Эта аббревиатура обозначает
локальный, вложенный, глобальный и встроенный уровни.

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

Казалось бы, всё просто, но не тут-то было. Такой код завершится с ошибкой UnboundLocalError: local variable‘someVar’ referenced before assignment on line 4:

Здесь вспоминаем правило LEGB. Сначала ищется переменная в
локальной области видимости, но someVar определена только после функции print, значит, выводить на экран нам нечего. Поэтому мы и получили ошибку.

Будьте внимательны при написании кода и не забывайте про
правило LEGB.

Подведём итоги

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

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

Один парень из моего чата в Telegram спросил меня: «Как я могу увидеть все внешние ключи, связанные с определенной таблицей?» Я дал ему быстрый ответ: «Посмотрите в `information_schema`». Я был полностью уверен в ответе, но всё равно решил убедиться лишний раз.

Я создал простую таблицу `test` и таблицу `ref1` с полем `test_id`, связанным с полем id:

Кажется, просто, потому что я люблю этот короткий синтаксис. После этого я посмотрел на таблицу информационной схемы `REFERENTIAL_CONSTRAINTS` и не нашел никаких записей.

Что за?! Это невероятно! Я люблю этот краткий синтаксис для создания внешних ключей и использовал его много раз!

Я создал еще одну связанную таблицу `ref2` используя стандартный синтаксис.

Снова проверил. И чудо свершилось! Я увидел запись в таблице `REFERENTIAL_CONSTRAINTS`. Как это возможно?

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

Теперь я думал, что если я попробую удалить первую строку из `test` то получу ошибку (я все еще сохраняю надежду на лучшее).

Но к моему ужасу MySQL спокойно удаляет эту строку без какого-либо предупреждения.  Как же так?! Мой мир рухнул. Я же постоянно использовал эту конструкцию в надежде, что целостность данных обеспечена.

Чтобы вернуть равновесие, делаю второй тест. Пытаюсь удалить вторую строку, связанную со второй таблицей.

И получаю долгожданную ошибку:

Итак, это не фича, это реальный БАГ!  MySQL позволяет создавать таблицы с использованием сокращенного синтаксиса без предупреждения, но ограничения не создаются и не защищают ваши данные от несогласованности.

Я поискал в Google и нашел открытую ошибку с 2004 года, которую до сих пор не исправили. Ребята, что вы делаете?

Для своего душевного спокойствия я решил запустить этот тест на других базах данных и обнаружил, что все базы данных, на которых я мог проверить на SQLize.online, позволяют использовать короткий синтаксис, и все они (MariaDB, PostgreSQL, SQL Server, Oracle) создают ограничения внешнего ключа в обоих случаях, кроме MySQL и SQLite.

Если Вам понравилась статья, Вы можете поддержать автора.

Компания OpenAI запустила конкурс “bug bounty”, поощряя пользователей находить  уязвимости в своих сервисах, включая ChatGPT.

Вознаграждение варьируется от 200 долларов за несерьёзные баги до 20 000 долларов за исключительные баги.

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

При этом вознаграждение за создание вредоносного кода или текста через ChatGPT не предусмотрено.

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

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

Такие сценарии поощряют чат-бота к ролевой игре в качестве его “злого двойника”, позволяя пользователю вызывать запрещенные ответы. К примеру, от злого двойника ChatGPT можно добиться инструкций по изготовлению оружия (категорически осуждаем).

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

Компания отмечает, что “решение таких проблем часто требует значительных исследований и более широкого подхода”, и сообщения о сбоях в ChatGPT следует отправлять через страницу обратной связи.

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

Например, в прошлом месяце хакер rez0 смог обнаружить 80 “секретных плагинов” для API ChatGPT. Это были ещё не выпущенные или экспериментальные дополнения для чат-бота. Rez0 отметил, что уязвимость была исправлена в течение дня после того, как о ней написали в Twitter.

Как тогда ответил один из пользователей в Твиттере: “Если бы у них только была платная программа #BugBounty, я уверен, что толпа могла бы помочь им поймать эти крайние случаи в будущем : )”.

Но дело в том, что предложение открывается в полноэкранном режиме. А если попытаться его скипнуть, вам предложат ввести данные карты.

Оказалось, что разработчики перепутали действие кнопок «Нет спасибо» и «Попробовать бесплатно».

Если вы столкнулись с проблемой, есть два способа её решить:

1. Нажать «Попробовать бесплатно» — окно закроется.
2. Железобетонный вариант — сначала оформить пробную версию, а потом отменить подписку, чтобы избежать списания 109 долларов в месяц.

Официально Microsoft пока не признала проблему, но ожидается, что сбой будет исправлен в будущем накопительном обновлении.

Не зря Microsoft изменили название «Моего компьютера» на «Этот компьютер». Ждём, когда уже честно назовут «Компьютер Microsoft».

Налейте любимый напиток в огромную кружку и украсьте понедельник мемами!

Ищем сотрудника. Кранчей (не) будет

«Если это календарь вам о чём-нибудь говорит, то просканируйте QR-код»

В комментариях обратили внимание на работу в выходные:

Немного о синдроме самозванца

«Не знаю, спроси у челов на Stack Overflow»

Эй, а в чём проблема с веб-разработкой?..

В погоне за KPI

Хорошо ведь, вышел в плюс получается

Постарайтесь не выгореть, любимые читатели!..

Хорошо, когда у джуна есть зарплата

Редкое фото, на котором джуниор получает свою первую зарплату:

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

Блокнот — тоже IDE?

Дорогая IDE, не лети впереди паровоза.

Вспомнил известный рассказ про Элизу. В рассказе код писали в тетрадке:

Опыт разработки — 71 год

Очень быстрый набор опыта

Но есть способ и похитрее:

Делитесь своими мемами под этой записью, и пусть ваш понедельник будет задорным. ?

Выглядит это так:

В данной статье мы рассмотрим наиболее популярные способы работы с ошибками в Golang.

1. Как обрабатывать ошибки в Go?
2. Создание ошибок
3. Оборачивание ошибок
4. Проверка типов с Is и As
5. Сторонние пакеты по работе с ошибками в Go
6. Defer, panic and recover
7. После изложенного

Как обрабатывать ошибки в Go?

Чтобы обработать ошибку в Golang, необходимо сперва вернуть из функции переменную с объявленным типом error и проверить её на nil:

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

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

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

Создание ошибок

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

• errors.New
• fmt.Errorf

Метод errors.New() создаёт ошибку, принимая в качестве параметра текстовое сообщение.

С помощью метода fmt.Errorf можно добавить дополнительную информацию об ошибке. Данные будут храниться внутри одной конкретной строки.

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

Оборачивание ошибок

Поскольку Error — это интерфейс, можно создать удовлетворяющую ему структуру с собственными полями. Тогда на вызывающей стороне этими самыми полями можно будет оперировать.

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

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

Также для оборачивания ошибок в fmt.Errorf есть плейсхолдер %w, который и позволяет произвести такую упаковку.:

Проверка типов с Is и As

В Go 1.13 в пакете Errors появились две функции, которые позволяют определить тип ошибки — чтобы написать тот или иной обработчик:

• errors.Is
• errors.As

Метод errors.Is, по сути, сравнивает текущую ошибку с заранее заданным значением ошибки:

Если это будет та же самая ошибка, то функция вернёт true, если нет — false.

errors.As проверяет, относится ли ошибка к конкретному типу (раньше надо было явно приводить тип ошибки к тому типу, который хотим проверить):

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

Сторонние пакеты по работе с ошибками в Go

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

В качестве примера можно посмотреть на пакет pkg/errors. Одной из его способностей является логирование stack trace:

Defer, panic and recover

Помимо ошибок, о которых позаботился разработчик, в Go существуют аварии (похожи на исключительные ситуации, например, в Java). По сути, это те ошибки, которые разработчик не предусмотрел.

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

Для работы с такими ошибками существует механизм «defer, panic, recover»

Defer

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

Panic

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

Например, Golang будет «паниковать», когда число делится на ноль:

Также панику можно вызвать явно с помощью метода panic(). Обычно его используют на этапе разработки и тестирования кода — а в конечном варианте убирают.

Recover

Эта функция нужна, чтобы вернуть контроль при панике. В таком случае работа приложения не прекращается, а восстанавливается и продолжается в нормальном режиме.

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

После изложенного

Можно ли игнорировать ошибки? В теории — да. Но делать это нежелательно. Во-первых, наличие ошибки позволяет узнать, успешно ли выполнился метод. Во-вторых, если метод возвращает полезное значение и ошибку, то, не проверив её, нельзя утверждать, что полезное значение корректно.

Надеемся, приведённые методы обработки ошибок в Go будут вам полезны. Читайте также статью о 5 главных ошибках Junior-разработчика, чтобы не допускать их в начале своего карьерного пути.

Преимущества использования исключений сомнительны, но мои претензии к ним не в этом. Исключения — экстраординарный инструмент, которые делает код более непонятным и запутанным. А прямую локальную обработку — слишком пространной. Исключения стали для меня худшим средством обработки ошибок. Печально, что создание объектов в С++ основано на их применении (позднее этот пост был отредактирован — прим.пер.).

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

Предупреждение. Если вы являетесь страстным поклонником исключений: я не выступаю против их использования.Предупреждение. Если вы являетесь ярым приверженцем политики отказа от применения исключений: я не призываю к их использованию.

Проблема

Самый очевидный способ обработки ошибок — это возврат значений. Но конструкторы не возвращают значения, поэтому так поступить нельзя. Это и было одной из причин, по которой исключения появились в С++.

Однако есть несколько способов возврата значения из функции. Например, можно использовать выходные параметры:

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

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

Если возврат вызова конструктора был успешным, то объект считается валидным. Это делает возможной идиому RAII («Получение ресурса есть инициализация» — прим.пер.). Рассмотрим класс, в распоряжении которого есть некий ресурс. Конструктор получает его, а деструктор разрушает. Мы хотим обеспечить выполнение гарантии непустого объекта (never-empty guarantee): каждый объект класса должен иметь ресурс.

Допустим, мы решили проблему семантики переноса. Тогда мы легко можем создать конструктор:

Благодаря гарантии это обеспечивает каждый объект ресурсом. Когда генерируется исключение, объекта не существует.

Всё это недоступно вам, если вы используете выходной параметр, чтобы установить код ошибки. Тогда деструктору приходится иметь дело со всеми возможными состояниями ошибки. А пользователь должен соблюдать осторожность и не использовать объект в состоянии ошибки. Это делает невыполнимой гарантию непустого объекта. Каждый объект имеет по крайней мере два состояния: валидное и невалидное.

Обход проблемы

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

Поэтому самый лёгкий способ обработки ошибок в конструкторе — это просто не пользоваться исправимыми техниками обработки ошибок. Используйте методы, не допускающие продолжения работы программы. Такие как, например, сообщение в stderr и вызов abort( ).

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

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

Также можно использовать метод, который я окрестил обработчиком исключений (exception handler). Но его можно применить, только если отключить исключения с помощью оператора if.

Но, это всё только пути обхода проблемы. Так давайте же решим её.

Решение

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

Подождите, дайте мне сказать.

Я не предлагаю функцию init( ) или что-то вроде неё. Если вы примените её, то потеряете все гарантии RAII, а также, наверное, вам придётся вызывать функцию destroy( ), так как для невалидных объектов будет вызван деструктор. И тогда с таким же успехом можно написать API для Си.

RAII нетрудный, делает жизнь намного легче и не имеет недостатков — если не считать ситуацию с исключениями в конструкторе.

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

По сути, есть два шага. Первый — выделить свободную память для объекта. Второй — вызвать конструктор для создания объекта в этой области памяти. Если на втором шаге выдаётся исключение, вводится раскрутка стека. Или планируется вызов деструктора.

Так же работает подход с применением методов init( ) и destroy( ): конструктор объекта ничего не делает, поэтому компилятор только выделяет память. И на самом деле init( ) и destroy( ) затем создают объект.

Но мы не хотим создать два состояния отдельно от самого объекта. Каждый созданный объект должен быть валидным. Вся сложность невалидного состояния и проблемы, которые она с собой несёт, должна быть передана куда-нибудь в другое место. Нам нужна оболочка, которая будет представлять нам невалидное состояние, когда объект отсутствует.

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

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

Теперь каждый раз, когда мы получаем объект, он гарантированно валидный. Невалидный объект передаётся туда, где его обработка может быть выполнена лучшим образом. Таким образом каждой функции-члену и деструктору нет необходимости иметь дело с невалидным объектом. Так, до тех пор, пока функция make( ) только создаёт объекты, то есть вызывает конструктор, ничего не может пойти не так.

Лучшее представление отчёта об ошибках

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

Лучшим решением могла бы стать интеграция c возвращаемым значением. Вместо возвращения optional, используйте класс «значение или ошибка». Предлагаемый здесь std::expected делает это и позволяет обрабатывать ошибки более элегантным способом.

А как насчёт конструкторов копирования?

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

Есть два решения: не поддерживать операции копирования и только перемещать — что обычно удаётся — или применить тот же метод снова. Предусмотреть статическую копирующую функцию, которая делает то же самое, возвращает optional/expected, и так далее.

Заключение

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

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

Опыта тогда у меня было немного (1,5 года QA Automation). Но программистов опытнее в команде первое время не было. И вот на первом же планировании ко мне приходят с пачкой задач, чтобы я выставил им оценки.

Одной из таких задач была сквозная аутентификация LDAP с сервером Active Directory, чтобы пользователи не вводили пароль при входе в приложение, единожды привязав свою учётку Windows. Немного подумав, я указал, что потребуется всего лишь 5 дней. Тогда я не осознавал всей сложности оценки задач и тленности бытия, но заботливый project manager увеличил срок до 10-15 дней. Да, тогда ещё не было модных story points, мы водопадили как могли.

Разработка тихого монстра

Задача прилетела в работу через месяц. К этому времени я уже немного размялся на формошлёпстве и почитал про LDAP. Первый прототип получился за 1-2 недели.

Он состоял из небольшого количества JS-кода и двух простейших AJAX-запросов на фронте, а также одного простенького servlet’a на бэке. Использовал я SPNEGO/Kerberos, найдя какую-то захудалую JAR’ку в интернете.

При входе пользователя в систему его перекидывало на login-форму, там то фоном и шёл один из AJAX-запросов, который проверял, кто пришёл и привязана ли его учётка Active Directory к учётной записи в приложении.

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

Прототип заработал локально и на dev-стенде. Он даже уже заработал у всех трёх программистов в кабинете и у аналитика из соседнего кабинета. Поэтому мы решили, что дело идёт к релизу. Но вдруг выяснилось, что у PM’a ничего не работает, а он территориально находился в Перми в то время как мы находились в Екатеринбурге. Мы по классике схлестнулись в битве «Но на моём компе же работает!», тем более таких компьютеров было аж 4.

Так, протестировав нашу поделку на ещё нескольких людях из разных регионов, мы уже поняли, что у нас может быть не один домен AD, а несколько, под каждый регион свой, и домены могут быть двух-, трёх-, четырёхуровневыми. С этими познаниями и ощущениями боли мы ушли ещё на 2-4 недели доработок. В итоге мы худо-бедно прошли ПСИ, на котором были некоторые проблемы несовместимости с IE, и пошли с нашей классной фичей и некоторыми доработками в ПРОМ.

Серые тучи несовместимости

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

У большинства пользователей фича не просто не работала, но и крашила все приложения. В основном это было связано с очень старыми версиями IE и Windows на компьютерах сотрудников. Ведь тестировал-то всё это дело ИТ-отдел, а у нас у всех свежая винда, обновления, браузеры.

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

Так вот, поговорим про баги и их фиксы или безысходность.

• Кого-то из пользователей просто бесконечно редиректило по кругу на странице login’a. Был написан фикс, который отслеживал такие частые редиректы и правил хедеры в запросе и дальнейшую логику поведения.
• Кто-то не мог заводить заявки и работать с документами. Всё это происходило, т.к. IE начинал пихать ненужные хедеры аутентификации в запросы к статике и бэку (это было видно по логам nginx) и сам же от этого помирал. Были и другие проблемы совместимости.
• Но были и те, у кого всё хорошо работало, но не работала сама сквозная аутентификация, а они её очень хотели, удобно же — залогинился в Windows и больше ничего вводить не надо, киллер фича!

Каждый день мы собирались на совещания с видеосвязью, и пользователи стримили нам свою боль. Через месяц таких мучений был написан подробный гайд о том, как настроить свой IE или Chrome для успешной работы, какие галочки снять, какие поставить, какие настройки поменять в ОС. Занимал он примерно две страницы в Word-документе.

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

За всё время работы в компании я периодически мониторил метрики использования данной фичи. Вроде как успешно ей пользовалось не более 5-10% пользователей. Надеюсь, теперь у большинства пользователей эта аутентификация работает. Или хотя бы не мешает им жить. Ещё надеюсь, что я немного сгустил краски и на самом деле всё было не так плохо.

В итоге эти запланированные 10 дней вылились в 1-2 месяца насыщенной разработки и настройки и ещё в полгода-год болезненной поддержки.

***

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

Если вам понравилась эта история, проголосуйте за неё.

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

А вот история другого участника — он написал кастомный шрифт ради одного символа. Но сначала неделю страдал.

В нашем приложении метод processEntity, конечно, был сильно сложнее, но я убрал всё, что не имеет отношения к делу. Код прошел ревью у опытного разработчика, да и автора неопытным назвать нельзя. Этот код сложно назвать образцом, но проблема здесь вовсе не в красоте или чистоте.

Этот код — часть приложения, которое уже года три как собираются декоммитить. Это приложение — GUI, написанное на дореволюционной технологии. Там null-значения несут бизнес-ценность, null означает «не отображать ничего». А то, что DTO-отображения используются в бизнес-логике, — так исторически сложилось и улучшать это ресурсов и желания нет.

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

Самое первое, что я начал проверять — когда valueProcessor может быть null. Через минут 15 я понял, что этого быть не может никогда. И даже после этого я не верил, что что-то ещё в этой строке не так.

Сейчас, когда я знаю проблему, я кажусь себе очень глупым. Как я мог не увидеть такой очевидный баг?! Но когда искал, я его в упор не видел. Что делают плохие программисты, когда код не работает? Правильно, перезапускают его! Но я потерян не полностью, я догадался выделить локальную переменную:

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

Я мог бы поставить брейкпоинт в IDE на выброс любого NPE, но локальной переменной оказалось достаточно. Даже моя любимая IDE мне подсказывала — она создала переменную примитивного типа, чему я не придал значения, мой мозг упростил всё — «ну проверка на null же есть».

Но на деле entity.value1 возвращала null, а тернарный оператор приводил null к примитивному long.

Я поигрался с разными вариациями: объявил переменную Long, поменял местами операнды, гуглил и в итоге почитал JLS. И вот там-то я нашёл очень подробное описание зависимости типов от операндов.

Я перечитал JLS пару лет назад, но не вспомнил о том, что существует такая особенность у тернарников. Плохо это или нет, мне сложно сказать. Я бы так никогда не написал. Вообще стараюсь обходиться примитивными значениями, возможно, поэтому я встретился с такой проблемой впервые. Если бы в этом приложении были тесты или хотя бы кто-то развивал его, то, скорее всего, я бы не встретил эту особенность.

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

А какие очевидные баги вы долго не могли обнаружить в коде?

Здесь система, по сути, сообщает нам, что произошла ошибка. Больше никакой информации из этого текста мы не получим. Разве что узнаем, что где-то в недрах самой системы существует какой-то метод, который что-то не то вернул. Ценность этого знания для обычного пользователя нулевая.

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

Давайте порассуждаем, каким должно быть идеальное сообщение об ошибке.

5 основных правил

В книге Сьюзан Уэйншенк «100 главных принципов дизайна» приведены основные правила написания информативного и полезного сообщения об ошибке:

1. Расскажите пользователю, что он сделал.
2. Объясните проблему.
3. Объясните, как исправить ошибку.
4. Используйте активный, а не пассивный залог.
5. Приведите пример.

В книге есть пример того, как не надо писать сообщения об ошибке:

#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.

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

А ещё хуже можешь?

«Вы хотите отправить разработчикам отчёт об ошибке в приложении?»«Ok»«Ну и ябеда!»

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

Счёт не может быть оплачен. Введены неправильные данные.

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

Счёт не может быть оплачен.

Теперь приблизимся вплотную к нашему почти нулевому варианту:

Ошибка выполнения метода bill_payment.

Дальше для достижения антиидеала нам остаётся только убрать название метода и творчески преобразовать текст:

Неизвестная ошибка.

Интересно, не возникло ли у вас чувство дежавю, когда вы читали примеры в этом подразделе?

Добавляем информацию

В случае возникновения критической ошибки обновления:1. Установите причину ошибки.2. Устраните причину ошибки.Документация Microsoft

Теперь давайте двигаться в другую сторону по нашей шкале — будем постепенно улучшать текст сообщения, руководствуясь правилами Сьюзан Уэйншенк.

Напомню исходный вариант сообщения из книги:

#402: до того как счёт может быть оплачен, необходимо, чтобы дата платежа была позднее, чем дата создания счёта.

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

#402: Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.

Теперь расскажем пользователю, что он сделал не так:

#402: Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Для оплаты счёта необходимо, чтобы дата платежа была позднее, чем дата создания счёта.

Выделим суть проблемы в отдельное предложение и явно объясним пользователю, что он должен сделать, чтобы её решить.

#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа — она раньше, чем дата создания счёта. Измените дату платежа так, чтобы она была позднее даты создания счёта.

Наконец, приведём конкретный пример. В данном случае нам известны даты и мы их можем использовать в тексте:

#402: Ошибка оплаты счёта. Вы ввели неправильную дату платежа 25.07.2021 — она раньше, чем дата создания счёта 29.07.2021. Измените дату платежа так, чтобы она была позднее даты создания счёта 29.07.2021. Например, 30.07.2021.

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

Лучшее сообщение об ошибке

Ошибка выполнения метода: «Метод выполнился без ошибок».

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

В нашем примере никто не мешает разработчику сделать две вещи:

1. При смене даты счёта очистить поле с датой платежа.
2. В интерфейсе запретить ввод даты платежа позже заданной даты счёта.

Эти незначительные изменения в коде позволят избежать ошибки вовсе. И не нужно будет ломать голову над текстом сообщения.

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

А с какими загадочными сообщениями об ошибках сталкивались вы?

Проблема №1: Программист ошибся в оценке объема работ и просит расширения

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

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

Решение

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

Проблема №2: Программист ошибся при выборе технологии, что негативно сказалось на проекте

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

Решение

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

Проблема №3: Код, написанный одним программистом, непонятен другому и требует много времени на изучение

Большая часть программирования – это работы по улучшению существующей кодовой базы или её полное переписывание. Самые успешные кодовые базы в мире были разработаны сотнями людей, которые никогда не встречались друг с другом. У многих из этих проектов было очень мало документации (или вообще не было), отсутствовали комментарии в кодовой базе, рекомендации или помощь.

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

Решение

Профессионалы должны принимать такие ситуации и вызовы, чтобы оправдывать звание настоящего программиста!

Проблема №4: Новый программист на проекте критикует предыдущего и рекомендует переделать всё с нуля

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

Решение

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

Проблема №5: программист просит выделить время на переработку своего кода и устранение дефектов, которые не видны пользователям системы

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

Решение

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

Из опыта и рекомендаций:

• не забывайте повторно факторизовать код, которого вы касаетесь;

• удаляйте устаревший код;

• просите перефакторинг каждый раз, когда вас просят проверить изменение кода.

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

При попытке загрузить списки пакетов из репозитория и «обновить» их с помощью apt update, пользователи наблюдают следующую картину:

404 ошибка преследует их и при попытке скачать эти пакеты заново. Сообщается, что проблема затронула вообще все версии Ubuntu, а не какие-то определённые.

В ответ на первое сообщение в треде, пользователь charliemenke отметил, что не может скачать не только Ubuntu, но и Debian-пакеты:

Проблема оказалась настолько массовой, что её обсуждение началось даже на Hacker News. Пользователь ресурса заявил, что проблема встречается не в первый раз — ранее пользователи также не могли обновить пакеты при использовании Ubuntu через Azure.

Microsoft пока никак не прокомментировала случившееся.

Ошибка ошибке рознь

Представьте себе, что вы работаете над довольно сложной программой. Например, с мудрёными математическими расчётами. Вы её компилируете, запускаете в первый раз, она выдаёт ожидаемый результат и работает без ошибок.

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

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

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

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

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

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

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

1. 1900 год, всё ещё високосный

Самое неприятное — когда ты в своей программе случайно находишь явную ошибку, исправляешь её и программа после этого перестаёт работать.bash.im

В 1983 году компания Lotus Software выпустила для компьютеров IBM PC своё знаменитое приложение для работы с таблицами, которое называлось «Lotus 1-2-3». В своё время эта программа считалась самым надёжным и быстрым табличным процессором. К сожалению, она содержала маленькую, но очень серьёзную ошибку.

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

В 1995 году компанию Lotus Software приобрела фирма IBM, но к тому времени уже набирал свои обороты Microsoft Excel. Многие пользователи переходили с Lotus 1-2-3 на Microsoft Excel, а это значит, что нужно было обеспечить их совместимость. Именно для обеспечения совместимости разработчики Microsoft приняли осознанное взвешенное решение аккуратно транслировать эту ошибку в пакет Microsoft Office.

Как утверждали сотрудники Microsoft, недостатки, которые могут возникнуть при исправлении этой ошибки, значительно перевешивают преимущества. Её исправление привело бы к тому, что изменились бы данные в тысячах файлов пользователей Excel.

Вы можете спросить: «Кто же использует в своих таблицах даты в начале XX века?» Оказалось, что исправление ошибки затронет и другие даты. Как написано на сайте Microsoft, если ошибку исправить, то «почти все даты в текущих Microsoft Excel и других документах будут уменьшены на один день».

Считается, что исправление ошибки повлияет на даты после 1 марта 1900, поэтому Microsoft не хочет рисковать, ведь книг Excel с такими датами «сотни тысяч». Кроме того, «исправление этого поведения нарушает совместимость последовательной даты между Microsoft Excel и другими программами, которые используют даты». Это тоже может стать проблемой для пользователей.

В некоторых источниках утверждается, что эта ошибка была исправлена ещё в 2007 году, но в моём рабочем Excel 2016 она всё ещё воспроизводится. Проведём эксперимент: если у вас есть Excel, откройте новую таблицу и введите в ячейки две даты: 29.02.1900 и 29.02.1901. Первая тут же выравнивается по правому краю, а значит Excel воспринимает эту строку как валидную дату. Вторая дата так и останется строкой — такой даты не бывает даже по версии Lotus. Так что баг, о котором известно уже больше 30 лет, всё ещё с нами.

2. Рассеянный процессор

Не печалься, Барт, все совершают ошибки. Просто твои публичные и дорого стоят.Гомер Симпсон

Мы все давно привыкли к тому, что сложные математические программы могут содержать ошибки. Это, конечно, неприятно, но этого можно ожидать. Где-то программист забыл перевести градусы в радианы, где-то ошибся в размерности. Такие баги бывают и их несложно исправить — главное вовремя их отловить.

Но когда речь заходит о процессоре, ошибок в расчётах мы никак не ожидаем. Мы твёрдо верим, что уж на аппаратном уровне всё должно быть чётко и надёжно. К сожалению, так бывает далеко не всегда. Довольно широкую известность получила ошибка, возникавшая при выполнении операций над числами с плавающей запятой в процессорах Intel Pentium. Этот баг обнаружили и обнародовали в 1994 году.

Процессор при использовании ассемблерной команды FDIV в некоторых случаях неправильно делил одно число на другое. Не всегда, только для определённых чисел, но, согласитесь, что это слабое утешение. Одно дело, если деление выполнено неправильно при расчёте домашнего бюджета. А если это расчёт траектории спутника?

Вот очень наглядный пример:

• 4195835 / 3145727 * 3145727 = 4195835 — правильный расчёт;
• 4195835 / 3145727 * 3145727 = 4195579 — то, что выдавал процессор Intel.

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

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

Замена процессора — дело хлопотное. Так что программисты исправили проблему самым простым доступным им способом: в компиляторах Delphi и Visual Basic была добавлена проверка наличия этой ошибки и её автоматическое исправление на уровне приложения. Если ошибка обнаруживается, то программа просто корректирует результат выполнения операции FDIV. Конечно, это несколько замедляет работу приложений, но правильный результат дороже.

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

3. Купертино с нашими итальянскими товарищами

— Тупой словарь: «калевалу» знает, а «коленвал» — нет.— Он не тупой, просто гуманитарный.bash.im

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

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

В английском языке есть вполне обычное слово «cooperation» — «сотрудничество». По правилам английского языка его можно написать и так: «co-operation». В моём словаре Lingvo есть обе версии написания. Соответственно, и программы проверки орфографии английских текстов должны содержать оба варианта.

К сожалению, долгое время в некоторых приложениях (например, в Microsoft Word примерно с 1989 года) вариант «cooperation» в списке правильных слов отсутствовал. В общем-то, ничего страшного в этом бы не было, если бы умная система не предлагала заменить вариант «cooperation» на «Cupertino» — название города в Калифорнии.

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

Вот вам несколько примеров:

• Купертино с нашими итальянскими товарищами было очень плодотворным.
• Азиатская ассоциация регионального Купертино.
• Презентация афро-немецкого Купертино.

Эта ошибка была настолько распространена, что даже получила своё собственное название: «эффект Купертино». Есть и другие примеры подобных автозамен в английском языке. Американский лингвист Бенжамин Зиммер даже коллекционирует такие случаи. В его коллекции есть пример публикации из газеты New York Times, в которой вместо «Voldemort» написано «Voltmeter».

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

4. Очень умный ксерокс

— Добрый день, а у нас ксерокс не печатает.— Он и не должен печатать, он делает копии.— Ой, да, спасибо!bash.im

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

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

Но устройства усложнялись, появились МФУ, в которых уже была встроена довольно сложная программная начинка. Видимо, в этом и заключалась причина ошибки, которую в 2013 году обнаружил немец Дэвид Крисель в МФУ фирмы Xerox.

Совершенно случайно Дэвид заметил, что при ксерокопировании некоторых документов с цифрами устройство периодически заменяло цифру «6» на «8», а цифру «2» на «1». Согласитесь, что это крайне странное поведение для ксерокса. Тем более, что в нём был отключён алгоритм распознавания текста и пользователь выполнял простое ксерокопирование.

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

Понятно, что распознавание текста позволяет существенно сжать исходный файл. Другой вопрос, зачем этот алгоритм применялся при простом ксерокопировании. Интересно, что при недостаточном качестве сканирования алгоритм может заменить ещё и «2» на «7» или даже «1» на «3».

Компания Xerox повела себя аналогично Intel — не сразу признала свою ошибку. Поупиравшись какое-то время, Xerox всё-таки выпустили обновлённую прошивку для своих устройств. Но многочисленные пользователи должны её скачать и установить, а это делают далеко не все.

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

5. Ядерный Ганди

Кстати, о «Цивилизации». Поначалу мне нравилась третья часть, до того самого момента, как рота элитных мушкетёров, окопавшихся в городе, сбила ракету с ядерной боеголовкой.bash.im

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

По легенде в ранних версиях популярной стратегии Sid Meier’s Civilization существовала ошибка, из-за которой один из самых миролюбивых лидеров цивилизаций Махатма Ганди при определённом стечении обстоятельств превращался в самого агрессивного персонажа и не задумываясь использовал ядерные боеголовки против других цивилизаций.

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

Для Ганди, понятное дело, по умолчанию был установлен минимальный уровень агрессии — 1. При переходе к демократии уровень агрессии по игровому алгоритму снижался на два пункта. Уровень агрессии Ганди при этом должен был стать отрицательным, но для хранения этого показателя использовалась однобайтовая беззнаковая целочисленная переменная. А это означало, что после такой операции уровень агрессии становился равным 255. Из-за этого бедный Ганди становился в 25 раз более агрессивным, чем самые отрицательные лидеры в игре.

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

Миф об этой ошибке появился примерно в 2012 году и постепенно стал распространяться в сети.
В итоге разработчики решили пошутить и специально добавили эту ошибку в качестве пасхалки в новую версию игры Sid Meier’s Civilization V. В ней Ганди остался таким же незлобливым и миролюбивым, как Нед Фландерс в сериале «Симпсоны», но при этом вероятность создания и применения ядерного оружия у него установлена максимальная — 12. Это самое больше из возможных значений.

Так ошибка под названием «Ядерный Ганди» из мифа стала реальностью. А ещё это источник множества мемов в сети. Сам же Махатма Ганди был очень мудрым человеком. Когда-то он сказал: «Ценность идеала в том, что он удаляется, по мере того как мы приближаемся к нему».

Программисты могут своим опытом подтвердить эти слова — идеальных программ не существует, в них всегда будут ошибки.

Так, при попытке зайти на официальную страницу Кремля, пользователи сталкивались с рядом проблем. Например, они видели ошибку 403, сообщает TJ:

То же самое происходило и при открытии сайта ТАСС.

Но хуже всего пережили объявление президента ресурсы РЖД. Так, помимо самого сайта, проблемы наблюдались и в мобильном приложении госкомпании. Об этом написало РИА Новости.

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

Источник: TJ, РИА Новости

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

После тщательного изучения [ситуации] мы можем подтвердить, что игрок t0st действительно раскрыл аспект игрового кода, связанный со временем загрузки ПК-версии GTA Online, который можно было бы улучшить. В результате мы внесли некоторые изменения, которые будут реализованы в предстоящем обновлении.

Напомним, что в конце февраля 2021 года пользователь под ником t0st рассказал об ускорении загрузки GTA Online.

Как оказалось, главной причиной замедления процесса было использование одного потока процессора для обработки 10 МБ JSON-файла. И всё это он выяснил и исправил, не имея доступа к исходному коду самой игры.

Источник: The Verge

Издание отмечает, что блокировка происходила автоматически. Это может означать, что слово на букву «M» каким-то образом попало в «чёрный список» автоматической системы фильтрации контента Twitter.

Пользователи предположили, что блокировка аккаунтов связана с тем, что футболист Мемфис Депай (Memphis Depay) зарегистрировал своё имя как товарный знак. Но журналисты сразу же отметили, что будь оно так, то пользователи платформы не могли бы использовать и прочие популярные названия (например, Coca-Cola, Apple, Google).

Сама соцсеть никак не прокомментировала случившееся. Она лишь молча, без дополнительного шума, исправила баг. На запрос The Independent представители компании отвечать не стали.

Источник: The Independent

9 сентября 1945 года тестировщики электронного компьютера Harvard Mark II обнаружили застрявшего в реле мотылька, который остановил работу машины. Грейс Хоппер внесла в журнал запись и прилепила к ней эту моль. С тех пор разработчики стали называть ошибки «багами» («жук» — англ.), а 9 сентября стал днём бага — или тестировщика.

Баг в игре, спасший GTA

В 1995 году ребята из студии DMA Design потёрли руки и взялись за разработку игры с рабочим названием Race’n’Chase. По задумке, здесь можно было ходить пешком и выполнять задания за полицейского или грабителя. Они планировали выпустить её за 18 месяцев. Однако концепция оказалась настолько скучной, что тестировщики задыхались от зевоты. После этого разработка приостановилась. Разработчики то возвращались к ней, то снова оставляли. Проект не сдвигался с мёртвой точки, и издатель уже подумывал вовсе его закрыть.

Всё изменил один баг в игре. Сломалось просчитывание пути у полицейских: при погоне они больше не объезжали игрока, а пытались просто проехать через него. Полицейские-психопаты добавили игровому процессу драйва и очень понравились тестировщикам. Разработчики переименовали игру, дошлифовали поведение копов, и в октябре 1997 года вышла Grand Theft Auto. А в начале 2002 года студия DMA Design была куплена и переименована в Rockstar North.

Файтинги могли быть без комбо-ударов?

Согласитесь, нет ничего лучше, чем отвесить сочное комбо на треть здоровья, играя в какой-нибудь Mortal Kombat с друзьями. Этим мы тоже обязаны игровому багу. На этот раз — в Street Fighter 2.

Его обнаружили во время теста бонусного уровня, в котором нужно разбить машину за отведённое время. Продюсер проекта Нориката Фунамидзу заметил, что если правильно подобрать момент, то можно прервать анимацию атак и нанести несколько ударов быстрее обычного. Разработчики не спешили это исправлять, так как подумали, что игроки не станут заморачиваться из-за сложности приёма.

Игра вышла в 1991 году, обрела всемирную популярность, а участники соревнований по Street Fighter 2, конечно же, обнаружили особенность анимации и активно её использовали. После этого разработчики создали специальную систему комбо-ударов. Так баг игры стал культовой фичей, определяющей жанр файтинга по сегодняшний день.

Искусство распрыжки: как появился strafe-jumping

Если вы играли в Counter-Strike или Quake, то скорее всего видели, как некоторые ребята перемещаются по карте прыжками и при этом постоянно ускоряются. Вы уже наверное догадались, что и здесь не обошлось без бага.

Снова возвращаемся в 1996 год: id Software работают над первым Quake и допускают ошибку в движке Quake engine. При одновременном движении вперёд и в сторону (например при нажатии W+A), игра просто складывает векторы. В результате игрок бежит примерно в 1,4 раза быстрее по диагонали, чем по прямой. Вот как это выглядит:

За много лет движок использовался разными компаниями. Сами id Software решили не исправлять этот баг, и он перекочевал в другие игры (например Half-Life, и как следствие — Counter-Strike). С выходом Quake 3 в 1999 году игроки обнаружили, что если добавить к диагональному бегу прыжок и правильное движение мышью, то можно разогнаться до больших скоростей. Это было возможно из-за того, что максимальная скорость ограничена значением не самого вектора скорости, а его проекции.

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

Баг в игре Team Fortress, когда друг оказался вдруг…

Хороший игрок прекрасно знает, что просто облачиться в шкуру врага недостаточно для обмана. Чтобы оставаться незамеченным как можно дольше, нужно имитировать его поведение. Так вот, шпионство в мультиплеере началось с того, что трое австралийских разработчиков в 1996 году создали мод для Quake, который назвали Team Fortress.

Они обнаружили баг в игре, из-за которого имя игрока, отображаемое при наведении прицела, окрашивалось в цвет вражеской команды. Благо, разработчики решили не просто пофиксить его (хотя запросто могли). Они развили идею, которую подкинул им баг, и создали целый класс — шпиона. Он мог превращаться во врагов и устраивать диверсии в их тылу. Дальше только история: TF стал сначала модом для Half-Life, а в 2007 вышла полноценная игра Team Fortress 2, которая обрела широкую популярность.

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

Самый настоящий баг

Топ багов откроет случай 9 сентября 1945 г. 75 лет назад учёные Гарвардского университета, тестировавшие электромеханический компьютер Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами реле. Он вызывал короткое замыкание, что приводило к неправильной работе машины.

Насекомое было извлечено и вклеено в дневник с сопроводительной подписью «Первый реальный случай обнаружения бага». От этого случая и пошло слово bug, а этот день стал днём бага (и заодно днём тестировщика).

Y2K — проблемы тысячелетия

Проблема Y2K ещё известна как «проблема 2000 года». Разработчики ПО в XX веке часто использовали для обозначения года в датах две последние цифры вместо привычных четырёх. Например, 7 апреля 1994 года представлялось как «07.04.94».

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

1 января 2000 по всему миру начали происходить локальные конфликты и сбои в системах. В некоторых городах даже начало пропадать электричество, отопление, часть вычислительных центров просто зависала. Всё это произошло из-за сокращения формата года. После 1999 года наступил 2000, но для машин этот год воспринимался как 1900 (у некоторых даже как 19100). Такая ошибка послужила причиной зависаний во многих системах.

img class=”wp-image-133888 size-full” src=”https://media.tproger.ru/uploads/2020/09/Bug_de_lan_2000.jpg” alt=”Электронное табло, неправильно отображающее год ” width=”640″ height=”480″ />

Однако никакой масштабной мировой катастрофы не произошло благодаря тому, что разработчики начали задумываться об этой проблеме заранее. По некоторым оценкам, на подготовку к 2000 году общие мировые затраты составили 300 млрд. долларов.

Ping of Death

Так назывался тип сетевой атаки, распространённый в середине 1990-х годов. Её суть заключалась в том, что компьютер-жертва получал особый эхо-запрос (ping), после которого машина намертво зависала. Эта уязвимость встречалась на многих ОС, включая Windows, Unix, Linux, Mac.

По стандарту протокола IPv4 объём передаваемого пакета не может быть больше 65 535 байт. Превышение этого размера вызывало у принимающего компьютера переполнение сетевого стека.

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

Эта уязвимость в большинстве систем была исправлена в конце 90-х.

Торговля — трудное ремесло

В самом начале на Amazon можно было заказать отрицательное количество товара. В таком случае при покупке деньги не списывались, а зачислялись на карту клиента. Такая глупая ошибка случилась из-за того, что разработчик магазина Джефф Безос старался как можно чаще выпускать обновления для своего сервиса и у него не хватало времени на его отладку.

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

Примитивные баги в программах случались и в других интернет-магазинах. Иногда можно было выставить в поле «Количество товара» значение 0,01 и тем самым получить скидку на товар в 99%. А в некоторых сервисах персональные данные хранились в файлах cookie. Можно было изменять ID покупателя и совершать покупки от другого лица.

Падение телефонной линии AT&T

Один из 114 коммутаторов AT&T был механически повреждён. Он отправил сообщение о поломке другим АТС, а те, в свою очередь, соседним. Запустилась цепная реакция, которая положила телефонную сеть на 9 часов, из-за чего 60 тыс. человек остались без связи.

Причина была в недавнем обновлении ПО для АТС. Теперь, если ломался один из коммутаторов, он посылал об этом сообщения соседним коммутаторам, чтобы те перехватывали его трафик. Тогда другие коммутаторы должны были перезагружаться в новый режим работы и периодически проверять, не заработал ли первый.

Однако из-за бага в коде неисправный коммутатор высылал по два сообщения. Второе сообщение достигало других коммутаторов прямо во время их перезагрузки. Из-за этого они начинали думать, что сами неисправны и рассылали сообщение дальше по цепи. Таким образом, словно домино, упала целая сеть. Общие потери компании составили примерно 60 млн. долларов.

Взрыв ракеты Ariane 5 из-за переполнения переменной

Авария ракеты-носителя «Ариан-5» произошла 4 июня 1996 г. Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового ПО. Этот баг в системе — самый дорогостоящий в нашем топе багов и вообще в мире — его ущерб оценивается от 360 до 500 млн. долларов. В результате аварии были также потеряны 4 спутника Cluster.

Во время разработки бортового программного обеспечения некоторые фрагменты кода были взяты из ПО предыдущей удачной Ariane 4. Однако софт так и не протестировали в новом окружении. После старта ракеты её модуль попытался просчитать определённое значение, исходя из горизонтальной скорости ракеты. Так как эта скорость у Ariane 5 была намного выше, чем у предыдущей версии, это вызвало переполнение переменной, что, в свою очередь, повлекло ошибки. На борту была запасная система управления, но т. к. в ней было идентичное ПО, ошибка повторилась.

Работы над строительством ракеты велись на протяжении 10 лет, а на разработку было потрачено 7 млрд. долларов.

Податливый Microsoft Bob

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

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

Microsoft Bob достаточно сильно критиковался СМИ. В журнале PC World эта ОС получила 7-е место в списке «25 худших продуктов всех времён», а в списке худших продуктов десятилетия от CNET.com она заняла 1-е место.

Шерстяной баг

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

На компьютере стоял LightDM — менеджер входа в систему. Именно он появляется при запуске ОС, где предлагает выбрать пользователя и ввести его пароль. Кошка, сев на клавиатуру, зажала какие-то из клавиш. Это и привело к зависанию системы.

Это происшествие не стало бы таким популярным, если бы разработчики не признали этот баг из-за выявления нескольких таких же случаев.

Сбой обнаружил аспирант Гавайского университета в Маноа Юхэн Луо, он проверял исследование Филиппа Уильямса по цианобактериям. Как и Уильямс, он использовал скрипт на Python, чтобы вычислить химический сдвиг. Однако контрольные значения не сошлись. Юхэн попросил учеников запустить код на своих компьютерах, и они обнаружили, что на разных ОС выходят разные данные.

Во всём виновата функция glob(). Авторы скрипта думали, что она возвращает файлы, отсортированные по имени, однако в документации указано, что сортировка не гарантируется. Проблему исправили добавлением метода list_of_files.sort().

Учёные используют этот скрипт с 2014 года, на него опирались авторы более 100 опубликованных работ. И это не считая исследователей, которые в своих статьях на результаты этих работ ссылались.

Шаг 1: Занесите ошибку в трекер

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

1. Вы забыли какую-то важную деталь об ошибке, например, в чем она заключалась.
2. Вы могли делегировать ее кому-то более опытному.

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

Вы должны записать в трекер следующую информацию:

1. Что делал пользователь.
2. Что он ожидал увидеть.
3. Что случилось на самом деле.

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

Шаг 2: Поищите сообщение об ошибке в сети

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

Шаг 3: Найдите строку, в которой проявляется ошибка

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

Шаг 4: Найдите точную строку, в которой появилась ошибка

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

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

Шаг 5: Выясните природу ошибки

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

1. Ошибка на единицу
   Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range.
2. Состояние гонки
   Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
3. Неправильные настройки или константы
   Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts, которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
4. Неожиданный null
   Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null, особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
5. Некорректные входные данные
   Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
6. Присваивание вместо сравнения
   Убедитесь, что вы не написали = вместо ==, особенно в C-подобных языках.
7. Ошибка округления
   Это случается, когда вы используете целое вместо Decimal, или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
8. Переполнение буфера и выход за пределы массива
   Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
9. Программисты не умеют считать
   Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
10. Конкатенация строки и числа
    Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
11. 33 символа в varchar(32)
    Проверяйте данные, передаваемые в INSERT, на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
12. Некорректное состояние
    Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
13. Особенности вашей системы, которых нет у пользователя
    Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

Если ваша ошибка не похожа на описанные выше, или вы не можете найти строку, в которой она появилась, переходите к следующему шагу.

Шаг 6: Метод исключения

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

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

Шаг 7: Логгируйте все подряд и анализируйте журнал

Пройдитесь по каждому модулю или компоненту и добавьте больше сообщений. Начинайте постепенно, по одному модулю. Анализируйте лог до тех пор, пока не проявится неисправность. Если этого не случилось, добавьте еще сообщений.

Ваша задача состоит в том, чтобы вернуться к шагу 3, обнаружив, где проявляется ошибка. Также это именно тот случай, когда стоит использовать сторонние библиотеки для более тщательного логгирования.

Шаг 8: Исключите влияние железа или платформы

Замените оперативную память, жесткие диски, поменяйте сервер или рабочую станцию. Установите обновления, удалите обновления. Если ошибка пропадет, то причиной было железо, ОС или среда. Вы можете по желанию попробовать этот шаг раньше, так как неполадки в железе часто маскируют ошибки в ПО.

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

Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?

Если у вас возникает одна и та же ошибка вне зависимости от среды, то она в вашем коде.

Шаг 9: Обратите внимание на совпадения

1. Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
2. Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
3. Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
4. Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

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

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

Полезные советы (когда ничего не помогает)

1. Позовите кого-нибудь еще.
   Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
2. Внимательно просмотрите код.
   Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
3. Рассмотрите случаи, когда код работает, и сравните их с неработающими.
   Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type='xs:string', все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
4. Идите спать.
   Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
5. Сделайте творческий перерыв.
   Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
6. Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
   Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
7. Поиграйте в доктора Хауса (только без Викодина).
   Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

1. Паника
   Не надо сразу палить из пушки по воробьям. Некоторые менеджеры начинают паниковать и сразу откатываться, перезагружать сервера и т. п. в надежде, что что-нибудь из этого исправит проблему. Это никогда не работает. Кроме того, это создает еще больше хаоса и увеличивает время, необходимое для поиска ошибки. Делайте только один шаг за раз. Изучите результат. Обдумайте его, а затем переходите к следующей гипотезе.
2. «Хелп, плиииз!»
   Когда вы обращаетесь на форум за советом, вы как минимум должны уже выполнить шаг 3. Никто не захочет или не сможет вам помочь, если вы не предоставите подробное описание проблемы, включая информацию об ОС, железе и участок проблемного кода. Создавайте тему только тогда, когда можете все подробно описать, и придумайте информативное название для нее.
3. Переход на личности
   Если вы думаете, что в ошибке виноват кто-то другой, постарайтесь по крайней мере говорить с ним вежливо. Оскорбления, крики и паника не помогут человеку решить проблему. Даже если у вас в команде не в почете демократия, крики и применение грубой силы не заставят исправления магическим образом появиться.

Ошибка, которую я недавно исправил

Это была загадочная проблема с дублирующимися именами генерируемых файлов. Дальнейшая проверка показала, что у файлов различное содержание. Это было странно, поскольку имена файлов включали дату и время создания в формате yyMMddhhmmss. Шаг 9, совпадения: первый файл был создан в полпятого утра, дубликат генерировался в полпятого вечера того же дня. Совпадение? Нет, поскольку hh в строке формата — это 12-часовой формат времени. Вот оно что! Поменял формат на yyMMddHHmmss, и ошибка исчезла.

Перевод статьи «How to fix bugs, step by step»

Журналистка Кэт МакГоуан опубликовала истории нескольких людей, которые сталкивались с угрозой своему здоровью из-за ошибок в программах их кардиостимуляторов. Сделала она это ещё в феврале, но внимание пост привлёк только недавно.

И о чём рассказывает Кэт?

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

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

Это вообще реальные истории?

Да, например, первый же комментарий на Reddit рассказывает о том, что некий(-ая) SaraMG обнаружил(-а) баг в своей инсулиновой помпе. Обнаружила, наблюдая за его работой, разумеется, исходников взять неоткуда.

Что с этим делать?

Бороться за повышение прозрачности работы корпораций, которые занимаются подобным оборудованием. Кстати, уже есть инициатива Private Play Accord, которая направлена на то, чтобы сделать более открытой работу различных интимных устройств, в том числе вибраторов и кардиостимуляторов.

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

Итак, вот моя история борьбы с хардварным багом.

Одна из моих задач в процессе разработки Crash Bandicoot’a заключалась в написании кода для сохранения/загрузки игры на карту памяти. Как для любого чванливого кодера, такой кодинг похож на прогулку в парке: я был уверен, что эта работа займет всего несколько дней. Но все закончилось спустя шесть недель. Нет, конечно же, я не тратил время только на этот баг, но над проблемным, как мне казалось, кодом, я проводил по несколько часов в два—три дня. Это были настоящие мучения.

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

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

Через некоторое время Кони Бут, наш продюсер из Sony, начала волноваться. Мы не могли выпустить игру с таким багом, а спустя шесть недель у меня не было ни единой мысли, откуда могла эта ошибка появится. Мы спросили наших коллег по работе с PlayStation, не сталкивались ли они с подобной проблемой. Нет. Ни у кого никогда не было подобных проблем с системой обработки данных карт памяти.

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

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

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

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

В конце концов у меня остался совсем небольшой фрагмент кода, который все еще порождал ошибку – и все так же случайно! Большую часть времени все происходило, как нужно, но время от времени баг снова проявлял себя. Уже почти ничего не осталось от кода Crash’a, но запись данных по-прежнему периодически завершалась с тайм-аутом. Дальнейшие действия предпринимать было затруднительно: оставшийся код, фактически, не делал вообще ничего.

Когда у вас больше нет идей, как справится с возникшим багом, остается последнее средство: принцип «разделяй и властвуй».

И в один момент – около 3 часов ночи – мне в голову пришла одна мысль. Чтение и запись имеют точную привязку ко времени. C чем бы вы ни работали – флешкой, Bluetooth-устройством – низкоуровневый код чтения/записи имеет строгую привязку ко времени.

Часы CPU позволяют синхронизировать действия оборудования, не подключенного напрямую к процессору, с самим процессором. CPU clock задает скорость изменения информационного параметра (baud rate), т.е., фактически, скорость чтения и записи информации, и если часы сбиваются, то сбиваются и программное, и аппаратное обеспечение. Это очень, очень плохо, и обычно приводит к порче данных на носителе.

Так что же в нашем коде запуска приводило к сбою часов? Я изучил игру на предмет влияющего на часы кода и заметил, что программный таймер PS1 был установлен на частоту 1 КГц, что значительно превышало 100 Гц, на которых по умолчанию начинала работать приставка при запуске. Частота программных часов большинства игр составляла те же 100 Гц.

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

А что если повышение частоты программных вычислений так накладывалось на общую частоту вычислений, что как-то сбивало частоту процессора PS1, нарушая обмен данными с картой памяти?

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

Прошло несколько дней, я игрался с тестирующей системой, и проблемы больше не возникало. Тогда я вернулся к полному коду Crash’а, исправив код так, чтобы перед записью или чтением данных с карты памяти частота устанавливалась на 100 Гц, а затем возвращалась к исходному значению в 1 КГц. И больше никогда эта проблема с сохранением/загрузкой игры не возникала.

Но почему?

Я снова и снова возвращался к тестирующей программе, чтобы выявить хоть какие-то причины появления ошибки при установлении таймера на частоту 1КГц. Наконец я заметил, что ошибки появлялись тогда, когда кто-то играл с джойстиком PS1. В силу того, что я сам не пользовался контроллером – к чему мне это в процессе тестирования чтения/записи? – я этого не замечал. Но вот однажды меня позвал к себе один из наших художников – тут я был уверен, что меня прокляли – при моем появлении он нервно вертел в руках джойстик приставки, и сказал, что сохранить игру вновь не удалось. «Что? Эй, повтори-ка, что сделал сейчас!»

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

Я пришел к Кони и рассказал, что обнаружил. Она связалась с одним из инженеров, разрабатывавших PS1. «Невозможно,» – ответили нам, – «это не аппаратная ошибка». Я попросил ее дать мне связаться с ним.

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

Следующим вечером (мы были в Лос-Анжелесе, а он в Токио, так что для меня начало его рабочего дня было уже вечером) он позвонил мне и извинился. Это действительно была проблема с оборудованием.

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

Но суть проблемы заключалась в том, что при одновременной обработке данных с карты памяти и контроллеров, работающих обособленно друг от друга, если частота программы установлена на 1 КГц, некоторые биты пропадут, и потому данные будут потеряны, а карта памяти повреждена.
Это единственный случай в моей практике, когда суть бага объяснялась квантовой механикой.

Наставления потомкам

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

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

Падение телефонной сети AT&T

15 января 1990 года ошибка в новой версии прошивки междугородних коммутаторов привела к тому, что в один прекрасный день 114 соседних коммутаторов перестали работать, и в следствие этого более 60 тысяч человек остались без междугородней связи на 9 часов. Согласно программе, коммутатор должен перезагрузиться, если получит соответствующий сигнал, однако он по ошибке рассылался каждый раз при восстановлении после сбоя какого-либо коммутатора. Все началось с падения и перезагрузки коммутатора в Нью-Йорке, который вызвал масштабную цепную реакцию, в результате которой 114 коммутаторов перезагружались непрерывно каждые 6 секунд. Сначала компания обвиняла хакеров, однако позже выяснилось, что причиной стала одна ошибочная строка кода, в которой реализовывалась отправка неверного сигнала.

Запуск ракеты Mariner I

В 1962 году ракета с космическим зондом Mariner-1, который должен был отправиться к Венере, вскоре после запуска отклонилась от намеченной траектории полета. Через 293 секунды был отдан приказ уничтожить ракету над Атлантическим океаном. Никто не погиб, однако экономические потери составили 18.3 миллиона долларов. Программист сделал ошибку, когда переводил рукописные математические формулы в код. Символ логического отрицания он принял за минус, и это привело к тому, что ракета воспринимала нормальные скорости как критические и из-за этого сбилась с курса. На будущее совет: внимательно переписывайте рукописный текст.

Аппарат лучевой терапии Therac-25

В 1985 году эта модель аппарата лишила жизни двух человек, и еще четверо получили серьезное облучение. Ошибка крылась в программном управлении защитой от облучения, которая считалась более надежной, чем электромеханическая. Известно, что неисправность была вызвана тем, что в проекте использовались библиотеки с ошибками, входящие в состав ПО аппарата Therac-20, что и привело к фатальным последствиям. В коде была найдена довольно распространенная ошибка многопоточности, называемое состоянием гонки. Тем не менее ошибку не заметили, так как Therac-20 работал исправно из-за дополнительных мер предосторожности. Не зря вопрос про состояние гонки — один из самых задаваемых на собеседовании вопросов по многопоточности, ведь он приносит так много хлопот. Рекомендуем почитать подробнее про эту ошибку.

Взрыв ракеты Ariane 5

В 1996 году ракета Ariane 5, на борту которой были 4 научных спутника, взорвалась через 36.7 секунд после взлета. Это тот случай, когда банальная ошибка переполнения переменной нанесла ущерб в 7 миллиардов долларов. При разработке системы управления ракетой были использованы некоторые части кода от ПО Ariane 4, однако у Ariane 5 показатели скорости были несколько больше, что и вызвало переполнение переменной. Ошибки можно было избежать, если бы при использовании ПО от другого оборудования не забыли подправить код. Видео, запечатлевшее аварию:

Массовое отключение электроэнергии в США и Канаде

В 2003 году состояние гонки в ПО системы управления электростанцией вызвала прекращение подачи электроэнергии и 55 миллионов человек лишились электроснабжения. Деревья, которые находятся под линиями электропередач, регулярно подстригают, однако в Кливленде этого не сделали. Вследствие жары и увеличения энергопотребления провода провисли ниже обычного и коснулись деревьев: случилось замыкание, и электростанция в Кливленде вышла из строя. Аварийная система не предупредила персонал о перегрузках в сети, поэтому произошло каскадное отключение еще около сотни электростанций. В ходе расследования установили, как такое произошло: состояние гонки вызывало подвисание сигнализации в комнате персонала на целый час, поэтому сотрудники электростанции не получали никаких сигналов о том, что произошла беда.

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

Что в них такого, что усложняет отладку приложения в несколько раз, особенно, если эти ошибки возникают в классе, который оборачивает какая-то используемая вами библиотека? Конечно, если стек вызовов уводит вас на двадцать уровней глубже вашего кода, то вы можете просмотреть все двадцать и таки найти ошибку, но ведь было бы гораздо лучше, если бы вам не пришлось этого делать?

Почему эта ошибка в CoffeeScript так часто появлялась в вопросах на StackOverflow?

Что, если бы каждая ошибка, которую вы встречали, будучи разработчиком, точно говорила вам, в чем проблема? Не просто почему что-то не работает, а что вы сделали такого, что это что-то перестало работать?

Контекст — наше все

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

Может, это и отнимет у вас немного времени при разработке продукта, но оно окупится — каждый раз, когда кто-то совершит ошибку при написании кода, ему не надо будет тратить минуты и часы, чтобы разобраться в ней и исправить ее.

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

Для Clojure-истов: используйте ex-info

Следующая информация предназначена только для тех, кто пишет на Clojure. Используйте функцию ex-info при дизайне исключений и указании контекста:

Если инструмент, который вы используете в продакшене для трассировки исключений, понимает Clojure, то он автоматически выведет ex-data, т.е. весь нужный контекст. Кроме того, вы можете манипулировать ex-data как любыми другими данными, что особенно полезно при отладке сложных ошибок.

Как это касается меня?

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

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

Перевод статьи «The art of the good error message»

1. Неисправленные ошибки скрывают новые

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

2. Неисправленные ошибки подразумевают, что качество кода неважно

Все мы стремимся, чтобы наши программы были высокого качества. Но иногда руки опускаются, и качество когда стремительно снижается. Если программист работает с кодом, в котором есть плохо написанные функции, без юнит-тестов, новый код, который он пишет, скорее всего будет таким же. Аналогично, тестировщик, видя десятки незакрытых багрепортов, вряд ли захочет добавлять новый. Если вы работаете в команде, такое настроение передается и коллегам. Рано или поздно они начнут задавать себе вопрос: «А есть ли смысл стараться? Зачем стремиться к лучшему, если оно и так работает?». Не позволяйте себе расслабляться — исправляйте ошибки сразу.

3. Обсуждение ошибок приводит к бесполезной трате времени

Обсуждение старых неисправленных ошибок — это пустая трата времени, вне зависимости, планируете ли вы архитектуру, тестируете приложение или просто собрались с коллегами. Есть только один важный вопрос: «Должна ли это ошибка быть исправлена?». Все остальное — просто шум. Какой приоритет ей присвоить? Сколько это займет времени? Следует ли сначала исправить баг №114 или №113? Всего этого можно избежать (как и долгих дискуссий), если исправлять ошибки сразу. Безусловно, в каждом проекте могут быть ошибки, которые требуют повышенного внимания, но это не должно быть нормой. Не тратьте время на пустую болтовню — исправляйте ошибки сразу.

4. Неисправленные ошибки ведут к дополнительной работе

Чем больше неисправленных ошибок в проекте, тем труднее понять, есть ли найденная в списке известных. Представьте, что у вас 5 неисправленных ошибок. При обнаружении новой легко увидеть, сообщал ли кто уже о ней. А если их будет 50? В этом случае или потребуется дополнительное время на просмотр всех отчетов (которое можно потратить с пользой), или отчет будет отправлен повторно. Повторный отчет потребует дополнительного исследования и тестов. Не делайте лишней работы — исправляйте ошибки сразу.

5. Неисправленные ошибки портят статистику

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

6. Неисправленные ошибки отвлекают

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

7. Неисправленные ошибки могут срывать релизы

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

8. Неисправленные ошибки срывают сроки

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

9. Исправлять знакомый код легче

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

10. Исправить ошибку сразу легче

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

Перевод статьи «Ten reasons why you fix bugs as soon as you find them»