Як дізнатися, чи програмне забезпечення добре чи погано на основі емпіричних показників?

Наразі мене просять переглянути проект, який завершив розробку основних процесів п'ять місяців тому, але все ще має високий рівень дефектів. Що стосується приблизно кожні 10 виправлених дефектів, ми піднімаємо щонайменше 4, а в деяких випадках 8 дефектів.

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

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

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

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

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

Окрім того, щоб змусити нашого провідного розробника зробити експертну перевірку коду за випуск, не знаєте, що ще можна зробити?

Ви цього не робите.

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

Обґрунтування статусом

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

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

Міркування контррозвідкою

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

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

Скажімо, ви вимірюєте дефекти на LOC. Як я буду це грати? Легко - просто додайте більше коду! Зробіть дурний код, що призводить до неробочої роботи понад 100 рядків і раптом у вас менше дефектів на LOC. Найкраще: ви фактично таким чином знизили якість програмного забезпечення.

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

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

Обґрунтування неправильним націленням

Ви хочете виміряти якість програмного забезпечення. Що ви вимірюєте, це одна чи кілька показників.

Існує розрив між тим, що ви вимірюєте, і тим, що ви вірите, що це скаже вам. Цей розрив є наче величезним рівним.

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

Обґрунтування кількісно вимірюваним

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

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

редагувати:

Підсумок

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

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

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

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

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

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

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

Це вам скаже, наскільки складний код. Я можу вам сказати, що в кожній проблематичній системі я мала погану кількість. Складність методів від 10 до 100 секунд значно перевищує допустимі межі. Страшні числа. Жахлива складність, гніздування, глибина тощо. Це призведе до безлічі проблем, постійного високого рівня дефектів, важко вносити зміни, не порушуючи щось інше тощо.

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

Сюжет повинен виглядати приблизно так:

Дефекти з часом

Якщо вони залишаються постійними або збільшуються, то програмне забезпечення не добре. У вас всього 4 місяці, тому я б дав це ще кілька місяців на рік. Через 6 місяців до року, якщо у вас був постійний потік дефектів, то це погана якість. Ваша команда розробила ще одну кульку грязі .

Наступні тести. У вас їх є? Якщо не менша якість, то більше клопів, більше пилу. Якщо у вас є такі показники, такі як покриття коду, добре мати уявлення про те, скільки коду охоплюється, але воно не вимірюватиме якість . Я бачив чудові цифри покриття коду, але фактичні тести були лайноми. Вони не перевіряли жодної поведінки чи функціональності системи. Розробники просто писали їх, щоб покращити метричні числа для управління. Отже, ви повинні мати тести, і вони повинні бути хорошими. Показники охоплення коду самі по собі не є показником якості.

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

Нарешті, вам просто доведеться оцінювати код, жоден показник не допоможе вийти з ладу. Кожен проблемний кодовий проект мав такі якості:

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

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

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

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

Якщо у вас є доступ до вихідного коду, ви можете запустити аналіз статичного коду. Для проектів .Net можна використовувати, наприклад, FxCop або ReSharper InspectCode. При правильному використанні команди, що розвивається, інструменти допоможуть поліпшити якість. Але звичайно, деякі «виправлення» для видалення попереджень без їх розуміння можливі.

Ви можете подивитися на автоматизовані тести / UnitTests: наскільки добре покриття коду? Але лише покриття не скаже вам, чи тести дійсно перевіряють код, чи його просто виконували один раз.

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

Одне, на що слід звернути увагу на додаток до збирання такої метрики, як інжекція дефектів, - це з'ясування джерела дефектів. Часто це стосується специфікації.

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

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

Знизу, немає способу це знати.

На первісне запитання (до філософської відповіді): Що повинен робити твір і чи він це робить? Вимірювання за кількістю / дефектом дефектів недостатньо. Я не міг сказати, чи це бібліотека, чи програма, наскільки велика база коду, наскільки велика проблемна домен, чи яка вираженість дефектів. Наприклад, не обробка одного із 123 форматів введення може бути тривіальним дефектом або показом пробки, залежно від важливості формату, який не використовується належним чином. І краще, ніж нічого, це високий стандарт.

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

Програмне забезпечення можна вимірювати лише суб'єктивно. Тобто, метрика, яка має значення для програмного забезпечення, полягає в тому, чи люди використовують його для вирішення проблеми. Ця метрика залежить від поведінки інших людей, отже, її суб'єктивно. Примітка. Для деяких проблем частина програмного забезпечення може бути досить корисною, і тому вважається високою якістю (Excel для розрахунків), але не якісною програмою для іншої проблеми (Excel для відтворення MP3-файлів).

Код можна (як правило) вимірювати емпіричними показниками . Але інтерпретація не є "так / ні" для якості або навіть дійсно за шкалою "0 до N". Показники вимірюються порівняно зі стандартом. Отже, в метриці можна знайти сфери, що викликають занепокоєння, визначені стандартом, але відсутність проблемних областей не є доказом того, що це код якості. Наприклад, корисні показники: чи компілюється? Ні -> Не якість. Так -> ??? Чи проходить тест одиниці? Ні? Можливо? (тому що, чи є код якості одиничного тесту?), так -> ???

Отже, як показано Доказ Недосконалості Годеля для аксіом математики (тобто існують математичні твердження, які не можуть бути підтверджені правдивими або хибними для будь-якого кінцевого набору аксіом), я не думаю, що ми ніколи насправді могли відповісти "- це ця якість код? ' для кожного фрагмента коду. Інтуїтивно зрозуміло, що, можливо, існує відображення між програмними показниками, щоб відповісти на якість та математичні аксіоми, щоб відповісти як істинно чи неправдиво.

Ще один спосіб зробити цей аргумент - перейти на природну мову. Вільям Шекспір, Льюїс Керролл та Марк Твен - усі успішні письменники, улюблені багатьма за якість своїх творів. Але який стандарт граматики, лексики, стилю чи голосу ми могли б застосувати, які б стабільно оцінювали їх вище, ніж випадкові 12-класоводи? І хоча для цих трьох можливо створити якусь синтетичну міру, як би вона оцінила Книгу Іоанна (KJV), JRR Толкіна, Гомера, Сервантеса тощо? Потім киньте в Берроуз, Фолкнер, Хемінгуей, Сильвію Плат тощо. Показник не працюватиме.

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

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

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

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

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

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

Якщо ви шукаєте повністю автоматизовані вимірювання, то рекомендую таких хлопців: Group Improvement Group

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

У них також є гідна книга, в якій описуються всі їхні показники на практиці, про які варто прочитати: «Побудова технічного забезпечення» .