Контролюємо якість коду за допомогою платформи SonarQube

<img src=«habrastorage.org/getpro/habr/post_images/688/dd3/790/688dd3790b6d716e43bd04da96b1a579.png» height=«300» alt=«Picture » 50" />
У цій статті ми розглянемо основні можливості SonarQube — платформи для безперервного аналізу і вимірювання якості коду, а також обговоримо переваги методики оцінки якості коду на основі метрик SonarQube.

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

Для початку розповім коротко про подання результатів аналізу PVS-Studio. Результати роботи нашого статичного аналізатора PVS-Studio зберігаються у форматі xml. Список повідомлень про виявлені помилки можна відкрити прямо у вікні Microsoft Visual Studio або в окремій утиліті Standalone, і працювати з цими помилками, використовуючи можливості навігації за кодом, сортування, фільтрації, придушення помилкових спрацьовувань і т. д.

<img src=«habrastorage.org/getpro/habr/post_images/58f/5e6/5ec/58f5e65ec727a5a7e429278b49e50d60.png» alt=«Picture » 5"/>
Список знайдених помилок у форматі xml можна перетворити в один з форматів, зручних для читання, наприклад, html. Такі звіти з результатами аналізу можна розсилати всім зацікавленим учасникам проекту поштою. Інший спосіб оповіщення учасників проекту — розсилка списків помилок тим розробникам, які їх допустили. Для цього користувачі можуть використовувати спеціальні утиліти, що поставляються в дистрибутиві PVS-Studio.

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

Динаміку кількості помилок, знайдених PVS-Studio, можна отримати, використовуючи функціональність Analysis Statistics плагіна PVS-Studio для Microsoft Visual Studio або утиліти Standalone:

<img src=«habrastorage.org/getpro/habr/post_images/6cf/332/a05/6cf332a059785abb94e51736b8a2be99.png» alt=«Picture » 4"/>
Перераховані способи представлення результатів роботи нашого статичного аналізатора, однак, існують самі по собі і не пов'язані з іншими метриками коду, такими як кількість рядків коду, цикломатическая складність, кількість помилок на 1000 рядків коду, рівень покриття коду модульними тестами, дублювання і так далі. Звіт про знайдені помилки після чергового аналізу і кількість цих помилок не дає відповідей на питання: багато у нас помилок чи мало? Динаміка кількості помилок пов'язана з зростанням кодової бази? Поліпшується або погіршується якість коду? І, напевно, найголовніше питання менеджерів: коли все буде працювати (скільки часу буде потрібно, щоб усунути помилки)? Ці питання змусили нас замислитися про те, як надати звітів PVS-Studio велику цінність і інформативність.

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

Далі, припустимо, команда усвідомила проблему і переконала свого менеджера в тому, що необхідно витратити ресурси на покращення якості коду. Менеджер, у свою чергу, поставить команді кілька простих запитань: скільки часу знадобиться на це команді? Які частини проекту необхідно покращити? Скільки помилок ви збираєтеся виправити? За якими критеріями ви оціните, що якість коду досягла необхідного рівня, і можна знову повернутися до розробки нової функціональності? Використання метрик дозволить відповісти на всі ці питання. Якщо перед початком робіт з поліпшення якості коду команда зафіксує поточний стан коду по кожному компоненту продукту і визначить порогові значення для кожної метрики, досягнення яких дозволить з певною мірою впевненості заявити, що код продукту став якісним, можна спрогнозувати дату закінчення робіт і зупинитися тоді, коли певні порогові значення будуть досягнуті. Так, наприклад, команда зможе показати менеджеру, що після закінчення робіт по підвищенню якості коду рівень покриття модульними тестами досяг 90%, слідування стандартам кодування, прийнятим в компанії, досягло 95%, а дублювання коду скоротилася до 5%, і т. д.

