v Praze Fakulta elektrotechnická Květen 2015 Vedoucí práce: Ing. Macek Ondřej, Ph.D.

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Analýza kvality zdrojových kódů Voříšek Lukáš Květen 2015 Vedoucí práce: Ing. Macek Ondřej, Ph.D.

2

3 3

4

5 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. V Praze dne i

6

7 Poděkování Děkuji Ing. Ondřeji Mackovi, Ph.D. za vedení mé bakalářské práce a konzultace, bez kterých by tato práce nemohla vzniknout. iii

8

9 Abstrakt Cílem této práce je analyzovat zdrojové kódy v open source projektech a ukázat postup analýzy zdrojového kódu softwarového projektu. Dobře napsaný kód je jednodušší na údržbu a přináší dobrou škálovatelnost projektu, proto by o něj měl vývojář usilovat. Hlavní část této práce je věnována analýze vybraných projektů pomocí automaticky měřitelných metrik kvality zdrojového kódu a jejich vývoji v průběhu času. Pro potřeby analýzy vzniklo měřící prostředí, které se skládá z nástroje procházejícího historii projektu, skriptu vykonávaného pro každý bod historie, nástroje pro automatickou analýzu kódu a webové aplikace, která vizualizuje naměřené hodnoty. Analyzovaná historie projektu napomáhá porozumět vývoji projektu a změnám, které se v něm odehráli. Nežádoucím změnám tak můžeme v budoucnu předcházet. V závěru této práce se tvrdí, že volně dostupné nástroje pro analýzu zdrojových kódů projektů poskytují užitečné metriky, ale k jejich vyhodnocení je potřeba osoba znalá projektu a schopná posoudit výhody a nevýhody použitých vzorů a metod. Klíčová slova: analýza zdrojového kódu, open source, škálovatelnost, údržba, kvalita kódu, historie projektu, softwarové metriky v

10

11 Abstract Main projects goal is to analyse source codes of open-source projects and display process of software project source code analysis. Well written code is easier to maintain and brings scalability. These are reasons why should each and every developer seek code perfection. Largest part of this project is dedicated to analysis of chosen projects using machine-measured metrics for source code quality and their evolution in time. Specialized interface was made for purposes of measurement, that consists of a tool checking history of tested project, a script executed on every single point in known project history, a tool for machine analysis of source code and a web application that visualize all measurement results. Analysed project history helps us understand process of development and alterations made during this process. As an outcome we can avoid undesirable changes in the future. The conclusion is that free tools for source code analysis offer useful metrics, but there is still a person needed with knowledge of specific issue, capable of judging pros and cons of chosen patterns and methods. Keywords: source code analysis, open source, scalability, maintenance, code quality, project history, software metrics vii

12

13 Obsah 1 Úvod 1 2 Analýza zdrojového kódu Analýza datového toku Code style analýza Dead code analýza Měřené metriky projektu Počet řádků kódu Cyklomatická složitost Počet duplicitních řádků Počet funkcí Počet tříd Počet řádků komentářů Veřejné API Nedokumentované veřejné API Složitost třídy Počet řádků na třídu Počet řádků na funkci Dostupné nástroje pro analýzu kódu SonarQube Copy/Paste Detector (CPD) CodeSonar Checkstyle PMD Další nástroje Nástroj vybraný pro analýzu kódu ix

14 4 Testovací prostředí RepoJumper JumpActor Webová aplikace Průběh analýzy Analýza zdrojových kódů Předpoklady Vyhodnocení analýzy zdrojových kódů Twitter4J Commit 9d Změna z na a63df Změna z 1fa56 na b Celkové vyhodnocení kvality projektu RxJava Commit Změna z 833c6 na 3e5d Celkové vyhodnocení kvality projektu Scribe Celkové vyhodnocení kvality projektu Komplikace v průběhu projektu Nedostatek místa pro zálohu Konflikt JRuby s Ruby Změna struktury projektu Závěr 41 x

15 Literatura 42 A Instalace SonarQube CD B Instalace a nastavení SSH CD C Instalace RVM (Ruby version manager) CD D Instalace PostgreSQL CD xi

16

17 Seznam obrázků 1 Průběh analýzy projektu Průběh metriky v čase u všech projektů Průběh metriky v čase u projektu Scribe Porovnání metrik v projektu Scribe Průběh metrik v projektu Twitter4J (1. část) Průběh metrik v projektu Twitter4J (2. část) Duplicitní řádky a funkce v projektu Twitter4J Paprskový graf metrik commitů 1fa56 a b Základní widgety v SonarQube Zobrazení detailu duplicitních řádků Průběh metrik v projektu RxJava (1. část) Průběh metrik v projektu RxJava (2. část) Průběh metrik v projektu Scribe (1. část) Průběh metrik v projektu Scribe (2. část) Přiblížení grafu počtu řádků v projektu Scribe Zobrazení testů v SonarQube Poměry metrik v projektu Scribe xiii

18

19 Seznam tabulek 1 Twitter4J Rozestup analyzovaných commitů v rámci dní 20 2 Hodnoty v metrik commitů 1fa56 a b RxJava Rozestup analyzovaných commitů v rámci dní Scribe Rozestup analyzovaných commitů v rámci dní.. 34 xv

20

21 Seznam výpisů 1 Blok kódu před úpravou stylu Blok kódu po úpravě stylu Ukázka mrtvého kódu Duplicita v souboru RateLimitStatusJSONImpl.java Možné odstranění duplicity v souboru RateLimitStatusJSO- NImpl.java Duplicitní kód ve třídách UpdateStatus a GetAccessToken 25 7 Zobrazení smazaných souborů pomocí GITu Zobrazení části historie souboru Nahrazení jednotlivých importů za hromadný import Využití stavitele v projektu Scribe xvii

22

