Как вы узнаете, если вы написали читаемый и легко ремонтируемый код?

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

Эти цели выполняются, когда вы можете сделать следующее с кодом без экспертного совета оригинального автора:

  • Можно прочитать код и понять на базовом уровне поток логики.

  • На более глубоком уровне можно понять, что делает код для включения входов, выходов и алгоритмов.

  • Другие разработчики могут внести существенные изменения в исходный код, такие как исправления ошибок или рефакторинг.

  • Можно написать новый код, например класс или модуль, который использует исходный код.

Как мы измеряем или измеряем качество кода, чтобы мы знали его читабельным, понятным и поддерживаемым?

306 голосов | спросил 13 revs, 10 users 32%
user22815
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

19 ответов


332

Ваш коллега говорит вам после просмотра кода.

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
207

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

Если вы это понимаете быстро - это можно прочитать.

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
85

Это:

  1. поддерживаемый , если вы можете его сохранить .
  2. легко поддерживаемый, если кто-то может его поддерживать , не прося вас о помощи
  3. читается, если кто-то еще , при чтении, правильно понимает дизайн, макет и намерение

Настоящий тест для 1. является (как Alex в Париже и quant_dev ), что вы можете забрать его обратно через несколько месяцев, делая что-то еще.

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

Есть правила большого пальца руки, принципы (т. е. эмпирические правила, которые кто-то написал хорошо и дали имя) и всевозможные предложения, которые могут привести вас в правильном направлении или вдали от общих ошибок. Никто из них не гарантирует качества, о которых вы просите.

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
28

Если ваш код соответствует принципам SOLID и DRY и имеет хороший набор единичных тестов вокруг него, вероятно, поддерживается.

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
20

Несмотря на то, как это кажется, есть некоторые довольно объективные меры, которые вы можете рассмотреть. Книги, такие как стандарты кодирования C ++ , рефакторинг и «Чистый код» имеют длинные списки критериев для оценки вашего кода, рассматривая такие вещи, как значащие имена, размеры функций, принципы, такие как сцепление и сцепление, дизайн объекта , модульное тестирование, последовательное уточнение и т. д.

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
20

Чтение Как писать неподъемный Код - Обеспечьте работу на всю жизнь Роди Грин, смеясь и учись.

  

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

В эссе приводятся многочисленные примеры того, как писать плохой код, используя множество забавных примеров. Он продолжает объяснять, как использовать Creative Miss-spelling , Повторное использование имен , высоко оцененный метод Повторное использование глобальных имен как Private .

Юмористическим способом эссе учит вас, как избежать всех примеров нечитаемого и неподдающегося сохранению кода.

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
17

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

Это был ранний урок в моей карьере. Наставник сказал: «Документируйте все, чтобы позже вы могли избежать программы. Если вы не ожидаете вопросов, когда ответы будут свежими в вашем сознании, вам придется их выяснить, когда они этого не сделают».

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
16

Я прочитал все ответы, и я заметил, что никто не упомянул о сложности кода.

Существует плохая корреляция между сложностью кода и удобочитаемостью /ремонтопригодностью. Существует множество алгоритмов подсчета сложности кода, но я просто расскажу о том, как работает оценка McCabe.

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

Если у вас 10 строк кода, и через этот код есть 300 путей, это довольно красивый код (трудно меняться безопасно и легко), и, вероятно, он не очень читабельен. И наоборот, если у вас есть 300 строк кода, но есть только один путь (он не имеет условий), он читается и легко поддерживается.

В то время, когда МакКейб падает, в последнем примере. Если у меня есть 300 строк кода без каких-либо условий, есть действительно хороший шанс, что я сделал «повторное использование копии /вставки», и, очевидно, это тоже нехорошо. Таким образом, существуют системные показатели, которые вы применяете в дополнение к McCabe - как дублирование или почти дублирование кода.

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
8

Одна точка, которую я бы разделил, - это если код встроен в «модули», и когда я говорю, что я имею в виду, что вы можете изменить одну вещь в модуле и легко заставить ее работать со всем. Он устраняет эффекты между несвязанными вещами. Также:

  • Код легко использовать повторно
  • Ваш код является гибким (это связано с построением модулей)
  • DRY - не повторяйте себя

Я настоятельно рекомендую прочитать «Прагматический программист».

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
8

