Конечно, Джордж Оруэлл ни слова не сказал о написании кода. Но он был известен своими писательскими способностями (дух). И написание книг имеет много общего с написанием кода.

Просматривая некоторые статьи сегодня, я наткнулся на жемчужину, которой хочу поделиться. Это список правил, которые Джордж Оруэлл установил для писателей.

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

Никогда не используйте длинное слово там, где подойдет короткое.

Слова имеют цену. И валюта — это познавательная энергия читателя. Это может показаться незначительной оптимизацией, но это не так! Сложные слова имеют эффект компаундирования, и читатель должен заплатить цену. Сложность требует и утомляет.

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

Мы должны быть очень избирательны, когда дело доходит до их расходования. Очень быстро стекает.

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

Итак, будьте мудры и используйте прямолинейные слова. Не усложняйте простые вещи. Вместо «persistUserToDb» назовите его просто «saveUser» или даже лучше — «save» (при условии, что он находится в каком-то модуле, связанном с пользователем). Пусть контекст «автозаполняет» смысл. Это намного дешевле.

Если можно вырезать слово, всегда вырезайте его.

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

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

Если не 100% ДА, то НЕТ. Это помогает мне сосредоточиться на главном и не заморачиваться с ресурсоемким исходным кодом.

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

Абстракция должна быть легкой и очевидной. Самое главное — это должно быть вашим последним средством.

Никогда не используйте пассив, когда вы можете использовать актив

Пассивный залог неэффективен. Это требует большей умственной силы. Позволь мне показать тебе. Пассивный залог требует большей умственной силы. Видеть?

Пассив не является естественным. Это как бы прерывает поток.

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

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

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

Нарушьте любое из этих правил раньше, чем скажете что-нибудь откровенное варварство

Есть ментальная модель, которая называется «карта — это не территория».

Карта — это всегда несовершенное, неточное представление реальности. Так же, как любое правило там. Это просто не точно.

Да, он может дать вам подсказку или два, общее направление, но никогда не бывает 100% гарантии, что он «картирует» вашу точную территорию. Иногда это может полностью ввести вас в заблуждение.

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

Вывод

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

Первоначально опубликовано на https://borislav.xyz/