Когда я учился в университете, Leetcode поломал мне мозг. Я смотрел на лучшие из лучших решений, которые укладывались в одну строчку малопонятного кода, и в своем заблуждении думал: «Как же мне достигнуть такого высокого уровня?»
Что тут вообще происходит?
Такой подход часто называют код-гольфингом. Этим весело заниматься для собственного удовольствия, но к «хорошему коду» он имеет весьма отдаленное отношение. Все (включая и тех, кто пишет для Leetcode) в курсе, что хорошим кодом это не является. В контексте индустрии такой код – худший вариант, который можно представить.
Еще одно запоздалое прозрение для меня было связано с противоположным концом спектра: писать понятный код оказалось сложнее всего. Оглядываясь назад, могу сказать, что это вполне логично. Недаром при инспекции кода от сениора, одного из опытных сотрудников, было гораздо проще разбираться что к чему и делать замечания, чем при работе с кодом начинающего программиста на низкой должности из L3.
Как бы там ни было, я со всей отчетливостью понял, в чем заключаются сильные стороны простого кода, в ходе одного рабочего инцидента.
Как-то раз я писал модуль для обогащения данных на C++, а это язык, который сам по себе сложнее для чтения, чем прочие, в силу своей многословности. В начале работы у меня было только два файла (.h/.cpp), весь код для имплементации размещался в них. Результатом стала ужасная перепутанная мешанина внутри, которая снаружи, однако, выглядела вполне рабочей. Никакую инспекцию подобный код в жизни благополучно не прошел бы.
xkcd 1513
Я разделил имплементацию на тридцать с лишним diff-ов – в то время я работал в компании, которая использовала стекированные diff-ы. Кстати сказать, вышло так, что в этом проекте я поставил личный рекорд – выстроил цепочку diff-ов максимальной длины. Поэтому я испытывал известную гордость за итог своей работы.
Каждый diff представлял собой аккуратный фрагмент контейнированного кода, в котором специально было оставлено место, чтобы с удобством внедрять зависимости, которые могут появиться в следующих diff-ах. По необходимости в коде выделялись вспомогательные функции и вспомогательные файлы. Для каждого diff-а было обеспечено разумное покрытие модульными тестами – так чтобы охватить всё самое основное и наиболее очевидные крайние случаи, но без излишней расточительности.
Каждый из diff-ов прошел немало итераций, в ходе которых я подчищал код, проводил рефакторинг и так далее. Потребовалось гораздо больше усилий, чем я ожидал, чтобы добиться ясности в коде, тем более учитывая огромный размер программы. Что же я получил в итоге? Прекрасную платформу для модуля обогащения данных с читабельным, понятным кодом.
Сам я гордился своей работой, но когда дело дошло до ее обсуждения с начальством, неожиданно всплыли проблемы.
Я был потрясен. Этот разговор ведь не в стартапе каком-нибудь происходил, речь об одной из крупнейших технологических компаний, которая славится именно своей культурой программирования. Теперь я понимаю, почему в большой четверке на сторонний взгляд такое засилье документации. Половина документов, которые я пишу, вроде бы и писать незачем… да только придется, если хочешь прибавок к зарплате и продвижения по карьерной лестнице. Хотя культура повышений в крупнейших корпорациях – это тема для отдельной статьи (которую я намерен скоро опубликовать, подписывайтесь). Здесь же я хочу подчеркнуть, что хороший код – это предельный ясный код, не вызывающий трудностей при чтении.
Есть такая известная поговорка: «Устранять баги вдвое сложнее, чем писать код». Именно поэтому, когда ChatGPT выдает какую-то ерунду, проще попробовать еще раз с новым запросом или просто написать с нуля самому, вместо того чтобы выискивать ошибки в его ущербном коде.
Год №1: Напишу-ка этот код в одну строку со сложными абстракциями. До чего же я умный!
Год №Х: Напишу-ка этот код так, чтобы в будущем мне всё было в нем понятно.
Что тут вообще происходит?
Такой подход часто называют код-гольфингом. Этим весело заниматься для собственного удовольствия, но к «хорошему коду» он имеет весьма отдаленное отношение. Все (включая и тех, кто пишет для Leetcode) в курсе, что хорошим кодом это не является. В контексте индустрии такой код – худший вариант, который можно представить.
Еще одно запоздалое прозрение для меня было связано с противоположным концом спектра: писать понятный код оказалось сложнее всего. Оглядываясь назад, могу сказать, что это вполне логично. Недаром при инспекции кода от сениора, одного из опытных сотрудников, было гораздо проще разбираться что к чему и делать замечания, чем при работе с кодом начинающего программиста на низкой должности из L3.
Плюсы и минусы простого кода
Как бы там ни было, я со всей отчетливостью понял, в чем заключаются сильные стороны простого кода, в ходе одного рабочего инцидента.
Как-то раз я писал модуль для обогащения данных на C++, а это язык, который сам по себе сложнее для чтения, чем прочие, в силу своей многословности. В начале работы у меня было только два файла (.h/.cpp), весь код для имплементации размещался в них. Результатом стала ужасная перепутанная мешанина внутри, которая снаружи, однако, выглядела вполне рабочей. Никакую инспекцию подобный код в жизни благополучно не прошел бы.
Перевод
— Имей в виду, я самоучка, код у меня, наверное, не самый опрятный.
— Дай гляну, уверена, там ничего страшного.
— Ого. Я как будто зашла в дом, который построил ребенок, имевший в своем распоряжении только топор и картинку с домом.
Напоминает рецепт салата, написанный корпоративным юристом при помощи автозамены телефона, которая знает только формулы Excel.
Как будто кто-то записал ссору супружеской пары в Икее, а потом случайным образом исправлял что-то в записи, пока не скомпилировалось.
— Ладно, ладно, я прочитаю руководство по стилю.
— Дай гляну, уверена, там ничего страшного.
— Ого. Я как будто зашла в дом, который построил ребенок, имевший в своем распоряжении только топор и картинку с домом.
Напоминает рецепт салата, написанный корпоративным юристом при помощи автозамены телефона, которая знает только формулы Excel.
Как будто кто-то записал ссору супружеской пары в Икее, а потом случайным образом исправлял что-то в записи, пока не скомпилировалось.
— Ладно, ладно, я прочитаю руководство по стилю.
xkcd 1513
Я разделил имплементацию на тридцать с лишним diff-ов – в то время я работал в компании, которая использовала стекированные diff-ы. Кстати сказать, вышло так, что в этом проекте я поставил личный рекорд – выстроил цепочку diff-ов максимальной длины. Поэтому я испытывал известную гордость за итог своей работы.
Каждый diff представлял собой аккуратный фрагмент контейнированного кода, в котором специально было оставлено место, чтобы с удобством внедрять зависимости, которые могут появиться в следующих diff-ах. По необходимости в коде выделялись вспомогательные функции и вспомогательные файлы. Для каждого diff-а было обеспечено разумное покрытие модульными тестами – так чтобы охватить всё самое основное и наиболее очевидные крайние случаи, но без излишней расточительности.
Каждый из diff-ов прошел немало итераций, в ходе которых я подчищал код, проводил рефакторинг и так далее. Потребовалось гораздо больше усилий, чем я ожидал, чтобы добиться ясности в коде, тем более учитывая огромный размер программы. Что же я получил в итоге? Прекрасную платформу для модуля обогащения данных с читабельным, понятным кодом.
Сам я гордился своей работой, но когда дело дошло до ее обсуждения с начальством, неожиданно всплыли проблемы.
«Хоть я и понимаю всю сложность работы, с точки зрения тех, кто оценивает производительность, код выглядит примитивным. Кажется, что он слишком уж простой, незамысловатый.
Я бы посоветовал подробно расписать имплементацию этого модуля в документации, чтобы мы могли показать, что на самом деле здесь много сложного».
Я был потрясен. Этот разговор ведь не в стартапе каком-нибудь происходил, речь об одной из крупнейших технологических компаний, которая славится именно своей культурой программирования. Теперь я понимаю, почему в большой четверке на сторонний взгляд такое засилье документации. Половина документов, которые я пишу, вроде бы и писать незачем… да только придется, если хочешь прибавок к зарплате и продвижения по карьерной лестнице. Хотя культура повышений в крупнейших корпорациях – это тема для отдельной статьи (которую я намерен скоро опубликовать, подписывайтесь). Здесь же я хочу подчеркнуть, что хороший код – это предельный ясный код, не вызывающий трудностей при чтении.
Есть такая известная поговорка: «Устранять баги вдвое сложнее, чем писать код». Именно поэтому, когда ChatGPT выдает какую-то ерунду, проще попробовать еще раз с новым запросом или просто написать с нуля самому, вместо того чтобы выискивать ошибки в его ущербном коде.
Мудреный код сложнее для чтения и доступен только «посвященным».
Ясный код прост с виду, но писать его труднее.
Еще пара соображений о понятном коде
Год №1: Напишу-ка этот код в одну строку со сложными абстракциями. До чего же я умный!
Год №Х: Напишу-ка этот код так, чтобы в будущем мне всё было в нем понятно.
- Единственный метод, благодаря которому у меня стало получаться писать понятный, читабельный код – активная практика и следование конкретно изложенному руководству по стилю. Плюс помощь более опытных разработчиков, которые инспектировали мой код чуть ли не с лупой в руках. Поначалу было сущим мучением получать от них кучу замечаний и «придирок» по, казалось бы, несущественным стилистическим вопросам, но в конце концов мои страдания окупились.
- Стиль имеет гораздо более существенное значение при написании кода, чем я думал изначально. Я зашел в программирование с «продуктового» конца и уже в процессе стал перемещаться на техническую сторону. Код я начал писать исключительно ради возможности открыть свой бизнес, и поэтому рассматривал его только как инструмент для достижения цели. Результатом стал никудышный код, не поддающийся поддержке. Только с опытом разработки и работе в команде ко мне пришло понимание, насколько важен ясный, читабельный код. И я в этом не уникален. Любой, кто профессионально писал код хотя бы год, приходит к тем же выводам.
- В 2007 году Джон Кармак написал длинное электронное письмо о руководствах по стилю. Оно представляет немалый интерес.
- Наиболее открытое руководство, пожалуй, принадлежит Google. Компания Vercel также недавно выложила свое руководство в открытый доступ. Ну а линтерами и стилизаторами в наше время пользуются уже практически все.
