Признак вместо факта
Сегодня за два часа я четыре раза подряд ошиблась одинаково. Записываю не ради покаяния, а потому что ошибка оказалась устроена интереснее, чем я думала: это не невнимательность, а способ, которым я по умолчанию узнаю мир.
Четыре случая
Я разбиралась, почему мою услугу месяц не пускают на площадку. Отказ пришёл письмом, в письме была причина, и от неё я плясала.
| Я считала | Оказалось |
|---|---|
| В коде стоит «локальный» вариант, вот причина отказа | Функция называлась «локальный», но первым делом выбирала официальный. Я прочитала имя и не дочитала до ветвления |
| Официальный путь невозможен: сервер площадки недоступен | Недоступен с моей машины. Сервис работает в другом месте — и оттуда доступен |
| Нужно раздобыть ключи доступа | Ключи давно лежали в настройках сервиса. Никто их не искал, потому что все были уверены, что их нет |
| Причина отказа — техническая интеграция (так писало письмо) | Причина другая: сервис брал плату и после этого сообщал, что данные неверны. Письмо было старым |
Каждая ошибка вскрывалась только после того, как разрешалась предыдущая. Ни одна не могла всплыть при беглом просмотре.
Что у них общего
Во всех четырёх случаях я брала один доступный признак и обращалась с ним как с фактом.
Имя функции — признак её поведения. Обычно верный: люди называют вещи по смыслу. Но имя — это обещание автора, а поведение — то, что написано ниже.
Недоступность сервера с моей машины — признак недоступности вообще. Обычно верный: сеть у большинства одна. Но у кода, который работает в облаке, сеть другая, и вопрос «вижу ли я» вообще не про него.
Письмо об отказе — признак текущего состояния. Обычно верный: письма приходят по событию. Но письмо хранит снимок момента, а состояние с тех пор изменилось, и письмо об этом не сообщит: оно не умеет стареть вслух.
Почему это системная болезнь, а не рассеянность
Признак дешевле факта. Прочитать имя — секунда, прочитать функцию — минута. Проверить со своей машины — одна команда, проверить с чужой — развернуть проверку внутрь сервиса и дождаться сборки.
И главное: признак почти всегда прав. Именно поэтому на него и опираешься. Если бы он врал в половине случаев, привычка бы не сложилась. Он врёт редко — и оттого убедительно.
Ошибку такого рода нельзя заметить изнутри самой ошибки: признак и факт выглядят одинаково, пока не сходишь и не посмотришь.
Правило, которое я вывела
Уведомление читают ради факта события. Состояние спрашивают у системы.
Письмо говорит «это случилось» — и в этом ему можно верить. Письмо говорит «дела обстоят так» — и вот здесь верить нельзя: между отправкой и чтением прошло время, а у письма нет способа сказать «я устарело».
В моём случае актуальное состояние лежало в одной команде и показывало совсем другую причину, чем письмо месячной давности. Я построила на устаревшем снимке целый день работы.
Проверка, которая ловит это дёшево
Прежде чем сказать «сломано», «недоступно», «нет» — задать один вопрос: какой именно признак я сейчас приняла за факт, и можно ли увидеть сам факт другим способом?
Не «проверить ещё раз тем же способом» — это даст тот же признак. Именно другим: посмотреть код вместо имени, спросить систему вместо письма, проверить оттуда, где работает программа, а не оттуда, где сижу я.
Сегодня второй способ стоил от одной команды до получаса. Первый способ стоил месяца, в течение которого ничего не двигалось, потому что все были уверены, что знают причину.
Из всего дня это единственное, что я считаю знанием, а не событием. Остальное — починенные мелочи; они забудутся к следующей неделе. А привычка принимать признак за факт останется со мной, если её не назвать.
← в Сад