23 Kapitola 1 Úvod Nástrojů pro analýzu zdrojových kódů je na trhu velké množství. Jedná se jak o komerční, tak open source řešení, které jsou bud to specifické pro konkrétní programovací jazyk, typ projektu a nebo jsou určeny pro více programovacích jazyků. Problémem těchto nástrojů je především to, že jejich uživatel musí vědět jak s daty naložit. Nástroj, provádějící statickou analýzu, uživatele většinou zahltí množstvím metrik, jejichž smysl mu nemusí být vůbec jasný a nedokáže tedy výsledky analýzy správně použít. Navíc uživatel musí data vyhodnocovat v rámci aktuálního projektu, nebo musí mít alespoň znalost z podobných projektů. Dalším problémem je absence podpory vizualizace průběhu projektu. Některé nástroje sice podporují správu verzí naměřených hodnot, ale většinou jen proto, aby uživatele informovali, zda se od poslední verze hodnota změnila (například pomocí červených a zelených šipek) nebo proto, aby si uživatel mohl zobrazit hodnoty v některém z minulých bodů. Díky vizualizaci si uživatel může vytvořit základní přehled o průběhu projektu a velkých změnách, které se v něm odehrály. Například přechod na nové API. Také vidí jakým směrem se projekt ubírá a ví, na jaké jeho části se má zaměřit. Pochopení výsledků analýzy je nezbytné pro úsporu času správce projektu a zlepšení výsledné kvality produktu. Díky pochopení jednotlivých metrik a jejich provázání v konkrétním projektu, může správce rychleji vyhodnocovat špatné směřování projektu a nebo dokonce určit, který uživatel projekt poškozuje. Po osvojení znalosti měřených údajů a jejich vzájemných vztahů rychleji nalezne nepřehledné, špatně dokumentované či jinak zanedbané části kódu. Cílem této práce je přinést uživateli postup, který může použít při vyhodnocování kvality zdrojového kódu a tento postup předvést na několika open source projektech s dlouhou historií. Uživateli se zároveň poskytne nástroj RepoJumper, procházející celý GIT 1 repozitář (nástroj naprogramován v rámci realizace této práce), a jednoduché rozhraní umožňující zobrazení průběhu projektu a konkrétních bodů jeho historie pomocí spojových a paprskových grafů /45

24 Kapitola 2 Analýza zdrojového kódu Analýza zdrojového kódu je součást white-box testování a provádí se v implementační části projektu. Opětovně se pak provádí při hledání zranitelností v rámci bezpečnostní analýzy. Využívá se většinou nástrojů, které upozorní (zvýraznění, výpis) na zranitelnosti či slabiny v kódu a to bez toho aby jej spustili (proto statická). K odhalení těchto zranitelností se používají různé metody jako jsou Taint analýza a analýza datového toku [23]. Některé současné IDE (například IntelliJ IDEA) obsahují prvky statické analýzy a upozorňují na možné problémy již při vývoji. Mezi problémy na které IDE upozorňuje patří dělení nulou či null pointer. V následujících sekcích představím několik metod statické analýzy. 2.1 Analýza datového toku W. Wögerer ve své práci [6] popisuje data flow analýzu jako: Data flow analysis is a process for collecting run-time information about data in programs without actually executing them. Data flow anlaysis however does not make use of semenatics of operators. The semantics of the program language syntax is, however, implicity captured in the rules of the algorithms. Tato analýza spočívá v sestavování množin dat v jednotlivých částech programu před jeho spuštěním. Může nás informovat například, že datový tok nikdy nenavštíví určitou funkci. Tento mechanizmus také využívá kompilátor pro optimalizační úkony. 2.2 Code style analýza Jedná se opět o statickou analýzu, která na rozdíl od předchozích nekontroluje stav ani chování proměnných. Jejím účelem je kontrola kódu oproti nějakému definovanému předpisu, který udává jakým způsobem mají být psány komentáře, funkce, proměnné či třídy. Ověřuje se například počet mezer před závorkami v definici funkce, odřádkování před otevírací závorkou třídy či funkce. Přítomnost nebo naopak nepřítomnost podtržítek v názvech privátních proměnných [2]. Analýza může být prováděna automaticky nebo programátorem. Dodržování code style zvyšuje přehlednost projektu a usnadňuje tak jeho úpravy a hledání chyb. 2/45

25 2.3 DEAD CODE ANALÝZA Výpis 1: Blok kódu před úpravou stylu class Dog { public S t r i n g name ; s t a t i c public f i n a l i n t e r j e c t i o n = Haf! ; } public Dog( S t r i n g name ) { this. name = name ; } public c a l l a n s w e r ( ) { i f ( name == Alik ) { return i n t e r j e c t i o n ; } return name + : + i n t e r j e c t i o n ; } Uvedený úsek kódu by podle zvyklostí Google [21] měl vypadat následovně: Výpis 2: Blok kódu po úpravě stylu class Dog { public s t a t i c f i n a l INTERJECTION = Haf! ; public S t r i n g name ; } public Dog( S t r i n g name ) { this. name = name ; } public callanswer ( ) { i f ( name == Alik ) { return INTERJECTION; } return name + : + INTERJECTION ; } Součástí stylu obvykle bývá pojmenování, odsazení, pořadí modifikátorů; není výjimkou, že součástí doporučení je i kódování souboru. V komunitních projektech je dodržování stylu většinou vyžadováno správcem projektu. 2.3 Dead code analýza Analýza mrtvého kódu je analýza, která se snaží zachytit nepoužívané funkce či bloky kódu a na ty upozornit. Analyzátor prochází celý projekt a prochází jednotlivé bloky kódu, například uvnitř podmínky. Také si zaznamenává názvy metod a jejich volání z živých bloků kódu [22]. Typicky se jako mrtvý kód nepočítá obsah veřejných metod, jelikož mohou být volány mimo správu autora. Výpis 3: Ukázka mrtvého kódu 3/45

26 2.4 MĚŘENÉ METRIKY PROJEKTU int f ( int x, int y ) { return x+y ; int z=x y ; } Funkce f obsahuje mrtvý kód int z=x*y. Tento kód se nikdy nevykoná, funkce je vždy ukončena na předchozím řádku příkazem return. 2.4 Měřené metriky projektu Nástroje pro analýzu nám poskytují široké spektrum dostupných metrik, které jsou vhodné pro porovnání projektů. V této kapitole uvedu několik základních a odvozených metrik spolu s jejich definicemi. Definice uvedená u metrik je používaná nástrojem SonarQube, který je představen v kapitole 3.1 na straně 9 a používán v tomto projektu Počet řádků kódu (Lines of code) SonarQube definice lines Počet fyzických řádků (zakončeno cr, crlf nebo lf) obsahujících alespoň jeden znak, který není mezerou, tabulátorem nebo součástí komentáře. Počet řádků kódu je nejdůležitější a zároveň nejběžnější metrikou softwarových projektů. Poskytuje nám základní pohled na velikost a složitost projektu a přibližnou dobu jeho trvání. Tato metrika může být definována různě, bud jako počet fyzických řádků, nebo jako počet logických řádků (například v Jave je za logický řádek považováno i zakončení pomocí středníku). Do počtu řádků kódu běžně nebývají započítány řádky komentářů, prázdné řádky nebo řádky obsahující jen speciální znaky. Nikdy bychom se neměli spoléhat pouze na tuto metriku. Jak uvádí web c2.com ve svém článku [12]: Jedná se o úžasnou metriku. Je lehké ji změřit, ale téměř nemožné správně interpretovat. Tato metrika se často používá i pro odhady ceny projektu či potřebné pracovní síly. Mezi nejznámější metody odhadu ceny projektu, využívající počet řádků kódu patří COCOMO [10] a jeho mladší varianta COCOMO II. Jejich fungování vysvětluje článek [9] na webu CodeProject. 4/45

