Поиск  
Always will be ready notify the world about expectations as easy as possible: job change page
24 марта

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

Мудрёный код — пожалуй, худший выбор
Автор:
Источник:
Просмотров:
436

Когда я учился в университете, 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 также недавно выложила свое руководство в открытый доступ. Ну а линтерами и стилизаторами в наше время пользуются уже практически все.
Похожее
24 марта
Автор: Сергей Кушниренко
Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и...
24 марта
Автор: MaxRokatansky
Автор оригинала: Stephen Young“Так, что здесь, черт побери, происходит?!?”Сейчас 1:30 ночи, и я смотрю на фрагмент кода, который написал около месяца назад. В то время он казался мне произведением искусства. Все здесь имело смысл. Он был элегантен, прост и замечателен....
15 марта
Автор: Рустем Галиев
Blazor — это технология, позволяющая создавать клиентские веб-приложения с использованием C# и .NET, а не JavaScript. Blazor может запускать ваш код одним из двух способов. Blazor WebAssembly выполняет код C# на стороне клиента в любом современном браузере, поддерживающем WebAssembly. Blazor...
24 марта
Я начал писать код в моей комнате родительского дома, когда мне было 14. Помню, как читал всё, что мог достать с помощью своего медленного соединения с Интернетом. Затем, когда мне было 20, я подписал первый контракт, став веб-разработчиком и изучая...
Написать сообщение
Почта
Имя
*Сообщение


© 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