Имеет ли значение красивый код?

Имеет ли значение красивый код?

автор Натан Винч

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

Красивый код - это то, чем я увлекаюсь, и я хотел поделиться своими мыслями по этой теме.

Почему мы находим вещи красивыми?

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

Каждый разработчик имеет уникальное представление о том, что такое красивый код и как он им кажется.

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

Как выглядит красивый код?

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

Давайте посмотрим на что-нибудь базовое, например, на функции обертывания:

1. dispatch(getThing(Thing(true)))
2. compose(dispatch, getThing, Thing)(true)

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

Понимание читателя также является важным фактором. Они понимают композицию? Есть ли у них опыт использования каких-либо библиотек? Разработчик, имеющий большой опыт использования служебных библиотек, таких как Lodash и Underscore, сможет более быстро проследить за невидимой сантехникой, которую такие библиотеки прячут.

Давайте посмотрим на другой пример, на этот раз касающийся потока условных выражений:

function callGarry(available, charged, message) {
  if (available) {
    if (charged) {
      if (message) {
        console.log(message);
      }
    }
  }
}

Вложенность затрудняет чтение кода. Мы также используем лишнее количество места, чтобы подробно описать, какие условия должны быть выполнены, прежде чем мы сможем позвонить Гарри. Более понятный и приятный способ написать это:

function callGarry(available, charged, message) {
  if (available && charged && message) console.log(message);
}

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

Для кого мы разрабатываем наш код?

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

Я вспоминаю слова своего универа из моей первой лекции «Введение в Java»:

«Всегда пишите код для следующего разработчика».

Это произвело на меня настоящий отклик еще в марте 2000 года, и звучит громко до сих пор.

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

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

Написание красивого кода занимает много времени?

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

Где заканчивается коммерческая ответственность и начинается художественная лицензия?

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

Уродливый код - это питательная среда для уродливого кода.

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

Сколько себя помню, я всегда стремился писать красивый код. Я? Я не знаю. Но погоня никогда не бывает унылой. Имеет ли значение красивый код? Да, мне нравится думать, что это так.

Что вы думаете?