Показники вихідного коду для вимірювання стабільності коду?

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

Наприклад, можна побачити, що протягом перших шести місяців проекту середнє становило 200 рядків коду на день, тоді як протягом останнього місяця це було 50 рядків коду на день та протягом останнього тижня (безпосередньо перед DVD-кодом продукту були відправлені), рядки коду взагалі не були змінені (заморозка коду). Це лише приклад, і залежно від процесу розробки, прийнятого певною командою, можуть з'являтися різні закономірності.

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

Один з заходів, який описав Майкл Перо, - " Активний набір класів ".

Він вимірює кількість класів, доданих проти "закритих". Описується закриття класу як:

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

Він використовує ці заходи для створення таких діаграм:

Чим менше число проміжків між двома лініями, тим краще.

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

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

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

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

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

Якщо ви використовуєте git або svn, а версія вашого ресурсу> = 0,39, це так само просто, як запуск gource в папці проекту.

Використання частоти модифікованих ліній як індикатора стабільності коду є принаймні сумнівним.

Спочатку розподіл модифікованих ліній у часі сильно залежить від моделі управління програмним забезпеченням проекту. Існують великі відмінності в різних моделях управління.

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

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

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

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

Міцність вимірюється за допомогою тестів. Одиничні випробування, димові випробування, автоматизовані регресійні тести; тести, тести, тести!

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

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

Найкращі побажання.