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

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

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

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

«Zǐ lù сказал: если бы вэйский монарх решил, что мастер станет правителем, что бы мастер сделал в первую очередь?»
«Учитель сказал: имена нужно будет исправить«.
«Zǐ lù сказал: ты бы это сделал? учитель — педант! зачем их исправлять?»
«Учитель сказал: потому что, если имена не исправлены, тогда слова неэффективны; если слова неэффективны, тогда дела не выполняются […]».

Когда имя перестает помогать

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

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

«Мы используем Viper [‘víbora’] для настройки, Cobra для командной строки, Melody для веб-сокетов, Casbin для разрешений и Asynq для рабочих очередей».

С точки зрения слушателя, эта фраза требует немедленных дополнительных усилий: остановиться, сопоставить каждое имя с его реальной функцией, обратиться к документации или выполнить принудительный мысленный поиск. Из всех названий только последнее имеет какое-либо отношение к его функциям: Asynq — это библиотека для асинхронной обработки задач и очередей заданий в Go (job queue).

В других отраслях инженерии этого бы не произошло

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

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

На заре компьютерных наук этот же принцип был нормой. Такие инструменты, как ‘grep‘ (печать глобальных регулярных выражений), ‘sed‘ (редактор потоков), ‘diff ‘(разница) или ‘cat‘ (объединить), оказались не очень лиричными, но функциональными. Ранние языки программирования также следовали этой логике: FORTRAN, COBOL, BASIC, SQL. Даже когда были сокращения, смысл был налицо.

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

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

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

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

Другая точка зрения

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

«Разработчики не» выходили из-под контроля «, мы никогда не сталкивались с этим, и точка».

Одна из первых реакций форума — отказаться от идеализации «классических» названий Unix и раннего программного обеспечения. Упоминаются такие примеры, как:

• GNU, рекурсивная аббревиатура (т.е. Включающая в себя:»GNU’s Not Unix»).
• awk, инициалы фамилий (в честь их создателей Ахо, Вайнбергера и Кернигана).
• dd, пожалуй, самый крайний случай: кажется, никто не согласен с тем, что это на самом деле означает.

Другие признают, что не все имена являются полностью бессмысленными. но то, что многие работают только в очень специфическом историческом и культурном контексте … и что если вы его не знаете, имя перестает быть подсказкой и превращается в иероглиф. Пример приложения «Bison» (Бизон) оказывается парадигматичным: это версия Yacc («Еще один компилятор-Компилятор») для GNU, которая звучит так же, как «yak» (животное, родственное бизону).

Знакомство и ясность — это не одно и то же

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

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

С этой точки зрения проблема не столько в названии, сколько в объеме: сегодня количество инструментов, библиотек и фреймворков резко возросло; каждый год появляются тысячи новых проектов, и когнитивная нагрузка возникает не из-за того, что одно имя редкое, а из-за того, что нужно выучить слишком много имен.

Маркетинг, удобство поиска и SEO

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

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

Так что проблем нет?

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

В некоторых комментариях обнаруживается очень интересная промежуточная точка: имена работают лучше всего, когда есть связь, пусть даже метафорическая, с тем, что делает инструмент. Bison работает, потому что это “GNU Yacc”; sodium, потому что он происходит от NaCl; grep, потому что он отсылает к конкретному действию в ed.

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

Редактор: AndreyEx