NDepend

Patrick Smacchia (az NDepend vezető programozója) felajánlott nekem egy ingyenes NDepend Pro licencet, mindössze annyit kért, hogy a tapasztalataimat osszam meg írásban. Természetesen nem kötelező pozitív véleményt alkotnom. Lássuk mire jutottam!

NDepend egy olyan eszköz, amely beleássa magát a forráskódba és elemzi, hogy megfelel-e adott minőségbeli vagy tervezési követelményeknek. Statikus kódelemzésről van szó, tehát anélkül teszi mindezt, hogy futtatná a programot, csakis a forráskód számít. A jó hír, hogy nem csak C# nyelvhez jó, de Java és C++ verziók is léteznek.

Ha statikus kódelemzésről van szó, akkor sokaknak eszébe fog jutni, hogy hóhó, ott az FxCop! Azonban sok különbség van a kettő között, egy valamit pedig ki akarok emelni, ez pedig a szabályrendszer. Az FxCop ad meghatározott szabályokat és ha ezeket ki akarjuk egészíteni az nem kevés munkával jár. Az NDepend viszont egy rendelkezik egy hihetetlenül erőteljes eszközzel: CQLinq (Code Query over LINQ), amely segítségével könnyedén hozhatunk létre szabályokat. Erről később még lesz szó.

Miután Patrick kiutalt nekem egy licencet kaptam egy email-t, amely tartalmazta a letöltéshez szükséges azonosítómat, illetve egy xml fájlt ami tulajdonképpen a “kulcs” a programhoz. Nincs telepítő, tömörített állományt kaptam, amelyet ki kell csomagolni tetszőleges mappába (28 MB helyet foglal). Ide kellett még másolnom a kapott xml-t is, ezzel elkészültem.

Az NDepend önállóan illetve Visual Studio kiegészítőként is képes futni – 2008, 2010 és 2012 változatokat támogat. A VisualNDepend.exe az előbbit indítja, értelemszerűen a VisualStudioAddin karakterláncot tartalmazó nevű exe pedig a VS addin-t telepíti. A program így néz ki:

1

Látható, hogy azonnal telepíthetjük innen a Visual Studio, sőt Reflector Add-In-t is. Ugyanezt megtehetjük a Tools menü Options ablakában.

2

A programból megnyithatunk létező NDepend projektet, illetve Visual Studio projektet is, utóbbi esetben igen kényelmes megoldás, hogy kiolvassa a Visual Studio cache-ból az utoljára megnyitott solution-öket.

Maga az analízis kifejezetten gyors, a dokumentáció szerint 10000 soron megy át másodpercenként. Miután végzett kapunk egy HTML alapú jelentést, ami enyhén szólva is brutális, azt sem igen tudja az ember hová nézzen. Szerencsére a program dokumentációja elég részletes, bár több illusztrációt elbírt volna. A jelentés utólag is elérhető, ha a programban megnyitjuk az adott projektet, majd az Analisys menü View Report parancsát választjuk.

Tesztalanynak a SignalR és az ASP.NET MVC/Web API forráskódját használtam. Nem fogok kitérni minden apró részletre, mert egyszerűen végtelen számú lehetőség van, nem tudok a felszín karcolgatásánál itt többet visszaadni. Így néz ki a jelentés főoldala:

3

A kép alján Rules summary néven láthatjuk, hogy az alapértelmezett szabályok közül 56-on átment, 74 szabályszegés volt, a piros szám pedig a kiértékelési hibákat jelezné, ilyenek nem voltak. Először nézzük meg a diagramokat!

A Dependency Graph a felhasznált .NET assembly-k kapcsolódását mutatja. HTML formában csak egy magaslati szempontot kapunk, érdemes a program interaktív “nézőkéjét” használni, amely tetszőleges nagyítást/kicsinyitést engedélyez, valamint kimenthető képként is:

DependencyGraphSnapshot

Ez a program legegyszerűbb része, viszont azonnal látszik, ha egészségtelen függőségek alakultak ki. Az interaktív nézet meg is színezi, hogy mi mitől függ, illetve átrendezhető. Az azért elmondható, hogy a SignalR elég jól néz ki innen nézve. Ha nem akarjuk látni őket, akkor a .NET könyvtárak (mscorlib és társai) eltüntethetőek, ehhez az interaktív ablak bal felső sarkában a Reset gomb lesz segítségünkre, válasszuk a “Reset to application assembly only” pontot és rögtön tisztább a kép:

DependencyGraphSnapshot2

Sokkal csinosabb az eredmény. Az ilyen apróságok sokat segítenek, bár kissé nehéz mindent tetszés szerintire módosítani a sok lehetőség között.

A Dependency Matrix már számszerűsíti is a függőségeket, természetesen az interaktív nézet itt is többet tud a jelentésbe ágyazott képnél.

ComponentDependenciesMatrix

A mátrix megértéséhez az alábbiakat kell tudni:

  • Zöld: metódusok száma az adott sorban lévő névtérből, amelyek az adott oszlopban lévő névtérből használnak valamit (tehát felül az első zöld szám egy hatos, vagyis a bal oldali SignalR névtér 6 metódusa használ valamit a felül lévő másik névtérből).
  • Kék: a zöld fordítottja, tehát a sor-oszlop kapcsolat ellenkező irányban működik.
  • Fekete: ilyen itt nincs, ez a körkörös függőségeket jelölné

Az interaktív nézet ezeket számszerűsíti, és képi formába is képes önteni. Látható (illetve itt nem, nincs elég hely a teljes képnek), hogy kiugró számok a teszt-projektek esetében vannak. Kíváncsi lettem, ezért gyorsan megnéztem, hogy az ASP.NET stack hogyan szerepel ebben az összehasonlításban:

