Метрики коду , або Як визначити внутрішню якість продукту

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

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

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

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

Отже, внутрішня якість нам забезпечує:

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

Як же це внутрішня якість контролювати? Підходів є декілька. Ми застосовуємо всі.

1. Проводити code review

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

На що ми перевіряємо код під час code review? На відповідність стандартам, відсутність антіпаттернов (як в коді, так і в побудові схеми БД), проходження практик ООП/ООД, якість документації.

На проведення code review ми окремо закладаємо час, у нас є спеціальний статус для задач (Open->In Progress->Ready for Code Review->In Review->Ready for Testing ...). Так що не зробити не вийде.

2. Використовувати сторонні інструменти контролю якості коду

Ми використовуємо Sonar і для Java, і для. NET проектів. На що ми інспектуємо код за допомогою Sonar?

Покриття коду юніт тестами (Code coverage). Так-так, ми пишемо юніт тести:

Line Coverage - скільки рядків коду виконано і протестовано. Наша метрика, яку ми дотримуємо - 80%.
Branch coverage - кожне Чи умовний вираз (true/false) було виконано і протестовано. Аналогічно - 80%. Більш важливий, ніж line coverage, тому показується реальний ступінь тестованих бізнес-логіки.

Коментарі (Comments) :

документовані API - стежимо, щоб код містив пояснень. Особливо важливо для розподілених Agile проектів. Метрика - 80% публічних методів повинні бути задокументовані.
Стежимо, щоб не було закоментувати коду - 0 рядків.

Відсутність зв'язності усередині методів (LCOM4) - чим ця метрика більше, тим ризик падіння системи вище при зміні функціонала. Особливо через тих місць, які дають збільшення цієї метрики (Sonar видає усереднену).

Індикатор сплутаності пакетів (Package tangle index) - кількість циклічний залежностей між пакетами і загальним числом залежностей повинно прагнути до 0.

Відсоток дублювання коду (Duplications) - відсутність копіпаста коду - повинно прагнути до 0%

Цикломатичне складність (Сomplexity) коду визначає складність структури коду: чим менше вкладених операторів розгалуження і циклів, тим краще:

На метод ми дотримуємося метрики - до 7. Більше - рефакторім.
На клас - до 15.
На файл - ми відключаємо.

Також ми уважні до зауважень (violations) , які видає Sonar - ми виправляємо блокери, крітікали і мажори.

Sonar - настроюється інструмент, і є ще безліч метрик, які можна збирати і аналізувати. Іноді ми до них звертаємося, але часто зупиняємося на вищеперелічених стандартних.

Що впливає на можливість відстежувати внутрішньо якість?

Грамотний CI. Не буде його - не буде можливості збирати метрики.
Вишикувані процеси. Під час спринту розробники відстежують метрики на своїх машинах, проводять code review В кінці спринту, на ретроспективі, метрики - один з обов'язкових предметів обговорення, якщо щось залишилося не так - закладаємо завдання на корекцію на слід спринт.

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

У наступній замітці спробую трохи відкрити таємницю KPI, CSF і ще декількох абревіатур, які так люблять замовники і топ менеджмент.

Опубліковано: 30/10/12 @ 09:08
Розділ Різне

SEO Блог