Некоторые тесты /индикаторы:

  • Выключите среду IDE. Можете ли вы прочитать свой собственный код? Когда есть ошибка, довольно легко проследить ее вручную и выяснить, какой класс вам нужен, чтобы выяснить, в чем проблема? Или когда вы используете IDE, вы просто не беспокоитесь и просто переходите с самого начала?

  • Отладка часто становится игрой wack-a-mole, где исправление одной ошибки создает еще 2.

  • От срабатывания триггера до чего-то полезного на самом деле происходит, сколько вызовов методов требуется? Сколько методов передает одни и те же или большинство одинаковых точных параметров на другой вызов метода?

  • Сколько файлов вам нужно открыть, чтобы просто добавить простой класс в класс?

  • Подумайте о моделях и приемах, которые вы приняли. Вы сделали это, потому что они имели прекрасный смысл или потому, что кто-то убедил вас, что «это единственный способ сделать это?» или потому, что вы хотели его в своем резюме или потому, что некоторые разработчики rockstar так сказали.

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
7
  

Как узнать, может ли созданный им код легко ремонтироваться и   читаемым?

Вы можете легко найти и прочитать код, просматривая эти свойства:

  1. Объекты, методы и /или функции всегда делают одно.
  2. Методы и /или функции являются краткими (как в «кратком, но исчерпывающем»).
  3. Объекты, методы и /или функции делают по существу то, что, по вашему мнению, они должны делать на основе их имен.
  4. Код, предназначенный для повторного использования, фактически повторно используется.
  5. И последнее, но не менее важное: если вы можете сразу же протестировать код, вы, вероятно, написали единую ответственность, модульный код, по крайней мере.
  

Как мы узнаем, написано ли мы довольно грязно и непримиримо   код? Существуют ли какие-либо конструкции или рекомендации, чтобы знать, если мы разработали   грязное программное обеспечение?

  1. Если вы читаете метод, и не ясно, что это за намерение, это в лучшем случае неэлегантно и, вероятно, в худшем случае недостижимо.
  2. Если это не кажется простым, это, вероятно, не просто, и это признак неподъемного кода или кода, который скоро станет недостижимым.
  3. Если в кодовой базе отсутствует симметрия (согласованность), вы, вероятно, смотрите на недостижимый код.
ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
6

В одном слове Опыт .

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
3

Без пуритания: предпочитайте функциональный стиль. Большинство языков в наши дни (.NET, Ruby, Python, Javascript и т. Д.) Поддерживают и продвигают его (например, LINQ, underscorejs).

Очень легко читать.

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

Он заставляет каждый узел иметь единое целенаправленное кредитование для ясности цели. И поскольку каждая дискретная задача изолирована, выключение, подключение и переупорядочение узлов (операций) до разных концов тривиально. Это облегчает обслуживание.

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
2

Свести к минимуму побочные эффекты (в идеале нет)

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

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

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

Избегать лишних внешних зависимостей

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

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

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

Проверьте дерьмо из него

Это заданный, но если ваш код не обрабатывает все входные случаи и пропускает некоторые крайние случаи, то как вы можете ожидать, что другие будут поддерживать код, который вы написали, что вы даже не попали прямо перед тем, как передать его глаза и Руки? Достаточно сложно внести изменения в код, который отлично работает, не говоря уже о коде, который никогда не был правильным.

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

Документация по интерфейсу

Приоритет «что делаете» над «как это происходит», если вы не можете посвятить равное время документированию обоих. Четкий интерфейс, очевидный в своих намерениях о том, что он будет делать (или, по крайней мере, что он должен делать) во всех возможных случаях ввода, даст ясность контекста для его собственной реализации, которая поможет понять не только то, как использовать код, но также и то, как он работает.

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

Для стороны реализации укажите приоритетность документирования того, что вы делаете иначе, чем у всех остальных. В качестве примера, Intel имеет ограниченную иерархию томов для своих ядер raytracing. Поскольку я работаю в этой области, я могу узнать основную часть того, что их код делает с первого взгляда, без просеивания через документацию. Тем не менее, они делают что-то уникальное, что является идеей пересечения BVH и параллельного выполнения пересечений с использованием пакетов ray . Вот где я хочу, чтобы они определили приоритетность своей документации, потому что эти части кода являются экзотическими и необычными для большинства исторических реализаций BVH.

читаемость

Эта часть очень субъективна. Я не очень-то забочусь о том, насколько хорошо читабельность, близкая к процессам человеческого мышления. Самый хорошо документированный код, описывающий вещи на самом высоком уровне, по-прежнему остается трудным для меня, если автор использует причудливые и запутанные мыслительные процессы для решения проблемы. Между тем краткий код с использованием 2 или 3 имен символов часто может быть легче для меня понять, если логика очень проста. Я думаю, вы могли бы просмотреть рецензию и посмотреть, что предпочитают другие люди.

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
1

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
1