DependencyMatrixSnapshot

Azt hiszem ez egy kissé látványosabb. A Dependency mátrix segít kiszűrni, ha az alkalmazás architektúrája nem a megfelelő módon épül fel, olyan rétegek között alakul ki függőség amelyek esetében nem várjuk.

Következő a sorban a metrika diagram, amely áttekintést ad a projektről adott kritérium alapján. Például nézzük meg programsorok száma szerint az ASP.NET stacket:

MetricTreemapSnapshot

Látható, hogy TDD mentén fejlesztették, így nem meglepő, hogy a forráskód legalább harmadát a tesztek teszik ki. Egyfajta bizarr Google Maps mintájára egész metódusszintig rázoomolhatunk a képre. Egy másik számomra érdekesebb metrika a Cyclomatic Complexity, amely tulajdonképpen azt mutatja meg, hogy a szoftver mely részei hozzák a legtöbb döntést. Minél több elágazás vagy ciklus van a kódban annál magasabb lesz a CC értéke. Erről többet itt lehet találni:

http://www.ndepend.com/Metrics.aspx#CC

Nézzük a SignalR CC értékeit (sajnos az ASP.NET stack tartalmaz olyan kódot is, amelyet az NDepend nem kezel):

MetricTreemapSnapshotSR

Az utolsó diagramtípus az Abstractness versus Instability lesz, először mutatom, aztán magyarázat:

AbstractnessVSInstability

Önmagáért beszél, minél több elem tartózkodik a vörös zónában annál valószínűbb, hogy elvisz az ördög. Az Abstractness tengely jelöli, hogy mennyire absztrakt a kód, kiterjeszthető-e újrafordítás nélkül. Itt tartózkodnak pl. az interfészek és absztrakt osztályok. Az Instability tengely mutatja, hogy adott assembly mennyire képes változásra. Minél több másik assembly támaszkodik rá annál stabilabb (vagyis nehezen változtatható), minél kevesebb annál instabilabb.

Na most, van két zónánk, a Fájdalom és a Használhatatlanság. Ha egy assembly-t sokan használnak (vagyis stabil), és nehézkesen módosítható/kiterjeszthető (nem abstract vagyis concrete) akkor a Fájdalom zónába kerül. Ha viszont egy assembly-t senki nem használ, cserében absztrakt, akkor tipikus “túlgondolt” megoldással van dolgunk és a Használhatatlan zónában a helye.

A metrikák megértéséhez némi segítség:

http://www.hanselman.com/blog/content/binary/NDepend%20metrics%20placemats%201.1.pdf

http://realfiction.net/files/NDependMetricsCheatSheet.pdf

Végül, de nem utolsósorban jöjjön a kedvencem: CQLinq. Erre az eszközre épül a kód minőségének vizsgálata. NDepend 130 előre meghatározott szabállyal érkezik, viszont mi magunk is írhatunk ilyet méghozzá nevetségesen könnyedén. Összesen 82 előre definiált érték szerint írhatunk lekérdezéseket (ugye Linq), pl. metódus sorainak száma, paraméterek száma, milyen százalékban fedtük le unit-tesztekkel stb.

Nézzünk át a Visual Studio-ba is egy kicsit, az NDepend nagyon kényelmesen beépül a menük közé ahonnan minden funkciót könnyen elérhetünk. A Queries and Rules ablakban akár hozzá is láthatunk lekérdezést írni:

4

Van Intellisense támogatás (!), a képen a “túl nagy típus” szabály kódja látható (igen, az összes beépített szabály átírható), vagyis az olyan típusok amelyek 500 sornál vagy 3000 IL utasításnál hosszabbak. Az NDepend mindig logikai programsorokat használ, tehát nem veszi figyelembe milyen stílusban kódolunk, így az itt megadott 500 sor egyáltalán nem kevés.

Írjunk hát egy szabályt, válasszuk ki azokat a metódusokat, amelyeket megváltoztattunk az utolsó fordítás óta:

5

Egyszerűen nem tudok mást mondani, a CQLinq zseniális, szinte bármilyen szabályt írhatunk amit csak a kis szívünk megkíván.

A helyzet az, hogy eddig leírtam 1100 szót, de még legalább kétszer ennyit kellene, hogy megmutassam még mit tud a program. NDepend egy igazi szörnyeteg, félelmetes mennyiségű funkcióval és lehetőséggel. Funkció szempontjából nemigen lehet fogást találni rajta, a felhasználói felület viszont kényelmetlen ha mindent át akar látni az ember folyamatosan rendezgetnie kell az ablakokat (egy óriási monitor megoldja a problémát :D). Ezt leszámítva csak ajánlani tudom.

A tanulási görbe jónak mondható, kell pár óra amíg megvilágosodik az ember, de utána kifejezetten könnyen használható. A Visual Studio integráció kiváló, észre sem veszem, hogy külső programmal van dolgom.

Rendkívül szimpatikus a készítő hozzáállása is. Amíg “játszottam” a szoftverrel több olyan blogbejegyzést találtam ahol a szerző hozzám hasonló módon jutott az NDepend-hez. Az általuk jelzett hiányosságok a mostani verzióban kivétel nélkül javítva lettek, tehát ez a fajta terjesztés nem csak reklámcélt szolgál.

Tagged with:
Nincs kategorizálva kategória

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés /  Módosítás )

Google kép

Hozzászólhat a Google felhasználói fiók használatával. Kilépés /  Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés /  Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés /  Módosítás )

Kapcsolódás: %s

Írtam
%d blogger ezt szereti: