Проверка: дата, автор, воспроизводимость

Есть два утверждения, которые выглядят одинаково:

• «Чтобы отключить это поведение, добавьте флаг --legacy-mode».
• «Чтобы отключить это поведение, добавьте флаг --legacy-mode» — написано в 2016 году, флага не существует с версии 3.0, а поведение теперь отключается иначе.

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

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

Пять осей проверки

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

Ось первая: датировка

Дата публикации — не то, что вам нужно. Вам нужна дата, на которую утверждение было верным, и версия, к которой оно относится.

Как определять:

• Явная дата на странице. Есть не всегда, и часто это дата последнего изменения шаблона сайта, а не текста.
• Версии, упомянутые в тексте. Самый надёжный маркер: если в примере фигурирует версия 2.x, а у вас 5.x, текст датирован независимо от того, что написано сверху.
• История файла документации. Если документация в репозитории, у страницы есть коммиты. git log -- docs/page.md даёт точную датировку каждого абзаца.
• Wayback Machine. Позволяет увидеть, как страница выглядела раньше, и понять, менялась ли она вообще. Страница без изменений за пять лет — это не «стабильная», это «заброшенная».
• Косвенные признаки. Скриншоты интерфейсов, названия компаний до переименования, упоминание инструментов, которых больше нет.

Период полураспада: разные знания стареют по-разному

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

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

Проверка «жив ли совет»

Самый быстрый способ датировать техническое утверждение — попробовать его выполнить:

# существует ли флаг, о котором пишут
mytool --help | rg -- '--legacy-mode' || echo "флага нет — совет устарел"

# существует ли опция конфигурации в текущей версии
rg -n 'legacy_mode' "$(mytool --print-config-schema-path 2>/dev/null || echo .)"

# существует ли метод в установленной библиотеке
python -c "import lib; print(hasattr(lib.Client, 'set_legacy_mode'))"

# когда опция появилась и когда исчезла
git log -S'legacy-mode' --oneline -- cmd/

Тридцать секунд, и вопрос датировки закрыт окончательно — причём не «в целом», а для вашей версии.

Ось вторая: авторство

Вопрос не «кто этот человек», а «что он мог знать в момент написания и за что он отвечает».

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

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

Ось третья: воспроизводимость

Главный водораздел всей главы:

Утверждение, которое нельзя проверить, — не инженерное знание, а мнение.

Признаки проверяемого утверждения:

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

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

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

Ось четвёртая: независимость и циркулярное подтверждение

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

Этот механизм называют циркулярной отчётностью или citogenesis (термин закрепился после xkcd 978). В технической области он встречается постоянно: неудачный совет из старого ответа расходится по статьям, статьи начинают ссылаться друг на друга, и через пять лет это выглядит как отраслевой консенсус.

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

1. Поиск характерной фразы в кавычках. Если дословная формулировка встречается в пяти текстах — это один текст в пяти местах.
2. Сравнение дат. Выстройте источники по времени: обычно видно, где начало.
3. Проверка ссылок вверх. У каждого источника посмотрите, на что ссылается он. Часто все ветви сходятся.
4. Смена корпуса. Ищите то же утверждение в другой языковой или профессиональной среде: в документации, в спецификации, в академической литературе. Настоящее независимое подтверждение выглядит как источник другого типа, а не как ещё один блог.

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

Ось пятая: интерес

Конфликт интересов не делает утверждение ложным. Он предсказывает, какая именно часть правды опущена.

Как читать бенчмарк, сделанный заинтересованной стороной

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

1. Кто настраивал проигравшего? Почти всегда — победитель. Своя система оттюнингована, чужая взята с настройками по умолчанию.
2. Какие версии? Сравнение свежей своей со старой чужой — классика.
3. Какая нагрузка? Синтетическая нагрузка, подобранная под сильные стороны, ничего не говорит о вашей.
4. Какая метрика? Средняя пропускная способность скрывает хвосты; хвосты скрывают среднее. Показывают то, что выигрывает.
5. Воспроизводимо ли? Есть ли код, конфигурации, сырые данные. Без них это не измерение, а утверждение.
6. Что с ценой? «Быстрее» без указания железа и стоимости — половина сравнения.

Стоит знать про клаузулу DeWitt — условие в лицензионных соглашениях ряда коммерческих СУБД, запрещающее публиковать результаты сравнительных измерений без разрешения вендора. Она названа по имени David DeWitt, чьё исследование в начале 1980-х вызвало такую реакцию. Практическое следствие: отсутствие независимых сравнений некоторых продуктов — не признак того, что сравнивать нечего, а следствие юридических ограничений.

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

Признаки протухшего ответа

Чек-лист для типичного ответа на Q&A-площадке или статьи. Каждый пункт — секунда.