27 2.4 MĚŘENÉ METRIKY PROJEKTU Cyklomatická složitost (Complexity) SonarQube definice complexity Cyklomatická složitost je také známá jako McCabeova metrika. Kdykoli se dělí datový tok, složitost se zvyšuje o jedničku. Minimální složitost každé funkce je jedna. Klíčová slova zvyšující složitost v Jave jsou následující: if, for, while, case, catch, throw, return, &&,,? Měření strukturální složitosti kódu. Strukturální složitost je vypočtena jako počet možných cest toku programu. Program, který má vysokou složitost vyžaduje větší množství testů a hůře se spravuje [11]. Pokud je tato metrika příliš vysoká vzhledem k počtu funkcí může se jednat o projekt, který obsahuje mnoho zanořených podmínek. Tato metrika také vypovídá o výpočetní složitosti projektu Počet duplicitních řádků (Duplicated lines) SonarQube definice duplicited lines Počet řádků účastnících se duplicity. Velmi jednoduchá avšak užitečná metrika. Hodí se zejména pokud máme znalost počtu tříd či funkcí. Balíčky či třídy s vysokou mírou duplicity je vhodné prověřit při kontrole kódu a zjistit, zda se některé bloky kódu nedají přesunout do samostatných metod. V některých případech můžeme duplicity odstranit i zavedením některého z návrhových vzorů nebo dědičností. Častým řešením je začlenění abstraktní třídy do hierarchie, využití kompozice, knihovní třídy, služebníka, šablonové metody... I z tohoto omezeného výčtu je vidět, že metod, které nám umožní snížit duplicity v kódu, je značné množství. O zmíněných návrhových vzorech se můžete v češtině dočíst například v knize pana Pecinovského [8] nebo na stránkách VŠE [13]. Tato metrika má své úskalí. Pokud přesuneme dva řádky opakující se v deseti třídách do jedné funkce, duplicita nám klesne z dvaceti na deset (volání vytvořené funkce), ale více ji již nesnížíme. Dalším takovým případem jsou rozhraní a závorky. Pokud se v rozhraní vyskytuje signatura pěti metod, musí obsahovat tyto signatury i každá třída implementující toto rozhraní. Pokud máme deset tříd implementujících rozhraní získáme padesát duplicitních řádků. Řídíme-li se navíc umíst ováním otevíracích a uzavíracích závorek na samostatné řádky, získáme dvě duplicity za definici každé třídy a interface. Dalších sto duplicit získáme na definicích funkcí. Pouhou implementací rozhraní tak získáme sto dvacet dva duplicit. 5/45

28 2.4 MĚŘENÉ METRIKY PROJEKTU Tato úskalí některé analyzační nástroje (včetně SonarQube) řeší tím, že některé z vyjmenovaných duplicit do výsledného součtu nezahrnují Počet funkcí (Functions) SonarQube definice functions Počet funkcí, kdy za funkci je považována jak funkce tak metoda. Významná metrika hlavně ve spojitosti s počtem tříd, řádků kódu nebo duplicit. Pokud budeme mít projekt obsahující jednu třídu a tři sta funkcí je velmi pravděpodobné, že došlo k porušení principů objektového programování. Také můžeme sledovat závislost duplicit na počtu funkcí, kdy očekáváme, že se počet duplicit sníží zároveň s nárůstem počtu funkcí při snížení počtu řádků kódu Počet tříd (Classes) SonarQube definice classes Počet tříd zahrnující zanořené třídy, rozhraní, výčtové typy (enums) a anotace. Tato metrika je pro nás důležitá zejména proto, že nám dává určitý přehled o funkčních celcích (úzká zodpovědnost třídy). Dále se často používá v kombinaci s jinými metrikami, jako je počet řádků kódu nebo počet funkcí, za účelem odhalení nevyužitých návrhových vzorů. Jedním z odhalených problémů může být nízká soudržnost (cohesion) [14]. Třída je zodpovědná za vykonávání více věcí. Její údržba se tak komplikuje a počet řádků ve třídě narůstá do neúnosných rozměrů. V některých případech se dostáváme i do bodu, kdy je celý zbytek projektu závislý na této supertřídě Počet řádků komentářů (Comment lines) SonarQube definice comment lines Počet řádků obsahujících komentář nebo zakomentovaný kód. Prázdné komentáře nebo obsahující jen speciální znaky nejsou započítány. Nepříliš důležitá metrika plnící převážně informační funkci. Obsahuje-li projekt příliš mnoho komentářů, je nejspíše příliš složitý a musí být vysvětlen. Na druhou stranu 6/45

29 2.4 MĚŘENÉ METRIKY PROJEKTU obsahuje-li příliš málo komentářů je možné, že autoři se nezabývají vysvětlováním kódu a jeho funkcionality. Zajímavější jsou odvozené metriky. Například pokrytí API (veřejné metody, třídy, proměnné) dokumentačními komentáři, které popisují jejich užití Veřejné API (Public API) SonarQube definice public api Počet veřejných tříd, funkcí/metod a proměnných (třídy, instance). Počet veřejně přístupných částí programu nás informuje o tom, jak velká část je zveřejněná. Tedy s kolika částmi programu může manipulovat uživatel. Takový údaj pro nás může být důležitý, zejména pokud máme podezření, že kód nedosahuje dostatečného zapouzdření. Zapouzdření zajišt uje snadnou správu kódu, kdy uživateli je známo o implementaci co nejméně, ideálně zná jen rozhraní. To nám umožňuje vyměnit některé části kódu za jiné bez toho, aby to uživatel postřehl. Pokud například zveřejníme v naší třídě proměnou typu ArrayList, musíme ji udržovat i v dalších verzích (kvůli kompatibilitě). Jelikož je proměnná veřejná, může ji uživatel používat ve svém projektu, nebo dokonce obejít/porušit její vlastnost. Právě tento problém řeší zapouzdření, které, není-li to třeba, takovouto proměnou nezveřejní, nebo ji zveřejní pomocí funkce. Pravděpodobně by návratovým typem takové funkce nebyl ArrayList, ale pouze rozhraní List Nedokumentované veřejné API (Public undocumented API) SonarQube definice public undocumented api Veřejné API bez dokumentačního komentáře. Veřejné API, které nenese dokumentační komentář, může tvořit pro uživatele bariéru, která mu brání používat analyzovaný projekt. Příkladem může být užití třídy, která bude obsahovat funkci setonresponse(handler param1). Naše očekávání je takové, že funkce se provede v případě vrácení odpovědi. Během jejího užívání ovšem zjistíme, že je volána i v případě chyby. Kdy informace o chybě je v lepším případě uchovávána v objektu, či zprávě, která je předána handleru. 7/45

