Почему лучшие программисты — это филологи (сами того не подозревая). Что общего у переменной temp и прозвища «Очкарик»?

Привет, Хабр!

Меня зовут Артем Лакомов, я филолог из МГУ. Да, вы не ослышались. И сегодня я хочу поговорить с вами о самой главной (и самой дорогой) боли в IT, но с совершенно неожиданной стороны.

Каждый из вас хоть раз в жизни видел код, от которого хотелось плакать или же тихо ненавидеть свою работу. Код с переменными вроде data, res, temp. Код, где есть один гигантский класс, который делает абсолютно всё, и коллеги с любовью (или ужасом) называют его godObject.

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

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

Давайте я покажу вам, как теория прозвищ, разработанная великим отечественным лингвистом А.В. Суперанской, вскрывает то, о чем инженеры только догадывались интуитивно, но, увы, не могли сформулировать.

1. Именование «от взора и естества» (или «Что вижу, то пою»)

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

Это ваш godObject. Это ваш spaghettiCode.

Это имя-диагноз, которое дается не за функцию, а за внешний вид и внутреннее устройство — его чудовищный размер или запутанную структуру. Это точная копия прозвища Громадила или Трёхтонка. Имя здесь — не просто ярлык, а оценочное суждение всего коллектива.

А еще это ваши utils, manager, handler — имена, которые ничего не говорят о функции, но многое — о том, что автор не знал, как назвать. Как прозвище «Тихоня» для того, кто просто не любит говорить.

2. Именование «от вещи» (или Великая Сила Метафоры)

Как назвать сложный процесс обработки данных? Конечно, DataPipeline (конвейер данных). А систему защиты? Firewall (огнеупорная стена). Здесь мы просто берем понятный объект из физического мира и переносим его свойства на абстрактную цифровую сущность.

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

3. Именование «от прецедента» (или Привет, гик-культура!)

А вот тут начинается самое интересное. Это высший пилотаж именования.

Heisenbug: Ошибка, которая исчезает, когда вы пытаетесь на нее посмотреть. Это прямая отсылка к принципу неопределенности Гейзенберга из квантовой физики.

Yoda Conditions: Конструкция if ("constant" == variable). Названа в честь магистра Йоды за инвертированный порядок слов.

Или возьмите zombie processes — процессы-зомби в Unix, которые формально мертвы, но все еще занимают место в таблице процессов. Или daemon — демоны, фоновые процессы, названные в честь добрых духов из греческой мифологии. Каждое такое имя — это культурный код, понятный только посвященным.

Зачем мы это делаем? Суперанская отвечает: такие прозвища (Аниськин, Белинский) работают как маркер принадлежности к группе. Они выполняют две важнейшие функции.

Сжимают информацию: Сказал Heisenbug — и коллега мгновенно понял всю сложность проблемы.

Разделяют на «своих» и «чужих»: Если ты понимаешь аллюзию (культурную отсылку) в Yoda Conditions — ты «свой», ты часть этой общей культуры. Если нет — тебе еще многому предстоит научиться.

4. Именование «от притчи» (или «Шрамы, которые мы оставляем в коде»)

У Суперанской есть и четвертая, самая редкая и интересная модель: прозвище, данное по какому-то уникальному событию или истории. Например, «Клубничник» — потому что когда-то попался на воровстве клубники. Такое имя — это маленький рассказ, понятный только тем, кто знает его предысторию.

В коде это — один из самых мощных прагматических инструментов. Каждый раз, когда вы видите имена вроде:

legacyAuthFix

hotfixForTicketJIRA123

tempWorkaroundForIE6

...перед вами не просто имя, а имя-нарратив. Оно рассказывает целую историю: «Этот код — костыль, потому что старая система аутентификации отвалилась», «Это срочная заплатка для конкретной задачи в Jira, не трогай ее, пока не прочитаешь тикет», «Это временное решение для проклятого Internet Explorer 6, и мы все надеемся его когда-нибудь удалить».

Или же возьмем для примера следующие наименования: 

quickFixForDemo

dontTouchThisItWorks

// TODO: refactor this mess

Каждое такое имя — это предупреждение будущим поколениям разработчиков: «Здесь была битва. Здесь принимались сложные решения. Осторожно.»

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

Так что же делать? Три принципа, которые изменят ваш код

Хорошо, скажете вы, это все очень интересно, но что мне с этим делать завтра на код-ревью?

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

1. Осознайте свою роль. Вы — Ономат (name-giver). 

   Каждый раз, когда вы пишете let data = ..., вы не просто создаете переменную. Вы совершаете акт номинации. Вы даете имя новой сущности в вашем маленьком мире. Подойдите к этому не как к рутине, а как к важнейшей части вашей работы. Ваше имя — это первое, что увидит другой человек. Это ваш шанс объяснить ему суть, помочь или, наоборот, навсегда запутать. Подобно автору, выступающего в роли того, кто дает имя, вы создаете уникальных персонажей в своем собственном произведении.

2. Думайте о «читателе», а не только о «писателе».

   Самая частая ошибка — давать имя, понятное только вам в данный момент. Теория Суперанской и практика IT доказывают: имя существует не для вас, а для коллектива. Перед тем как назвать переменную temp, спросите себя: «Поймет ли мой коллега через полгода, что здесь имелось в виду, без моих устных комментариев?». Если ответ «нет» — ищите другое имя.

3. Исповедуйте «Принцип семантической полноты».

   В итоге, все сводится к одному. Хорошее имя — это то, которое обладает семантической полнотой и предсказуемостью. Оно должно исчерпывающе отвечать на вопрос «что это?» и позволять предсказать, «как оно себя ведет». Имя archive_inactive_users_and_notify() длинное, но оно идеально. Оно полное и предсказуемое. Имя proc_users() — короткое, но бесполезное. Оно скрывает суть, а не раскрывает ее.

Чтобы разница была еще нагляднее, давайте просто посмотрим на примеры в таблице:

Плохо (Имена-диагнозы, скрывающие суть)	Хорошо (Имена-действия, раскрывающие суть)
data, info, temp, item, list	userProfile, emailList, validUsers
utils, helper, manager, handler	EmailValidator, TaxCalculator, CurrencyFormatter
doStuff(), handleIt(), processData()	parseUserInput(), sendNotification(), updateUserProfile()

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

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

Заключение: Код — это гуманитарная дисциплина

Мы привыкли думать о программировании как о чисто технической сфере. Но чем дальше, тем очевиднее становится то, о чем писал еще Дональд Кнут: 

программы пишутся для людей.

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

И всегда помните: каждый раз, когда вы пишете let data = ... , где-то плачет филолог. Не потому что это технически неверно, а потому что вы упускаете шанс рассказать историю. А хороший код, как и хорошая литература, всегда рассказывает историю.

Спасибо за ваше время!

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

Об авторе

Артем Лакомов

аспирант кафедры английского языкознания филологического факультета МГУ им. М.В. Ломоносова, преподаватель РТУ МИРЭА

Эта статья — часть большой научной работы и первая в запланированном цикле, посвященном созданию нового подхода на стыке IT и лингвистики. Сегодня мы поговорили о «слове» в коде. В следующих статьях мы перейдем к анализу «высказывания» (почему один код — поэзия, а другой — шум) и, самое главное, наконец-то объясним с научной точки зрения феномен «естественности кода» — ту самую «магию», которая зафиксирована во многих исследованиях, но до сих пор не имела строгого объяснения.

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