Автоматичний контроль якості Java-коду
Однак, на відміну від працездатності коду, яку можна оцінити за допомогою перевірочних тестів, якість коду не є простою оцінкою TRUE або FALSE. Понад те, під якістю коду розуміється набір суб'єктивних оцінок сприйняття коду іншим людиною. Однак давайте спробуємо якось формалізувати завдання оцінки якості, і, за можливості, дати спосіб автоматичного виконання цього завдання. Який може бути хоча б початковий список пунктів для оцінки?
- Компілювання всього коду
- Працездатність всього коду
- Відповідність стилю написання коду, який використовується в проекті
- Наявність документації для кожної ділянки коду
- Зручність коду на рівні окремих рядків, функцій, файлів
- Можливість швидкого внесення змін до коду, зачіпаючи мінімальний існуючий функціонал
Компіляція
На жаль, ще трапляються в нашому житті ситуації, коли код на проекті не компілюється цілком. У дереві коду зустрічаються ділянки, написані кілька років тому, які ніхто не чіпав, ніхто не змінював, і вони якось перестали не тільки працювати, а й навіть компілюватися. При цьому ці ділянки коду не використовуються в 99%, 99,9% або навіть у 99,98% випадків, але коли настане година X (а за законом Мерфі він обов'язково настане саме в production-системі), замовник буде дуже засмучений.
Чи можна із цим боротися? Потрібно! Вручну – повною періодичною компіляцією всього коду у проекті, а краще автоматично. Наприклад, налаштувати щоденкову компіляцію коду, а краще заразом і викладання цього коду на так званий «інтеграційний сервер» — на якому буде найсвіжіший, можливо, місцями непрацюючий код. Але на цьому сервері ви завжди матимете актуальний стан вашогопроекту, і точно не пропустіть помилок компіляції.
Окремим рядком варто згадати компіляцію не-java файлів. Майже для будь-яких скриптів і для JSP-сторінок існує спосіб перевірити файл на наявність помилок компіляції. Наприклад, у WebLogic можна вказати параметр precompile для вашої веб-програми. Якщо якась JSP міститиме помилки, прекомпіляція перерветься і виведе помилку в балку. Також існує утиліта jspc, що входить до складу WebLogic, що виконує ту ж саму функцію для окремих jsp.
Працездатність
Ваш код працює? А де ви знаєте? Чи можете ви сказати, чи весь код працює прямо зараз, чи якась частина точно працювала тижнів зо два тому, а зараз може вже й не працює? Але ж ви самі знаєте, що практично будь-яка зміна може зламати щось не там, де треба, і навіть там, де не треба.
Або ваша впевненість ґрунтується на тому, що відділ QA (quality assurance) поставив «passed» на всі ваші bugs/issues/patches? То це ще нічого не означає! По-перше, в деяких компаніях QA тестує тільки частини системи, що змінилися. По-друге, QA буває лінивим і непрофесійним, і, як показує мій недавній досвід у деякій неназваній компанії, може просто поставити passed на тест, який просто ліньки було проходити. По-третє, швидше за все в QA теж працюють люди, і вони теж можуть припускатися помилок.
Тож оцінки працездатності вже скрізь використовуються автоматичні тести. Саме вони дозволяють оцінити, чи працездатний ні ваш код на всі 100%. Щоправда, для цього потрібно, щоб:
- автоматичні тести були
- ці автоматичні тести мають покривати 100% функціоналу
Якщо перший пункт є організаційним завданням, то другий — технічним. І під "100%" потрібнорозуміти не наявність тесту на кожну вимогу в деяких requirements'ах, а те, що кожен рядок коду буде виконано в результаті виконання хоча б одного тесту. Ця характеристика називається "code coverage" і буквально означає ступінь покриття коду тестами. Розрізняються такі показники:
- Function Coverage - підрахунок за викликами методів
- Decision Coverage - підрахунок за можливими напрямками виконання коду (then-else або case-case-default в структурах, що управляють). Враховує єдине розгалуження у кожному конкретному випадку.
- Statement Coverage - підрахунок за конкретними рядками коду
- Path Coverage - підрахунок за можливими шляхами виконання коду. Більш широке поняття, ніж decision coverage, оскільки враховує результат усіх розгалужень.
- Conditional Coverage – підрахунок за можливими результатами обчислення значенням булевських виразів та виразів у коді.
Деякі показники є суто теоретичними і для практичних програм зазвичай не використовуються, наприклад, «Path Coverage». Так як досягнення цього показника до 100% для якогось циклу зі змінним числом ітерацій означатиме необхідність перевірки для всіх можливих числа ітерацій… а якщо це залежить від користувача? Та практично неможливо перевірити. Тому зазвичай використовують або «functional coverage», або «statement coverage» (з останнього легко отримати decision coverage). З open source проектів можна назвати:
- emma.sourceforge.net - EMMA
- cobertura.sourceforge.net - Cobertura
Чому одразу про IDE? Та тому, що стиль коду повинен підтримуватись не програмістом, а його IDE, а програміст лише повинен стежити, щоб програма незаривалася. Але якщо програма помилилася, а програміст не простежив? Тоді на допомогу приходять знову ж таки автоматичні засоби перевірки:
- checkstyle.sourceforge.net - Checkstyle
- findbugs.sourceforge.net - FindBugs
Документація
Зручність коду
Зрозуміло, поки що навіть Microsoft Word (OpenOffice Writer) неспроможна відрізнити хороший текст твори від поганого. Максимум – виправити граматичні та стилістичні помилки. Але все-таки хоч щось.
Тому й для коду складно формалізувати поняття «здобутки», але є деякі характеристики, які відзначаютьлегкочитаний код від незручного:
- розмір окремого рядка не більше 120 символів для розміщення на екрані
- Розмір методу не більше одного екрану, щоб читач міг охопити весь метод поглядом і зрозуміти, що він робить
- розмір класу не більше 1000 рядків - відсутність BLOB-антипатерну
- відсутність «магічних» констант (наприклад, 5, 7, 10… читач повинен легко зрозуміти, що це за цифри та звідки вони беруться)
Підбиваючи підсумки"
Прийшовши з ранку, програміст повинен отримати від сервера завдань – список завдань на день, а від інтеграційного – поточний стан справ із кодом.
Хардкорна конфа за С++. Ми запрошуємо лише профі.