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

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

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

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

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

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

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

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). Так-так, ми пишемо юніт тести:

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

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

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

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

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

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

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

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

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

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

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

Рекомендуємо:

Звіт з IDCEE 2012
« Розумні » пошуковики в мережі
Мобілочка
Дайджест : досвід співбесіди в Google , колекція онлайн - уроків програмування , Mono 3.0
Результати опитування по мобільній розробці