Які корисні показники для вихідного коду? [зачинено]

Які корисні показники для отримання вихідного коду?

Як такі показники, як, наприклад, рядки (виконувані?), Коду чи цикломатичної складності можуть допомогти у забезпеченні якості чи як вони взагалі корисні для процесу розробки програмного забезпечення?

"Вимірювання продуктивності програмного забезпечення за допомогою рядків коду - це як вимірювання прогресу в літаку на скільки він важить" - Білл Гейтс

Подивіться публікації Джеффа на цю тему:

Візит до покоївки «Метрики»

Інженерія програмного забезпечення: Мертві?

Існує стара, але хороша публікація від Джоела, також тісно пов'язана з метрикою програмного забезпечення, і я настійно рекомендую її прочитати: Метод управління Econ 101

Ключовим моментом для мене є цитування Джеффа: «Відповідальне використання метрик так само важливо, як і збирання їх в першу чергу».

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

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

Складність: Це вимірювання добре робити на кодових базах, над якими ви не працювали, і може дати точну інформацію про те, де лежать проблемні області. Як корисний анекдот, я оцінював складність на одній із власних баз коду, а область найвищої складності - та, на яку я витрачав найбільше часу, коли мені потрібно було її змінити. Робота над зменшенням складності призвела до значного скорочення часу на обслуговування. Якщо керівництво мало ці вимірювання під рукою, вони могли б планувати рефакторинг ітерацій або перероблення певних областей системи.

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

Графіки залежності Знаходження поганих та кругових залежностей є важливим вимірюванням коду. Це майже завжди вказує на неправильну конструкцію високого рівня, яка потребує перегляду. Іноді одна залежність може висмоктувати безліч непотрібних інших, оскільки хтось використовує addNumber всередині бібліотеки електронної пошти, щоб зробити свої фінансові розрахунки. Усі в шоці, коли бібліотека електронної пошти змінюється і фінанси перериваються. Якщо все залежить від однієї речі, це також може вказувати на те, що робити - всі бібліотеки, які важко підтримувати і погано розроблені.

Хороший показник завжди скаже вам, що кожна функція системи має невеликий слід. Менше залежностей, менше складностей, менше дублювання. Це вказує на слабке з'єднання та високу згуртованість.

Невже це "метрика вихідного коду" ніколи не помре?

Сировинні рядки коду (SLOC) - це найдавніший, найпростіший, найосновніший показник.

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

У цей момент показники Галстеда були відмовлені, оскільки вимірювання SLOC завжди легше вимірювати.

Показники вихідного коду для забезпечення якості мають на меті дві цілі:

• написання коду з меншими помилками всередині
• написання коду для зручного обслуговування

Обидва призводять до написання коду максимально просто. Це означає:

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

Наскільки мені відомо, кількість виявлених помилок безпосередньо співвідноситься з рядками коду (ймовірно, збивають), мовою модуля, програмістом та доменом.

Я не знаю жодної іншої прямої та практичної метрики, добре співвіднесеної з помилками.

Одне, що я хотів би зробити, - почати запускати номери для різних проектів, на яких я працюю, - Test Coverage :: kLOC, а потім обговорити "сприйняту якість", щоб побачити, чи є кореляція.

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

Загальні показники, які можуть бути корисними:

• Виявлені помилки / тиждень
• Виправлені помилки / тиждень
• # Визначені вимоги / випуск
• # Виконані вимоги / випуск

Перші два вимірюють тенденції. Ви знаходите помилки швидше, ніж ви можете їх виправити? Два можливі результати: можливо, нам потрібно більше ресурсів для виправлення помилок, можливо, нам потрібно припинити впроваджувати нові функції, поки ми не наздоженемо. Другі два дають уявлення про те, наскільки ви близькі до виконання. Agile команди називають це діаграмою "згоряння".

Цикломатична складність - цікавий показник. В його базовій концепції - це кількість унікальних шляхів виконання у функції / методі. У важкому середовищі для тестових одиниць це відповідає кількості тестів, необхідних для перевірки кожного шляху виконання. Тим не менш, те, що у вас є метод, який має цикломатичну складність 96, не означає, що це обов'язково баггі-код - або що вам потрібно написати 96 тестів, щоб забезпечити розумну впевненість. Не рідкість створеного коду (через генератори WPF або парсера) створити щось таке складне. Це може дати приблизне уявлення про рівень зусиль, необхідний для налагодження методу.