30 2.4 MĚŘENÉ METRIKY PROJEKTU Složitost třídy (Class complexity) SonarQube definice class complexity Průměrná složitost třídy (cyklomatická složitost / počet tříd). Jedná se o odvozenou metriku. Její přínos je obdobný jako u jejího základu (2.4.2) Počet řádků na třídu I zde se se jedná o odvozenou metriku, která není součástí standardních metrik SonarQube. Je spočtena jako: loc per class = loc classes Existují různá doporučení pro hodnotu této metriky. My budeme považovat za maximální přípustné číslo 200 (vycházím z doporučení NetBeans v kombinaci s diskuzemi [25, 26, 27] na StackOverflow) Počet řádků na funkci Odvozená metrika, která není součástí standardních metrik SonarQube. Je spočtena jako: loc loc per func = functions I zde existují různá doporučení. My budeme považovat za maximální přípustné číslo 30 (vycházím z doporučení NetBeans v kombinaci s diskuzemi [25, 26, 27] na StackOverflow). 8/45

31 Kapitola 3 Dostupné nástroje pro analýzu kódu V mém průzkumu se nepodařilo najít nástroj, který by přinášel komplexní funkcionalitu zmiňovanou v úvodní kapitole (analýza kódu, vizualizace průběhu, manuál jak nakládat s naměřenými metrikami). Nástroje, které jsou běžně k dispozici však poskytují solidní základnu pro jejich rozšíření tímto směrem. Většina těchto nástrojů totiž obsahuje API nebo textový výstup. Analýza se pak často dá spouštět pomocí parametrizovaných příkazů a naměřená data, získaná z API či textového výstupu, dále zpracovávat. Kompletní seznam nástrojů, určených k analýze zdrojových kódů, by byl velmi obsáhlý, proto jsem při výběru vhodného nástroje vycházel ze stránky na anglické Wikipedii [1] a z doporučení uživatelů na webových stránkách Stack Overflow. Počet použitelných nástrojů pro tento projekt se snížil také tím, že jsme je omezili pouze na nástroje podporující více jazyků, přinejmenším pak jazyky C++ a Java. Hledaný nástroj musel obsahovat podporu pro více jazyků; API, které by umožnilo získávat z něj analyzovaná data pro následné zpracování; možnost spuštění skriptem nebo jiným programem; aktivní komunitu, která poskytne pomoc při případných problémech. 3.1 SonarQube SonarQube, dříve Sonar, je jedním z nejčastěji doporučovaných multiplatformních open source nástrojů pro analýzu zdrojových kódů programovacího jazyka Java. Tento nástroj navíc podporuje i jiné programovací jazyky jako C++, C#, PHP, JavaScript. Některé z těchto jazyků jsou součástí standardní verze, jiné jsou obsaženy v pluginech. Celkově je podporováno přes dvacet jazyků [3]. Toto číslo zkreslené tím, že se započítávají i značkovací jazyky a některé neuvedené jsou dostupné pomocí pluginů třetích stran. Jednou z nesporných výhod SonarQube je právě jeho rozšířenost a velikost komunity, díky které je k dispozici řada pluginů a nástrojů. Pomocí pluginů lze obohatit i serverovou stranu o nové metriky či widgety. Pomocí nástrojů je snadné analýzu začlenit do projektu, at již pomocí pluginu pro nějaký rozšířený build nástroj nebo pomocí pluginu pro continuous integration server jako je Jenkins 2. Použití SonarQube vyžaduje dvě samostatné části analyzátor a server přičemž funkci analyzátoru může plnit i jiný nástroj než výchozí (dostupné jsou pluginy pro 2 9/45

32 3.4 CHECKSTYLE Maven 3, Jenkins, Gradle 4,... ). SonarQube Runner je výchozí analyzátor, který se spouští z příkazové řádky. Jeho nastavení uchovává soubor sonar-project.properties umístěný v root složce projektu. Všechny potřebné hodnoty mohou být však předány jako argumenty. SonarQube je pak označení pro samotný server, který je napsaný v Javě a Ruby. Server udržuje záznamy o projektech a naměřených metrikách pomocí databázového serveru, s využitím JDBC, což nám umožňuje provozovat jej na jakékoli relační databázi (stačí získat nebo napsat JDBC driver) [4]. Také nám poskytuje API založené na HTTP protokolu, které je nezbytné pro časovou analýzu dat. 3.2 Copy/Paste Detector (CPD) Jako v předchozím případě se jedná o nástroj určený k analýze zdrojových kódů více jazyků. Zde se jedná o statickou analýzu jediné metriky. Tento nástroj se zaměřuje na analýzu duplicit v kódu [5]. Protože nástroj analyzuje pouze jedinou metriku, není pro nás vhodný. Museli bychom mít velké množství specializovaných nástrojů a jejich výsledky ukládat do databáze pro pozdější využití. 3.3 CodeSonar Je nástroj statické analýzy k rozpoznávání potencionálně nebezpečných částí programu, který má za účel zabránit pádům aplikace, memory leakům a bezpečnostním zranitelnostem. Základem tohoto systému je vyhledávání možných null pointerů, dělení nulou, špatný přístup k bufferu (přetečení) a podobně. Více se můžete dozvědět na stránkách produktu Checkstyle Checkstyle 6 je projekt zaměřený na kontrolu stylu kódu. Tento nástroj tedy neanalyzuje další vyžadované metriky jako je počet funkcí, řádků kódu nebo tříd. Navíc je tento nástroj určen převážně pro programovací jazyk Java /45

33 3.7 NÁSTROJ VYBRANÝ PRO ANALÝZU KÓDU 3.5 PMD PMD 7 je nástroj určený pro více programovacích jazyků. Obsahuje i moduly pro Maven, Eclipse, InteliJ IDEA, Netbeans a další. Výstupem tohoto analyzačního nástroje je XML soubor, který lze používat pro dodatečné zpracování dat. Na stránkách projektu je sice vypsán seznam pluginů, ale pouze pro použití tohoto nástroje, nikoli pro rozšíření jeho funkcionality. 3.6 Další nástroje Navštívil jsem i stránky dalších nástrojů, uvedených v seznamu [1], ale jejich zaměření, licence a nebo podporované programovací jazyky nesplňovali požadavky, které jsem na nástroje kladl. 3.7 Nástroj vybraný pro analýzu kódu Nástroje SonarQube a PMD splnili veškeré požadavky. Oba tyto nástroje mají výstup, který se dá dále zpracovávat, jsou spustitelné pomocí skriptu a analyzují více programovacích jazyků. Z těchto dvou nástrojů byl vybrán SonarQube, zejména pro možnost rozšíření sledovaných metrik pomocí pluginů a doporučení [28, 29] uživatelů na fóru StackOverflow /45

34 Kapitola 4 Testovací prostředí Za normálních okolností stačí správci projektu analyzovat nově vznikající kód. Analýzu může provádět ručně a nebo s pomocí automatizačních nástrojů. Velmi mu tuto práci ulehčují continuous integration servery. Takový postup jsme ovšem nemohli zvolit u tohoto projektu. Počet analyzovaných commitů by byl příliš nízký a nebyl by dostatečně názorný. Z toho důvodu jsme museli postup upravit tak, aby analyzoval body v historii. Z toho důvodu jsem napsal RepoJumper, který prochází historii projektů a pro každý bod historie spouští JumpActora. K analýze projektů jsem si musel vytvořit postup, jenž jsem dodržoval při analýze každého projektu. 4.1 RepoJumper Jedná se o jednoduchý nástroj napsaný v Ruby, který se spouští z příkazové řádky a přijímá tři parametry. Prvním z těchto parametrů je skript, který má být proveden pro každý bod historie. Druhým parametrem je adresa GIT repositáře v rámci filesystému a třetím je název větve, tagu nebo hash commitu první analyzovaný bod. Analýza probíhá zpětně, konkrétně tak, že pro každý analyzovaný uzel se získají jeho předci, a na ty se rekurzivně spustí RepoJumper. RepoJumper opětovně neprochází již navštívené uzly. K tomuto chování využívá index storage, které uchovává seznam již navštívených commitů (jejich hashe). Index storage může být uchováváno různými způsoby. Výchozím způsobem je záznam pomocí SQLite 8. Po každém skoku, který RepoJumper provede se zjistí, zda commit již navštívil (ověří se hash) a pokud tomu tak není provede se checkout projektu následovaný spuštěním skriptu. Jelikož GIT checkoutu vadí změněné soubory a neprovede se, je RepoJumper checkout implementován jako GIT příkaz reset --hard. 4.2 JumpActor SonarQube Runner vyžaduje poměrně velké množství argumentů. Mezi tyto argumenty patří informace o připojení k databázi (uživatel, heslo, adresa a port), název projektu, id projektu, datum analýzy projektu, adresář obsahující zdrojové kódy a podobné. Aby nemusel RepoJumper uchovávat tyto parametry, spouští JumpActor. JumpActor je Bash skript s připravenou posloupností akcí /45

35 4.3 WEBOVÁ APLIKACE JumpActor se provede pro každý skok RepoJumperu, který mu předá pár informací o commitu (hash, autor, datum). Skript poté provede build pomocí Mavenu nebo Gradle a spustí SonarQube Runner s náležitými parametry, které mohou být pro každý projekt specifické. K tomuto účelu by za normálních okolností sloužil soubor sonar-project.properties, ale ten by musel být generován po každém skoku RepoJumperu. 4.3 Webová aplikace Webová aplikace, napsaná s využitím Ruby on Rails, slouží k získávání dat ze serveru SonarQube. Tyto data organizuje do skupin tak, že je slučuje pod jeden projekt (například Twitter4J), případně s nimi provádí další manipulaci (průměr, hledání maxima a minima). Takto zpracovaná data jsou následně vykreslována, pomocí JavaScriptové knihovny Highcharts 9, do spojnicových a paprskových grafů. Funkce aplikace jsou: zobrazování průběhu metrik v čase, zobrazování a skrývání projektů, přiblížení úseku grafu s metrikami, vykreslení paprskového grafu metrik pro konkrétní bod (commit), vykreslení více bodů do stejného paprskového grafu, minimální a maximální rozestup commitů v rámci dní, zobrazení data commitu, získání dat ze serveru SonarQube. Dodatečnou funkcionalitu pak tvoří: cache dat zajišt ující odstínění serveru od provádění náročných operací (databázové dotazy, datový přenos, tvorba objektů) /45

36 4.4 PRŮBĚH ANALÝZY 4.4 Průběh analýzy Postup analýzy projektu, znázorněný na obrázku 1, se skládá z pěti hlavních částí. Uživatele, který analýzu provádí, RepoJumperu, JumpActora, SonarQube analyzátoru, webové aplikace. Uživatel vybere projekt který chce analyzovat a vytvoří lokální kopii repozitáře projektu, JumpActora (4.2) a spustí RepoJumper (4.1). Po dokončení analýzy pomocí RepoJumperu a SonarQube si uživatel zobrazí data prostřednictvím webové aplikace (4.3) a provede analýzu naměřených hodnot (podle grafů, extrémů, rozestupu commitů, hodnot měřených metrik atd.). Obrázek 1: Průběh analýzy projektu 14/45

37 Kapitola 5 Analýza zdrojových kódů Pro analýzu zdrojových kódů (dále jen analýza) byly vybrány projekty, které jsou navrženy pro sestavení build nástrojem, konkrétně pak projekty pro Maven a Gradle. Zdrojové kódy těchto projektů byly také umístěny na serveru GitHub 10 s využitím GITu 11. Vybranými projekty pak jsou: Twitter4J ( RxJava ( Scribe ( 5.1 Předpoklady Před samotným provedením analýzy projektů si stanovíme jedenáct předpokladů. 1. Metoda by neměla přesáhnout 30 řádků kódu. 2. Třída by neměla přesáhnout 200 řádků kódu. 3. Při rostoucím počtu funkcí a zachování či snížení počtu řádků se sníží množství duplicitních řádků kódu. 4. Významné změny se projeví ve všech měřených metrikách. 5. Zdrojové kódy v rámci projektu budou mít jednotný styl. 6. Pořadí modifikátorů se bude řídit doporučením Javy [21]. (public, protected, private, abstract, static, final, transient, volatile, synchronized native strictfp). 7. Projekt bude využívat návrhové vzory. 8. Konstanty budou umístěny na prvních řádcích třídy. 9. Počet duplicit nebude rostoucí. 10. Množství funkcí výrazně roste a klesá ve stejném okamžiku jako množství tříd. 11. Množství duplicitních řádků by nemělo přesáhnout 10 % /45

38 Kapitola 6 Vyhodnocení analýzy zdrojových kódů Vyhodnocení analyzovaných dat probíhalo v několika krocích, kdy jsem se zaměřoval na stále specifičtější části kódu. Prvním krokem bylo nahlédnutí do grafů zobrazujících průběh metrik v čase (Obrázek 2). Jak se měnily metriky v rámci commitů. V grafu jsem si všímal především skokových změn metrik nebo změny pouze jedné metriky (bez ovlivnění ostatních). Obrázek 2: Průběh metriky v čase u všech projektů Po skrytí ostatních projektů v grafu, je průběh metriky mnohem více patrný (Obrázek 3). Obrázek 3: Průběh metriky v čase u projektu Scribe V grafu si můžeme všimnout různých skokových změn, které nás budou zajímat především. Commity před touto a po této změně budou nejspíše zachycovat nějakou významnou změnu v projektu. Například odstranění duplicit nebo jejich zanesení do projektu. 16/45

39 6.1 TWITTER4J V druhém kroku použijeme námi vytipované commity z předchozího kroku k zobrazení poměrů mezi metrikami. K tomuto účelu mi sloužil paprskový graf (Obrázek 4). Při vyhodnocování tohoto grafu je nezbytné mít již přehled o předpokládaném rozložení jednotlivých paprsků (nejlépe z podobných projektů). Obrázek 4: Porovnání metrik v projektu Scribe Pokud nám podle výsledků předchozích dvou kroků přijde nějaká metrika podezřele vysoká či nízká ověříme ji nahlédnutím do zdrojových kódů. Dobré je také ověřit metriky, jejichž změnu jsme nepředpokládali nebo byla příliš rychlá. Ve zdrojových kódech budeme hledat příčinu této změny a možné způsoby jejího odstranění, pokud je nežádoucí, nebo možnosti její replikace, pokud je žádoucí. Třetím krokem je tedy využití rozhraní SonarQube serveru k nalezení podezřelých míst, například balíčků s vysokým počtem duplicit, a naše posouzení příčiny duplicit. 6.1 Twitter4J Twitter4J je open source knihovna pro programovací jazyk Java, pracující s Twitter API. Je šířena pod licencí Apache 2.0. V současné době tento projekt na GitHubu obsahuje 1997 commiů z nichž je v této práci analyzováno 494 (25 %). Projekt má 95 přispěvatelů, ale téměř celý je prací jedné osoby (yusuke), která projekt vede. Většina přispívajících se projektu neúčastnila ani celý měsíc a množství změněných řádků je zanedbatelné. Na obrázku 5 a 6 je zobrazen průběh všech porovnávaných metrik s vyznačením významných skoků. Z obrázku je patrné, že výrazné skokové změny se promítají do všech metrik. 17/45

40 6.1 TWITTER4J 18/45 Obrázek 5: Průběh metrik v projektu Twitter4J (1. část)

41 6.1 TWITTER4J Obrázek 6: Průběh metrik v projektu Twitter4J (2. část) 19/45

42 6.1 TWITTER4J Minimální rozestup commitů 1 Maximální rozestup commitů 136 Tabulka 1: Twitter4J Rozestup analyzovaných commitů v rámci dní V průběhu projektu si můžeme všimnout i toho, že počet duplicitních řádků kódu narůstá i klesá stejně jako počet funkcí, což je proti našemu očekávání. Při bližším pohledu zjišt ujeme, že skoky, kdy obě metriky rostou, doprovází i významné navýšení počtu řádků kódu. Na obrázku 7 jsou zobrazeny obě metriky a do jejich grafu je červenou barvou vepsán průběh změny počtu řádků. Obrázek 7: Duplicitní řádky a funkce v projektu Twitter4J Zajímavé je i zjištění, že se mezi daty a výrazně změnil počet funkcí a to napřed odebráním 138 funkcí a poté přidáním 91 funkcí, kdy se opakovaně v obou případech snížila duplicita řádků a ubyl celkový počet tříd. Abychom si lépe utvořili představu o změně jenž se odehrála, vykreslíme si stav před změnou a po změně do paprskového grafu (Obrázek 8). Z grafu a tabulky 2 vidíme, že došlo k zeštíhlení projektu, kdy jsou všechny zobrazené metriky novějšího commitu (b5312), s výjimkou složitosti třídy, která si zachovala svou hodnotu, menší. Projekt v celém svém průběhu splňuje náš požadavek maximálního počtu funkcí na třídu i na funkci (v průměru). Kdy maximální průměrný počet funkcí na třídu byl 141 a na funkci 17. Celkové směřování projektu se zdá být dobré. Autoři se snaží odstraňovat duplicity, přidávat funkcionalitu a zároveň nenavyšovat složitost projektu. Z grafu je také patrné, že metody se stávají konkrétnější. Autoři jich vytvářejí více s menšími částmi kódu. 20/45

43 6.1 TWITTER4J Obrázek 8: Paprskový graf metrik commitů 1fa56 a b5312 Metrika 1fa56 b5312 lines complexity duplicated lines functions classes comment lines public api public undocumented api class complexity Tabulka 2: Hodnoty v metrik commitů 1fa56 a b5312 Problematickou částí projektu však může být nedostatečně dokumentované veřejné API. I tato metrika se sice časem zlepšuje, většinou v jednorázových skocích, ale stále projekt obsahuje přes tisíc veřejně přístupných metod či proměnných, které nejsou zdokumentovány. Na základě průběhu metrik jsem se rozhodl dále porovnávat následující commity: 9d706 ze dne (jeden z prvních analyzovaných), ze dne , 21/45

44 6.1 TWITTER4J a63df ze dne , 1fa56 ze dne , b5312 ze dne , c809b ze dne (jeden z posledních analyzovaných) Commit 9d706 Jeden z prvních analyzovaných commitů (9d706) si zobrazím v rozhraní SonarQube, které zobrazuje různé widgety podle nastavení a nainstalovaných pluginů. Já mám aktivovány pouze základní widgety. První z nich (Obrázek 9a) zobrazuje základní informace jako je počet řádků kódu, počet tříd nebo počet souborů. Druhé dva widgety (Obrázek 9b) zobrazují pak informace o duplicitách a složitosti. (a) Widget zobrazující počet řádků, tříd, souborů,... (b) Widgety zobrazující informace o složitosti a duplicitách Obrázek 9: Základní widgety v SonarQube Tento commit obsahuje 1911 duplicitních řádků na řádků kódu. Duplicitní řádky tvoří 3, 1% kódu. Ač se absolutní množství duplicit zdá vysoké, je v rámci projektu relativně malé. Přejdeme k ověření některých duplicit. Při zobrazení detailu duplicitních řádků v SonarQube uvidíme přehled balíčků a souborů, vedle kterých je zobrazen počet duplicitních řádků (Obrázek 10). 22/45

45 6.1 TWITTER4J Obrázek 10: Zobrazení detailu duplicitních řádků Vybereme si nějaký soubor ke kontrole. Já jsem zvolil soubor s největším výskytem duplicit, který se netýkal testování nebo logování. SonarQube nám zobrazí obsah souboru a vyznačí duplicitní části. V mnou vybraném souboru se vyskytuje 58 duplicitních řádků. Tato duplicita je způsobena přílišnou podobností dvou funkcí. Výpis 4: Duplicita v souboru RateLimitStatusJSONImpl.java s t a t i c RateLimitStatus createfromresponseheader ( HttpResponse r e s ) { i f ( null == r e s ) { return null ; } int r e m a i n i n g H i t s ; // X RateLimit Remaining int hourlylimit ; // X RateLimit Limit int resettimeinseconds ; // not i n c l u d e d in t h e response header. Need to be c a l c u l a t e d. Date resettime ; //new Date ( X RateLimit Reset ) } S t r i n g l i m i t = r e s. getresponseheader ( X RateLimit Limit ) ; i f ( l i m i t!= null ) { hourlylimit = I n t e g e r. p a r s e I n t ( l i m i t ) ; } else { return null ; } S t r i n g remaining = r e s. getresponseheader ( X RateLimit Remaining ) ; i f ( remaining!= null ) { r e m a i n i n g H i t s = I n t e g e r. p a r s e I n t ( remaining ) ; } else { return null ; } S t r i n g r e s e t = r e s. getresponseheader ( X RateLimit Reset ) ; i f ( r e s e t!= null ) { long longreset = Long. parselong ( r e s e t ) ; resettimeinseconds = ( int ) ( longreset / 1000) ; resettime = new Date ( longreset 1000) ; } else { return null ; } return new RateLimitStatusJSONImpl ( hourlylimit, remaininghits, resettimeinseconds, resettime ) ; s t a t i c RateLimitStatus createfeaturespecificratelimitstatusfromresponseheader ( HttpResponse r e s ) { i f ( null == r e s ) { return null ; } int r e m a i n i n g H i t s ; // X FeatureRateLimit Remaining int hourlylimit ; // X FeatureRateLimit Limit int resettimeinseconds ; // not i n c l u d e d in t h e response header. Need to be c a l c u l a t e d. Date resettime ; //new Date ( X FeatureRateLimit Reset ) 23/45

46 6.1 TWITTER4J } S t r i n g l i m i t = r e s. getresponseheader ( X FeatureRateLimit Limit ) ; i f ( l i m i t!= null ) { hourlylimit = I n t e g e r. p a r s e I n t ( l i m i t ) ; } else { return null ; } S t r i n g remaining = r e s. getresponseheader ( X FeatureRateLimit Remaining ) ; i f ( remaining!= null ) { r e m a i n i n g H i t s = I n t e g e r. p a r s e I n t ( remaining ) ; } else { return null ; } S t r i n g r e s e t = r e s. getresponseheader ( X FeatureRateLimit Reset ) ; i f ( r e s e t!= null ) { long longreset = Long. parselong ( r e s e t ) ; resettimeinseconds = ( int ) ( longreset / 1000) ; resettime = new Date ( longreset 1000) ; } else { return null ; } return new RateLimitStatusJSONImpl ( hourlylimit, remaininghits, resettimeinseconds, resettime ) ; Metody se od sebe liší jen obsahem textových řetězců. V metodě createfeaturespecificratelimitstatusfromresponseheader obsahují řetězce, získávající obsah hlavičky, navíc Feature. Tato duplicita je snadno řešitelná pomocí funkce s parametrem, který rozhoduje o užití slova Feature. Funkce by po změně mohli vypadat takto: Výpis 5: Možné odstranění duplicity v souboru RateLimitStatusJSONImpl.java private s t a t i c f i n a l S t r i n g FEATURE PREFIX = Feature ; s t a t i c RateLimitStatus createfromresponseheader ( HttpResponse r e s ) { return createratelimitstatusfromresponseheaderwithprefix ( r e s ) ; } s t a t i c RateLimitStatus createfeaturespecificratelimitstatusfromresponseheader ( HttpResponse r e s ) { return createratelimitstatusfromresponseheaderwithprefix ( res, FEATURE PREFIX) ; } r e s Processed HTTP p r e f i x P r e f i x used in custom header / s t a t i c RateLimitStatus createratelimitstatusfromresponseheaderwithprefix ( HttpResponse res, S t r i n g p r e f i x = ) { i f ( null == r e s ) { return null ; } S t r i n g headerlimit = X + p r e f i x + RateLimit Limit ; S t r i n g headerremaining = X + p r e f i x + RateLimit Remaining ; S t r i n g headerreset = X + p r e f i x + RateLimit Reset ; int r e m a i n i n g H i t s ; int hourlylimit ; int resettimeinseconds ; // not i n c l u d e d in t h e response header. Need to be c a l c u l a t e d. Date resettime ; S t r i n g l i m i t = r e s. getresponseheader ( headerlimit ) ; i f ( l i m i t!= null ) { hourlylimit = I n t e g e r. p a r s e I n t ( l i m i t ) ; 24/45

47 6.1 TWITTER4J } } else { return null ; } S t r i n g remaining = r e s. getresponseheader ( headerremaining ) ; i f ( remaining!= null ) { r e m a i n i n g H i t s = I n t e g e r. p a r s e I n t ( remaining ) ; } else { return null ; } S t r i n g r e s e t = r e s. getresponseheader ( headerreset ) ; i f ( r e s e t!= null ) { long longreset = Long. parselong ( r e s e t ) ; resettimeinseconds = ( int ) ( longreset / 1000) ; resettime = new Date ( longreset 1000) ; } else { return null ; } return new RateLimitStatusJSONImpl ( hourlylimit, remaininghits, resettimeinseconds, resettime ) ; Podívejme se na jinou náhodně vybranou třídu. Zvolil jsem třídu UpdateStatus, která bude vzhledem k účelu knihovny jednou z nejpoužívanějších. Podle SonarQube tato třída obsahuje 19 duplicitních řádků kódu. Třída obsahuje kód, který je duplicitní se třídou GetAccessToken. V obou třídách se nachází: Výpis 6: Duplicitní kód ve třídách UpdateStatus a GetAccessToken while ( null == accesstoken ) { System. out. p r i n t l n ( Open the f o l l o w i n g URL and grant a c c e s s to your account : ) ; System. out. p r i n t l n ( requesttoken. getauthorizationurl ( ) ) ; // Od t o h o t o mista j e z b y t e k metody d u p l i c i t n i System. out. p r i n t ( Enter the PIN( i f a v a i l a b l e ) and h i t e n t e r a f t e r you granted a c c e s s. [ PIN ] : ) ; S t r i n g pin = br. readline ( ) ; try { i f ( pin. l e n g t h ( ) > 0) { accesstoken = t w i t t e r. getoauthaccesstoken ( requesttoken, pin ) ; } else { accesstoken = t w i t t e r. getoauthaccesstoken ( requesttoken ) ; } } catch ( TwitterException t e ) { i f (401 == t e. getstatuscode ( ) ) { System. out. p r i n t l n ( Unable to get the a c c e s s token. ) ; } else { t e. p r i n t S t a c k T r a c e ( ) ; } } } System. out. p r i n t l n ( Got a c c e s s token. ) ; System. out. p r i n t l n ( Access token : + accesstoken. gettoken ( ) ) ; System. out. p r i n t l n ( Access token s e c r e t : + accesstoken. gettokensecret ( ) ) ; Proměnná twitter, typu Twitter, je naplněna pomocí tovární metody TwitterFactory().getInstance(). Tovární metoda (factory method) slouží k získání objektu. Uživatel je tak odstíněn od postupu tvorby konkrétního objektu i výsledného návratového typu. Pokud není tato funkce součástí rozhraní, které ji vyžaduje, bývá často nazývána jako jednoduchá tovární metoda (simple factory method) [8]. 25/45

48 6.1 TWITTER4J Tento blok kódu zajišt uje získání accesstokenu a opakovaně se provádí dokud není jeho hodnota různá od null nebo není vyhozena výjimka. Myslím, že tento blok kódu by se dal umístit do specializované metody ve třídě Twitter a nebo vytvořit dekorátor, který obstará získání accesstokenu. Velmi podobný problém nalezneme i ve třídách GetCurrentTrends a GetTrends. V celém projektu jsou umístěny textové řetězce, které vyzývají uživatele k zadání vstupu nebo mu sdělují nějaké informace. Všechny jsou bohužel, jak je vidět z úryvků kódu výše, vepsány v kódu a nedají se snadno nahradit. Změna lokalizace by vyžadovala zásah do zdrojových kódů většiny zúčastněných tříd. Takovéto umístění textových řetězců a jiných hodnot navíc velice často porušuje princip DRY (Don t repeat yourself). Jelikož jsou hodnoty v kódu umístěny na tvrdo, je takový styl programování označován jako hard coding [15] Změna z na a63df Z grafů metrik (Obrázky 5 a 6 na straně 18) víme, že se výrazně snížil počet tříd i počet řádků kódu. Zjistíme si tedy, které třídy byly odstraněny a jaký byl jejich účel. Výpis 7: Zobrazení smazaných souborů pomocí GITu g i t d i f f name only d i f f f i l t e r =D a63df readme a n n o t a t i o n s. t x t t w i t t e r 4 j appengine / s r c /main/ java / t w i t t e r 4 j / i n t e r n a l / j s o n / LazyRateLimitStatus. java t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api /AccountMethodsAsync. java t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api / BlockMethodsAsync. java t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api / DirectMessageMethodsAsync. java t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api / FavoriteMethodsAsync. java t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api / FriendsFollowersMethodsAsync. java... Ve výpisu vidíme soubory, které byly přítomny v commitu a nejsou přítomny v commitu a63df. K Jejich zobrazení jsme použili příkazu diff s parametry --name-only (vypisuje pouze názvy souborů) a --diff-filter=d (vypisuje pouze odstraněné soubory). Vidíme, že bylo odstraněno mnoho asynchronních [17] tříd, kromě nich došlo i k odebrání specializovaných tříd, například pro trendy. Pokud chceme zjistit, proč byl soubor odstraněn, můžeme si zobrazit jeho historii commitů. Výpis 8: Zobrazení části historie souboru g i t l o g 1 f o l l o w p t w i t t e r 4 j async / s r c /main/ java / t w i t t e r 4 j / api / AccountMethodsAsync. java commit 9 d4cc4501adb1baaf4f2d1e27266df539c Author : Yusuke Yamamoto <yusuke@mac. com> Date : Thu Nov : 4 6 : TFJ 679 migrate r e s o u c e c a t e g o r i e s 26/45

49 6.1 TWITTER4J Obdobným způsobem si zjistíme i další změny, které by nás mohly zajímat. Ke snížení počtu řádků kódu přispěly i úpravy importů, kdy je místo výčtu všech importovaných tříd použita hvězdička (Výpis 9). Řádky začínající znakem - byly odebrány a řádky začínající znakem + byly přidány. Výpis 9: Nahrazení jednotlivých importů za hromadný import import com. g o o g l e. appengine. api. u r l f e t c h. HTTPHeader ; import com. g o o g l e. appengine. api. u r l f e t c h. HTTPMethod ; import com. g o o g l e. appengine. api. u r l f e t c h. HTTPRequest ; import com. g o o g l e. appengine. api. u r l f e t c h. URLFetchService ; import com. g o o g l e. appengine. api. u r l f e t c h. URLFetchServiceFactory ; +import com. g o o g l e. appengine. api. u r l f e t c h. ; Pokud používáme více tříd z jednoho balíčku je, dle mého názoru, lepší využít hromadného importu. Jedinou výjimkou je případ, kdy by hromadným importem byl zanesen konflikt jmen. Autor také upravil styl kódu. Například přidal mezery za a před kulaté závorky. Nejspíše se začal řídit nějakým obecným doporučením nebo mu byl původní styl vytknut někým z komunity. Zde se zřejmě změnila verze Javy o čemž svědčí přidání anotace Override. Toto podezření podporuje i zveřejnění Java SE 7 dne [24]. Anotace je formou metadat zavedenou v Java SE 7, která není součástí programu a nemá přímý dopad na operace v kódu, který je anotovaný. Anotace mohou nést informace pro kompilátor, informace potřebné během kompilace či zpracování kódu a nebo informace nutné během běhu programu (runtime) [16] Změna z 1fa56 na b5312 Jedná se o rozsáhlé čištění kódu, kdy některé třídy byly odstraněny nebo nahrazeny obecnějšími. Bylo přidáno nemalé množství továrních tříd, které zprostředkovávají vytváření často využívaných objektů. Zastoupení duplicit v kódu je stále 3, 1%, ale jejich celkové množství se snížilo na 1911 duplicitních řádků. Byla snížena i složitost, která před změnou dosahovala hodnot kolem 7200 a po změně kolem Série commitů v této změně vedla k již zmíněnému rozmělnění problému na menší celky a snížení počtu řádků obsažených v metodě i třídě Celkové vyhodnocení kvality projektu Twitter4J je projekt, který využívá návrhových vzorů (Adaptér, Factory,...), zachovává soudržnost tříd a jejich nízkou provázanost. Většina závislostí je předávána v konstruktorech a jejich vkládání má na starost tovární metoda (Factory method), která je často součástí třídy napsané právě za tímto účelem. 27/45