Od samego początku zakładano, że kod przed refaktoryzacją ma niższą jakość niż kod po refaktoryzacji. Tak w rzeczywistości powinno być, ale nawet rezultaty otrzymane z doświadczenia opisanego w rozdziale 5 pokazały, że nie zawsze jest to zgodne z prawdą.
Dlatego, po niezadowalających wynikach przy pierwszych próbach uczenia modelu postanowiono sprawdzić, czy zbudowana sieć neuronowa w ogóle jest w stanie przyjąć jakąkolwiek wiedzę z tak zaprojektowanego wejścia.
Podjęto trzy próby stworzenia coraz bardzie skomplikowanej, ale jednoznacznej metryki jakości kodu źródłowego i sprawdzono rezultat uczenia na tak przygotowa-nych daprzygotowa-nych. Do analizy były wykorzystywane te same metody, które były wybrane w poprzedniej części, ale ich klasyfikacja była przeprowadzona według zaproponowa-nych metryk, z porzuceniem zasady „kod przed refaktoryzacją jest niższej jakości niż kod po refaktoryzacji”. Oczekiwano, że zaprojektowana sieć neuronowa będzie w sta-nie odkryć zaprojektowane metryki i poprawsta-nie klasyfikować kod. To potwierdzi po-prawność zaimplementowanego modelu i pozwoli skupić się na dobrze odpowiednich parametrów lub lepszym przygotowaniu danych wejściowych.
W testowych próbach modelu ograniczono się do metod o maksymalnej długości 100 tokenów i modelu bezwzględnego aSCQM. Zgodnie z tabelą 4.3, na wejściu modelu bezwzględnego uzyskano 40452 metody1.
D.1. Negatywne traktowanie wyrażenia warunkowego
Pierwszą – trywialną – metryką klasyfikującą zebrane metody było negatywne traktowanie wyrażenia warunkowego.
Jeśli rozbiór syntaktyczny zawiera węzeł IfStmt lub ConditionalExpr, reprezentujący kolejno wyrażenie warunkowe if oraz warunkowy operator potrójny (z ang. ternary) – traktuj kod jako niskiej jakości. W przeciwnym razie – traktuj kod jako wysokiej jakości.
1podwojona liczba refaktoryzacji, ponieważ w modelu bezwzględnym jedna zmiana tworzy dwie
Iteracja 1000 2000 3000 4000 5000 0 0.2 0.4 0.6 0.8 1
Strata (Loss) Trafno (Accuracy)
Rys. D.1: Rezultat uczenia modelu bezwzględ-nego w uproszczonej metryce jakości kodu trak-tującej negatywnie wyrażenia warunkowe Według powyższej reguły 34526
metod zostało sklasyfikowane jako kod niskiej jakości (85%).
Okazuje się, że dla tak przygo-towanych danych model potrzebuje tylko kilkadziesiąt iteracji uczenia by osiągnąć całkowitą skuteczność w rozpoznawaniu przygotowanej de-finicji kodu niskiej jakości. Wynik ten nie był zaskakujący – dla tak zdefiniowanego pojęcia jakości kodu wystarczy rzucić okiem na imple-mentację by wyznaczyć klasyfikację,
którą powinien zwrócić model. Ten krok potwierdził jednak wstępnie poprawność im-plementacji modelu. Pełny przebieg uczenia zaprezentowano na rysunku D.1.
D.2. Wirtualna metryka bezwzględna
Iteracja 2K 4K 6K 8K 10K 12K 0 0.2 0.4 0.6 0.8 1
Strata (Loss) Trafno (Accuracy)
Rys. D.2: Rezultat uczenia modelu bezwzględ-nego w uproszczonej metryce jakości kodu zli-czającej koszt wybranych konstrukcji języko-wych
Po uzyskaniu pozytywnego re-zultatu przy zastosowaniu trywial-nej metryki, podjęto próbę uczenia modelu klasyfikacją według bardziej złożonej reguły. W tym celu przypi-sano wybranym konstrukcjom języ-kowym stały koszt (rozumiany jako „koszt zrozumienia danej konstruk-cji przez programistę”, idąc za przy-kładem metryki Cognitive Comple-xity [39] wspomnianej w sekcji 2.4). Ustalone koszty poszczególnych kon-strukcji językowych przedstawiono w tabeli D.1. Metryka ta jest
bar-dziej skomplikowana niż wariant pierwszy. Jeśli tak byłaby rozumiana jakość kodu źródłowego, programiście wystarczyłaby krótka analiza implementacji by stwierdzić czy jest ona czytelna. Model nie powinien mieć więc żadnych problemów z rozpozna-niem nałożonych reguł.
Druga metryka testowa jest zdefiniowana następująco.
Jeśli koszt metody liczony według tabeli D.1 przekroczy 7, traktuj kod jako niskiej jakości. W przeciwnym razie – traktuj kod jako wysokiej jakości.
Tabela D.1: Koszt poszczególnych konstrukcji językowych w przyjętej wirtualnej me-tryce kodu źródłowego
Typ węzła AST Koszt
IntegerLiteralExpr 1 StringLiteralExpr 1 ConditionalExpr 2 ForeachStmt 2 IfStmt 2 CastExpr 3 ForStmt 3 WhileStmt 3 SwitchStmt 4
Wartość 7 ustalono tak, aby reguła podzieliła posiadany zbiór danych w stosunku 40%:60%. W efekcie, 17181 metod (42%) zostało sklasyfikowanych jako kod niskiej jakości.
Według tak przygotowanych danych, na zbiorze testowym model wahał się bardziej niż przy pierwszej – trywialnej – metryce, ale i tak po kilkudziesięciu iteracjach był w stanie rozpoznać przygotowaną regułę klasyfikacji kodu i jego trafność nie spadała poniżej 98%. Przebieg uczenia zaprezentowano na rysku D.2.
D.3. Wirtualna metryka zależna od długości metody
Metryka zaproponowana w sekcji D.2 nie traktowała sprawiedliwie dłuższych me-tod. Jeśli – przykładowo – metoda posiada 50 konstrukcji językowych, sprawiedliwa klasyfikacja powinna pozwolić jej na osiągnięcie wyższego koszt niż metodzie, która zawiera ich tylko 20. Dlatego finalną metryką rozstrzygająca o poprawnej implemen-tacji modelu sieci neuronowej było uzależnienie kosztu, przy którym metoda była klasyfikowana jako niskiej jakości od jej długości. Poprawne wytrenowanie modelu
dla takiej metryki przekonało już autora rozprawy, że problemów z osiągnięciem po-żądanej trafności jakościowego modelu należy szukać w innym miejscu.
Ostatnią testową metrykę można zdefiniować w następujący sposób.
Jeśli stosunek kosztu metody liczonego według tabeli D.1 do długości me-tody wyrażonej w liczbie węzłów AST przekroczy 0.15, traktuj kod jako niskiej jakości. W przeciwnym razie – traktuj kod jako wysokiej jakości.
Iteracja 5K 10K 15K 20K 0 0.2 0.4 0.6 0.8 1
Strata (Loss) Trafno (Accuracy)
Rys. D.3: Rezultat uczenia modelu bezwzględ-nego w uproszczonej metryce jakości kodu zli-czającej wybrane konstrukcje językowe i klasy-fikującej kod w zależności od jego długości Analogicznie do poprzedniego
przypadku – wartość 0.15 została ustalona empirycznie tak, by uzy-skać zrównoważony podział danych wejściowych. Przy zastosowaniu tej reguły, 16533 metody (41%) zostało sklasyfikowane jako kod niskiej jako-ści.
Również w tym przypadku model poradził sobie z odpowiednim klasy-fikowaniem zbioru testowego. Prze-bieg uczenia przedstawiono na ry-sunku D.3.
Na tym etapie zakończono
testo-wanie zaimplementowanego modelu i powrócono do prób przekazania wiedzy do mo-delu na podstawie danych sklasyfikowanych według oryginalnych założeń.