ez nem titok a kód megírása, hibakeresése és karbantartása bonyolult dolog, ami a magas szoftverminőséghez szükséges. Sőt, a nagy kódösszetettség magasabb szintű kódhibákat eredményez,így a kód fenntartása költségesebb.
tehát a kód bonyolultságának csökkentésével csökkenthetjük a hibák és hibák számát, valamint az élettartam költségeit. Mi is pontosan a komplex kód? Hogyan tudjuk objektíven felmérni, hogy egy kóddarab mennyire összetett, legyen az egy teljes kódbázis vagy egy kis függvény?
ebben a cikkben három komplexitási mutatót fogok áttekinteni a kód összetettségének értékelésére. Ezek a következők:
- Ciklomatikus komplexitás
- kapcsolási utasítás és logikai feltétel komplexitás
- fejlesztői készség
a kód bonyolultságának értékelésével és megértésével kapcsolatos előnyöket is áttekintem.
- Ciklomatikus komplexitás
- első példa
- második példa
- harmadik példa
- Switch utasítás és logikai feltétel komplexitás
- szoftverfejlesztő képzettségi szint
- a szoftver komplexitásának mérésének előnyei
- jobb tesztek
- csökkentett kockázat
- alacsonyabb költségek
- nagyobb kiszámíthatóság
- segíti a fejlesztőket a tanulásban
- ez egy Wrap
Ciklomatikus komplexitás
1976-ban Thomas McCabe Snr javasolt egy metrikát a kód bonyolultságának kiszámításához, az úgynevezett Ciklomatikus komplexitás. Ez határozza meg, mint:
a Program forráskódján keresztül lineárisan független útvonalak számának kvantitatív mérése…a Program vezérlőáramlási grafikonjával számítva.
ha nem ismeri a vezérlési Folyamatgráfot:
ez egy ábrázolás, gráf jelöléssel, minden olyan útvonalról, amely a program végrehajtása során áthaladhat.
egyszerűbben mondta: minél kevesebb út vezet át egy kódrészleten, és minél kevésbé bonyolultak ezek az utak, annál kisebb a Ciklomatikus komplexitás. Ennek eredményeként a kód kevésbé bonyolult. A metrika bemutatásához használjunk három, kissé önkényes Go kód példát.
első példa
func main() { fmt.Println("1 + 1 =", 1+1)}
mivel csak egy út van a függvényen keresztül, Ciklomatikus komplexitási pontszáma 1, amelyet a gocyclo futtatásával találhatunk meg.
második példa
func main() { year, month, day := time.Now().Date() if month == time.November && day == 10 && year == 2018 { fmt.Println("Happy Go day!") } else { fmt.Println("The current month is", month) }}
ebben a példában az aktuális évet, hónapot és napot töltjük le. Ezzel az információval ellenőrizzük, hogy az aktuális dátum az 10th November 2018 egy if/else feltétellel.
ha igen, akkor a kód kiírja: “Boldog Go napot!”a konzolhoz. Ha nem, akkor kiírja, hogy “az aktuális hónap” és az aktuális hónap neve. A kódpélda bonyolultabbá válik, mivel az IF feltétel három alfeltételből áll. Tekintettel arra, hogy magasabb komplexitási pontszáma van 4.
harmadik példa
func main() { _, month, _ := time.Now().Date() switch month { case time.January: fmt.Println("The current month is January.") case time.February: fmt.Println("The current month is February.") case time.March: fmt.Println("The current month is March.") case time.April: fmt.Println("The current month is April.") case time.May: fmt.Println("The current month is May.") default: fmt.Println("The current month is unknown.") }}
ebben a példában az aktuális hónapot nyomtatjuk ki, a month
érték alapján, amelyet a hívásból time.Now().Date()
– ra szereztünk be. Hét útvonal van a függvényen keresztül, egy az egyes case utasításokhoz, egy pedig az alapértelmezetthez.
ennek eredményeként Ciklomatikus komplexitása 7. Ha az év összes hónapját elszámoltuk volna, az alapértelmezéssel együtt, azonban, a pontszáma tizennégy lenne. Ez azért történik, mert a Gocyclo a következő számítási szabályokat használja:
1 A
+1 függvény alapkomplexitása minden ‘if’,’ for’, ‘esetre’, ‘&&’ vagy ‘||’
e három példa felhasználásával láthatjuk, hogy a kód komplexitásának kiszámításához szabványos mutatóval gyorsan felmérhetjük, mennyire összetett egy kóddarab.
azt is láthatjuk, hogy a kód különböző összetett szakaszai egymáshoz képest vannak. A Ciklomatikus komplexitás azonban önmagában nem elegendő.
Switch utasítás és logikai feltétel komplexitás
a kód komplexitásának következő értékelője a switch utasítás és logikai feltétel komplexitás. Az alábbi kódpéldában a második Go példát vettem, és az összetett if feltételt három beágyazott feltételre osztottam; egyet az eredeti feltételekhez.
func main() { year, month, day := time.Now().Date() output := fmt.Sprintf("The current month is %s", month) if month == time.November { if day == 13 { if year == 2018 { output = fmt.Sprintf("Happy Go day!") } } } fmt.Println(output)}
melyik könnyebben érthető (vagy kevésbé bonyolult), az eredeti vagy ez? Most építsünk erre, figyelembe véve a következő három kérdést.
- mi lenne, ha több if feltételünk lenne, és mindegyik meglehetősen összetett lenne?
- mi lenne, ha több lenne, ha a feltételek és a kód mindegyik testében meglehetősen összetett lenne?
- könnyebb vagy nehezebb lenne megérteni a kódot?
helyes azt mondani, hogy minél nagyobb a beágyazott feltételek száma és minél nagyobb a komplexitás szintje ezeken a feltételeken belül, annál nagyobb a kód összetettsége.
szoftverfejlesztő képzettségi szint
mi a helyzet a fejlesztő képzettségi szintjével? Vessen egy pillantást az alábbi második Go példa C verziójára.
#include <stdio.h>#include <time.h>#include <string.h>int main(){ time_t t = time(NULL); struct tm tm = *localtime(&t); const char * months = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"}; if (tm.tm_year == 2018 && strncmp(months, "November", strlen(months)) == 0 && tm.tm_mday == 10) { printf("Happy C Day!.\n"); } else { printf("The current month is %s.\n", months); }}
technikailag azt teszi, amit a többi példa. Ugyanazon eredmény eléréséhez azonban több kódra van szükség. Hogy igazságos legyek, ha jobban ismerem a C-t, a kód nem lehet hosszabb, mint a Go példa.
tegyük fel azonban, hogy ez a minimum, amely ugyanazon eredmény eléréséhez szükséges. Ha összehasonlítjuk a kettőt, tekintettel a C szintaxisának bőbeszédűbb jellegére a Go-hoz képest, nehezebb megérteni.
mi több, ha nem lenne korábbi tapasztalata a C-vel, a viszonylag hasonló Ciklomatikus komplexitási pontszám ellenére, mi lenne az észlelése?
Ön szerint a kód kevésbé vagy bonyolultabb? Tehát ez egy másik lényeges tényező a kód összetettségének megértésében.
a szoftver komplexitásának mérésének előnyei
a kód komplexitásának mérésének négy alapvető előnye van, plusz egy extra.
jobb tesztek
ha tudjuk, hogy hány független út van egy kódrészleten keresztül, akkor tudjuk, hogy hány utat kell tesztelni.
egyébként nem támogatom a 100%—os kód lefedettséget-ez gyakran értelmetlen szoftvermutató. Mindazonáltal mindig támogatom a kód lefedettségének olyan magas szintjét, amely mind praktikus, mind lehetséges.
tehát, ha tudjuk, hogy hány kódútvonal van, akkor tudjuk, hogy hány utat kell tesztelnünk. Ennek eredményeként, van egy intézkedés, hogy hány teszt szükséges, legalább, annak biztosítása érdekében, hogy a kód lefedett.
csökkentett kockázat
ahogy a régi mondás tartja:
nehezebb olvasni a kódot, mint írni.
mi több:
- a kódot sokkal többet olvassák, mint amennyit írnak
- egy jó szoftverfejlesztőt soha nem az általuk írt (vagy megváltoztatott) kódsorok alapján kell értékelni, hanem az általuk fenntartott kód minősége alapján.
tekintettel arra, hogy a kód bonyolultságának csökkentésével csökkentheti a hibák bevezetésének kockázatát; legyenek azok kicsik vagy nagyok, kissé kínosak vagy csődöt idéznek elő.
alacsonyabb költségek
ha a potenciális hibák kockázata csökken, kevesebb hibát kell megtalálni és eltávolítani. Ennek eredményeként a karbantartási költségek is csökkennek.
mindannyian láttuk és ismerjük a szoftver életének különböző szakaszaiban fellépő hibák megtalálásának költségeit, amint azt az alábbi táblázat szemlélteti.
tehát logikus, hogy ha megértjük kódunk összetettségét, és mely szakaszok bonyolultabbak, mint mások, akkor sokkal jobb helyzetben vagyunk az említett komplexitás csökkentésére.
tehát a komplexitás csökkentésével csökkentjük a hibák bevezetésének valószínűségét. Ez beáramlik a szoftver életének minden szakaszába.
nagyobb kiszámíthatóság
a szoftver bonyolultságának csökkentésével nagyobb kiszámíthatósággal tudunk fejlődni. Ez alatt azt értem, hogy jobban meg tudjuk mondani—magabiztosan -, hogy egy kódrészlet mennyi ideig tart. Ennek ismeretében jobban meg tudjuk jósolni, hogy mennyi ideig tart egy kiadás szállítása.
ezen ismeretek alapján a vállalkozás vagy szervezet jobban képes meghatározni céljait és elvárásait, különösen azokat, amelyek közvetlenül függenek az említett szoftvertől. Amikor ez megtörténik, könnyebb reális költségvetéseket, előrejelzéseket stb.
segíti a fejlesztőket a tanulásban
a fejlesztőknek a tanulásban és növekedésben való segítése a végső előnye annak, ha megértjük, miért tekintik a kódjukat összetettnek. Azok az eszközök, amelyeket eddig a komplexitás felmérésére használtam, nem ezt teszik.
amit csinálnak, az átfogó vagy szemcsés komplexitási pontszám. Azonban egy átfogó kód komplexitás eszköz,mint például a Codacy, nem.
a fenti képernyőképen láthatjuk, hogy a felsorolt hat fájl közül az egyik összetettsége 30, a pontszám általában elég magasnak tekinthető.
a Ciklomatikus komplexitás nagyszerű mutató annak megértéséhez, hogy a kód minősége romlik-e egy adott változásnál. A ciklomatikus komplexitást nehezebb megmagyarázni, ha megnézzük, vagy egész modulokat hasonlítunk össze, tekintettel annak végtelen skálájára, és nem kapcsolódik a modul méretéhez. Azonban valami, amit hasznosnak találhat, a codacy Fájllistáját prioritás szerint rendezi, ami segít megérteni, hogy mely fájlok Rossz kódminőségűek, majd ennek következtében a moduljaik.
ez egy Wrap
Ezenkívül ez egy mélyreható vita volt arról, hogy mi a kód bonyolultsága, hogyan értékelik, valamint a csökkentés jelentős előnyei. Bár a kód bonyolultságának megértése több, mint amit itt tárgyaltam, hosszú utat tettünk meg annak megértéséhez.
ha ez az első alkalom, hogy meghallja a kifejezést, vagy megismeri bármelyik eszközt, javasoljuk, hogy vizsgálja meg a kapcsolódó cikkeket és eszközöket, hogy többet tudjon meg. Ha nem kódol Go vagy C, akkor a google “kód komplexitás eszköz”, valamint a szoftver nyelv(ek). Biztos, hogy sok rendelkezésre álló eszközt talál.
további tippek a kódminőség javításához nézze meg a codacy néhány más blogbejegyzését.
végül, ha átfogó eszközt szeretne a kódminőség értékeléséhez, és olyan eszközt, amely segíti a fejlesztőket a tanulásban és a növekedésben, akkor próbálja ki a Codacy-t.
a Codacy-t fejlesztők ezrei használják, hogy naponta több milliárd sornyi kódot elemezzenek!
a kezdés egyszerű – és ingyenes! Csak használja GitHub, Bitbucket vagy Google-fiókját a regisztrációhoz.
ELSŐ LÉPÉSEK