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

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

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

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

Існує ряд показників, які можуть дати вам деяку вказівку щодо якості коду:

• Покриття коду. Існують різні інструменти, які показують, який відсоток ваших функцій, висловлювань та рядків охоплюється одиничними тестами. Ви також можете зіставити системні та приймальні тести до вимог, щоб визначити відсоток вимог, які охоплюються тестом на рівні системи. Відповідне покриття залежить від характеру програми.
• З'єднання та згуртованість . Код, який демонструє низьке з'єднання та високу згуртованість, як правило, легше читати, розуміти та тестувати. Існують інструменти аналізу коду, які можуть повідомити про кількість з'єднань та згуртованості в даній системі.
• Цикломатична складність - це кількість унікальних шляхів через додаток. Зазвичай він рахується на рівні методу / функції. Цикломатична складність пов'язана з зрозумілістю та заповітністю модуля. Мало того, що більш високі значення цикломатичної складності вказують на те, що хтось матиме більше проблем з кодом, але цикломатична складність також вказує на кількість тестових випадків, необхідних для досягнення покриття.
• Різні заходи складності Галстеда дозволяють зрозуміти читабельність коду. Вони підраховують операторів і операндів для визначення обсягу, складності та зусиль. Часто це може вказувати на те, як комусь буде складно забрати код і зрозуміти його, часто в таких випадках, як огляд коду або новий розробник до бази коду.
• Кількість дублюючого коду. Дублюваний код може вказувати на потенціал для рефакторингу на методи. Дублікат коду означає, що існує більше рядків для введення помилки, і більша ймовірність наявності одних і тих же дефектів у кількох місцях. Якщо однакова бізнес-логіка існує в декількох місцях, стає важче оновити систему для обліку змін.

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

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

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

Він також підтримує досить широкий діапазон мов.

SonarQube (раніше Sonar ) - платформа з відкритим кодом для постійної перевірки якості коду ...

• Підтримка 25+ мов: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL тощо.
• SonarQube також використовується в Android Deveopment.
• Пропонує звіти про дублюваний код, стандарти кодування, тести блоку, покриття коду, складний код, потенційні помилки, коментарі та дизайн та архітектура.
• Машина часу та диференціальний погляд.
• Повністю автоматизований аналіз: інтегрується з Maven, Ant, Gradle та інструментами безперервної інтеграції (Atlassian Bamboo, Jenkins, Hudson тощо).
• Інтегрується із середовищем розробки Eclipse
• Інтегрується із зовнішніми інструментами: JIRA, Mantis, LDAP, Fortify тощо.
• Розширюється за допомогою плагінів.
• Реалізує методологію SQALE для обчислення технічної заборгованості ...

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

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

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

Між розробниками досить надійним показником технічної заборгованості є WTF / хвилина .

_{Проблема з цією "метрикою" полягає в тому, що спілкуватися "зовні", як правило, досить складно.}

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

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

• набагато простіше зазначити загальну витрату на реалізацію функції A за 3 тижні, ніж
   
  я витратив 14 годин на проект впровадження функції A, потім 29 годин на тестування диму, потім 11 годин на впровадження виправлених я для регресій, а потім 18 годин на тестування якості - вже реалізація функції. Після цього хлопці з QA витратили 17 годин на тестування початкового релізу кандидата. Після цього я витратив 13 годин на аналіз помилок, поданих QA для початкового випуску кандидата, та 3 години на реалізацію виправлень. Після цього я витратив 11 годин на тестування диму змін, які я вніс до початкового звільнення кандидата. Після того...

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

Для останнього випуску ми витратили близько 90% часу на тестування та виправлення регресійних помилок. Для наступного випуску запропонуйте докласти певних зусиль для зниження цього значення до 60-70%.

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

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

• Скажімо, якщо є два подібних компонента / програми, що підтримуються одним і тим же розробником, перший випуск із "витратою" приблизно 50%, а другий на 80-90, це робить досить вагомий випадок на користь того, що другий є об'єктом технічної заборгованості.

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

Завдяки тестерам ви зможете створити резервне копіювання розуміння проблем дизайну. Коли тільки розробники скаржаться на якість коду , це часто звучить як суб'єктивні WTF з-за закритих дверей .
 
Але коли це повторюється тим, що хлопець QA каже щось на зразок component A100 помилок регресії для 10 нових функцій, на відміну від component B10 регресійних помилок на 20 нових функцій , спілкування раптом перетворюється на зовсім іншу гру.

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

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

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

Там є досить сильна платформа під назвою CASTшукати технічну заборгованість у великих програмах. Ми використовували його в проекті, де ми перейняли велике вдосконалення спадкової системи. Це не говорить вам, що було в головах людей, які написали код, але він вивчає код і знаходить недоліки коду та архітектури, а потім кількісно визначає технічну заборгованість. Реальне використання при розгляді цього питання - це не сума $, а перелік проблем, які вже є в коді. Це говорить вам про частину вашої технічної заборгованості (тому я не погоджуюся з деякими відповідями вище). Існує деяка технічна заборгованість, заснована виключно на дизайні, і це дуже суб'єктивно - як порнографія - ви це знаєте, коли бачите її і знаєте контекст. Я б заперечив, чи справді це "технічна" заборгованість. Є деяка технічна заборгованість, яка суто втілюється в життя, і я вважаю, що "

Ось вебінар з MIT, що описує технічну заборгованість у великих програмних системах: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Автори написали код, щоб проаналізувати проект та витягнути метрику «архітектурної складності». Показано, що ці показники мають міцний зв'язок із щільністю дефектів, продуктивністю розробника та плинністю персоналу.

Робота, описана у Вебінарі, ґрунтується на дослідженні модульності, проведеному Аланом Маккормаком та Карліссом Болдуїном у Гарвардській школі бізнесу. Я б також подивився на їхні документи. Їх «вартість розмноження» може бути саме тим, що ви шукаєте.

Я б сказав, що стандартні показники коду можуть використовуватися як високий рівень відносної технічної заборгованості. VS Ultimate включає аналізатор коду, який дасть вам "Індекс ремонтопридатності" на основі цикломатичної складності, зчеплення, LoC та глибини спадкування. Ви можете зануритися в будь-які місця проблем і переглянути деталі (до рівня функцій). Я щойно запустив його у свій проект, і найнижчі результати отримали 69 у нашому пакеті даних (налаштування та ініціалізація EF) та нашому тестовому наборі. Все інше було 90 і вище. Є й інші інструменти, які дадуть вам більше показників, як ті, які обговорювалися в ДПП дядька Боба

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

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

Які ваші думки? Рада відповісти на будь-які запитання і голодна почути ваші відгуки :).

Власність для запобігання дефектам та небажаній заборгованості за техніку

Власність є провідним показником здоров’я інженерії.

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

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

Це дещо аналогічно трагедії общини .

Згуртованість для покращення архітектури

Згуртованість - це індикатор чітко визначених компонентів.

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

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

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

Збийте, щоб визначити проблемні зони

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

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

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

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

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