Хватит уже бояться субъективно красивых решений в коде — вы же не роботы
У меня есть странная привычка. Когда я заканчиваю модуль, несколько минут просто смотрю на свежий код и радуюсь, что он красивый. Я отлично знаю, что код — штука функциональная. Он должен хорошо выполнять задачу, быть удобным в обслуживании и всё. Но у меня есть внутреннее убеждение —- код должен быть красивым. Не только красивым решением —, а именно эстетически красивым.
Для меня это проявляется во всем. Я очень долго настраиваю IDE, ищу нужный шрифт, подсветку, цвет интерфейса, могу часами сидеть за настройками кодстайла, чтобы код выравнивался и строился приятно для моих глаз. Визуальная красота плавно перетекает в функциональную — я стараюсь строить дсл, использовать такие именования классов и функций, чтобы код казался супер идиоматичным и уместным конкретно здесь. Могу на этапе проектирования поменять апи своего сервиса чисто ради визуальной красоты. Могу взять и бахнуть select/map/fold вместо более перфомансного цикла for — просто потому, что с функциональным подходом мне красивей.
И я ненавижу языки программирования с уродским синтаксисом вроде го или паскаля. Когда-то давно я купил функциональное программирование только потому, что код на F# мне показался красивей кода на C#. Я изучил его, поприменял в пет-проектах, использовал коммерчески около полугода, и вернулся в родной C#. Сейчас я достаточно интеллектуален, чтобы не пихать персистентность и функциональщину повсюду, но я очень рад, что изучил эти подходы. И очень рад, что признался себе — в ФП мне нравится именно красивость и элегантность, а не какие-то реальные бенефиты.
Вообще, мне в голову часто взбредает всякая чепуха — типа зачем пить воду, если есть кофе или кола, или что я ненавижу все песни, где звучит пианино. Я помню, что я большой идиот, но думаю — эстетика кода сюда не относится.
У кода гораздо больше задач, чем просто решать бизнесовый кейс. Код надо саппортить, читать, модифицировать, он должен быть понятным, масштабируемым, гибким — и много каким ещё. Чем больше думаешь, тем больше параметров качества найдешь. Мы, инженеры, склонны в такие моменты останавливать мысленную рекурсию, и нести чушь в стиле — «На самом деле всё просто. Если код решает задачу бизнеса и не создает проблем — он хороший». Нет, всё совсем не просто. В программировании вообще ничего не просто.
Все эти параметры кода существуют, влияют на качество работы и жизни людей, и, главное — часто противоречат друг другу. Штуки вроде работоспособности или перформанса мы можем измерить около-объективно.
Но есть объективные вещи, которые мы не можем измерить метриками — и считаем их субъективными. Читабельность, элегантность и красота кода, соответствие его архитектуры всем требованиям. Мой инженерный умишко — и не только мой — не готов принять, что инженерная работа может быть напрочь субъективным творчеством. Поэтому мы напридумывали паттернов, подходов, практик и гайдлайнов. Они на самом деле тоже очень субъективные, но они хороши тем, что на деле показали — с субъективщиной можно работать. Не идеально —, но код пишется, его модифицируют, и никто не умирает.
Субъективных вопросов море. Как структурировать код, как называть сущности, как выравнивать параметры в методах, как называть параметр и поле, если они означают одну и ту же вещь, стоит ли разбивать один файл на два только из нежелания иметь раздутые файлы, должен ли ты использовать рекурсию вместо цикла, просто потому что она изящнее.
Проблема в том, что часто у меня нет времени сидеть и часами рассчитывать, в каком месте выделение подметода — это реализация принципа единой обязанности, а в каком — оверхед. Если у меня условный цикл на десять шагов в маленькой функции, не имеет большого значения, сделаю я фор или использую функциональный мап. Ну, потому что, ало, десять шагов же, какой ещё перфоманс. Я делаю такие вещи интуитивно. И если мой код будет писать другой человек, он сделает по-другому.
Тут вступает в игру чувство прекрасного конкретного разработчика. Все дилеммы в коде, когда задача уже решена, и функциональные требования соблюдены, я решаю на своей инженерной чуйке. Грубо говоря, когда код уже написан и работает, а архитектура моих правок достаточно сносная, чтобы отправить пулл реквест — я просто беру и начинаю делать код красивым. Делаю это наполовину подсознательно, и потому мне важно, чтобы IDE его красиво рисовала, в наушниках играла любимая музыка, а я был максимально настроен на работу с кодом.
Поймите правильно, я работаю над большими проектами. Во многих из них всякие ридабилити — ключевой показатель кода. Бывает, вношу по пять тысяч строк кода сразу, и бюджета вот прям все посчитать, составить таблички и обсудить с коллегами каждую строку — ну просто нет. А бегло глянуть, и понять, красиво или некрасиво, можно.
У меня есть ощущение, что код, который хорошо работает — должен быть красивым. Как самолеты, гитары, или оружие — штуки, у которых красота форм порождена функциональными качествами. Я считаю, код из таких штук. Ты можешь написать красивый, но плохой код, но ты не можешь написать хороший, но некрасивый код.
Я следую этой идее, когда у меня нет ресурсов, чтобы полагаться на метрики, и когда известные практики не дают ответа на мои вопросы. Я опираюсь на чувство прекрасного, когда мы с командами вырабатываем кодстайл проекта. И я думаю, что подсознательно — или нет — так делают все инженеры. Но не говорят об этом.
Поэтому я призываю вас понять и принять наконец идею, что мы живем в мире, где не все можно посчитать и описать в логичных табличках, и не на все можно выработать четкий алгоритм решений. И согласиться с тем, что это не так уж и страшно.
Ваше чувство прекрасного касательно кода сформировано вашим опытом, и за этим стоит гораздо больше работы вашего мозга, чем кажется. Не стоит посылать его в жопу. Когда внутренний голос требует поменять форматирование скобочек в вашем сишарп проекте — послушайте его. Возможно он знает намного больше, чем вы.
Смотрите мой подкаст
