Хватит уже бояться субъективно красивых решений в коде — вы же не роботы


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


    Для меня это проявляется во всем. Я очень долго настраиваю IDE, ищу нужный шрифт, подсветку, цвет интерфейса, могу часами сидеть за настройками кодстайла, чтобы код выравнивался и строился приятно для моих глаз. Визуальная красота плавно перетекает в функциональную — я стараюсь строить дсл, использовать такие именования классов и функций, чтобы код казался супер идиоматичным и уместным конкретно здесь. Могу на этапе проектирования поменять апи своего сервиса чисто ради визуальной красоты. Могу взять и бахнуть select/map/fold вместо более перфомансного цикла for — просто потому, что с функциональным подходом мне красивей.


    И я ненавижу языки программирования с уродским синтаксисом вроде го или паскаля. Когда-то давно я купил функциональное программирование только потому, что код на F# мне показался красивей кода на C#. Я изучил его, поприменял в пет-проектах, использовал коммерчески около полугода, и вернулся в родной C#. Сейчас я достаточно интеллектуален, чтобы не пихать персистентность и функциональщину повсюду, но я очень рад, что изучил эти подходы. И очень рад, что признался себе — в ФП мне нравится именно красивость и элегантность, а не какие-то реальные бенефиты.


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


    У кода гораздо больше задач, чем просто решать бизнесовый кейс. Код надо саппортить, читать, модифицировать, он должен быть понятным, масштабируемым, гибким — и много каким ещё. Чем больше думаешь, тем больше параметров качества найдешь. Мы, инженеры, склонны в такие моменты останавливать мысленную рекурсию, и нести чушь в стиле — "На самом деле всё просто. Если код решает задачу бизнеса и не создает проблем — он хороший". Нет, всё совсем не просто. В программировании вообще ничего не просто.


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


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


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


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


    Тут вступает в игру чувство прекрасного конкретного разработчика. Все дилеммы в коде, когда задача уже решена, и функциональные требования соблюдены, я решаю на своей инженерной чуйке. Грубо говоря, когда код уже написан и работает, а архитектура моих правок достаточно сносная, чтобы отправить пулл реквест — я просто беру и начинаю делать код красивым. Делаю это наполовину подсознательно, и потому мне важно, чтобы IDE его красиво рисовала, в наушниках играла любимая музыка, а я был максимально настроен на работу с кодом.


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


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


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


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


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


    Смотрите мой подкаст

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 40

      +3
      Увы иногда обстоятельства решают больше чем сам программист, особенно если комманда большая или работаешь в стартапе. Например бывает когда бизнес просит что-то сделать аля «херак-и-в-продакшн» с огромной вероятностью твой с трудом написаный красивый код будет выкинут через 2-3 месяца за ненадобностью с требованием полностью все переписать.
        0
        Мне нравится рефакторинг. Нет, не так. Я люблю рефакторинг. Не, даже не так. Я чертовски люблю рефакторинг.

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

        Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.
        Отличная статья о компромиссах между желанием писать идеальный код и суровой реальностью.
          –9

          Это какой то хрестоматийный вид нарциссизма.
          Пофиг, что написано как попало, главное, что субъективно "красиво".

            +9
            Ну вот где вы это взяли? Серьезно, какое предложение из текста вызвало такое впечатление?
              +4
              Есть ощущение, что вы сделали какой-то свой вывод из статьи, а автор имел в виду другое.
                –5

                Да. У Вас, как и у автора… Качество кода, по всей видимости определяется субъективной эстетичностью, шрифтами и прочими очень важными аспектами. Зачем нам оптимизация и поддержка. Главное, чтоб "хорошо смотрелся". Так то весь текст пропитан этим.

                  +2
                  Само собой. Когда меня приглашают в новый проект, я первым делом заставляю всех сменить шрифт с Comic Sans на Courier New, а то код некрасивый. А вы так не делаете?
              +6

              Всё измеряется. Есть старая добрая метрика качества кода – WTF/час. И правило "пиши код так, будто поддерживать его будет склонный к насилию психопат, знающий, где ты живёшь". Так что да, красота кода – важно.

                0
                Всё измеряется.

                Вопрос объективности этого измерения.


                Так что да, красота кода – важно.

                Вопрос в том, что делать, когда понятия о красоте кода расходятся, скажем, у автора и рецензента pull request.

                  0
                  Ну мы обычно утряхиваем такие штуки во время обсуждения конфигов линтера и т.д.
                  В итоге код проекта отображает коллективное чувство прекрасного
                    +1
                    Ну мы обычно утряхиваем такие штуки во время обсуждения конфигов линтера

                    А ваше понятие красоты можно формализовать конфигом линтера?


                    Да вы счастливый человек.

                      0
                      Ну какую-то часть можно. Остальное больше устными конвенциями — ну и плюс до таких вещей, как дробление десятистрочного метода обычно ревьюверам дела нет
                        +1
                        Остальное больше устными конвенциями — ну и плюс до таких вещей, как дробление десятистрочного метода обычно ревьюверам дела нет

                        Это до тех пор, пока критерии ревьювера не выше, чем критерии автора.

                          +1
                          Да, до них. Ну я в таких вопросах не сверхпринипиален, и как то вырос уже из возраста, когда мог долго холиварить по этому поводу
                    0
                    Оцениваем итоговый wtf/час по команде, минимизируем.
                    Ну то есть как правило «красоту кода» придётся затачивать под того, кому его поддерживать.
                      0
                      Оцениваем итоговый wtf/час по команде

                      То есть даете каждому человеку прочитать код и меряете?

                        0
                        Ну, пока не удастся добиться общих впечатлений о прекрасном – можно и так. Хотя я имел в виду больше «экспертную оценку». Т.е. если A и B не сходятся во мнениях, приглашается начальник и решает.
                        Но вообще по моему опыту обычно довольно быстро удаётся договориться, и привыкаешь писать так, чтобы не оскорблять чужое чувство прекрасного.
                          0
                          Хотя я имел в виду больше «экспертную оценку». Т.е. если A и B не сходятся во мнениях, приглашается начальник и решает.

                          Это не очень хорошо сочетается с "все измеряется".


                          привыкаешь писать так, чтобы не оскорблять чужое чувство прекрасного

                          … если заинтересован.

                            0
                            Так все то может измеряется, просто мы не умеем измерять)
                              0

                              Ну, просто испытывать оба варианта – можно (т.е. измеряемость в наличии), но дорого (уходит много рабочего времени). Так что раз измерили, два измерили, а дальше уже опыт есть.


                              "Если заинтересован" на работе определяется зарплатой и т.п.
                              Если из-за сотрудника wtf/час в отделе резко вырос – или сотрудника надо менять, или отдел :-)

                    –1

                    Для каждой группы языков характерен свой стиль кода. Уродливость редко связана с самим языком.

                      +4
                      УРА! Я не один такой!
                        0
                        Машина, которая хорошо ездит должна быть красивой, мощный комп должен быть красивым, ну и жена…
                        –1
                        С каких пор хабр превратился в личный блог?
                          +4
                          Одному мне режет глаз на картинке тот факт — что код не скомпилируется?
                            +4
                            Зато красиво! :)
                            +3

                            О, да, чертовски знакомо.
                            Лично для меня, "красивый код" — это тот, при чтении которого не приходится дёргаться "эээ… чО?!" и перечитывать для вникания. Это, так сказать, идеал для вечного устремления к. Код легко читается, логика разбиения и работы видна сразу, он плавно льётся с экрана в мозг.


                            При этом жертвовать красотой и читаемостью ради производительности иной раз приходится. Двойной-тройной вложенный list comprehension в том же Python быстрее, чем разложить его в явные циклы — но как же он ломает мозг при чтении! Ибо кто на ком стоял понять сложно. Нет, иногда очень сложно. Но оно быстрее, оно отлажено и проверено, и конкретно вот тут нужна скорость. И потому чувство прекрасного переживёт, в данном конкретном случае.


                            Но если есть возможность — причесать и пригладить, разбить и пояснить. Выстроить. Легче читать — проще понимать — легче поддерживать и отлаживать. Как-то так.

                              –2
                              бизнесовый кейс.
                              Посмотрел — да нет, вроде не перевод (ну для нынешних переводов было бы нормально).
                                +2

                                В голове вертится слово "мизантроп", но это не то. В общем я вас поддерживаю. Но, скорее, эмоционально — сам я все же не такой.

                                  +2
                                  Конечно, код должен быть красивым.
                                  Ёлки-палки, ВСЁ в жизни должно быть красивым! Иначе, если что-то уродливо, можно железобетонно сказать «это баг» (иногда с этим приходится жить, но это — баг!)

                                    +1

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


                                    Но у меня есть внутреннее убеждение —- код должен быть красивым.

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

                                    Вообще, мне в голову часто взбредает всякая чепуха — типа зачем пить воду, если есть кофе или кола, или что я ненавижу все песни, где звучит пианино.

                                    И я думаю, что подсознательно — или нет — так делают все

                                    Когда внутренний голос требует

                                    Патологический перфекционизм может быть видом обсессий или компульсий или ОКР, поэтому можно попробовать лечить перфекционизм как обсессии или как компульсии или как ОКР.

                                      0

                                      "Субъективно красивый" это все равно что "хорошо работает" только первое выдает натренированная нейросетка непонятно каким образом. Она натренирована на некотором наборе компромиссов (читаемость против скорости, читаемость против быстроты разработки, концептуальная целостность против практичности и т.д.) и может работать хуже на другом.


                                      Этот набор компромиссов везде свой, даже у каждого программера свой собственный опыт.


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


                                      Если вам нужно быстро и область привычная дайте поработать нейросетке — она оценит быстрее.

                                        0
                                        В паскале не красивый код?
                                          +1
                                          У меня это вызывает ассоциации с математическими формулами. Кто занимался геймдевом, тот понимает, насколько все красиво получается в цифрах, а если в этих местах говнокодить, то и подавно проще будет заново писать) Хотя для обычной бизнес логики может и прокатит
                                            +1
                                            У меня по поводу красивости кода есть немного другая теория.
                                            С помощью языка мы излагаем свои мысли. ЯП — это формализованный язык, он достаточно отличается от разговорного, на котором мы думаем. Из-за отличий, нам постоянно приходится переводить (компилировать) ЯП на русский, это напрягает мозг. Поэтому, чем код ближе к разговорному аналогу, тем он нам кажется красивее. Причем, так как мы говорим одни и те же вещи разными словами, поэтому мы и код воспринимаем субъективно. Вывод, код — вещь динамическая, как и любой другой язык общения. Нет смысла стремится делать его идеальным, поэтому что это равносильно написанию идеального четверостишия. (Решил написать комментарий после 4 часов миграции лодаш на рамда)
                                              0
                                              Практичесик невозможно сейчас представить чтобы современный инженер создал регенеративный приемник. Или приемник с двойным усилением — когда один и тот же каскад лампы сначала усиливает высокочастотный сигнал, потом этот сигнал детектируется и идет на тот же каскад лампы для усиления звуковой частоты.

                                              Это — примеры красоты и совершенства, немыслимые сейчас.

                                                0
                                                У меня есть ощущение, что код, который хорошо работает — должен быть красивым. Как самолеты, гитары, или оружие — штуки, у которых красота форм порождена функциональными качествами.

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

                                                  0

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


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


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

                                                  –2

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

                                                  Only users with full accounts can post comments. Log in, please.