Що таке захоплення метриками коду? [зачинено]

Останнім часом я бачив низку питань, пов’язаних із „метрикою коду”, пов’язаних із SO, і мені доводиться замислюватися, в чому полягає захоплення? Ось останні приклади:

• які метрики коду переконують вас, що наданий код є безглуздим
• коли коли-небудь кількість рядків коду є корисною метрикою
• написання тестів якості

На мою думку, жоден показник не може замінити огляд коду, однак:

• деякі показники іноді можуть вказувати на місця, які потрібно переглянути, та
• радикальні зміни метрик протягом коротких часових рамок можуть вказувати на місця, які потрібно переглянути

Але я не можу придумати жодної метрики, яка сама по собі завжди вказує на "хороший" чи "поганий" код - завжди є винятки та причини, які вимірювання не бачать.

Чи є якесь магічне розуміння метрик коду, які я пропустив? Чи ледачі програмісти / менеджери шукають виправдання, щоб не читати код? Чи пропонують людям гігантські основи застарілого коду та шукають, з чого почати? Що відбувається?

Примітка: Деякі з цих питань я задавав у конкретних темах як у відповідях, так і в коментарях, і відповідей не отримав, тому я подумав, що слід запитати спільноту загалом, оскільки, можливо, мені чогось не вистачає. Було б непогано запустити пакетну роботу з метриками і фактично більше ніколи не читати чужий код (або свій), я просто не думаю, що це практично!

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

Відповіді в цій темі дивні, оскільки вони говорять про:

• "команда", подібно до "єдиного бенефіціара" цих згаданих показників;
• "метрики", як би вони самі по собі щось означали.

1 / Метрики не для однієї сукупності, а для трьох :

• розробники: вони стурбовані миттєвими статичними метриками коду щодо статичного аналізу їх коду (цикломатична складність, якість коментарів, кількість рядків ...)
• керівники проекту: вони стурбовані щоденними показниками коду в реальному часі, що надходять від модульного тесту, охоплення коду, постійного тестування інтеграції
• спонсори бізнесу (про них завжди забувають, але вони є зацікавленими сторонами, котра платить за розробку): вони стурбовані щотижневими глобальними показниками коду щодо архітектурного дизайну, безпеки, залежностей, ...

Звичайно, усі ці показники можуть спостерігати та аналізувати всі три групи, але кожен вид призначений для кращого використання кожною конкретною групою.

2 / Метрики самі по собі представляють знімок коду, а це означає ... нічого!

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

Це повторення тих показників, що дасть реальну додану вартість, оскільки вони допоможуть менеджерам бізнесу / керівникам проектів / розробникам визначити пріоритети серед різних можливих виправлень коду

Іншими словами, ваше запитання про "захоплення метрик" може стосуватися різниці між:

• "красивий" код (хоча це завжди в очі глядача-кодера)
• "хороший" код (який працює, і може довести, що працює)

Так, наприклад, функцію з цикломатичною складністю 9 можна визначити як "красиву", на противагу одній довгій звивистій функції цикломатичної складності 42.

Але якщо:

• остання функція має стійку складність у поєднанні з охопленням коду 95%,
• тоді як перший має все більшу складність у поєднанні з покриттям ... 0%,

можна посперечатися:

• останній представляє " хороший " код (він працює, він стабільний, і якщо його потрібно змінити, можна перевірити, чи все ще він працює після модифікацій),
• перший - це " поганий " код (йому все одно потрібно додати деякі випадки та умови, щоб охопити все, що йому потрібно зробити, і немає простого способу зробити якийсь тест на регресію)

Отже, підсумовуємо:

єдиний показник, який сам по собі завжди вказує на [...]

: не багато, за винятком того, що код може бути більш "красивим", що саме по собі не означає багато ...

Чи є якесь магічне розуміння метрик коду, які я пропустив?

Тільки поєднання та тенденція показників дають справжнє "магічне розуміння", яке ви шукаєте.

У мене був проект, який я виконував як одноосібна робота, відрахована на цикломатичну складність кілька місяців тому. Це був мій перший вплив на такі метрики.

Перший звіт, який я отримав, був шокуючим. Майже всі мої функції не пройшли перевірку, навіть (imho) дуже прості. Я обійшов складність, перемістивши логічне підзавдання в підпрограми, навіть якщо вони були викликані лише один раз.

Для іншої половини процедур почалася моя гордість як програміста, і я намагався переписати їх так, щоб вони робили те саме, просто простіше і читабельніше. Це спрацювало, і я зміг максимально знизитися до порогу складності клієнтів.