Нижня лінія

Кожне вимірювання, яке ви проводите, повинне мати наступне визначення або воно є марним:

• Розуміння того, що таке "нормально". Це можна скорегувати протягом життя проекту.
• Поріг поза "нормальним", де потрібно вжити певних дій.
• План поводження з кодом при перевищенні порогу.

Вказані показники можуть сильно відрізнятися від проекту до проекту. У вас може бути кілька показників, якими ви користуєтесь у різних проектах, але визначення "нормального" буде іншим. Наприклад, якщо один проект виявив в середньому 5 помилок на тиждень, а новий проект виявляє 10 помилок на тиждень, це не обов'язково означає, що щось не так. Це може бути, що на цей раз команда тестування більш ретельна. Також визначення поняття "нормальне" може змінюватися протягом життя проекту.

Метричний показник - це лише термометр, що ви робите з ним.

Вихідний код - це зобов'язання, а не актив. Зважаючи на це, вимірювання рядків коду є аналогом відстеження доларів, витрачених під час будівництва будинку. Це потрібно зробити, якщо ви хочете залишатися за бюджетом, але вам не обов'язково думати, що витрачати 1000 доларів на день краще, ніж витрачати 50 доларів на день; ви хочете дізнатися, яка частина будинку побудована за ці гроші. Те ж саме з рядками коду в програмному проекті.

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

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

Анекдот, який показує, чому підрахунки KLOC марні (і навіть шкідливі) для оцінки ефективності.

Роки тому я працював над великим проектом (70+ людей у ​​нашій компанії, ще 30+ у нашого замовника), який використовував підрахунки KLOC як єдиний показник ефективності роботи команд та людей.

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

Кінцевий результат за чверть: -40 000 рядків коду. Під час огляду продуктивності після кварталу ми отримали офіційну догану від компанії за те, що ми не виконали наших вимог щодо продуктивності в 20 000 рядків коду, що виробляються на квартал (адже інструменти показали, що ми створили -40 000 рядків коду), які Це призвело б до того, що б нас усіх не зафіксували як недооцінку та обійшли акції, навчання, підвищення зарплати тощо. Якби не втручався керівник проекту та команда з питань якості, а догану скасували та замінили на це похвалою.

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

Я здивований, поки ніхто не згадував Заява / Рішення Покриття одиничних тестів (відсоток коду, що використовується одиничними тестами).

Покриття коду корисно тим, що ви знаєте, який відсоток програми не виходить з ладу; решта його корисності залежить від якості одиниць тестів.

Чим менше, тим краще, тим краще. Йдеться про інструменти SCM, а не за кодом, але це дуже вимірюваний показник. Чим менша фіксація, тим легше бачити кожну зміну як атомну одиницю; тим простіше відновити конкретні зміни та чітко визначити, коли все порушилось.

Поки жодна комісія не порушує збірку ...

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

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

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

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

На моїй роботі є багато ситуацій, коли я використовую кодові показники:

Під час написання коду

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

Розробники абсолютно вільні порушувати всі правила, оскільки вони ніколи не застосовуватимуться до всіх ситуацій. "Правила" існують, щоб стимулювати думку і говорити "Ей, це найкращий спосіб зробити це?"

Під час оглядів QA / Code

Перше, що я зазвичай роблю, коли виконую перевірку коду, - це перевірити покриття коду, який я переглядаю, спільно з інструментом покриття коду, який виділяє, які рядки коду були охоплені. Це дає мені загальне уявлення про те, наскільки ретельним є тестовий код. Мені дуже не байдуже, чи покриття становить 20% або 100%, якщо важливий код добре перевірений. Таким чином, відсоток покриття дещо безглуздий, але 0% впевненості виділяються як біль у великому пальці, як щось, на що я хочу уважно подивитися.

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

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

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

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

З: Які корисні показники можна отримати для вихідного коду?

Для бізнесу:

A: Кількість людино-годин

Для керівника кодеру:

A: Не має значення. Зробимо все сьогодні

Для самооцінки кодера:

A: Кількість SLOC (вихідні рядки коду)

Для матері кодера:

A: Їжте більше цих м'яких французьких булочок і пийте чай

продовження в коментарях нижче ...

Пам’ятайте: весь код можна зменшити хоча б на 1 інструкцію. Усього коду принаймні 1 помилка. Тому весь код можна звести до однієї інструкції, яка не працює. Сподіваюся, що це допомагає!