Что означает читаемость кода?

  • Эта публикация - перевод статьи. Ее автор - Greg Jorgensen. Оригинал доступен по ссылке ниже:

Программисты жалуются на удобочитаемость и говорят о плохом коде и нечистом коде, а также о трудностях, с которыми они сталкиваются, пытаясь понять и сохранить этот код. Что мы понимаем под читабельностью? Что делает код нечитаемым?

Переопределение проблемы

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

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

Просто перефразируя утверждение «этот код нечитабельно», поскольку «я не могу прочитать этот код» ставит проблему в перспективе.

По аналогии, многие люди находят чтение Гомера, Шекспира или Набокова трудным и сложным, но мы не говорим: «Макбет не читается». Мы понимаем, что проблема кроется с читателем. У нас может не быть достаточного опыта работы с языком и идиомами. У нас может не быть достаточно исторического и культурного контекста (аналогично отсутствию опыта работы в области знаний при просмотре программного обеспечения). У нас может не быть терпения или желания вкладывать время в изучение того, как читать сложную книгу. Статьи Википедии и заметки Клиффасуществуют, чтобы дать версии книг для пользователей, которые не могут или не хотят читать оригинал. Когда мы наблюдаем эту тенденцию в других (не-программирующих) контекстах, мы можем интерпретировать ее как лень или короткий промежуток внимания. Когда мы реагируем таким образом на код, мы обвиняем код и оригинального программиста.

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

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

Ошибка программирования

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

Я лично стал свидетелем (более чем в несколько раз) профессиональных программистов уволить работу, производственный код как «нечитаемый» и «неподъемный», посмотрев на него всего несколько минут. Их возражения обычно сводятся к эстетике: «Я ненавижу PHP». «В коде вместо вкладок используются пробелы и плохо выглядит в моем редакторе». «Код не был написан с помощью классов и объектов». Они не потратили достаточно времени понимать систему или достаточно изучать бизнес-домен, чтобы читать код в контексте (например, кто-то не знает о древнегреческой истории, отбрасывающей «Илиаду» ).

Программисты, которые смотрят код, который они не понимают или не любят, могут найти примеры священных принципов и так называемые лучшие практики: «Это нарушает принцип единой ответственности». «Это выглядит как СУХОЕ нарушение». «Глобалы - это запах кода ». Затем они предлагают переписать систему или, возможно, переписать ее на предпочтительном языке, идиоме и стиле (часто ошибочно называемом« рефакторинг », потому что это звучит как техническая вещь для клиента или босса).

Всякий раз, когда я должен думать, чтобы понять, что делает код, я спрашиваю себя, могу ли я реорганизовать код, чтобы сделать это понимание более очевидным. - Мартин Фаулер.

Любой дурак может написать код, который компьютер может понять. Хорошие программисты пишут код, который люди могут понять. - Мартин Фаулер

Все уважение к Мартину Фаулеру, но эти цитаты иллюстрируют мою мысль. Мой опыт побуждает меня ожидать что я буду «думать», чтобы понять незнакомый код. Как мне тяжело думать, но я не ожидаю немедленного понимания нетривиального кода с первого взгляда, даже с моим многолетним опытом. После того, как я понял код, я могу подумать, что могу писать его более четко и реорганизовать, или я чувствую, что узнал что-то новое из кода и оставил его в покое. Я не думаю, что код должен подходить к пониманию с первого взгляда, особенно учитывая очень широкий диапазон навыков и опыта среди программистов. И я не называю других программистов дураками, если я не сразу понимаю их код. «Другие люди» или даже другие программисты включают слишком много людей в обширном спектре навыков и опыта, чтобы «написать код, который люди могут понять», значимую цель.Голодные гусеницы и щенок Peek-a-boo на наших книжных полках.

Просто потому, что люди говорят вам, что это невозможно сделать, это не обязательно означает, что это невозможно. Это просто означает, что они не могут этого сделать. - Андерс Хейлсберг

Это так же важно при чтении кода, как при написании кода. Помните, что в следующий раз, когда вы или кто-то, с кем работаете, объявляют код «нечитаемым» и «невозможно поддерживать».

Истинный тест интеллекта - это не то, насколько мы знаем, как это сделать, но как вести себя, когда мы не знаем, что делать. - Джон Холт

Простой против тупика вниз

Это натолкнулось на мой канал Twitter некоторое время назад:

Хороший код прост. Кодовые обзоры - отличный способ обучить команды писать простой код. Не бойтесь сказать «это трудно понять». - Эрик Эллиот

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

