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

336

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

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

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

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

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

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

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

user22815
источник
154
Обязательная ссылка (на этот раз не на xkcd): osnews.com/images/comics/wtfm.jpg
Джерри Гроб
3
Я бы просто легкомысленно сказал, что вы это знаете, когда видите, но этот аргумент был в корне ошибочным и смущающим даже в его первоначальной форме, не говоря уже о применении к исходному коду.
Конрад Рудольф
6
«Конечно, с вашей точки зрения, ваш код читабелен» - не так уж и очевидно!
UncleZeiv
24
Я бы сказал, что вы это знаете, когда увидите это через несколько месяцев после того, как написали.
JeffO
2
@asfallows: я показал некоторый код моей жене, и она подумала, что это действительно плохой код, потому что она могла его прочитать! (Слишком много английских слов в нем и недостаточно символов @ [! ^ $ & *) ...)
gnasher729

Ответы:

370

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

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

user1249
источник
6
Ничто не сравнится с эмпирическим тестированием.
Мировой инженер
25
+1 Ваша самая важная аудитория - ваши сверстники, которые погружены в вас, чтобы знать, почему, как и над какой проблемой вы работаете и как ее решить. Хороший код отражает текущее понимание вашей группы сверстников. Если предположить, что команда способна, вдумчива и открыта для новых идей, то, по моему опыту, «ваш коллега говорит вам, что он хороший / постоянный», это лучшее определение, чем любое другое.
Даг Т.
69
По моему опыту, это работает только тогда, когда ваш коллега знает, что хорошо, а что плохо. В противном случае это будет звучать так: «Вы должны написать этот код одним и тем же методом, это проще найти»
Rangi Lin
12
@RangiLin, твой коллега может быть прав.
11
@ Ранги Вы должны работать с вашими коллегами. если они находят ваш код сложным, то это проблема вашего кода. В долгосрочной перспективе, вы можете обучить их, или попытаться получить лучшие коллег (вы можете переместить или вы можете влиять на процесс приема на работу) ... Ах , да, и делать всегда помнит , что они могут быть правы.
MarkJ
220

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

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

Алекс в Париже
источник
28
Да, это звучит хорошо (и верно), но это не очень хороший подход к решению, что / как делать сегодня ...
Майкл Даррант
10
Рассечение предполагает, что это занимает некоторое время, и вы должны делать это осторожно ...
deworde
3
Я мог бы сократить срок для повторного посещения до месяца или даже меньше для первого повторного посещения. Я думаю, что это зависит от сложности проекта и предметной области, а также от вашего ментального подхода. Я обнаружил, что через шесть месяцев я отвлекся, увидев возможности рефакторинга или оптимизации с использованием инструментов или методов, которые я изучил с тех пор, как впервые написал код, вместо реальной читабельности.
Крис Бай
1
@MichaelDurrant Каждый раз, когда вы просматриваете старый код, вы обнаруживаете фрагменты, которые должны были быть написаны иначе, а затем учитываете код, который вы пишете «сегодня». Да, нужно время, чтобы научиться писать хороший код.
dj18
1
@MichaelDurrant это все еще вроде как, потому что вы можете узнать, какие неясные вещи вы делали шесть месяцев назад, а не делать эти вещи сегодня.
Джечлин
94

Это:

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

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

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

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

Бесполезный
источник
2
Как насчет того, чтобы учесть количество времени, которое нужно потратить на исправление ошибки или изменить существующее поведение как фактор ремонтопригодности? Часть кода, которая требует меньше времени, чтобы сделать то же самое изменение, должна быть более понятной, верно?
VCD
1
Зависит; иногда для правильного внесения изменений потребуется рефакторинг (который, как вы можете сказать, необходим, потому что разборчивый код дает понять, что он не предназначен для такого использования), что занимает больше времени, чем хакерство в особом случае (который нечитаемый код поощряет, потому что цель неясна ).
бесполезно
30

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

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

