Перевод статьи Developer Fallacies с сайта heydonworks.com, опубликовано на css-live.ru с разрешения автора — Хейдона Пикеринга.

Время от времени веб-разработчики (и вообще программисты) находят неудачные аргументы в защиту своего выбора технологий, рабочих процессов или организационных схем, а также для принижения чужого выбора. Я видел такое не раз, да и сам порой не удерживался от крепкого словца по такому поводу. Мы особенно уязвимы для неудачных аргументов, поскольку привыкли считать себя логичными. Как же сильно мы порой заблуждаемся.

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

• Заблуждение священного писания
• Заблуждение о луддитах
• Заблуждение о масштабе
• Заблуждение о шоколадной каминной решетке
• Заблуждение о пуллреквестах
• Заблуждение «Сделано в Фейсбуке»
• Заблуждение фиксиков
• Заблуждение о реальном мире
• «Страшное» заблуждение

Заблуждение священного писания

Начну с того, о котором вы уже наверняка слыхали, возможно, под другим названием. Это ошибка вида «мы всегда так делали». Что-либо — что-то из так называемых устоявшихся подходов, правил или процессов — восхваляется, беспрекословно, лишь потому, что оно восхвалялось в прошлом. Это своего рода замкнутый круг.

Сейчас это «что-то» может быть хорошей идеей или подходом, а может и не быть, но просто говорить, что это хорошо, потому что общепринято… ну, не совсем хорошо. Эта ошибка названа в честь Библии, которую некоторые фанатичные верующие воспринимают буквально и беспрекословно, несмотря на отдельные весьма сомнительные советы.

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

1-е послание Петра, глава 2, стих 18

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

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

Заблуждение о луддитах

Заблуждение о луддитах — по сути, противоположность ошибки священного писания. Это две стороны одной медали, если угодно. Названное в честь ткачей-луддитов, которые сопротивлялись новым технологиям, угрожавшим их единственному заработку, оно встречается в двух видах:

• Ошибочное утверждение, что единственная причина не внедрять новую технологию — то, что кто-то из вредности сопротивляется переменам или боится их;
• Ошибочное утверждение, что всё новое обязательно лучше, просто потому что новое.

Например, вас могут обвинить в «нелюбви к переменам» за то, что вы отказываетесь переводить проект с одной технологии на более новую, когда у вас есть серьезные доводы, что эта новая технология — интеллектуальный онанизм, и вы можете это обосновать. На фоне этого без конца повторяющегося ложного заявления затеряются любые разумные аргументы, что превращает его в разновидность нападки ad hominem.

Разработчики склонны сами выбирать для себя технологии. Есть большущий соблазн внедрить новую технологию лишь потому, что хочется поиграть с прикольной новой игрушкой. Конечно, они в этом никогда не признаются, но заблуждение о луддитах в какой-то мере может подпитывать их надежду выторговать себе такую игрушку. Будьте бдительны.

Вот несколько примеров свежайших изобретений, ужасных что пипец.

Заблуждение о масштабе

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

• Проекты, обслуживающие большее количество людей, непременно должны быть более сложными внутри;
• Проекты, обслуживающие большие объемы контента, способны к этому лишь ценой усложнения.

Есть ли какая-либо пропорциональность между популярностью приложения и объемом его кода? Конечно же, нет. Есть сколько угодно примеров, указывающих на обратное. Утверждать, будто расширение аудитории продукта с неизбежностью ведет к навороченному коду — заблуждение. Не будьте Джорджами Лукасами. Дайте уже рукам отдохнуть, блин, и перестаньте добавлять всякую фигню.

Точно так же нет причин, почему отдача 10 страниц контента должна отличаться от отдачи 10000 на уровне механизма. Да, они часто различаются, но нет ни одной специальной причины, по которой так должно быть. Количество записей в базе данных никак не связано с общей сложностью этой базы.

Количество пользователей — не оправдание для громоздкости систем публикации.

Заблуждение о шоколадной каминной решетке

Некоторые вещи просто не годятся для задачи. Некоторых вещей лучше бы вообще не было, или лучше бы вместо них было что-то другое. Не надо принимать это на веру, не изучив (см. ошибку священного писания), но не всё можно оправдать спасительной оговоркой «если его разумно использовать, это вполне нормально». Постель из колючей проволоки? Да не вопрос, только ложитесь на нее поосторожнее!

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

Я могу утверждать — и утверждал — что вложенность в Sass была плохой чертой этого языка. Аргумент у меня был тот, что она понапрасну увеличивает сложность синтаксиса, неизбежно ухудшая читаемость исходного Sass-кода. Буду только рад, если вы это оспорите и приведете примеры того, как вложенность улучшает читаемость кода где бы то ни было, или покажете другие ее плюсы.

Но тем не менее, просто сказать «как и со всем остальным, всё зависит от того, как вы ей пользуетесь» — это не ответ на моё заявление, что вложенность не может улучшить код Sass. Это всего лишь сомнительное утверждение, будто буквально всё одинаково ценно и полезно.

Заблуждение о пуллреквестах

