Каково восхищение метриками кода? [закрытый]
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
17 ответов
Ответы в этом потоке довольно нечетны, поскольку они говорят о:
- "команда", как "та и только бенефициарий" тех упомянутых метрик;
- "метрики", как они имеют в виду что-либо в себе.
1/Метрики не для одна население, а для три :
- разработчики: они обеспокоены в мгновенные статические метрики кода относительно статического анализа их кода (цикломатическая сложность, качество комментариев, количество строк...)
- руководители проекта: они обеспокоены в ежедневные живые метрики кода прибытие из модульного теста, кодируют покрытие, непрерывное интеграционное тестирование
- бизнес-спонсоры (о них всегда забывают, но они - заинтересованные стороны, та, платящая за разработку): они обеспокоены в еженедельные глобальные метрики кода относительно архитектурного проекта, безопасности, зависимостей...
за Всеми теми метриками может наблюдать и анализировать все три населения, конечно, но каждый вид разработан, чтобы лучше использоваться каждой определенной группой.
2/Метрики, собой, представляют снимок из кода, и это... ничего не означает!
Это - комбинация тех метрик и комбинации тех разных уровней анализа, который может указать на "хороший" или "плохой" код, но что еще более важно, это тенденция тех метрик , который является значительным.
, Который является повторение из тех метрик, что даст реальную добавленную стоимость, поскольку они помогут бизнес-лидерам/разработчикам менеджеров/проекта к [1 150] , располагают по приоритетам среди различного возможного кода, фиксирует
<час>, Другими словами, Ваш вопрос о "восхищении метрик" мог относиться к различию между:
- "красивый" код (хотя это всегда находится в глазу наблюдателя-кодера)
- "хороший" код (который работает, и может доказать, что это работает)
Так, например, функция с цикломатической сложностью 9 могла быть определена столь же "красивая", как отклонено одной долгой замысловатой функции цикломатической сложности 42.
, НО, если:
- последняя функция имеет устойчивый сложность, объединенный с [1 112] покрытие кода 95%,
- , тогда как первый имеет увеличение сложность, объединенный с [1 114] покрытие... 0%,
можно было спорить:
- последний представляет" хороший " код (он работает, это стабильно, и если он должен измениться, каждый может проверки, если он все еще работает после модификаций),
- первый" плох " код (он все еще должен добавить некоторые случаи и условия покрыть все, что он должен сделать, и нет никакого простого способа сделать некоторый регрессионный тест)
Так, для суммирования:
одиночная метрика, которая отдельно всегда указывает [...]
: не очень, за исключением того, что код может быть более "красивым", который сам по себе не означает много...
там некоторое волшебное понимание, которое будет получено от метрик кода, которые я пропустил?
Только комбинация и тенденция из метрик дает реальное "волшебное понимание", Вы после.
Я не думаю, что небольшие изменения в метриках значимы: функция со сложностью 20 является не обязательно более чистой, чем функция со сложностью 30. Но это стоит рабочих метрик для поиска значительных различий.
Одно время я рассматривал пару дюжины проектов, и один из проектов имел максимальное значение сложности приблизительно 6 000, в то время как любой проект имел значение приблизительно 100 или меньше. Тот хит я по голове как бейсбольная бита. Очевидно, что-то необычное, и вероятно плохо, продолжало тот проект.
Метрики себя не особенно интересны. Именно то, что Вы делаете с ними, рассчитывает.
, Например, если бы Вы измеряли количество комментариев на строку кода, что Вы рассмотрели бы хорошим значением? Кто знает? Или возможно что еще более важно, у всех есть их собственное мнение.
Теперь при сборе достаточной информации, чтобы быть в состоянии коррелировать количество комментариев на строку кода против времени, потраченного для разрешения ошибки или против количества ошибок нашли, что приписываются кодированию, тогда можно начать находить опытным путем полезное число.
нет никакого различия между использованием метрик в программном обеспечении и использованием никакого другого критерия качества работы ни на каком другом процессе - сначала Вы имеете размеры, тогда Вы анализируете, тогда Вы улучшаете процесс. Если все, что Вы делаете, имеет размеры, Вы тратите впустую свое время.
редактирование: В ответ на комментарии Steven A. Lowe - это абсолютно корректно. В любом анализ данных нужно стараться различать причинную связь и простую корреляцию. И выбор метрик на основе пригодности важен. Нет никакого смысла в попытке измерить потребление кофе и приписать качество кода (хотя я уверен, что некоторые попробовали;-))
, Но прежде чем можно будет найти отношения (причинный или не) у Вас должны быть данные.
выбор данных для сбора, на основе какого процесса Вы хотите проверить или улучшиться. Например, при попытке проанализировать успех своих процедур рассмотрения кода (использующий Ваше собственное определение для "успеха", быть, который уменьшил ошибки или уменьшенное кодирование ошибок или более короткого срока выполнения работы или безотносительно), тогда Вы выбираете метрики, которые измеряют общий уровень ошибок и уровень ошибок в рассмотренном коде.
Поэтому перед сбором данных, необходимо знать то, что Вы хотите сделать с ними. Если метрики являются средствами, каков конец?
Одна часть ответа - то, что некоторые метрики кода могут дать Вам очень быстрый, начальный удар в ответе на вопрос: Как что этот код?
Даже 'строки кода' могут дать Вам общее представление о размере кодовой базы, на которую Вы смотрите.
, Как упомянуто в другом ответе, тенденция метрик дает Вам большую часть информации.
Метрики не являются заменой для обзора кода, но они являются намного более дешевыми. Они - индикатор больше, чем что-нибудь.
Я соглашаюсь с Вами, что метрики кода не должны заменять обзором кода, но я полагаю, что они должны дополнить обзоры кода. Я думаю, что это возвращается к старой поговорке, что "Вы не можете улучшить то, что Вы не можете измерить". Метрики кода могут предоставить группе разработчиков измеримые "запахи кода" или шаблоны, которым, возможно, понадобится дальнейшее расследование. Метрики, которые получены в большинстве инструментов статического анализа, обычно являются метриками, которые были определены в течение исследования в краткой истории нашего поля для имения значительного значения.
Метрики могут быть полезными для определения улучшения или неисправности в проекте, и могут, конечно, найти стиль и нарушения соглашения, но нет никакой замены для того, чтобы сделать обзоры кода однорангового узла. Вы не можете возможно знать качество своего кода без них.
, О... и это предполагает, что у по крайней мере одного из участников Вашего обзора кода есть подсказка.
Мы - программисты. Нам нравятся числа.
кроме того, что Вы собираетесь сделать, НЕ, описывают размер кодовой базы, потому что "строки метрик кода не важны"?
существует определенно различие между кодовой базой 150 строк и одним из 150 миллионов, для взятия глупого примера. И это не твердое число для получения.
Существует одна метрика кода, в которую я верю.
я работаю над большой системой. Когда единственное новое требование прибывает ко мне, я приступил к кодированию его. Когда я сделан и разработал ошибки, я проверяю его в системе управления версиями. Та система делает разность и подсчитывает все изменения, которые я внес.
, Чем меньший, что число, тем лучше.
Измерения только полезны если:
- команда разработала их
- команда, согласованная на них
- , Они используются для идентификации определенной области
В целом, любая метрика, которая не вписывается, который пострадает от оптимизации команды до него. Вы хотите измерить строки кода? Черт возьми, смотрите, сколько они могут записать! Вы хотите измерить покрытие кода, ей-богу, наблюдайте, что я покрываю тот код!
я думаю, что метрики могут быть полезны для идентификации тенденций, и на самом деле, я видел некоторые полезные, такие как графическое изображение, когда сборка повреждается, маслобойка кода (количество строк кода, изменяющегося в течение проекта) и другие вещи. Но если команда не придумывает их, или они не согласовывают или понимают их, Вы вероятны в мире вреда.
Люди привлечены к идее механистических способов понять и описать код. Если это правда, думайте о разветвлениях для эффективности и производительности!
я соглашаюсь, что метрики для "совершенства кода" почти так же разумны как метрика для "хорошей прозы". Однако это не означает, что метрики бесполезны, просто возможно, неправильно используемые.
, Например, экстремальное значение значения для некоторых метрик указывают путь к возможным проблемам. 1 000 строк длинный метод , вероятно неудобны в сопровождении. Код с нулевым покрытием кода модульного теста , вероятно имеет больше ошибок что подобный код с большим количеством тестов. Большой переход в коде, добавленном к проекту непосредственно перед выпуском, который не является сторонней библиотекой, , вероятно причина для дополнительного внимания.
я думаю, используем ли мы метрики в качестве предложения - красный флаг - возможно, они могут быть полезными. Проблема состоит в том, когда люди начинают измерять производительность в SLOC или качество в проценте строк с тестами.
Мое очень субъективное мнение - то, что метрики кода выражают непреодолимое установленное восхищение способностью определить количество чего-то по сути неисчислимого.
Имеет смысл, в некотором смысле, по крайней мере, в психологическом отношении - как можно принять решения о чем-то, что Вы не можете оценить или понять? В конечном счете, конечно, Вы не можете оценить качество, если Вы не хорошо осведомлены о предмете (и по крайней мере так же хороши как, что Вы пытаетесь оценить), или спросите кого-то, кто хорошо осведомлен, который, конечно, просто помещает проблему, поддерживают один шаг.
В этом смысле, возможно, разумная аналогия оценила бы участников колледжа очками SAT, это несправедливо и пропускает каждый вид тонкости, но если необходимо определить количество, необходимо сделать что-то.
Не высказывание я думаю, что это - хорошая мера, только что я вижу установленную неотразимость его. И, как Вы указали, существует, вероятно, несколько разумных метрик (много из 500 + методы строки, высокая сложность вероятно плохо). Я никогда не был в месте, которое вложилось в это, все же.
Для меня единственная самая важная метрика, которая определяет плохой код, является цикломатической сложностью. Почти все методы в моих проектах ниже CC 10, и ошибки неизменно найдены в методах прежней версии с CC более чем 30. Высокий CC обычно указывает:
- код, записанный в поспешности (т.е. не было никакого времени для нахождения изящного решения и не потому что проблема потребовала сложного решения)
- непротестированный код (никто не пишет тесты для таких зверей)
- , код, который был исправлен и зафиксировал многочисленные времена (т.е. пронизал IFS и комментариями todo)
- главная цель для рефакторинга
Хороший обзор кода не является никакой заменой для хорошего инструмента статического анализа, который является, конечно, не, заменяют хороший набор модульных тестов, теперь модульные тесты бесполезны без ряда приемочных испытаний......
метрики Кода являются другим инструментом для помещения на панель инструментов, они не решение самостоятельно, они - просто инструмент, который будет использоваться в качестве соответствующих (с, конечно, всеми другими инструментами в поле!).
Метрики и автоматизированные тесты не предназначены, чтобы быть заменой для полных обзоров кода.
Они просто ускоряют вещи. С автоматизированным средством проверки очень легко видеть, за какими соглашениями Вы забыли следовать, что Вы используете обозначенные пакеты и методы и т.д. Вы видите то, что можно зафиксировать, не используя время других людей.
менеджеры также как метрики их, потому что они чувствуют, что получают точное число по производительности (хотя это часто - не действительно случай) и они должны быть в состоянии манипулировать людьми лучше.
У меня был проект, который я сделал как одно задание человека, измеренное для цикломатической сложности некоторый месяц назад. Это было моим первым воздействием подобным метрикам.
первый отчет, который я получил, был шокирующим. Почти все мои функции провалили тест, даже (по моему скромному мнению), очень простые. Я обошел вещь сложности путем перемещения логической подзадачи в подпрограммы, даже если их назвали только однажды.
Для другой половины стандартных программ моя гордость как втолкнутый программист и я пытался переписать их способом, что они делают то же, просто более простое и более читаемое. Это работало, и я смог получить максимум вниз клиентам yclomatic порог сложности.
В конце я почти всегда смог предложить лучшее решение и намного более чистый код. Производительность не сделала пострадал от этого (доверяйте мне - я параноик на этом, и я проверяю дизассемблирование выхода компилятора довольно часто).
я думаю, что метрики являются хорошей вещью, если Вы используете их в качестве причины/мотивации улучшить Ваш код. Важно знать, когда остановиться и попросить метрическое предоставление нарушения все же.
Метрики являются руководствами, и помогает, не самоцели.
Лучшая метрика, которую я когда-либо использовал, это C.R.A.P. score.
По сути, это алгоритм, который сравнивает взвешенную цикломатическую сложность с покрытием автоматизированных тестов. Алгоритм выглядит следующим образом: CRAP(m) = comp(m)^2 * (1 - cov(m)/100)^3 + comp(m)
, где comp(m) - цикломатическая сложность метода m, а cov(m) - покрытие кода тестами, обеспечиваемое автоматизированными тестами.
Авторы вышеупомянутой статьи (пожалуйста, прочитайте ее... она стоит вашего времени) предлагают максимальную оценку C.R.A.P. в 30 баллов, что выглядит следующим образом:
Method’s Cyclomatic Complexity % of coverage required to be
below CRAPpy threshold
------------------------------ --------------------------------
0 – 5 0%
10 42%
15 57%
20 71%
25 80%
30 100%
31+ No amount of testing will keep methods
this complex out of CRAP territory.
Как вы быстро увидите, метрика вознаграждает написание несложного кода в сочетании с хорошим тестовым покрытием (если вы пишете модульные тесты, а вы должны писать, и не измеряете покрытие. ...что ж, вероятно, вам также понравится плевать на ветер). ;-)
Для большинства моих команд разработчиков я очень старался, чтобы оценка C.R.A.P. была ниже 8, но если у них были веские причины, оправдывающие дополнительную сложность, это было приемлемо, пока они покрывали сложность достаточным количеством тестов. (Написание сложного кода всегда очень трудно тестировать... своего рода скрытое преимущество этой метрики).
Поначалу большинству людей было трудно написать код, который прошел бы оценку C.R.A.P.. Но со временем они писали более качественный код, код, в котором было меньше проблем, и код, который было гораздо легче отлаживать. Из всех метрик именно эта имеет меньше всего проблем и больше всего преимуществ".