Одед
источник
8
... и после того, как вы прочитаете это, передайте это кому-то еще, чтобы попытаться прочитать.
jcmeloni
19
Это не особенно хороший тест. Многие применения этих правил носят субъективный характер, и вы почти всегда можете прочитать собственный код сразу после его написания.
DeadMG
1
«Если ответ да, то код читается» ... вами . Чтобы увидеть, может ли он быть читаемым для других, другие должны попытаться прочитать его.
2
ИМО, ТВЕРДЫЙ переоценен. Особенно "С." Это или все неправильно это понимают.
Эрик Реппен
Я бегал бесчисленное количество раз в код, который был СУХИМ и ТВЕРДЫМ, и все же ужасным. Следующие принципы могут создать ложное впечатление, что то, что ты пишешь, не дерьмо.
Якуб Арнольд
24

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

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

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

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

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

iikkoo
источник
См. Также waterfall2006.com/gorman.html Рефукторинг - это процесс получения хорошо продуманного фрагмента кода и, благодаря серии небольших, обратимых изменений, делающих его полностью не поддерживаемым никем, кроме вас.
Sjoerd
22

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

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

Карл Билефельдт
источник
4
+1 для дополнительного обучения и не пытаться стать совершенным за одну ночь
dj18
19

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

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

MathAttack
источник
10
Помните, что люди могут воздерживаться от вопросов из-за боязни разоблачения своего невежества. Вы можете даже воспринимать этих людей как «достаточно компетентных» в первую очередь из-за их склонности воздерживаться от разоблачения. Таким образом, отсутствие вопросов не может быть хорошей вещью, если вы не знаете, что вы оба искренни.
Герман Ингальдссон
1
@HermannIngjaldsson - Достаточно справедливо. Конечно, если они не компетентны и что-то сломается, вы скоро об этом услышите. "Помогите!!!!"
MathAttack
это, кажется, просто повторяет то, что было указано в верхнем ответе
комнат
17

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

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

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

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

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

оборота Джо Раунсвилл
источник
2
Это должно быть ответом. Мера. Другие ответы - это скорее мнение, чем факт, если я могу это понять, это должно быть хорошо? Сначала измерьте, используя анализ сложности, затем человеческий рефакторинг для поиска дублирования и т. Д.
Джон Рейнор
1
Ваш последний абзац, в котором упоминаются недостатки оценки МакКейба, поделенные на LOC, скорее всего сводит на нет всю идею. Если вам нужно 300 путей через ваш код, почему вы думаете, что он сделает код более понятным для использования большего количества строк? Это все равно что сказать, что если книга представляет сложные идеи, она должна быть действительно большой книгой, а не пытаться общаться кратко. -1.
Wildcard
8

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

  • Код легко использовать повторно
  • Ваш код гибкий (это связано со сборкой в ​​модулях)
  • СУХОЙ - не повторяйся

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

jket
источник
8

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

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

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

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

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

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

Эрик Реппен
источник
3
Чтение кода без IDE кажется глупым, особенно как мера читабельности. Этот тип метрики приводит к «решениям» венгерского стиля нотации, которые в конечном итоге действительно ухудшают читабельность.
rubenvb
8

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

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

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

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

  1. Если вы читаете метод, и неясно, каково было его намерение, это в лучшем случае не элегантно, а в худшем - скорее всего невозможно.
  2. Если это не кажется простым, это, вероятно, не просто, и это признак не поддерживаемого кода или кода, который скоро станет не обслуживаемым.
  3. Если в кодовой базе отсутствует симметрия (согласованность), вы, вероятно, обращаете внимание на не поддерживаемый код.
оборота Уилмур
источник
Я не согласен с тем, что ваш пример рефакторинга более понятен. Я согласен, что исходный код нуждается в работе, но чисто с точки зрения ясности и намерений общения, я думаю, что оригинал намного лучше. Я очень подозреваю любой рефакторинг, который утверждает, что он улучшает ясность при введении регулярных выражений.
Рой
1
@ Рой, да, достаточно справедливо. Я, вероятно, никогда не должен был добавлять этот пример кода. Конечно, это было почти 3 года назад, но даже тогда я, вероятно, не должен был использовать PHP (сейчас я просто смотрю на него), и я не должен был использовать регулярное выражение, поскольку это одна из тех вещей, которую некоторые люди можно посмотреть и сразу получить, но для других, какими бы краткими они ни были, регулярные выражения немедленно отключаются. Я собираюсь отредактировать ответ и опустить пример кода. Спасибо за комментарий.
Уил Мур III
Как объект может сделать одну вещь?
Корай Тугай
@KorayTugay Думай об этом так. Если объект описывает больше, чем одно связное понятие, у вас есть запах.
Уил Мур III
6

Одним словом, Опыт .

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

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

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

