Автоматичен контрол на качеството на Java кода

Въпреки това, за разлика от изправността на кода, която може да бъде оценена чрез провеждане на тестове за валидиране, качеството на кода не е проста оценка на TRUE или FALSE. Освен това качеството на кода се разбира като набор от субективни оценки на възприемането на кода от друго лице. Нека все пак се опитаме по някакъв начин да формализираме задачата за оценка на качеството и, ако е възможно, да дадем начин за автоматично изпълнение на тази задача. Какъв може да бъде поне първоначален списък с елементи за оценка?

Компилиране на целия код
Изпълнението на целия код
Съответствие със стила на кодиране, използван в проекта
Наличие на документация за всеки раздел от кода
Четимост на кода на ниво отделни редове, функции, файлове
Възможност за бързо извършване на промени в кода, засягащи минималната съществуваща функционалност

Компилация

За съжаление, все още има ситуации в нашия живот, когато кодът на проекта не се компилира в своята цялост. В кодовото дърво има секции, написани преди няколко години, които никой не е пипал, никой не е променил и те някак си спряха не само да работят, но дори и да компилират сами. В същото време тези кодови секции не се използват в 99%, 99,9% или дори 99,98% от случаите, но когато дойде часът X (и според закона на Мърфи той определено ще дойде в производствената система), клиентът ще бъде много разстроен.

Възможно ли е да се борим с това? Трябва да! Ръчно - пълна периодична компилация на целия код в проекта и за предпочитане автоматично. Например, настройте седмично компилиране на кода и в същото време е по-добре да качите този код на така наречения "интеграционен сървър" - който ще съдържа най-новия, може би на някои места неработещ код. Но на този сървър винаги ще имате текущото си състояниепроект и със сигурност не пропускайте грешки при компилиране.

На отделен ред си струва да се спомене компилацията на не-java файлове. За почти всеки скрипт и за JSP страници има начин да проверите файл за грешки при компилиране. Например в WebLogic можете да посочите опцията за предварително компилиране за вашето уеб приложение. Ако някой JSP съдържа грешки, предварителната компилация ще прекъсне и ще отпечата грешката в журнала. Има също така помощна програма jspc, включена в WebLogic, която изпълнява същата функция за отделни jsp.

производителност

Вашият код работи ли? Откъде знаеш? Можете ли да разберете дали целият код работи в момента или някоя част определено е работила преди две седмици, а сега може вече да не работи? Но вие сами знаете, че почти всяка промяна може да „счупи“ нещо на грешното място и дори на грешното място.

Или вашата увереност се основава на факта, че отделът за QA (осигуряване на качеството) е поставил „приет“ на всички ваши грешки/проблеми/кръпки? Така че нищо не означава! Първо, в някои компании QA тества само части от системата, които са се променили. Второ, QA може да бъде мързелив и непрофесионален и, както показва скорошният ми опит в някои неназовани компании, може просто да издържи тест, който просто е бил твърде мързелив, за да премине. Трето, най-вероятно хората също работят в QA и те също могат да правят грешки.

Следователно автоматизираните тестове вече се използват навсякъде за оценка на ефективността. Те ви позволяват да прецените дали вашият код е 100% работещ или не. Вярно е, че за това трябва да:

бяха автоматични тестове
тези автоматизирани тестове трябва да покриват 100% от функционалността

Ако първата точка е организационна задача, то втората е техническа. И под "100%" трябваразбирайте не наличието на тест за всяко изискване в някои изисквания, а факта, че всеки ред от код ще бъде изпълнен в резултат на изпълнението на поне един тест. Тази характеристика се нарича "покритие на кода" и буквално означава степента на покритие на кода от тестовете. Различават се следните показатели:

Функция Coverage - броене по извиквания на метод
Decision Coverage - преброяване по възможни посоки на изпълнение на кода (then-else или case-case-default в контролните структури). Разглежда един клон във всеки случай.
Statement Coverage - броене за конкретни редове код
Path Coverage - изчисляване на възможните пътища за изпълнение на кода. По-широка концепция от покритието на решенията, тъй като взема предвид резултата от всички клонове.
Условно покритие – изчисление въз основа на възможни резултати от изчисление, стойности на булеви изрази и подизрази в кода.

Някои индикатори са чисто теоретични и обикновено не се използват за практически приложения, например „Покритие на пътя“. Тъй като достигането на този индикатор до 100% за някакъв цикъл с променлив брой итерации ще означава необходимост от проверка за всички възможни итерации ... и дали зависи от потребителя? Да, почти невъзможно е да се провери. Следователно обикновено се използва или „функционално покритие“, или „покритие на отчет“ (лесно е да се получи покритие за вземане на решения от последното). От проекти с отворен код можем да споменем:

emma.sourceforge.net - ЕММА
cobertura.sourceforge.net - Кобертура

EclEmma - Покритие на Java код за Eclipse

Защо веднага за IDE? Да, защото стилът на кода трябва да се поддържа не от програмиста, а от неговата IDE, а програмистът трябва само да се увери, че програмата незаровен. Но какво ще стане, ако програмата направи грешка и програмистът не я последва? Тогава отново на помощ идват инструментите за автоматична проверка:

checkstyle.sourceforge.net - Стил на проверка

Но стилът не завършва с оформлението и броя на интервалите във вдлъбнатината. Следващата стъпка е да използвате общоприети или корпоративни стандарти в кода. Например, прието е, че всеки Serializable клас трябва да има serialVersionUID, че всяко изключение трябва да бъде неизменно и стойността на изключението в блока catch не се променя. Въпреки че нарушенията на тези конвенции може в момента да не генерират грешки, те правят кода по-малко разбираем от лицето, от което се очаква да следва стандартните правила. Сред програмите, които проверяват кода за такива несъответствия, бих искал да спомена същия стил на проверка, както и програмата FindBugs:

findbugs.sourceforge.net - FindBugs

Тази област от проверки на кода се нарича статичен анализ. Това включва както прости проверки, като наличието на serialVersionUID в Serializable клас, така и по-сложни, като незатворени входно/изходни I/O потоци. Отново, тези помощни програми могат да намерят грешки в кода, който изглежда преминава 100% от тестовете и има 100% покритие. Просто тези помощни програми ще намерят потенциални грешки и несъответствия на програмата със стандартния стил на програмиране.Използване на FindBugs в Eclipse

Документация

Четливост на кода

Разбира се, досега дори Microsoft Word (OpenOffice Writer) не може да различи добро есе от лошо. Максимумът е да се коригират граматически и стилистични грешки. Но все пак поне нещо.

Следователно е трудно да се формализира понятието „четимост“ за кода, но има някои характеристики, които отбелязватчетим код от нечетлив:

размерът на един ред е не повече от 120 знака, за да се побере на екрана
размерът на метода е не повече от един екран, така че читателят да може да обхване целия метод с един поглед и да разбере какво прави
размер на класа не повече от 1000 реда - без BLOB антипаттерн
липса на "магически" константи (например 5, 7, 10 ... читателят трябва лесно да разбере какви са тези числа и откъде идват)

Повечето от тези проверки са свързани със стила на кода и се проверяват от вече споменатите помощни програми.

Обобщаване на "резултатите"

Пристигайки сутринта, програмистът трябва да получи от сървъра на задачите списък със задачи за деня, а от сървъра за интеграция текущото състояние на нещата с кода.

Hardcore conf в C++. Каним само професионалисти.