• Принятый ответ старше пяти лет, а рядом есть более новые с меньшим числом голосов — обычно правильный ответ уже написан ниже.
• В комментариях есть «this no longer works in version N» — самая ценная строка на странице.
• В примере используются флаги или методы, которых нет в текущей документации.
• Ссылки в ответе ведут в 404 или на редирект в корень сайта.
• Упоминаются инструменты, которых больше нет.
• Ответ обсуждает проблему, которая в текущей версии решается штатной опцией.
• В самом вопросе указана версия, и она не ваша.

Правило чтения Q&A-площадок: сначала комментарии и даты, потом ответ. Комментарии — это слой рецензирования, который обычно пролистывают, а именно там написано, при каких условиях ответ перестал работать.

Сгенерированные тексты: как относиться

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

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

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

Трёхминутный протокол

Свод, который имеет смысл выполнять до того, как найденное превратится в код.

1. Дата и версия. Есть? К моей относится? — 30 секунд.
2. Существует ли то, о чём речь. Флаг, метод, опция — проверить локально. — 30 секунд.
3. Первичный источник. Есть ссылка? Она открывается? Там написано то же самое? — 60 секунд.
4. Второй источник другого типа. Не второй блог, а документация, спецификация или код. — 30 секунд.
5. Кому выгодно. Одно предложение про интерес автора. — 10 секунд.
6. Проверка. Если утверждение проверяемо за пять минут — проверьте, и предыдущие пять шагов можно было бы пропустить.

Разбор: как протухает совет по производительности

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

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

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

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

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

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

Проверка. Занимает полчаса: прогнать нагрузочный тест при трёх значениях размера пула и посмотреть на насыщение и на хвост латентности. После этого вопрос закрыт для вашей системы — навсегда и с числами.

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

Типичные ошибки

1. Оценивать источник по убедительности текста. Гладкость письма не коррелирует с точностью; часто наоборот, потому что детали портят гладкость.
2. Считать дату публикации датой актуальности. Нужна версия, а не дата.
3. Принимать повтор за подтверждение. Пять статей с одной формулировкой — один источник.
4. Читать бенчмарк вендора как измерение. Это заявление, у которого есть автор и интерес.
5. Пропускать комментарии под ответом. Там лежит слой рецензирования.
6. Не проверять существование упомянутого. Половина ошибок отсекается одной командой --help.
7. Проверять то, что дешевле измерить. Если эксперимент занимает пять минут, оценка источника — потеря времени.

Как это выглядит в команде

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

• В обсуждениях просить ссылку, а не спорить. Формула «давай посмотрим, где это написано» закрывает большинство технических споров за минуту и не задевает никого.
• В проектных документах помечать статус утверждения. Три пометки достаточно: «проверено экспериментом», «из документации версии N», «предположение». Читатель через год скажет вам спасибо.
• При разборе инцидента отделять то, что измерено, от того, что найдено в интернете. Иначе постмортем зафиксирует не причину, а чужую гипотезу; про жанр — глава про постмортемы.

Мини-итог

• Устаревшая техническая информация выглядит точно так же, как актуальная. Единственная защита — процедура.
• Пять осей: датировка, авторство, воспроизводимость, независимость, интерес. Датировка первая, потому что дешевле всего и отсекает больше всего.
• Нужна не дата публикации, а версия, к которой относится утверждение; проверка существования флага или метода закрывает вопрос за тридцать секунд.
• У каждого типа автора свой предсказуемый профиль умолчаний — это позволяет проверять адресно, а не «критически мыслить вообще».
• Непроверяемое утверждение не является инженерным знанием.
• Независимое подтверждение — это источник другого типа, а не ещё один текст того же жанра. Циркулярное подтверждение создаёт иллюзию консенсуса.
• Конфликт интересов не делает утверждение ложным, но предсказывает, что опущено; в бенчмарках главный вопрос — кто настраивал проигравшего.
• Если утверждение можно проверить за пять минут, проверка сильнее любой оценки источника.

Источники

• xkcd 978, «Citogenesis» — каноническая иллюстрация циркулярного подтверждения: xkcd.com/978.
• Boyd S., «The DeWitt Clause» — история и обсуждение ограничений на публикацию сравнительных измерений СУБД; исходный контекст — работа David DeWitt по Wisconsin Benchmark (1983).
• Raasveldt M., Holanda P., Gubner T., Mühleisen H. (2018). Fair Benchmarking Considered Difficult: Common Pitfalls In Database Performance Testing. DBTest'18 — dl.acm.org/doi/10.1145/3209950.3209955.
• NIST Computer Security Resource Center — актуальные статусы криптографических рекомендаций: csrc.nist.gov/publications.
• Internet Archive Wayback Machine — web.archive.org.
• Stack Overflow, руководство по редактированию и устареванию ответов — stackoverflow.com/help/editing.

Что дальше

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