Заблуждение о пуллреквестах — разновидность риторического приема увода в сторону. Она утверждает, что жаловаться на особенность какой-либо программы с открытым исходником неправильно, потому что можно просто послать пуллреквест и исправить ее; таким образом, весь опенсорсный софт вне критики. Недавно я процитировал этот твит с наблюдением насчет подозрительной путаницы в синтаксисе современного javascript. На это мне возразили, мол, поскольку это опенсорсная программа, я мог просто взять и «исправить ее».

Я решительно не представляю, как хотя бы подступиться к такому пуллреквесту, поскольку ему придется иметь дело с целой горой распределенных стандартных решений и кода нестандартных API, дошедших в том примере до своей высшей точки. Но не в этом суть. Из наличия Github вовсе не вытекает то, что я не вправе отпускать замечания о культуре разработки или о сомнительных плодах, которые он временами приносит.

Столь же наивно полагать, будто исправление какого-то кода пуллреквестом непременно исправит и культуру, его породившую.

Заблуждение «сделано в Фейсбуке»

Это заблуждение напоминает известную ошибку «отсылка к авторитету», когда указывают на уважаемого человека, скажем, ученого или писателя, объявляя непогрешимой истиной всё, что этот человек изрекает.

В веб-разработке мы часто пробуем вдохновиться примером известных, успешных организаций: Гугла, Фейсбука, Микрософта, Яндекса. Ну ладно, Яндекс трогать не будем. Мы ошибочно приписываем их успех принятым там методикам разработки и надеемся приманить их успех, копируя те же подходы на манер меланезийских самолетов из соломы.

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

Знаете ли вы, что OOCSS (объектно-ориентированный CSS) возник, чтобы помочь Фейсбуку с их избыточным и как попало организованным CSS? Знаете, кто его придумал? Независимый консультант.

Заблуждение фиксиков

В заблуждении фиксиков наглядно проявляется наша нехватка целостного подхода к веб-разработке. Ее можно выразить одной фразой: «Раз проблема с дизайном подтверждена, следовательно, ее нужно исправить»

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

Я привел воображаемый диалог, иллюстрирующий наш близорукий подход к проблемам, в статье «Чего нужно избегать при написании CSS (часть 2)»:

— Слушай, тут вот у меня три рекламных тизера в ряд. В каждом картинка, немного текста и кнопка (ну, ссылка). Беда в том, что текст в них разной длины, поэтому кнопки не выстраиваются в одну линию по горизонтали.

— Ну и ладно.

— В смысле, это же выглядит некрасиво. Можешь как-нибудь поправить?

— Ну, в принципе, я мог бы задать всем тизерам одинаковую высоту (чтоб самому большому хватило места), а потом абсолютным позиционированием прибить каждую кнопку к нижнему краю контейнера. Но я бы не…

— Звучит круто, так и сделай!

— Но эти тексты хотя бы уже не будут меняться, ведь если…

— ЗВУЧИТ КРУТО, ТАК И СДЕЛАЙ!

— Но ведь, если уменьшить окно браузера, текст перенесется и…

— ЗВУЧИТ. КРУТО. ТАК. И. СДЕЛАЙ.

В том, что касается разработки средств передачи информации, ничто не бывает черным или белым, сломанным или исправным. Далеко не всё — баг. Кое-что — ограничения, и от некоторых ограничений выигрывает гораздо больше пользователей, чем те немногие, ради которых затевалась «починка». Заблуждение названо в честь детского мультсериала, девиз героев которого выражен в песне: «Раз, два, три / И мы внутри / Чтоб оценить / И ПОЧИНИТЬ!».

Да, фиксики могут — тыдыщ! — починить всё, но ведь надо сперва оценить, а надо ли чинить это?

Заблуждение о реальном мире

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

Иными словами, предполагая собственный опыт всеобщим, они не могут представить себе кого-либо «в реальном мире», кто принял бы эту идею всерьез.

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

Спросите себя: «Я тут, что, самая важная шишка?»

Заблуждение «Ну что ж ты страшная такая?»

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

Один из примеров — добавление атрибутов WAI-ARIA. Да, код с ним становится «страшнее», но для этого есть важная причина (обеспечение семантики для пользователей вспомогательных технологий). Так что говорить, что это «безобразие» — хак или признак некачественного кода, будет неправильно.

Вот небольшой пример CSS:

:nth-last-child(-n+6):first-child,
:nth-last-child(-n+6):first-child ~ * {
	/* тут свойства */
}

Этот CSS делает то, чего не сделать меньшим количеством кода: он задает стиль элементам, если их шесть и более подряд. Это трудновато прочесть, если вы не спец в продвинутом CSS, и, пожалуй, его надо бы сопроводить поясняющим комментарием. Кроме того, он решает не самую очевидную задачу. Но ничто из этого не означает, что этот код плохо написан или бесполезен.

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

P.S. Это тоже может быть интересно:

• Как читать W3C-спецификации
• Голограммы, пленочные засветки и шейдеры на чистом CSS
• «Запашки» кода React-компонентов