Врешті-решт я майже завжди міг придумати краще рішення та набагато чистіший код. Продуктивність від цього не постраждала (повірте - я параноїк у цьому, і я досить часто перевіряю розбирання результатів компілятора).

Я думаю, що метрики - це добре, якщо ви використовуєте їх як причину / мотивацію для вдосконалення свого коду. Важливо знати, коли зупинитися і попросити грант на метричне порушення.

Метрики - це керівництво та допомога, а не самоціль.

Найкращий показник, який я коли-небудь використовував, - це бал CRAP .

В основному це алгоритм, який порівнює зважену цикломатичну складність з автоматизованим тестовим покриттям. Алгоритм виглядає так: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) де comp (m) - це цикломатична складність методу m, а cov (m) - охоплення тестовим кодом, що забезпечується автоматизованими тестами.

Автори вищезазначеної статті (будь ласка, прочитайте її ... це варте свого часу) пропонують максимальний бал CRAP 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.

Як ви швидко бачите, метрика винагороджує написання коду, який не є складним у поєднанні з хорошим покриттям тестів (якщо ви пишете модульні тести, і ви повинні бути, і не вимірюєте охоплення ... ну, вам, мабуть, сподобалося б плювати на вітер так само). ;-)

Для більшості моїх команд розробників я дуже старався отримати показник CRAP нижче 8, але якщо у них були вагомі причини, щоб виправдати додаткову складність, це було прийнятно, якщо вони покривали складність достатніми тестами. (Написання складного коду завжди дуже важко перевірити ... якась прихована перевага для цієї метрики).

Більшості людей спочатку було важко написати код, який би пройшов оцінку CRAP. Але з часом вони написали кращий код, код, який мав менше проблем, і код, який було набагато простішим для налагодження. З будь-якої метрики, це та, яка має найменше проблем і найбільшу користь.

Для мене найважливішим показником, який ідентифікує поганий код, є цикломатична складність. Майже всі методи в моїх проектах нижче CC 10, і помилки незмінно зустрічаються в застарілих методах з CC понад 30. Висока CC зазвичай вказує:

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

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

Метрики коду - це ще один інструмент, який можна додати до вашої панелі інструментів, вони самі по собі не є рішенням, вони просто інструмент, який слід використовувати за необхідністю (звичайно, з усіма іншими інструментами у вашому вікні!)

Людей тягне ідея механістичних способів зрозуміти і описати код. Якщо це правда, подумайте про наслідки ефективності та продуктивності!

Я погоджуюсь, що метрика для "доброго коду" приблизно така ж розумна, як метрика для "доброї прози". Однак це не означає, що метрики марні, просто, можливо, використовуються неправильно.

Наприклад, екстремальні значення для деяких показників вказують шлях до можливих проблем. Метод довжиною 1000 рядків, мабуть, неможливий. Код з нульовим модулем тестового покриття коду, ймовірно, має більше помилок, ніж аналогічний код із великою кількістю тестів. Великий стрибок коду, доданий до проекту безпосередньо перед випуском, який не є сторонньою бібліотекою, можливо, привід для додаткової уваги.

Думаю, якщо ми використаємо метрики як пропозицію - червоний прапор - можливо, вони можуть бути корисними. Проблема полягає в тому, коли люди починають вимірювати продуктивність у SLOC або якість у відсотках ліній за допомогою тестів.

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

Має сенс, певним чином, принаймні психологічно - як ти можеш приймати рішення щодо того, чого ти не можеш оцінити чи зрозуміти? Зрештою, звичайно, ви не можете оцінити якість, якщо ви не обізнані з предметом (і не менше ніж те, що ви намагаєтесь оцінити) або не запитаєте когось, хто обізнаний, що, звичайно, просто вирішує проблему один крок.

У цьому сенсі, можливо, розумною аналогією було б оцінювати абітурієнтів за балами SAT, це несправедливо і пропускає всі тонкощі, але якщо вам потрібно кількісно визначити, вам потрібно щось зробити.

Не кажучи, я вважаю, що це хороший захід, лише те, що я бачу його нестабільність у справах. І, як ви зазначили, існує, мабуть, кілька розумних показників (безліч методів лінії 500+, висока складність - можливо, погана). Однак я ніколи не був там, де купував це.

Я вірю в одну метрику коду.

Я працюю над великою системою. Коли до мене з’являється одна нова вимога, я беруся за кодування. Коли я закінчу і виправляю помилки, я перевіряю це в систему контролю версій. Ця система робить різницю та враховує всі зміни, які я зробив.

Чим менше це число, тим краще.