S.Robins
источник
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);

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

Марио Т. Ланца
источник
2

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

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

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

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

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

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

оборота JW01
источник
это, кажется, не добавляет ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих ответах
комнат
Я думаю, что одна из самых существенных вещей, которые он добавляет, - это ссылка на Code Complete, о которой ни один предыдущий ответ не упоминает. Эта книга является одной из самых значительных и влиятельных книг, которая сосредоточена на написании удобочитаемого и поддерживаемого кода. Любому, кто читал эту книгу, не нужно спрашивать: «Как бы вы узнали, если вы написали читаемый и легко обслуживаемый код?».
JW01
... следовательно, по моему мнению, я думаю, что лучшее, что может получить любой, если они действительно заинтересованы в написании поддерживаемого кода, - это прочитать эту книгу. Следовательно, после долгих минут тщательного обдумывания (что зачастую на много минут больше обдумывания, чем у модераторов SO), я думаю, что это не только адекватный ответ на вопрос ОП, но и лучший .
JW01
2

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

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

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

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

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

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

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

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

Испытай дерьмо из этого

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

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

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

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

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

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

читабельность

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

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

user204677
источник
1

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

FrustratedWithFormsDesigner
источник
1

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

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

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

JohnFx
источник
Предполагая, что одноранговый программист, по крайней мере, одинаково опытен и знаком с языком программирования и его идиомами. Все эти часто используемые методы могут привести к тому, что люди будут писать код в подмножестве выразительности языка в ошибочной попытке сделать инт понятным даже для самого младшего члена команды. В результате получается большая часть кода в скрытом подмножестве языка. И независимо от того, сколько вы потушите языкового подмножества, 500KLOC кода небольшого языкового подмножества всегда будет более трудоемким, чем 200KLOC-код, который использует более выразительное подмножество.
user1703394
это, кажется, просто повторяет то, что было указано в верхнем ответе
комнат
-1

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

  • увеличить СУХОЙ.

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

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

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

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

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

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

  • Разложите свой код по уровню квалификации разработчика и напишите соответствующий код.

я

user1703394
источник
1
кажется, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 25 ответах
комнат
@gnat, я надеялся добавить «нюанс» ко многим (потенциально вредным) упрощениям в других ответах. Особенно с пунктом 3.
user1703394
1
@ user1703394 этот вопрос и его ответы вики сообщества. Если вы считаете, что существующий ответ может быть улучшен, вы можете редактировать его даже без привилегии «редактировать посты других пользователей».
-2

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

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

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

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

    • каждый раз, когда вы видите дубликат, ищите место для инкапсуляции
  3. ваш код открыт для расширения и закрыт для модификации - OCP [принцип Open-closed]
  4. Когда вы меняете код, всегда помните: «Не создавайте проблем для решения проблем», ИТ-отдел просто заявляет, что не изменяет вашу существующую функциональность
  5. Модульное тестирование вашего кода
    • всегда проверяйте свой код, когда что-то идет не так
  6. При работе над функциональностью всегда не забывайте следовать базовым ООП (объектно-ориентированным принципам) и методикам, чтобы с самого начала убедиться, что ваше приложение хорошо спроектировано.
    • Объекты должны делать то, что указывает их имя
    • Каждый объект должен представлять единую концепцию
  7. Всегда помните формулировку проблемы системы и в каком контексте / доменном программном обеспечении работает
  8. Делай бумажные работы тоже - да, это работает для меня
    • всегда есть распечатки материалов, связанных с пользовательским интерфейсом и UML-диаграмм
    • Вы можете даже получить скриншоты мозгового штурма с Белой доски тоже
  9. Архитектурные макеты
  10. Применить принципы дизайна, если это возможно
  11. Документация
    • всегда документируйте свой код
    • установите отступ в IDE и запишите это тоже
Нарендер Пармар
источник
1
Это теория, которая не отвечает на вопрос « Как мы можем измерить или измерить качество кода, чтобы мы знали его читабельным, понятным и поддерживаемым?» вопрос
Ян Догген
Согласовано !! но если мы будем следовать вышеупомянутым принципам, то легко измерить качество кода, читабельное, понятное и, очевидно, поддерживаемое. Поправьте меня если я ошибаюсь.
Нарендер Пармар
Я не знаю, почему мой ответ был отвергнут, даже я уже
охватил