Умный код — это, вероятно, худший код, который вы можете написать

Когда я был студентом, Leetcode сломал мне мозг. Я видел топовые решения эзотерических однострочников и ошибочно думал: «Как я вообще cмогу работать так же хорошо?».

Это обычно называют «код-гольфом«. Это забавное хобби, но очень далекое от «хорошего кода».

Все (в том числе и на Leetcode) знают, что это плохой код. В индустрии это худший код, который можно написать.

Но со временем я понял, что на другом конце спектра — самый понятный код, и его, на самом деле, труднее всего написать.

Это стало понятно задним числом. Просматривать код senior staff инженера было гораздо легче, чем код инженера начального уровня L3.

Понятный код: хорошее и плохое

В полной мере «сила» понятного кода, как в хорошем, так и в плохом смысле, стала очевидной для меня после одного случая на работе.

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

Я начал всего с двух файлов (.h/.cpp), и весь код реализации поместился только в эти два файла.

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

Такая программа никогда бы не прошла code review.

Я разбил реализацию на 30 с лишним дифов. В то время я работал в компании, которая использовала стековые дифы (это также стало моим личным рекордом по длине цепочки дифов, так что я был очень горд этим результатом :)).

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

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

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

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

Хотя я и гордился этим, но когда я заговорил об этом со своим руководителем, неожиданно возникла проблема.

Хотя я понимаю, насколько это было сложно, но когда речь идет о performance review, этот код выглядит тривиально. Он выглядит слишком легко, слишком просто.

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

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

Теперь я понимал, почему в Big Tech, казалось бы, так много документации — половина документов, которые я писал, не нуждалась в написании, но они были написаны… потому что я хотел получить повышение и продвижение по службе.

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

Существует поговорка, что отлаживать код вдвое сложнее, чем писать его. Именно поэтому, когда ChatGPT выдает какую-то чушь, проще просто переспросить его или написать с нуля самому, чем пытаться разобраться с ошибками в его глючном коде.

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

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

Некоторые другие мысли о понятном коде

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

• Кроме того, более опытные разработчики просматривали мой код с увеличительным стеклом.
  • Поначалу было мучительно получать тонны замечаний и «придирок» к, казалось бы, бессмысленному стилю, но в конце концов это окупилось.

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

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

В 2007 году Джон Кармак написал длинное письмо о стиле кодирования, которое интересно почитать.

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

Источник