Метрики та автоматизовані тести не мають замінити повний огляд коду.

Вони просто пришвидшують справи. За допомогою автоматизованої перевірки дуже легко зрозуміти, яких домовленостей ви забули дотримуватися, що ви використовуєте призначені пакети та методи тощо. Ви можете бачити, що ви можете виправити, не витрачаючи часу інших людей.

Менеджерам також подобаються метрики, тому що вони відчувають, що вони отримують точну цифру продуктивності (хоча це часто не так), і вони повинні мати можливість краще жонглювати людьми.

Вимірювання корисні лише в тому випадку, якщо:

• Команда їх розробила
• Команда погодилася на них
• Вони використовуються для ідентифікації конкретної області

Загалом, будь-яка метрика, яка не вписується в неї, постраждає від оптимізації команди до неї. Ви хочете виміряти рядки коду? Боже, дивись, скільки вони можуть написати! Ви хочете виміряти охоплення коду, Голі, стежте, як я покриваю цей код!

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

Ось деякі метрики складності від stan4j .

Інструмент аналізу структури затьмарення.

Мені подобається цей інструмент і показники. Я розглядаю показники як статистику, показники, попереджувальні повідомлення. Іноді завдяки деяким методам або деяким класам дійсно є складна логіка, яка робить їх складними, що потрібно зробити, це стежити за ними, переглядати їх, щоб побачити, чи немає потреби їх переробляти або ретельно переглядати, як правило, вони схильні до помилок. Також я використовую його як інструмент аналізу для вивчення вихідного коду, оскільки мені подобається вчитися від складного до простого. Насправді він включає деякі інші метрики, такі як Роберт К. Мартін, Метрики Chidamber & Kemerer, Count Metrics, але мені це найбільше подобається

Метрики складності

Метрики цикломатичної складності

Цикломатична складність (CC) Цикломатична складність методу - це кількість точок прийняття рішень у графіку управління потоком методу, збільшена на одиницю. Точки рішення виникають у операторах if / for / while, реченнях case / catch та подібних елементах вихідного коду, де потік управління не просто лінійний. Кількість точок рішення (байт-код), введених одним (вихідним кодом) висловленням, може змінюватися, залежно, наприклад, від складності булевих виразів. Чим вище значення цикломатичної складності методу, тим більше тестових випадків потрібно для тестування всіх гілок графіку контролю потоку методу.

Середня цикломатична складність Середнє значення метрики цикломатичної складності за всіма методами програми, бібліотеки, дерева пакетів або пакету.

Метрики жиру Метрика жиру артефакту - це кількість ребер у відповідному графіку залежності артефакту. Тип графіка залежності залежить від метричного варіанту та обраного артефакту:

Жир Метрика жиру програми, бібліотеки або дерева пакетів - це кількість країв графіка залежності піддерева. Цей графік містить усі діти артефакту в ієрархії дерева пакетів, тим самим включаючи також пакунки листя. (Щоб побачити відповідний графік у поданні композиції, потрібно відключити перемикач Плоских пакетів Провідника структур. Перемикач Показувати бібліотеки повинен бути ввімкнений, якщо вибраний артефакт є бібліотекою, інакше його потрібно вимкнути.)

Метрика жиру пакета - це кількість країв графіка залежності одиниці. Цей графік містить усі класи пакету найвищого рівня.

Метрика жиру класу - це кількість країв графа-члена. Цей графік містить усі поля, методи та класи-члени класу. (Цей графік і значення Fat доступні лише в тому випадку, якщо аналіз коду виконувався за допомогою елемента рівня деталізації, а не класу.)

Жир для бібліотечних залежностей (Fat - Бібліотеки) Метрика Fat для бібліотечних залежностей програми є числом граф залежності її бібліотеки. Цей графік містить усі бібліотеки програми. (Щоб побачити відповідний графік у поданні композиції, потрібно ввімкнути перемикач Показувати бібліотеки Провідника структур.)

Жир для плоских залежностей пакету (Fat - Packages) Метрика жиру для плоских пакетних залежностей додатка - це кількість країв його графіку залежностей плоских пакетів. Цей графік містить усі пакети програми. (Щоб побачити відповідний графік у поданні композиції, потрібно ввімкнути перемикач «Плоскі пакети» Провідника структур і відключити перемикач «Показати бібліотеки».)

Показник Fat for Flat Package Dependencies (Бібліотека) для бібліотеки - це кількість країв її графіку залежностей з плоским пакетом. Цей графік містить усі пакети бібліотеки. (Щоб побачити відповідний графік у поданні композиції, потрібно включити перемикачі Flat Packages та Show Libraries.)

