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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

Машина, которая хорошо ездит должна быть красивой, мощный комп должен быть красивым, ну и жена…
Одному мне режет глаз на картинке тот факт — что код не скомпилируется?

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


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


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

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

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

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

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


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

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

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

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

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

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

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


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


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


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

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

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

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

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

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


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


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

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

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