Чому SonarQube?
SonarQube — це платформа з відкритим вихідним кодом, призначена для безперервного аналізу і вимірювання якості коду. SonarQube надає наступні можливості:

  • Підтримка мов Java, C, C++, C#, Objective-C, Swift, PHP, JavaScript, Python та ін
  • Надає звіти про дублювання коду, дотримання стандартів кодування, покриття коду модульними тестами, можливі помилки в коді, щільність коментарів в коді, технічний борг і інше.
  • Зберігає історію метрик і будує графіки зміни цих показників у часі.
  • Забезпечує повністю автоматизований аналіз: інтегрується з Maven, Ant, Gradle і поширеними системами безперервної інтеграції.
  • Дозволяє інтегруватися з такими IDE, як Visual Studio, IntelliJ IDEA і Eclipse з допомогою плагіна SonarLint.
  • Забезпечує інтеграцію з зовнішніми інструментами: JIRA, Mantis, LDAP, Fortify і т. д.
  • Можна розширювати існуючу функціональність за допомогою сторонніх плагінів.
  • Реалізує методологію SQALE для оцінки технічного боргу.
Вражаючий список, чи не так? Ви можете самі познайомитися з можливостями SonarQube і спробувати його в дії, перейшовши за посиланням https://sonarqube.com/. Компанія SonarSource надає цей сервіс для аналізу open source-проектів, і, якщо у вас є відкритий проект на GitHub, ви можете завантажити його в сервіс https://sonarqube.com/ і користуватися звітами SonarQube для котролю якості коду вашого проекту.

Ми ретельно вивчили можливості платформи SonarQube і вирішили, що ці можливості можуть бути цікаві нашим клієнтам. Тому ми прийняли рішення про розробку плагіна для імпорту результатів аналізу PVS-Studio.

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

Виходячи з потреб клієнта і нашого дослідження можливостей платформи SonarQube, ми запропонували впровадити цю платформу. Що і було зроблено. У рамках завдання по впровадженню був реалізований плагін для SonarQube, що дозволяє імпортувати в SonarQube результати аналізу PVS-Studio. Процес розгортання SonarQube і його інтеграції з наявним оточенням (складальна система, сервер безперервної інтеграції, система контролю версій) не викликав труднощів завдяки логічним механізмів налаштування і великої кількості докладної документації. Були налаштовані віджети, які дозволяють оцінювати стан портфоліо проектів клієнта в цілому, так і стан кожного проекту окремо, налаштовані Quality Profiles і Quality Gates (про ці механізми SonarQube я розповім нижче) згідно потребоностям клієнта, автоматичне призначення завдань на виконавців, розсилка повідомлень всім зацікавленим особам.

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

Слід зазначити, що SonarQube, завдяки своїм широким можливостями інтеграції з іншими інструментами, легко може стати невід'ємною частиною вашого фреймворку ALM. За допомогою плагінів в SonarQube можна додати підтримку Git, SVN, Mercurial, Team Foundation Version Control, ClearCase, налаштувати авторизацію через LDAP, GitHub, Bitbucket, Microsoft Active Directory, імпортувати результати роботи сторонніх аналізаторів. Плагіни SonarLint для IntelliJ IDEA, Eclipse і Visual Studio дозволяє аналізувати код в режимі реального часу в вашої улюбленої IDE, використовуючи правила, визначені в профілі SonarQube. Також доступна інтеграція з Team Foundation Server і Visual Studio Team Services. Ви можете запустити аналіз коду і імпорт даних в SonarQube прямо з складального процесу в цих системах, або, наприклад, керувати станом збірок в Team Foundation Server і Visual Studio Team Services з допомогою Quality Gates (індикаторів якості збірки), настронных в SonarQube: якщо код не задовольняє вимогам Quality Gate, збірка буде вважатися невдалою. Таким чином, розробники SonarQube прагнуть зробити свій продукт максимально відкритим і дозволити командам розробників інтегрувати SonarQube в їх оточення.