Жир для залежностей класу верхнього рівня (жир - одиниці) Метрика жиру для залежностей класу верхнього рівня програми чи бібліотеки - це кількість країв графіка залежності одиниці. Цей графік містить усі класи найвищого рівня програми чи бібліотеки. (Для розумних додатків він занадто великий, щоб його можна було візуалізувати, і тому його неможливо відобразити в поданні композиції. Графіки залежності одиниць можуть відображатися лише для пакетів.)

Метрики можуть бути корисними для визначення вдосконалення або погіршення стану проекту, і, безсумнівно, можуть виявити порушення стилю та конвенції, але заміни для проведення аналізів коду не існує. Без них ви не можете знати якість вашого коду.

О ... і це передбачає, що принаймні один із учасників вашого огляду коду має підказку.

Я згоден з вами, що показники коду не повинні замінювати огляд коду, але я вважаю, що вони повинні доповнювати огляди коду. Я думаю, що це повертається до старої приказки, що "ти не можеш вдосконалити те, чого не можеш виміряти". Показники коду можуть надати команді розробників кількісно визначувані "запахи коду" або шаблони, які можуть потребувати подальшого дослідження. Метрики, які фіксуються у більшості інструментів статичного аналізу, як правило, є метриками, які були виявлені в ході досліджень у короткій історії нашої галузі, що мали суттєве значення.

Метрики не замінюють перегляд коду, але вони набагато дешевші. Вони є індикатором більше за все.

Однією з частин відповіді є те, що деякі показники коду можуть дати вам дуже швидкий початковий удар при відповіді на запитання: Яким є цей код?

Навіть "рядки коду" можуть дати вам уявлення про розмір основи коду, яку ви переглядаєте.

Як зазначалося в іншій відповіді, тенденція показників дає вам найбільше інформації.

Метрики самі по собі не особливо цікаві. Важливо те, що ви робите з ними.

Наприклад, якби ви вимірювали кількість коментарів на рядок коду, що б ви вважали хорошим значенням? Хто знає? Або, що ще важливіше, у кожного своя думка.

Тепер, якщо ви зібрали достатньо інформації, щоб мати можливість співвідносити кількість коментарів на рядок коду з часом, витраченим на усунення помилок, або з кількістю знайдених помилок, які приписуються кодуванню, тоді ви можете почати знаходити емпірично корисне число .

Немає різниці між використанням показників у програмному забезпеченні та використанням будь-якого іншого показника продуктивності в будь-якому іншому процесі - спочатку ви вимірюєте, потім аналізуєте, потім вдосконалюєте процес. Якщо все, що ви робите, це вимірювання, ви марно витрачаєте час.

редагувати: У відповідь на коментарі Стівена А. Лоу - це абсолютно правильно. При будь-якому аналізі даних потрібно бути обережним, щоб розрізнити причинно-наслідковий зв’язок та просту кореляцію. І вибір показників на основі придатності є важливим. Немає сенсу намагатись вимірювати споживання кави та приписувати якість коду (хоча я впевнений, що деякі намагалися ;-))

Але перш ніж ви зможете знайти стосунки (причинно-наслідкові чи ні), ви повинні мати дані.

Вибір даних для збору базується на тому, який процес ви хочете перевірити або вдосконалити. Наприклад, якщо ви намагаєтеся проаналізувати успіх своїх процедур перегляду коду (використовуючи власне визначення "успіху", будь то зменшення помилок або зменшення помилок кодування, або коротший час обробки чи інше), тоді ви вибираєте показники, які вимірюють загальна частота помилок і частота помилок у переглянутому коді.

Тому перед тим, як збирати дані, ви повинні знати, що ви хочете з ними робити. Якщо метрика є засобом, то який кінець?

Я не думаю, що невеликі зміни в метриках мають значення: функція зі складністю 20 не обов'язково є чистішою, ніж функція зі складністю 30. Але варто запустити метрики, щоб шукати великі відмінності.

Одного разу я опитував пару десятків проектів, і один із проектів мав максимальну складність близько 6000, тоді як кожен інший проект мав вартість близько 100 або менше. Це вдарило мене по голові, як бейсбольна бита. Очевидно, що з цим проектом відбувалося щось незвичне і, мабуть, погане.

Ми програмісти. Нам подобаються цифри.

Крім того, що ви збираєтеся робити, НЕ описувати розмір кодової бази, оскільки "рядки метрик коду не мають значення"?

Безумовно, є різниця між кодовою базою із 150 рядків та однією із 150 мільйонів, щоб взяти дурний приклад. І це не важка цифра.