Search  
Always will be ready notify the world about expectations as easy as possible: job change page
24 марта

Мудрёный код — пожалуй, худший выбор

Мудрёный код — пожалуй, худший выбор
Source:
Views:
380

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

Python

Что тут вообще происходит?

Такой подход часто называют код-гольфингом. Этим весело заниматься для собственного удовольствия, но к «хорошему коду» он имеет весьма отдалённое отношение. Все (включая и тех, кто пишет для Leetcode) в курсе, что хорошим кодом это не является. В контексте индустрии такой код – худший вариант, который можно представить.

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

Плюсы и минусы простого кода

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

Как-то раз я писал модуль для обогащения данных на C++, а это язык, который сам по себе сложнее для чтения, чем прочие, в силу своей многословности. В начале работы у меня было только два файла (.h/.cpp), весь код для имплементации размещался в них. Результатом стала ужасная перепутанная мешанина внутри, которая снаружи, однако, выглядела вполне рабочей. Никакую инспекцию подобный код в жизни благополучно не прошёл бы.

Keep in mind that I'm self-taught

Перевод

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


xkcd 1513

Я разделил имплементацию на тридцать с лишним diff-ов – в то время я работал в компании, которая использовала стекированные diff-ы. Кстати сказать, вышло так, что в этом проекте я поставил личный рекорд – выстроил цепочку diff-ов максимальной длины. Поэтому я испытывал известную гордость за итог своей работы.

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

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

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

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

Я был потрясен. Этот разговор ведь не в стартапе каком-нибудь происходил, речь об одной из крупнейших технологических компаний, которая славится именно своей культурой программирования. Теперь я понимаю, почему в большой четверке на сторонний взгляд такое засилье документации. Половина документов, которые я пишу, вроде бы и писать незачем… да только придется, если хочешь прибавок к зарплате и продвижения по карьерной лестнице. Хотя культура повышений в крупнейших корпорациях – это тема для отдельной статьи (которую я намерен скоро опубликовать, подписывайтесь). Здесь же я хочу подчеркнуть, что хороший код – это предельный ясный код, не вызывающий трудностей при чтении.

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

Мудреный код сложнее для чтения и доступен только «посвященным».
Ясный код прост с виду, но писать его труднее.

Еще пара соображений о понятном коде

Let me write this code in one line

Год №1: Напишу-ка этот код в одну строку со сложными абстракциями. До чего же я умный!
Год №Х: Напишу-ка этот код так, чтобы в будущем мне всё было в нем понятно.

  • Единственный метод, благодаря которому у меня стало получаться писать понятный, читабельный код – активная практика и следование конкретно изложенному руководству по стилю. Плюс помощь более опытных разработчиков, которые инспектировали мой код чуть ли не с лупой в руках. Поначалу было сущим мучением получать от них кучу замечаний и «придирок» по, казалось бы, несущественным стилистическим вопросам, но в конце концов мои страдания окупились.
  • Стиль имеет гораздо более существенное значение при написании кода, чем я думал изначально. Я зашел в программирование с «продуктового» конца и уже в процессе стал перемещаться на техническую сторону. Код я начал писать исключительно ради возможности открыть свой бизнес, и поэтому рассматривал его только как инструмент для достижения цели. Результатом стал никудышный код, не поддающийся поддержке. Только с опытом разработки и работе в команде ко мне пришло понимание, насколько важен ясный, читабельный код. И я в этом не уникален. Любой, кто профессионально писал код хотя бы год, приходит к тем же выводам.
  • В 2007 году Джон Кармак написал длинное электронное письмо о руководствах по стилю. Оно представляет немалый интерес.
  • Наиболее открытое руководство, пожалуй, принадлежит Google. Компания Vercel также недавно выложила свое руководство в открытый доступ. Ну а линтерами и стилизаторами в наше время пользуются уже практически все.
Similar
24 марта
Автор: Сергей Кушниренко
Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и...
24 марта
Автор: Александр Клименков
Как же хочется иногда остановить дикую гонку разработки и получить удовольствие от вдумчивого, размеренного написания кода. Как же не хватает времени на обдумывание алгоритмов и исследование перспективных архитектурных вариантов системы. Как же тянет протянуть руку к стоп-крану и остановить взбесившийся...
24 марта
В современном программном обеспечении очень часто возникает необходимость выполнять различные операции с всевозможными суммами денег. Однако до сих пор мне нигде не попадалось документации, в которой были бы сведены воедино основные правила представления сумм и реализации финансовых вычислений. В этой...
23 июля 2014 г.
Исповедь 1Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.Весь мой опыт программирования складывается из университетских работ и пары...
Send message
Email
Your name
*Message


© 1999–2024 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET Framework | .NET Core | C# | ASP.NET | Windows Forms | WPF | HTML5 | CSS3 | jQuery | AJAX | Angular | React | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban