Domov arrow Programovanie arrow Code Metrics - Základné metriky pre kód
Code Metrics - Základné metriky pre kód
Hodnotenie čitateľov: / 2
SlabéVynikajúce 
ImageEclipse Metrics Plugin, s ktorým som vám predstavil v tomto článku, podporuje sadu základných metrík, na základe ktorých by ste mohli vylepšiť váš zdrojový (Java) kód.

V dnešnej verzii tento plugin podporuje merania na dvoch rôznych úrovniach: merania na úrovni triedy a merania na úrovni jednotlivých metód. Metriky pre triedy sa ďalej rozdežujú na dve kategórie: všeobecné triedne metriky a metriky zamerané na nedostatok kohézie v triedach (LCOM - Lack of Cohesion in Methods).

Merania na úrovni metód

Nižšie sú uvedené všetky metriky podporované pluginom pre merania na úrovni metód:

Feature Envy (FE) - závisť prvkov (metód a polí) - metóda M v triede C1 je závistlivá, keď využíva prvky triedy C2 viac ako využíva prvky triedy, v ktorej sa metóda M nachádza. Riešenie je presunúť metódu M z triedy C1 do C2.

Lines of Code (LOC) in Method - počet riadkov kódu v metóde - jednoduchá metrika, ktorá vášnivých písačov sekvenčného kódu, často plného duplikácií a temporálnej závislosti, donúti rozsekať epopejové metódy na niekoľko kratších, či refaktorovať a zlepšiť dizajn, keď dĺžka metódy prekročí určitý limit. (Ja viem, som veľký idealista!)

McCabe's Cyclomatic Complexity (CC) - Cyklomatická komplexita (Wikipedia) - CC si vysníval a kvalitne teoreticky podložil svojim výskumom istý pán Thomas J. McCabe. V skratke, možno nie celkom presne formulované, ale pre lepšiu predstavu čo CC je: CC je súčet IF blokov, TRY blokov, a LOOP blokov (for, while, do) v rámci metódy, plus jedna: Nif + Ntry + Nloop + 1 = CC. Zaujímavosť ohľadne cyklomatickej komplexity je taká, že pri štrukturovanom unit-testovaní metódy budete potrebovať presne CC test metód na úplné otestovanie každého rohu a zákutia testovanej metódy. (SWITCH bloky sú zvlášť zákerné pre CC)

Number Of Levels (NOL) - počet úrovní - pokiaľ v rámci metódy máte len niekoľko riadkov (invokácií či priradení), všetky sú na úrovni 1. Akonáhle vnoríme riadky kódu do nejakého kondicionálu - t.j. IF bloku - či do smyčky (loop - for/while/do), či CASE bloku (v nejakom SWITCHi), či TRY bloku (do sekcie TRY, CATCH, či FINALLY) úroveň týchto vnorených riadkov je 2. Ak napríklad v rámci IF bloku vopcháme kód do FOR smyčky, už sme na leveli 3.

Number Of Locals in Scope (NOLS) - počet lokálnych premenných v rámci metódy - keď ich je veľa, asi sa metóda snaží robiť priveľa na jednom mieste a jej čitateľnosť trpí.

Number Of Parameters - počet parametrov metódy - pokiaľ ich je viac než 5, čosi je zvláštne s vašim dizajnom. Pokiaľ si myslíte, že je nutné metóde posielať napr. prvé meno, priezvisko, titul, pohlavie, farbu očí, váhu, výšku, dátum narodenia a ešte niekoľko zaujímavých informácií, tak by ste sa mohli seriózne zamyslieť nad modelovaním všetkých týchto parametrov ako triedu a poslať radšej jeden objekt typu Osoba.

Number Of Statements (NOS) - počet výrokov - výroky sú základné časti kódu. Vnútro každej metódy pozostáva z nula alebo viac výrokov. (Terminológia je celkom pekne vysvetlená na tejto stránke). Každý výrok, okrem bloku, sa v Jave končí bodkočiarkou. Počítanie výrokov je o niečo lepší spôsob na zistenie veľkosti metódy, než počítanie riadkov kódu. Výrok je predsa výrok, nezávisle od toho či je napísaný na jednom riadku, alebo či sme ho kôli formátovaniu rozhádzali po viacerých riadkoch. Meranie počtu výrokov slúži rovnakej dobrej veci ako počítanie riadkov kódu (LOC).

Merania na úrovni tried

Okrem premeriavania jednotlivých metód v rámci triedy je dobré premeriavať aj samotnú triedu, či rozhranie (interface). Meranie rozhraní nedáva veľký zmysel, keďže obsahujú len definície metód a žiaden merateľný kód. Popravde, dá sa v nich merať len EC (efferent coupling vysvetlený nižšie) a na jednotlivých definíciách sa dá ešte vytknúť NOP (number of parameters). Väčšinou nás merania na rozhraniach nebudú veľmi interesovať. Zaujímavé sú však čísla pre celé triedy. Eclipse Metrics Plugin od StateOfFlow poskytuje analýzu metrík dvoch kategórií na triednej úrovni - nižšie uvediem tie všeobecné:

Efferent Coupling (EC) - eferentné (smerom von, preč od centra) prepojenie - veľmi dôležitá metrika. Na toto číslo je dobré si posvietiť. Nastaviť vhodný limit a snažiť sa ho stoj-čo-stoj neprekročiť. Trieda by nemala byť závislá na priveľkom množstve iných tried. Pokiaľ z jedného miesta (jednej triedy) vystrežujú príkazy do všetkých možných smerov na všetky svetové strany, tak je veľmi pravdepodobné, že sa nám podarilo vyhotoviť božskú triedu (God object /class antipattern), ktorá je riešením na všetky svetové problémy, o všetkom vie, všetko koordinuje, riadi, do všetkého má čo povedať. Šikovne, treba s tým niečo urobiť, a znova nasleduje refaktorovanie a redizajn.

Number of Fields (NOF) - počet polí - Triedy s väčším množstvom polí nie sú automaticky vadné, lej je vhodné sa nad nimi pozastaviť. Treba porozmýšľať, či by sa niektoré súvisiace polia nedali zoskupiť do zvlášť triedy. (Napr. ulica, číslo domu, mesto, PSČ, atď by mohli byť zoskupené do triedy Adresa). Takéto zmeny prispievajú k vylepšeniu sémantiky objektového modelu a lepšej distribúcii znalostí o systéme.

Weighted Methods Per Class (WMC) - suma jednotlivých cyklomatických komplexít metód v triede. Triedy s vysokým WMC sú s najväčšou pravdepodobnosťou príliš špecifické pre aplikáciu a tak sa stávajú menej znovu-použiteľné. Taktiež toto číslo naznačuje koľko úsilia je potrebné na údržbu danej triedy - ako veľmi komplexné je vnútro triedy.

Kohézia metód v triedach (LCOM)

Ešte na úrvoni tried máme so spomínaným pluginom poruke metriky zamerané na kohéziu tried (respektíve jej nedostatok v triedach, nekohezívnosť metód vo vnútri tried - Lack of Cohesion in Methods - LCOM). Kohézna trieda reprezentuje iba jednu abstrakciu v rámci systému (venuje sa len jednej vyčlenenej úlohe). Keď sa jedna trieda venuje práci v niekoľkých oblastiach naraz, jej vnútro nie je kohézne, prilínavé, a začína sa podobať na rozstrapkaný špagát, či suchý zips, ktorý sa kde-tu zachycuje o nechcené časti tkaniny. Tieto metriky sú však "chlpaté" samé o sebe a len s ťažkosťou sa dajú upozornenia vygenerované meradlami týchto metrík porozumieť a využiť pre vylepšenie dizajnu. Osobne som zvykol analýzu LCOM metrík vypnúť, ale časom som sa pokúsil s nimi spolupracovať a pochopiť o čo ide. A keď si dáte tú námahu sa nad ich definíciami zamyslieť, je možné, že vám aj práve tieto metriky pomôžu k vylepšeniu vášho OO dizajnu a teda k vašej excelencii. Nižšie uvediem zoznam metrík typu LCOM podporovaných pluginom od StateOfFlow. Rôzni výskumníci prišli na svet s rôznymi názormi na to, čo je v triede nekohezívne a ako nekohezívnosť merať. Rôzne prístupy k meraniu LCOM boli pomenované podľa výskumníkov:

Chidamber and Kemerer (CK) - aby sme zachovali ideálnu kohéziu v metódach triedy podľa Chidambera a Kemerera, mali by všetky metódy M triedy C mať aspoň o jedno pole F (v triede C) spoločný záujem. Nedostatok kohézie nastáva vtedy keď v triede je viac párov metód, ktoré nemajú žiadny spoločný záujem o niektoré polia, než metód, ktoré spoločný záujem majú. Ako som už spomínal, je to celé trošku zložitejšie na predstavu a preto namerané čísla CK metriky sa ťažko reprezentujú programátorovi a nie je vždy celkom jasné, ako by sa s vysokými hodnotami CK dalo bojovať. Ale ak sa nad tým, čo o kohézii metód v triede vyskúmali títo dvaja odborníci Chidamber a Kemerer, uvidíte, že majú celkom pravdu. Každopádne triedy s obzvlášť krikľavým narušením tejto metriky je vhodné skontrolovať a uvážiť rozdelenie triedy na viacero kohéznych tried.

Henderson-Sellers (HS) - pán Henderson-Sellers nedostatok kohézie v metódach tiež definuje na základe využitia polí metódami triedy, ale jeho rovnica je trošku odlišná. Až trošku príliš komplikovaná, aby som ju tu dal v plnom slovnom znení. Znova, problémy s touto metrikou sú tie isté ako u iných metrík orientovaných na LCOM - len ťažko sa zisťuje, čo namerané číslo znamená a ako triedu upraviť, aby bola podľa HS čo najkohezívnejšia.

Total Correlation (TC) - celková korelácia (vzájomný vzťah) - analyzér tried počítajúci túto hodnotu sa snaží nájsť také triedy, v ktorých sa javia možnosti extrakcie súvisiacich polí do osobitnej triedy (podobne ako NOF môže naznačovať, že polia tvoria štruktúru). Pokiaľ sa v triede skrýva samostatná podštruktúra, táto podštruktúra by mala byť z triedy vybratá, čím pôvodná trieda by mala nadobudnúť lepšiu kohéziu, keďže ďalej reprezentuje len jednu abstrakciu, čo je už z definície kohéznej triedy dobrá vec. A z definície objektovo-orientovaného programovania OOP, kohézne triedy sú tiež dobrá vec.

Pairwise Field Irrelation (PFI) - párová nesúvislosť polí - pokiaľ sa trieda venuje dvom veciam naraz, napríklad udržiava zoznam došlej a odoslanej pošty, venuje sa vlastne dvom (podobným) úlohám naraz. V takejto triede budú metódy venujúce sa práci s dátovou štruktúrou došlej pošty, a celkom nezávislé metódy venujúce sa práci s dátovou štruktúrou odoslanej pošty. Pokiaľ teda metódy M1,M2... prejavujú záujem o pole F1 a metódy N1,N2... prejavujú záujem o pole F2, tak metódy Mi a Ni sú párovo nezávislé od seba a trieda obsahujúca tieto metódy sa venuje dvom úlohám naraz, stráca zameranie, je nekohézna, a by mala byť prerobená na dve zvlášť triedy.

Posledná úprava ( Thursday, 02 June 2011 )
 
< Predchádzajúca   Ďalšia >