Чи популярні метричні показники програмного забезпечення в сучасній галузі?

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

Як студент з інформатики, я знаю дуже мало про метрику та їх важливість, але мої запитання:

1. Чи має більшість компаній якийсь спосіб, чи не обов'язково бути елегантною програмою для вимірювання значущих показників?
2. Які показники, поодинокі чи комбіновані, допоможуть вам звузити сферу проектів та оцінку?
3. Як людина, яка аналізує метрику, як часто ви базуєте їх рішення? IE. Невдалі тести на тиждень різко зростають?
4. Чи вважаєте ви, що впровадження вивчення метрик допомогло вам краще зрозуміти проект?

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

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

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

Visual Studio включає деякі інструменти аналізу коду, які можуть розпочати роботу. Більшість компаній навіть не мають змоги оцінити найгірший показник: рядки коду. "Тільки виконайте це", здається, є найбільшою рушійною силою в галузі, і занепокоєння щодо ремонту приділяється дуже короткою увагою до занепокоєнь керівників щодо "я отримаю свій бонус у цьому році?" і "чи буде це зроблено в час, який я обіцяв?" Навіть із продуктами, які з року в рік переносяться з поступовими змінами, ці 2 проблеми карбували розробників щодо проблем ремонту та виявлення / запобігання помилок.

Які показники, поодинокі чи комбіновані, допоможуть вам звузити сферу проектів та оцінку?

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

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

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

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

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

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

Основними ідеями були:

• Жодна особлива метрика не корисна сама по собі.
• Встановлення абсолютної цілі (тобто покриття коду XX%) не має сенсу.
• Показник без історії корисний.

Отже, щоб вирішити це:

• Показати кілька показників, таких як:
  • Кількість рядків / змінено
  • # комісій
  • % покриття коду
  • # тестів
  • цикломатична складність
  • файл / пакет / ... залежність
  • ...
• Показати дані з QA / CI:
  
  • кількість помилок / удосконалення / змін (я особисто думаю, що ця категоризація важлива)
  • # загальна / додана / фіксована
• Покажіть ці показники на графіках, які показують тенденції з часом

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

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

Я планую розмістити кілька графіків за цією схемою на широкоекранному телевізорі поруч із нашими лампами, підключеними CI. ;)