8 lines
20 KiB
JSON
8 lines
20 KiB
JSON
{
|
||
"index": 41,
|
||
"slug": "editorial-2026-11-mechanism-technology-evaluation",
|
||
"title": "Как сравнивать технологии, если данных пока мало",
|
||
"excerpt": "Практический способ отделить наблюдение от предпочтения: как зафиксировать критерии, остановить псевдоточный выбор и подготовить проверяемое решение.",
|
||
"contentHtml": "<p>Команда сравнивает два runtime. В одном демо вариант A отвечает быстрее. В другом варианте B проще выглядит в коде. Через неделю появляется таблица с баллами 8,7 и 7,9. В ней нет версии окружения, размера входа, повторений и стоимости перехода. Симптом ясен: число выглядит точным, но его нельзя связать с конкретной нагрузкой.</p>\n<p>Цена ошибки приходит после выбора. Команда переносит код на неподходящую границу, тратит время на обучение и поддержку, а затем объясняет сбой «шумом измерения». Вернуться трудно: исходные условия не записали, поэтому никто не знает, какой вывод нужно пересмотреть. Тезис статьи простой: технология не выбирает себя числом. Сначала нужно разделить вопрос, наблюдение, неопределённость и предпочтение.</p>\n<h2>Четыре сущности, которые нельзя смешивать</h2>\n<p>Вопрос описывает, что команда хочет узнать. Например: «какой вариант уменьшает работу по миграции при сохранении текущего API?». Наблюдение отвечает, что произошло в конкретных условиях. Это может быть время операции, число ошибок или объём памяти при названном входе.</p>\n<p>Неопределённость описывает, где наблюдение может не перенестись. Результат зависит от версии, данных, нагрузки и способа измерения. Предпочтение показывает, что команда считает более важным. Вес критерия 40 — это не свойство технологии. Это открытое решение людей, которое можно оспорить.</p>\n<p>Если поставить вес на место наблюдения, таблица скроет пробел. Если поставить одно измерение на место решения, команда выдаст локальный результат за универсальный. Если убрать неопределённость, читатель не поймёт, где действует вывод. Поэтому эти четыре слоя нужно хранить отдельно и проверять по отдельности.</p>\n<figure><img src=\"/assets/editorial/2026/technology-evaluation-2026-tradeoff-frontier.svg\" alt=\"Граница компромиссов при сравнении технологий: пригодность, стоимость внедрения и эксплуатация без точки победителя\" loading=\"lazy\" /><figcaption>Схема показывает пространство компромиссов. Точка победителя не появляется без согласованных входов, измерения и правил интерпретации.</figcaption></figure>\n<h2>Таблица диагностики: симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Проверка инженерного сравнения до выбора технологии</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Есть итоговый балл, но нет входных условий</td><td>Локальное наблюдение выдали за общий результат</td><td>Найти версию, вход, нагрузку и границу операции</td><td>Убрать итог и записать недостающие условия</td></tr><tr><td>Веса появились после демо</td><td>Предпочтение подогнали под понравившийся результат</td><td>Спросить, кто и до измерения утвердил критерии</td><td>Вернуть веса на обсуждение и сохранить объяснение</td></tr><tr><td>В отчёте написано «одинаковая среда»</td><td>Ключевые параметры спрятали в общей фразе</td><td>Раскрыть версии, зависимости, входы и пределы времени</td><td>Остановить сравнение до явной конфигурации</td></tr><tr><td>Есть среднее, но нет разброса</td><td>Неопределённость потеряли при агрегации</td><td>Проверить повторения и правило обработки выбросов</td><td>Показать вариацию или назвать её неизвестной</td></tr><tr><td>Один вариант назван победителем во всех условиях</td><td>Компромисс заменили универсальным рейтингом</td><td>Проверить, какие критерии ухудшаются у победителя</td><td>Описать trade-off и границу применимости</td></tr></tbody></table></div>\n<h2>Измерение начинается с вопроса</h2>\n<p>Слово «производительность» слишком широкое. Оно может означать задержку, пропускную способность, расход памяти или время восстановления. Сначала назовите одну операцию и её границу: например, «время сериализации объекта размером 1 МБ при версии X». Затем укажите, какое решение это наблюдение должно поддержать.</p>\n<p>После этого зафиксируйте вход. Запишите версию runtime, версию зависимостей, тип процессора, размер данных, число повторений и правило очистки окружения. Не используйте формулировки «реальная нагрузка» и «одинаковая машина» без расшифровки. Они создают видимость контроля, но не дают читателю повторить проверку.</p>\n<p>Среднее без разброса тоже не даёт уверенности. Если один прогон занял 10 мс, а другой 100 мс, запись «среднее 55 мс» скрывает важное свойство системы. Нужны повторения, диапазон или другая заранее выбранная форма описания вариации. Если повторений не было, напишите «не измерено». Это честнее, чем нулевой разброс.</p>\n<h2>Вес критерия — договорённость, а не метрика</h2>\n<p>Взвешенная матрица помогает сделать спор видимым. Пусть команда оценивает пригодность, стоимость внедрения и эксплуатацию. Она может назначить веса 40, 35 и 25. Числа задают порядок внимания. Они не говорят, что пригодность в 1,6 раза важнее эксплуатации в объективном смысле.</p>\n<p>Каждый вес должен иметь вопрос-владелец. Для пригодности спросите, какую границу задачи обязан закрыть вариант. Для стоимости внедрения — какие обучение, миграция, документация и обратимость входят в расчёт. Для эксплуатации — кто будет замечать отказ и сколько времени есть на восстановление.</p>\n<p>Сумма 100 удобна как контроль записи. Она не превращает шкалу в физическую величину. Оценка 3 не означает, что вариант в три раза лучше оценки 1. Если шкала порядковая, так и пишите. Её задача — поддержать разговор о приоритетах, а не создать научный вид.</p>\n<h2>Учебный пример: остановить скрытую конфигурацию</h2>\n<p>Ниже — учебный JavaScript-пример. Он не запускает технологии, не читает файлы и не получает данные из среды. Функция проверяет только структуру заранее заданного объекта. Имена вариантов условны. Код показывает отрицательный путь: если конфигурация скрыта, функция не выдаёт победителя.</p>\n<pre><code>function assessEvaluation(input) {\n const required = ['question', 'alternatives', 'criteria', 'measurement'];\n\n if (!required.every((key) => key in input)) {\n return { status: 'stop', reason: 'missing-field' };\n }\n\n const totalWeight = input.criteria.reduce((sum, item) => sum + item.weight, 0);\n const measurementIsVisible = Boolean(\n input.measurement.input &&\n input.measurement.version &&\n input.measurement.repetitions > 0\n );\n\n if (totalWeight !== 100) {\n return { status: 'stop', reason: 'invalid-weight-total' };\n }\n\n if (!measurementIsVisible) {\n return { status: 'stop', reason: 'hidden-measurement' };\n }\n\n return { status: 'ready-for-review', result: 'no-winner' };\n}\n\nconsole.log(assessEvaluation({\n question: 'compare serialization cost for a fixed input',\n alternatives: ['runtime-a', 'runtime-b'],\n criteria: [\n { name: 'fit', weight: 40 },\n { name: 'adoption-cost', weight: 35 },\n { name: 'operation', weight: 25 },\n ],\n measurement: { input: '1 MB JSON', version: 'fixed', repetitions: 0 },\n}));\n// { status: 'stop', reason: 'hidden-measurement' }</code></pre>\n<p>В примере веса заполнены, но число повторений равно нулю. Поэтому код возвращает stop. Он не угадывает результат и не заменяет отсутствующее измерение единицей. Статус <code>ready-for-review</code> тоже не означает, что технология выбрана. Он означает только, что структура прошла локальные проверки и может перейти к отдельному обсуждению данных.</p>\n<p>Это важное ограничение автоматизации. Проверка полей ловит пропуск, но не знает, подходит ли вход реальному пользователю. Она не проверяет корректность бенчмарка, статистический метод, права доступа и стоимость поддержки. Для этого нужны отдельные владельцы и доказательства.</p>\n<h2>Как читать trade-off</h2>\n<p>Сравнение редко даёт вариант, который лучше по всем осям. Быстрый runtime может потребовать больше обучения. Инструмент с простой миграцией может усложнить диагностику. Библиотека с хорошими метриками может ограничить формат данных. Такие отношения образуют границу компромиссов.</p>\n<p>Поэтому не спрашивайте «кто победил вообще». Спросите, какой компромисс допустим для данной операции. Если миграцию нельзя откатить за рабочее окно, стоимость обратимости получает больший вес. Если операция чувствительна к задержке, важнее зафиксировать задержку именно этой операции, а не пересказывать общий результат демо.</p>\n<p>Проверяйте чувствительность решения. Измените один вес и посмотрите, меняется ли порядок вариантов. Если небольшое изменение переворачивает вывод, решение хрупкое. Это не доказывает, что оно неверно. Это показывает, что нужно уточнить критерии и границы данных. Без реальных оценок такая проверка остаётся подготовкой, а не доказательством устойчивости.</p>\n<h2>Порядок действий</h2>\n<ol><li>Опишите наблюдаемый симптом: что сравнение скрывает, где это видно и сколько стоит ошибочный выбор.</li><li>Сформулируйте один вопрос и назовите минимум две альтернативы. Не называйте вариант победителем до проверки условий.</li><li>Разделите критерии на пригодность, стоимость внедрения и эксплуатацию либо на другие явно объяснённые группы.</li><li>Зафиксируйте владельца каждого критерия и веса до получения результата. Проверьте, что сумма весов равна 100.</li><li>Опишите вход, версию, окружение, операцию, повторения и правило обработки вариации.</li><li>Сохраните неизвестные значения как неизвестные. Не подставляйте ноль, среднее из одного прогона или оценку из памяти.</li><li>Проверьте отрицательный путь: отсутствующее поле, скрытую конфигурацию, неверную сумму и запрещённый положительный вывод.</li><li>Сравните варианты по каждому критерию отдельно. Затем запишите компромисс, границу применимости и решение уполномоченного владельца.</li><li>После изменения проверьте тот же сигнал на той же границе. Если условие изменилось, это новый замер, а не продолжение старого.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Этот механизм не выбирает язык, runtime или базу данных. Он не определяет допустимую нагрузку и не выдаёт статистическую значимость. Он не заменяет security review, оценку лицензий, accessibility-проверку, финансовую модель и план отката.</p>\n<p>Учебная матрица может помочь увидеть пробел, но не создаёт production-результат. Не вставляйте в неё реальные секреты, идентификаторы клиентов и ссылки на закрытые панели. Если нужно сравнить рабочие системы, сначала получите разрешение на данные и опишите протокол. Пока этого нет, допустим только структурный разбор.</p>\n<p>Отрицательный путь должен оставаться нормальным исходом. Неверный вес возвращает вопрос к критериям. Скрытый input возвращает вопрос к конфигурации. Большой разброс возвращает вопрос к нагрузке и повторениям. Наличие stop не означает провал команды. Оно показывает, что следующий вывод пока нельзя защищать.</p>\n<h2>Критерий готовности</h2>\n<p>Сравнение готово к решению, когда читатель может назвать операцию, вход, версии, повторения, критерии и веса. Для каждого числа есть источник и правило интерпретации. Для каждого неизвестного поля есть явная отметка и следующий способ проверки. Для каждого варианта описаны сильная сторона, цена внедрения, эксплуатационный риск и условие отката.</p>\n<p>Готовность не равна строке «выбран вариант B». Она означает, что решение можно оспорить по частям: отдельно проверить вход, отдельно пересмотреть вес, отдельно повторить измерение. Если хотя бы один слой скрыт, корректный результат — stop, а не красивый рейтинг.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/30/r1/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments</a> — официальный документ NIST о входах, оценке риска и неопределённости. Он не выбирает технологию и не подтверждает учебные числа.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc8174.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</a> — официальный RFC, уточняющий силу нормативных слов. Он помогает не путать требование с рекомендацией, но не заменяет измерительный протокол.</li></li></ul>"
|
||
}
|