Означает ли это, что все программисты должны заглушить свой код, поэтому даже новички, не имеющие опыта работы в домене, могут сразу это понять? Должны ли мы стремиться удовлетворить Шекспира для чайников?демографические? Когда я сталкиваюсь с кодом, я не понимаю, что сначала задаю свои собственные навыки и терпение, и если у меня будет достаточная мотивация (например, платежный клиент), я потрачу время на изучение кода, чтобы улучшить свою способность его понимать. Мне, возможно, придется посмотреть документацию на языке или рамочную документацию или поэкспериментировать с кодом, чтобы выяснить, как это работает. Когда я понимаю код, я могу подумать, что я знаю более простой или более понятный способ выразить это, или я могу подумать, что код только представил мне вызов, потому что у меня не было навыков, знаний или правильного настроя. По моему опыту вычисление кода требует значительных усилий и времени, но когда я получаю это, я обычно не думаю, что код имеет фатальные ошибки чтения или что исходный программист не знал, как писать код.

Контрольная сложность - это суть компьютерного программирования. - Брайан У. Керниган

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

Производительность

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

В давние времена программисты писали код, который могли бы увидеть немногие другие программисты - другие члены их команды или группы, их наставники, возможно, аналитик или менеджер проекта. Теперь у нас есть открытый исходный код, и люди публикуют свой код в блогах и в вопросах переполнения стека. Программисты, склонные вкладывать свое эго в свой код, беспокоятся о критике со стороны многих людей, которых они не знают. Оскорбления в области компетенции изобилуют на форумах программистов. Образцы кода из контекста подвергаются критике и подвергаются стилистическому набору нит. Этот процесс может оказаться полезным для программистов с толстой шкурой, которые могут интерпретировать критику как полезное наставничество или бесполезные оскорбления. Менее опытные программисты могут ввести в заблуждение и бровь. Публичные обзоры кода создают своеобразное представление о производительности программиста, когда программисты пишут код, чтобы произвести впечатление на других программистов,

Ключом к эффективному развитию является совершение интересных новых ошибок. - Том Любви

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

Программирование - это форма творческого искусства, основанная на логике. Каждый программист отличается и кодируется по-разному. Это важно. - Джон Ромеро

Наиболее важным свойством программы является то, выполняет ли она намерение своего пользователя. - Автомобильный хор

Лучшее программирование происходит через практику, изучение (из книг и другого кода) и наставничество. Это происходит не от попыток слепо придерживаться правил, догм и грузов, которые вы не понимаете или не можете относиться к реальному кодексу.

Как написать читаемый код

Когда я начал программировать в середине 1970-х годов, один из моих наставников дал мне копию «Элементов стиля программирования» (Kernighan and Plauger, 1974). Из этой книги я узнал, что некоторые методы часто работают лучше, чем другие, я узнал о языковых идиомах, названии переменных и функций и других стилистических и эстетических соображениях, которые застряли со мной. Оттуда я прочитал немало других книг о «хорошем» программировании, выше уровня стиля и эстетики. И я прочитал много кода, некоторые из которых я понял и много чего не понял (или не понял сразу). Как английская классика «Элементы стиля», Kernighan и Plauger фокусируются главным образом на методах кодирования и стиле, а не на более крупных проблемах проектирования системы, разложения модулей, сцепления и сцепления, а также на сборе требований. Элементами стиля программированияслужит отправная точка, введение в разработку стиля, который сделает ваш код выразительным, сжатым и понятным для чтения. Подобным образом Элементы стиля советуют «Опустить ненужные слова» и предостерегают авторов от пассивного голоса и слишком многих прилагательных.

Мы строим наш компьютер (системы) так, как мы строим наши города: со временем, без плана, поверх руин. - Эллен Ульман

Ну, да, и мы склонны любить многие из наших городов. Я согласен с Эллен Ульман в том, что разработка программного обеспечения часто следует более случайному пути, чем нам нравится говорить. Это просто означает, что мы не можем надежно предсказать будущее, и у нас не всегда есть ресурсы или желание оторвать вещи и начать все заново. В жанре афоризмов программирования есть такие утверждения, которые имеют смысл только в том случае, если мы верим в «правильный путь» к разработке программного обеспечения, к набору жестких, проверенных принципов, которые приводят к «хорошему» коду, и что любой код, t сразу понимают, должно иметь присущую плохую ошибку, или указывает на дурака на клавиатуре.

Программисты, кажется, верят в царство красивого, читаемого, простого в обслуживании кода, с которым они еще не видели или не работали. Они, похоже, думают, что другие программисты получают время и поддержку для написания совершенного, чистого, проверенного кода. Это мифическое царство не существует. Весь код перегоняет и расстраивает и оскорбляет значительную часть программистов. Все программное обеспечение разрабатывается с учетом времени, бюджета, управления, требований и ограничений навыков, которые не позволяют делать что-либо совершенно. Мы должны держать эти ограничения и ограничения в виду, когда мы смотрим на код и немедленно заключаем, что код не согласуется с пониманием или что только дураки могли бы создать такое программное обеспечение.

Никто в краткой истории вычислений никогда не писал идеальное программное обеспечение. Вряд ли вы станете первыми. - Энди Хант

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