Для яких же проектів і команд доцільно впроваджувати SonarQube? Я вважаю, що для відносно короткосрочних проектів (не більше 2 — 3 місяців), якими займаються невеликі команди (не більше 5 осіб), інвестиції у впровадження SonarQube в процес розробки можуть не виправдатися. Як правило, такі проекти не вимагають великих витрат на підтримку продукту. Для таких проектів я б рекомендував обмежитися окремими інструментами для контролю стану коду проекту: статичний аналізатор, контроль покриття коду тестами, відповідність стандартам кодування і т. д., які команда звикла використовувати.

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

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

Як SonarQube допомагає оцінити якість коду
В основі моделі якості SonarQube лежить реалізація методології SQALE (Software Quality Assessment based on Lifecycle Expectations) з певними доповненнями. Як відомо, методологія SQALE фокусується в основному на складності підтримки коду (maintainability) і не враховує ризики проекту. Наприклад, якщо сьогодні в проекті виявилася критична проблема безпеки, суворе дотримання методології SQALE зобов'язує вас усунути всі вже існуючі проблеми з надійністю (reliability), можливістю змін (changeability), тестируемостью (testability) і т. д., і тільки потім повернутися до нової критичної проблеми. Насправді, якщо потенційні проблеми існують в коді давно і не проявляють себе у вигляді користувальницьких баг-репортов, набагато важливіше сфокусуватися на виправлення нових багів.

З урахуванням цього, розробники SonarQube модифікували модель якості, засновану на SQALE, щоб акцентувати увагу на таких важливих моментах:

  • Модель якості повинна бути максимально простою у використанні
  • Баги і уразливості не повинні губитися серед проблем поддерживаемости (maintainability)
  • Наявність серйозних помилок і вразливостей в проекті повинно призводити до того, що вимоги Quality Gate не виконані
  • Проблеми поддерживаемости коду теж важливі, і їх не можна ігнорувати
  • Обчислення вартості усунення проблем (використання моделі аналізу SQALE) важливо і повинно виконуватися
Стандартний Quality Gate SonarQube використовує наступні значення показників для визначення того, що код успішно пройшов перевірки:

  • 0 нових багів
  • 0 нових вразливостей
  • коефіцієнт технічного боргу на новому коді <= 5%
  • покриття нового коду не нижче 80%
Команда Sonar визначила сім смертних гріхів розробників, збільшують технічний борг:

  • Баги і потенційні баги
  • Порушення стандартів кодування
  • Дублювання коду
  • Недостатнє покриття модульними тестами
  • Поганий розподіл складності
  • Спагетті-дизайн
  • Недостатньо або занадто багато коментарів
Платформа SonarQube призначена для того, щоб допомагати боротися з цими сімома гріхами.

Розглянемо більш детально основні можливості SonarQube.

Головна сторінка
На головній сторінці SonarQube ви бачите список проектів, доданих у систему, з короткою статистикою щодо кожного проекту: версія збірки, кількість рядків коду, кількість багів, вразливостей і ознак «коду з душком», дата останнього аналізу:

Picture 7
Вміст головної сторінки можна налаштувати під ваші цілі з допомогою великого набору вбудованих віджетів, що дозволяють візуалізувати стан коду проектів в SonarQube.

Метрики проекту
Для отримання більш детальної інформації про стан проекту перейдемо на сторінку метрик проекту:

<img src=«habrastorage.org/getpro/habr/post_images/221/0a2/150/2210a215052586f9864017951fa29fdd.png» alt=«Picture » 9"/>
Тут представлена інформація про наступних метриках коду: Reliability (Надійність), Security (Безпека), Maintainability (Поддерживаемость), Coverage (Покриття тестами), Duplications (Дублювання), Size (Розмір кодової бази), Complexity (Цикломатическая складність), Documentation (Документування коду) і Issues (Помилки).

Перейшовши до метриці Reliability, ми отримуємо інформацію про загальну кількість виявлених багів і нові баги, виявлені під час останнього аналізу, рейтинг надійності коду за шкалою від A до E, де E — найгірший рейтинг, який свідчить про те, що був знайдений принаймні один blocker баг, а також час, необхідний на виправлення всіх знайдених помилок:

<img src=«habrastorage.org/getpro/habr/post_images/999/190/03d/99919003d36420fd51b4be20e675d7ed.png» alt=«Picture » 11"/>
Платформа SonarQube дозволяє аналізувати метрики коду зверху вниз, від рівня проекту в цілому до окремих модулів і файлів. Так, наприклад, якщо ви натисните на рейтинг надійності (Reliability Rating), ви побачите список файлів проекту, відсортованих по зростанню рейтингу надійності. Це дозволить сфокусуватися на найбільш проблемних ділянках коду:

Picture 13
Потім ви можете перейти до файлу з вихідним кодом і до конкретних ділянок коду, в яких виявлені помилки:

Picture 15
Така навігація зверху вниз доступна і для інших показників.

На сторінці метрики Security доступна інформація про загальну кількість вразливостей, нових вразливості, рейтингу безпеки (також за шкалою від A до E), і часу, який буде потрібно на усунення вразливостей:

<img src=«habrastorage.org/getpro/habr/post_images/33f/af1/d18/33faf1d18f6e3ff1e040cf71dd6a1fcb.png» alt=«Picture » 17"/>
Сторінка Maintainability містить інформацію про технічний борг у проекті:

<img src=«habrastorage.org/getpro/habr/post_images/f3a/561/ea0/f3a561ea09511bf7c9543174b5b6d8b8.png» alt=«Picture » 19"/>
Завдяки навігації «зверху вниз» ви можете перейти до списку файлів, відсортованих за кількістю виявлень коду з душком:

<img src=«habrastorage.org/getpro/habr/post_images/45a/b7e/d42/45ab7ed423fa156c69cc0b9b023e4c96.png» alt=«Picture » 21"/>
і потім безпосередньо до коду, який потребує уваги:

<img src=«habrastorage.org/getpro/habr/post_images/a24/4c0/ddf/a244c0ddf4fbe22b96c9096473c24b65.png» alt=«Picture » 23"/>
На сторінці Coverage представлена інформація про покриття коду тестами:

<img src=«habrastorage.org/getpro/habr/post_images/ac6/2aa/5d8/ac62aa5d8e2191f8e9fe4b01c812cba4.png» alt=«Picture » 25"/>
Сторінка Duplications містить інформацію про дублювання коду в проекті:

<img src=«habrastorage.org/getpro/habr/post_images/bb4/abc/ef1/bb4abcef1e5844d67fa513b95212a4cd.png» alt=«Picture » 27"/>
За допомогою цієї метрики ви легко можете виявити повторювані рядки, блоки коду і навіть цілі файли:

<img src=«habrastorage.org/getpro/habr/post_images/e0f/a8c/546/e0fa8c546aed3e9913d2d8346cc0b553.png» alt=«Picture » 29"/>
Сторінка Size містить інформацію про розмірі проекту: кількість рядків коду, виразів, функцій, класів, файлів та директорій:

<img src=«habrastorage.org/getpro/habr/post_images/e28/d36/be5/e28d36be58f974c18226708590cd43fa.png» alt=«Picture » 31"/>
На сторінці Complexity представлена інформація про сумарної цикломатической складності проекту, а також про середньої складності функцій та файлів:

<img src=«habrastorage.org/getpro/habr/post_images/16f/e20/fde/16fe20fdefa2852ba021726a4afc85b8.png» alt=«Picture » 33"/>
Сторінка Documentation надає інформацію про коментарі в коді: ставлення рядків з коментарями до загальної кількості рядків в проекті, кількість рядків з коментарями, кількість публічних API і рівень документування публічних API:

Picture 35
Остання вкладка в розділі метрик проекту — Issues — містить загальна кількість знайдених проблем в коді (сума кількості багів, вразливостей і code smells), а також розподіл проблем за станом на: відкриті, переоткрытые, підтверджені, помилкові спрацьовування і won't fix:

<img src=«habrastorage.org/getpro/habr/post_images/94d/19a/dca/94d19adcadafeb9dc54ecd545c76823b.png» alt=«Picture » 37"/>
Навігація по помилок і кодом
Після аналізу метрик коду подивимося, як SonarQube дозволяє працювати з знайденими проблемами в коді. Для цього перейдіть у розділ Issues:

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

По подвійному кліку на повідомленні про помилку, ви можете перейти до коду, в якому була знайдена проблема. Також доступно детальний опис помилки і рекомендації, як її виправити:

Picture 41
Зверніть також увагу, що, завдяки інтеграції з системами контролю версій, видно, хто і коли вніс зміни в код, які викликали спрацювання аналізатора:

Picture 43
Інтеграція з системами контролю версій дозволяє автоматично призначати баги в SonarQube на тих розробників, які їх допустили. Також ви можете призначати баги на розробників вручну, змінювати їх тип (bug, vulnerability або code smell), важливість, теги, додавати коментарі. Для більшої зручності використання доступна функція масового зміни багів:

<img src=«habrastorage.org/getpro/habr/post_images/a4f/15c/040/a4f15c0404fa3e9c72379ceed767f06a.png» alt=«Picture » 44"/>
Rules, Quality Profiles і Quality Gates
Діагностичні правила (Rules), профілі якості (Quality Profiles) і межі якості (Quality Gates) — ключові понятния платформи SonarQube. Кожен плагін для SonarQube, здійснює статичний аналіз коду, містить репозиторій з описом діагностичних правил, які цей плагін виконує. Порушення цих правил використовуються для визначення технічного боргу в коді і обчислення часу на усунення проблем. Для зручності використання правила об'єднуються в профілі якості (Quality Profiles). За замовчуванням, SonarQube створює дефолтний профіль якості для кожного підтримуваного мови, але ви можете створювати свої профілі якості з тим набором діагностичних правил, які вам можуть бути корисні. Наприклад, для аналізу критично важливих проектів, вимоги до якості коду яких самі суворі, можна визначити профіль якості, що містить всі доступні діагностики, а для менш критичних проектів можна визначити менш суворий профіль якості, що містить тільки серйозні помилки, що дозволить не відволікатися на незначні code smells.

Quality Gate — це індикатор відповідності (або невідповідності) коду проекту заданим граничним значеннями метрик. За замовчуванням, всі проекти, додані в SonarQube, використовують стандартний quality gate, в якому визначені наступні метрики та їх порогові значення:
  • Нові баги = 0
  • Нові уразливості = 0
  • Коефіцієнт технічного боргу на новому коді <= 5%
  • Покриття нового коду >= 80%
Виходячи з ваших власних вимог до якості вихідного коду, ви можете змінити стандартний quality gate або створити новий, додаючи або видаляючи ті метрики та їх порогові значення, які представляють для вас інтерес.

PVS-Studio і SonarQube
Для імпорту результатів аналізу в SonarQube ми розробили плагін sonar-pvs-studio-plugin. Використання плагіна дозволяє додавати повідомлення, знайдені аналізатором PVS-Studio, в базу повідомлень сервера SonarQube. Плагін містить репозиторій з описом діагностик, які виконує наш статичний аналізатор. Після того, як ви додасте наш плагін в SonarQube, ви побачите репозиторій з назвою PVS-Studio для мов C, C++ і C#:

Picture 45
Діагностичні повідомлення PVS-Studio в репозиторії плагіна супроводжуються докладними описами помилок з прикладами коду та рекомендаціями щодо усунення проблеми:

Picture 47
Після статичного аналізу коду проекту та імпорту результатів у SonarQube, з допомогою фільтрів ви можете, наприклад, вибрати всі невиправлені проблеми, знайдені PVS-Studio:

Picture 49
Щоб додати результати аналізу PVS-Studio в SonarQube, досить встановити плагін sonar-pvs-studio-plugin, додати діагностики PVS-Studio з репозиторію плагіна в Quality Profile і передати шлях до файлу звіту PVS-Studio властивості sonar.pvs-studio.reportPath при запуску сканера SonarQube.

