Когда я был студентом, Leetcode сломал мне мозг. Я видел топовые решения эзотерических однострочников и ошибочно думал: «Как я вообще cмогу работать так же хорошо?».
Это обычно называют «код-гольфом«. Это забавное хобби, но очень далекое от «хорошего кода».
Все (в том числе и на Leetcode) знают, что это плохой код. В индустрии это худший код, который можно написать.
Но со временем я понял, что на другом конце спектра — самый понятный код, и его, на самом деле, труднее всего написать.
Это стало понятно задним числом. Просматривать код senior staff инженера было гораздо легче, чем код инженера начального уровня L3.
Понятный код: хорошее и плохое
В полной мере «сила» понятного кода, как в хорошем, так и в плохом смысле, стала очевидной для меня после одного случая на работе.
Однажды я писал модуль обогащения данных на C++ — языке, который обычно труднее читать по сравнению с другими языками просто из-за его многословности.
Я начал всего с двух файлов (.h/.cpp), и весь код реализации поместился только в эти два файла.
В результате получился огромный, отвратительный кусок спагетти внутри, но прекрасно работающая программа снаружи.
Такая программа никогда бы не прошла code review.
Я разбил реализацию на 30 с лишним дифов. В то время я работал в компании, которая использовала стековые дифы (это также стало моим личным рекордом по длине цепочки дифов, так что я был очень горд этим результатом :)).
Каждый диф представлял собой аккуратный контейнерный кусок кода с удобными плейсхолдером для зависимостей, которые появятся в последующих дифах. При необходимости код аккуратно разбивался на вспомогательные функции и вспомогательные файлы.
В каждом дифе было разумное покрытие юнит-тестами — основные и некоторые очевидные крайние случаи были покрыты, но я не перебарщивал с этим.
Кроме того, каждый диф потребовал от меня нескольких итераций «очистки кода», рефакторинга и прочего. Для достижения «понятного кода» потребовалось гораздо больше усилий, чем я ожидал, особенно для такой большой программы.
Результат? Красивый модуль обогащения данных с легко читаемым и понятным кодом.
Хотя я и гордился этим, но когда я заговорил об этом со своим руководителем, неожиданно возникла проблема.
Хотя я понимаю, насколько это было сложно, но когда речь идет о performance review, этот код выглядит тривиально. Он выглядит слишком легко, слишком просто.
Я бы рекомендовал написать документ по реализации этого модуля, чтобы мы могли продемонстрировать, что на самом деле он был достаточно сложным.
Я был потрясен — это был не какой-то стартап. Это была одна из крупнейших компаний в мире, известная своей инженерной культурой.
Теперь я понимал, почему в Big Tech, казалось бы, так много документации — половина документов, которые я писал, не нуждалась в написании, но они были написаны… потому что я хотел получить повышение и продвижение по службе.
Хотя культура продвижения в Big Tech — это история для другой статьи, главное здесь то, что отличный код очень понятен и читабелен.
Существует поговорка, что отлаживать код вдвое сложнее, чем писать его. Именно поэтому, когда ChatGPT выдает какую-то чушь, проще просто переспросить его или написать с нуля самому, чем пытаться разобраться с ошибками в его глючном коде.
Умный код труднее читать и он выглядит эзотерическим.
Понятный код труднее писать и он выглядит просто.
Некоторые другие мысли о понятном коде
Единственный способ стать лучше в написании понятного, читабельного кода — это писать много кода, строго следуя четкому руководству по стилю.
- Кроме того, более опытные разработчики просматривали мой код с увеличительным стеклом.
- Поначалу было мучительно получать тонны замечаний и «придирок» к, казалось бы, бессмысленному стилю, но в конце концов это окупилось.
Стиль кодирования гораздо важнее, чем я предполагал вначале. Мой путь в программной инженерии начался с того, что я был ориентирован на продукт и перешел на «техническую» сторону спектра.
- Я начал заниматься программированием исключительно для того, чтобы начать свой бизнес, поэтому изначально меня интересовал только код как инструмент, что приводило к созданию дрянного, не поддерживаемого в рабочем состоянии кода.
- Только с приобретением опыта написания кода и работы в команде важность понятного, читаемого кода стала более очевидной.
- И не только мне. Это очевидное откровение для любого, кто пишет код в индустрии больше года.
В 2007 году Джон Кармак написал длинное письмо о стиле кодирования, которое интересно почитать.
Google, вероятно, имеет наиболее публичное руководство по стилю. Компания Vercel также недавно выпустила свое руководство по стилю, и практически каждая компания использует тот или иной линтер и преттифайер.