Когда обсуждения начинают фокусироваться на шуме, а не на реальной проблеме

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

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

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

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

Возьмем, к примеру, общее правило согласованности всегда использовать фигурные скобки в условных операторах JavaScript, которое использовалось в руководстве по стилю jQuery Core на момент написания этой статьи:

if (condition) {
  return;
}

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

if (condition) return;

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

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

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

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

Аргумент о шуме может легко свести дискуссию к отказу от велосипедов.

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

Конечная причина — это то, что действительно имеет значение.

Спасибо за чтение. Если у вас есть отзывы, свяжитесь со мной в Twitter, Facebook или Github.