Для аналізу проектів MSBuild розробники SonarQube рекомендують використовувати SonarQube Scanner for MSBuild. Цей сканер являє з себе обгортку над стандартним сканером SonarQube і полегшує процес створення конфігураційного файлу сканера sonar-project.properties, автоматично додаючи в нього модулі (проекти у вирішенні) і записуючи шляху до вихідних файлів, які необхідно проаналізувати.

Однак ми зіткнулися з важливими з нашої точки зору обмеженнями сканера SonarQube Scanner for MSBuild.

По-перше, при аналізі C/C++ проектів цей сканер додасть до списку файлів для аналізу тільки ті файли, які додані властивості ClCompile і ClInclude проектного файлу .vcxproj. Якщо, наприклад, заголовковий файл не включений в проект і підключений в коді одного з вихідних файлів, цей файл буде проігноровано, і результати аналізу цього файлу будуть відсутні в SonarQube.

По-друге, SonarQube Scanner for MSBuild не додає для аналізу вихідні файли, розташовані вище по дереву каталогів, ніж каталог, в якому знаходиться проектний файл. Повідомлення для таких файлів будуть також відображатися в SonarQube.

Виходячи з цих обмежень, для імпорту результатів аналізу PVS-Studio ми рекомендуємо використовувати стандартний сканер SonarQube. Використання цього сканера передбачає створення конфігураційного файлу sonar-project.properties вручну. Використання та налаштування сканера описані в статті Analyzing with SonarQube Scanner.

За замовчуванням, сканер SonarQube індексує вихідні файли для аналізу, розташовані по дереву каталогів нижче, ніж рішення файл (.sln) або проекту (.vcxproj/.csproj). Для аналізу проектів зі складною структурою, де вихідні файли можуть знаходитися вище по дереву каталогів, ніж файл або проекту рішення, властивості sonar.projectBaseDir потрібно вказати найвищий загальний каталог для всіх вихідних файлів (в крайньому випадку, це може бути корінь диска), і властивості sonar.sources потім перерахувати директорії, в яких слід шукати вихідні файли для аналізу (або повні шляхи до вихідних файлів).

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

При розробці нашого статичного аналізатора ми фокусуємося на пошуку помилок в коді, і не підтримуємо пошук потенційних вразливостей і code smells, тому при використанні нашого плагіна для SonarQube метрики Security і Maintainability не будуть заповнені. Також слід зазначити, що в поточній версії нашого плагіна не реалізовано обчислення Duplications, Complexity і Documentation.

Висновок
У цьому огляді я спробував показати, як SonarQube дозволяє впровадити і застосовувати практики контролю якості коду на основі метрик. Як сказав Пітер Друкер (або, можливо, це був Вільям Демінг): if you can't measure it, you can't improve it. Регулярний збір метрик коду, аналіз їх зміни з плином часу дозволяє виявляти, що технічний борг накопичується, поддерживаемость коду знижується, що призводить до збільшення вартості розробки нового функціоналу та підвищення ризиків, пов'язаних з постачанням нових версій продукту. Наведу цитату з книги «Програміст-прагматик. Шлях від підмайстри до майстра» Ендрю Ханта і Девіда Томаса:

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

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

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

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

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

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

Також ви можете перевірити свої проекти, написані на мовах C/C++ та C#, з допомогою статичного аналізатора PVS-Studio.

Корисні посилання



Якщо хочете поділитися цією статтею з англомовної аудиторією, то прошу використовувати посилання на переклад: Pavel Kusnetsov. Control source code quality using the SonarQube platform.

Прочитали статтю і є питання?Часто до наших статей задають одні і ті ж питання. Відповіді на них ми зібрали тут: Відповіді на питання читачів статей про PVS-Studio, версія 2015. Будь ласка, ознайомтеся зі списком.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.