В данной статье попробуем рассмотреть варианты некорректной полемики, которая, увы, часто встречается на Хабр и иных площадках.

Абсолютизирование описанного подхода

Известно, что любой способ, доведённый до абсолюта становится глупостью.

Например чрезмерное применение ООП приводит к нечитаемому коду. Полный отказ от ООП и переход к чисто функциональному коду тоже снижает читаемость.

Истина всегда где-то посередине.

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

Я как-то написал статью об использовании именованных событий и ко мне пришёл комментатор и заявил:

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

Что делать?

1. Не включаться в спор.
2. Однократно прокомментировать что не стоит перебарщивать с инструментом.

Терминологическое забалтывание

Не секрет что во многих случаях границу между терминами провести сложно. Часто два разных термина означают одно и то же и наоборот. Зависит от контекста и границы употребимости.

Например Вы о чём-то рассказываете. О проблеме X:

Рассмотрим проблему X, которая проявляется, например, в случаях A, B, C и D. Проблема состоит в том-то и том-то. Решать её можно так-то и так-то.

Обязательно найдётся комментатор, который скажет:

Полная лажа! У Вас термин D применён неправильно! На самом деле надо говорить D-штрих. Термин D ввёл такой-то Ф.И.О в таком-то году. А термин D-штрих другой Ф.И.О в другом году.

Почему-то года и Ф.И.О оказываются важны.

Вы ему отвечаете:

В рамках данной статьи не особо важно D это или D-штрих, поскольку здесь речь о проблеме X. D тут — пример и D-штрих может быть таким же примером. В данном контексте разницы нет: проблема X присутствует и в D и в D-штрих.

Сразу появляется ещё один участник. Заявляет:

Это не D-штрих, это E!

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

Нет, это не E, это D!

В итоге пост собрал 100+ коментариев о терминах D, D-штрих, E и годах рождения тех кто ввёл термины. Но проблему X не обсудили.

У меня был как-то комментарий о проблемах использования глобальных (или статических) переменных.

В нём приводился пример с синглтоном. Синглтон в примере был реализован с использованием глобальной переменной.

Сразу нашёлся персонаж, который воскликнул:

Полная лажа! Это не синглтон, это мемоизация!

Я ответил:

Это синглтон, который в данном примере реализован при помощи мемоизации.

И вот я включился в эту игру. О проблеме глобальных/статических переменных забыли.

Что делать?

1. Не включаться в спор (если реально хотим обсуждать именно то о чём писали в статье).
2. Тщательно выверять термины в статье. Если что-то может иметь два названия — приводим их оба.
3. Мягко возвращать аудиторию к обсуждаемой проблеме. Напоминать о ней.

Это не серебряная пуля!

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

Допустим Вы обсуждаете какой-то способ решения какого-то спектра проблем.

Обязательно найдётся человек, который придёт и скажет:

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

Что делать?

Не включаться в спор. Просто игнорируем комментарий.

Гиперболизация проблем

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

Его комментарии можно свести к такому (только он его прямо не говорит):

Раз из 100 случаев мы улучшаем всего 99, а целый один у нас остаётся не улучшенным, то Ваше предложение — полная лажа.

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

Что делать?

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

Игнорирование проблем

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

Скопипастить код 23 раза? Пфф какая мелочь! Установи себе правильный IDE, где это делается одной кнопкой, и не надо тут статьи писать!

Что делать?

Игнорировать такие комментарии.

А какие варианты некорректной полемики знаете Вы?

Автор: Бот Кремля

Источник ^[1]