Читаемый и поддерживаемый код: Код, который, с первого взгляда, программист может понять достаточно хорошо, чтобы легко:

  • повторно использовать его через свой интерфейс или
  • отладить его или
  • изменить свое поведение. (добавить /удалить функцию) или
  • оптимизировать его
  • проверить его

Это сводится к «ясности». i.e Сколько вопросов программист должен запросить у определенного сегмента кода, прежде чем они будут уверены, что они «понимают, что он делает достаточно хорошо» для достижения текущей задачи в руке, не вызывая неожиданных побочных эффектов.

Книга «Code Complete, Стив Макконнелл» подробно рассказывает об этом.

Он просматривает различные показатели, которые вы можете использовать, чтобы определить, имеет ли код хорошее качество.

См. пример здесь: http: //books.google.co.uk/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
1

Вот техника, которую я люблю использовать:

Покажите код одному из ваших одноранговых программистов и попросите их объяснить вам, что он делает. Следите за этими вещами.

1) Если они не могут легко объяснить цель блока рефакторинга кода, то он. 2) Если им нужно перейти к другому разделу кода, чтобы понять текущий раздел, реорганизовать его.
4) В любое время, когда вы чувствуете желание говорить во время процесса, эта часть кода нуждается в рефакторинге. (Код не говорит сам за себя).

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
-1

Самый поддерживаемый код - это код, которого нет. Таким образом, вместо добавления к подсчету LOC новый код, который «уменьшает» количество LOC (даже если он немного меньше поддерживаемых при просмотре в изоляции), может сделать общую базу кода более удобной для обслуживания просто за счет уменьшения ее размера. Таким образом, основное правило для поддерживаемого кода:

  • увеличить DRY.

Во-вторых, нет ничего хуже для ремонтопригодности, чем скрытые зависимости. Итак, для правила № 2:

  • Сделать все ваши зависимости явными.

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

Библиотеки кросс-проектов: старшие разработчики, полный код трюков /идиома /методы Специфичные для проекта библиотеки и системные бэкэнды: разработчики медиумов, избегают самых передовых и трудно объясняющих. Пожилые люди пойдут через этот код, ищущие возможности СУХОЙ улучшения.

Front-end: junior devs, используйте строгий стиль руководства и набор методов языковых конструкций и идиом, которых следует избегать. Разработчики Medior пройдут через этот код, ищущие возможности СУХОЙ и скрытую бизнес-логику.

Итак, для правила № 3:

  • Сложите свой код с уровня навыка разработчика и соответствующим образом создайте код поддержки.

I

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
-2

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

OOAD - это четырехзначное слово, но его трудно понять за один раз - следуйте объектно-ориентированному анализу & Дизайн

  1. Всегда начинайте с сбора хорошего требования и точной постановки задачи

    • начать с нескольких случаев использования, т.е. Взаимодействие системного пользователя.
  2. Вы должны держать ваши объекты слабо связанными и убедиться, что ваш код не будет повторяться - следуйте за DRY [Не повторяйтесь]

    • в любое время, когда вы видите дубликат, найдите место для инкапсуляции
  3. ваш код открыт для расширения и закрыт для модификации - OCP [принцип открытого закрытия]
  4. Когда вы меняете свой код, всегда помните - не создавайте проблем для решения проблем, IT просто заявляет, что вы не изменяете существующую функциональность.
  5. Модуль тестирует ваш код
    • всегда проверяйте свой код, когда что-то не так.
  6. При работе над функциональностью всегда помните, что нужно следовать основным принципам ООП (объектно-ориентированным принципам) и методам, чтобы убедиться, что ваше приложение хорошо спроектировано с самого начала
    • Объекты должны делать то, что указывает их имя.
    • Каждый объект должен представлять единую концепцию
  7. Всегда помните операционную систему системы и в которой работает контекстное /доменное программное обеспечение
  8. Будут ли работать некоторые бумаги - да, что работает для меня
    • с некоторыми распечатками материалов, связанных с пользовательским интерфейсом, и диаграмм UML всегда работают
    • вы даже можете иметь скриншоты сеанса мозгового штурма с Белой доски.
  9. Архитектурные макеты
  10. Примените принципы проектирования, если возможно
  11. Документация
    • всегда документируйте свой код
    • установить отступ в среде IDE и документировать это тоже
ответил dthorpe 26 AM000000100000001831 2011, 10:58:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132