perusteellinen selitys koodin monimutkaisuudesta

It ’ s no secret code on monimutkainen asia kirjoittaa, debugata ja ylläpitää, mikä on välttämätöntä ohjelmiston korkean laadun kannalta. Lisäksi suuri koodin monimutkaisuus tuo mukanaan korkeamman tason koodivirheitä, jolloin koodi on kalliimpi säilyttää.

joten koodin monimutkaisuutta vähentämällä voimme vähentää vikojen ja vikojen määrää sekä niiden elinkaarikustannuksia. Mikä on monimutkainen koodi? Miten voimme objektiivisesti arvioida kuinka monimutkainen koodinpätkä on, onko se kokonainen koodipohja vai yksi pieni funktio?

tässä artikkelissa käyn läpi kolme kompleksisuuden mittaria koodin monimutkaisuuden arvioimiseksi. Nämä ovat:

• Cyclomatic complexity
• Switch statement and logic condition complexity
• Developer skill

I ’ ll also go through some the benefits of assessing and understanding code complexity.

Syklomaattinen kompleksisuus

vuonna 1976 Thomas McCabe Snr ehdotti koodin kompleksisuuden laskemiseen metriikkaa, jota kutsutaan Syklomaattiseksi Kompleksisuudeksi. Se määritellään seuraavasti::

kvantitatiivinen mitta lineaarisesti riippumattomien polkujen määrästä ohjelman lähdekoodin kautta … laskettuna käyttäen ohjelman ohjausvirtakuvaajaa.

jos Ohjausvirtakäyrä ei ole tuttu:

se on esitys, käyttäen graafin merkintää, kaikista poluista, jotka voidaan kulkea ohjelman läpi sen suorittamisen aikana.

sanottiin suoraviivaisemmin, että mitä vähemmän polut kulkevat koodinpätkän läpi ja mitä monimutkaisempia nämä polut ovat, sitä pienempi on Syklomaattinen monimutkaisuus. Tämän seurauksena koodi on yksinkertaisempi. Osoittaaksemme metriikan, käytetään kolmea, hieman mielivaltaista, Go-koodiesimerkkiä.

esimerkki yksi

func main() { fmt.Println("1 + 1 =", 1+1)}

koska funktion läpi on vain yksi polku, sillä on Syklomaattinen Kompleksisuuspistemäärä 1, jonka voimme löytää ajamalla sille gocycloa.

esimerkki kaksi

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) }}

tässä esimerkissä haetaan kuluvaa vuotta, kuukautta ja päivää. Näillä tiedoilla Tarkistamme, onko nykyinen päivämäärä 10. marraskuuta 2018 if / else-ehdolla.

jos se on, niin koodi tulostaa ”Happy Go day!”konsolille. Jos se ei ole, niin se tulostaa ”kuluva kuukausi on” ja kuluvan kuukauden nimi. Koodiesimerkki monimutkaistuu, kun if-ehto koostuu kolmesta alaehdosta. Ottaen huomioon, että se on suurempi monimutkaisuus pisteet 4.

esimerkki kolme

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.") }}

tässä esimerkissä tulostamme kuluvan kuukauden arvon perusteella month, joka on haettu kutsusta time.Now().Date(). Funktion läpi kulkee seitsemän polkua, yksi kullekin tapauslauseelle ja yksi oletuslauseelle.

tämän seurauksena sen Syklomaattinen kompleksisuus on 7. Jos olisimme laskeneet kaikki vuoden kuukaudet, yhdessä oletusarvon kanssa, sen pistemäärä olisi kuitenkin neljätoista. Näin tapahtuu, koska Gocyclo käyttää seuraavia laskentasääntöjä:

1 on funktion peruskompleksisuus
+1 jokaiselle ”if”, ”for”, ”case’, ’&&’ tai ’||’

käyttämällä näitä kolmea esimerkkiä, voimme nähdä, että ottaa standardin metriikka laskettaessa koodin monimutkaisuus, voimme nopeasti arvioida, kuinka monimutkainen pala koodi on.

voidaan myös nähdä, miten eri kompleksiset koodiosat ovat toisiinsa verrattuina. Syklomaattinen monimutkaisuus ei kuitenkaan yksin riitä.

Kytkinlauseke ja Logiikkaolosuhteiden monimutkaisuus

koodin kompleksisuuden seuraava arvioija on kytkinlauseke ja logiikkaolosuhteiden monimutkaisuus. Alla olevassa koodiesimerkissä olen ottanut toisen Go-esimerkin ja jakanut yhdisteen, jos ehto on kolme sisäkkäistä edellytystä; yksi kullekin alkuperäisille ehdoille.

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)}

kumpi on helpompi ymmärtää (tai vähemmän monimutkainen), alkuperäinen vai tämä? Rakennetaanpa nyt tämän varaan pohtimalla seuraavia kolmea kysymystä.

• mitä jos meillä olisi, kuten edellä, Useita jos olosuhteet ja jokainen olisi melko monimutkainen?
• mitä jos meillä olisi Useita, jos olosuhteet ja koodi jokaisen kehossa olisivat melko monimutkaisia?
• olisiko koodi helpompi vai vaikeampi ymmärtää?

on kohtuullista sanoa, että mitä suurempi on sisäkkäisten olosuhteiden määrä ja mitä suurempi kompleksisuus näissä olosuhteissa on, sitä suurempi on koodin monimutkaisuus.

ohjelmistokehittäjän taitotaso

entä kehittäjän taitotaso? Tutustu alla olevan toisen Go-esimerkin C-versioon.

#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); }}

teknisesti se tekee saman kuin muut esimerkit. Saman lopputuloksen saavuttaminen vaatii kuitenkin enemmän koodia. Jos tuntisin C: n paremmin, koodi ei ehkä olisi Go-esimerkkiä pidempi.

kuitenkin sanotaan, että tämä on minimi, joka vaaditaan saman tuloksen saavuttamiseksi. Jos vertaat näitä kahta, ottaen huomioon C: n syntaksin verbaalisemman luonteen verrattuna Go: hon, sitä on vaikeampi ymmärtää.

mikä olisi havaintosi, jos sinulla ei olisi aiempaa kokemusta C: stä huolimatta verrattain samanlaisesta Syklomaattisesta Kompleksisuuspisteestä?

pitäisitkö koodia vähemmän vai monimutkaisempana? Tämä on siis toinen olennainen tekijä koodin monimutkaisuuden ymmärtämisessä.

ohjelmistojen monimutkaisuuden mittaamisen edut

koodin monimutkaisuuden mittaamisen neljä keskeistä etua plus yksi ylimääräinen.

parempia testejä

tietämällä, kuinka monta itsenäistä polkua on koodinpätkän kautta, tiedämme, kuinka monta polkua on testattavana.

en kannata 100% koodin kattavuutta muuten—se on usein merkityksetön ohjelmisto metriikka. Kuitenkin, olen aina kannattaa niin korkea taso koodin kattavuus kuin on sekä käytännön ja mahdollista.

joten tietämällä kuinka monta koodipolkua on olemassa, voimme tietää kuinka monta polkua meidän on testattava. Tämän seurauksena, sinulla on mitata kuinka monta testiä tarvitaan, vähintään, jotta voidaan varmistaa, että koodi on katettu.

pienempi riski

kuten vanha sanonta kuuluu:

koodin lukeminen on vaikeampaa kuin sen kirjoittaminen.

What ’ s more:

1. koodia luetaan paljon enemmän kuin kirjoitetaan
2. hyvää ohjelmistokehittäjää ei tulisi koskaan arvioida heidän kirjoittamiensa (tai muuttamiensa) koodirivien perusteella, vaan heidän ylläpitämänsä koodin laadun perusteella.

kun otetaan huomioon, että koodin monimutkaisuutta vähentämällä vähennetään riskiä virheiden syntymisestä; olivatpa ne pieniä tai suuria, hieman kiusallisia tai konkurssiin johtavia.

pienemmät kustannukset

kun mahdollisten vikojen riski pienenee, löydettäviä ja poistettavia vikoja on vähemmän. Tämän seurauksena myös ylläpitokustannukset vähenevät.

olemme kaikki nähneet ja tunteneet kustannukset, jotka liittyvät vikojen löytämiseen ohjelmiston elämän eri vaiheissa, kuten alla olevasta taulukosta käy ilmi.

joten on järkevää, että jos ymmärrämme koodimme monimutkaisuuden ja mitkä osat ovat monimutkaisempia kuin muut, niin meillä on paljon paremmat mahdollisuudet vähentää kyseistä monimutkaisuutta.

joten vähentämällä tätä monimutkaisuutta vähennämme virheiden todennäköisyyttä. Joka virtaa kaikissa vaiheissa ohjelmiston elämän.

parempi ennustettavuus

vähentämällä ohjelmistojen monimutkaisuutta voimme kehittyä paremmin ennustettaviksi. Tarkoitan tällä sitä, että pystymme paremmin sanomaan—varmuudella – kuinka kauan koodiosuuden valmistuminen kestää. Kun tiedämme tämän, voimme paremmin ennustaa, kuinka kauan vapautus kestää.

tämän tiedon perusteella yritys tai organisaatio pystyy paremmin asettamaan tavoitteensa ja odotuksensa, erityisesti ne, jotka ovat suoraan riippuvaisia kyseisestä ohjelmistosta. Kun näin tapahtuu, on helpompi asettaa realistisia budjetteja, ennusteita ja niin edelleen.

Helps Developers Learn

Helping developers learn and grow is the final benefit of understanding why their code is considered complex. Työkalut, joilla olen arvioinut monimutkaisuutta tähän asti, eivät tee sitä.

ne antavat kokonais-tai rakeisen kompleksisuuden pisteet. Kuitenkin kattava koodi monimutkaisuus työkalu, kuten Codacy, tekee.

yllä olevasta kuvakaappauksesta voimme nähdä, että kuudesta luetellusta tiedostosta yhden monimutkaisuus on 30, mitä yleensä pidetään melko korkeana.

Syklomaattinen monimutkaisuus on hyvä indikaattori ymmärtää, jos koodin laatu heikkenee jonkin tietyn muutoksen. Syklomaattinen monimutkaisuus voi olla vaikeampi perustella, kun tarkastellaan sitä tai vertaamalla kokonaisia moduuleja ottaen huomioon sen ääretön mittakaava ja ei liity moduulin kokoon. Codacyn tiedostoluetteloa, joka on lajiteltu Prioriteetin mukaan, voi kuitenkin olla hyödyllistä tarkastella, mikä auttaa sinua ymmärtämään, mitkä tiedostot ovat heikkolaatuisia ehdokkaita, ja sitten niiden moduulit.

se on Wrap

myös, tämä on ollut syvällistä keskustelua siitä, mitä koodin monimutkaisuus on, miten sitä arvioidaan, sekä sen vähentämisen merkittävistä hyödyistä. Vaikka koodin monimutkaisuuden ymmärtämisessä on enemmän kuin mitä olen tässä käsitellyt, olemme päässeet pitkälle sen ymmärtämisessä.

jos tämä on ensimmäinen kerta, kun kuulet termistä tai opit jotain työkaluista, kehotan sinua tutustumaan linkitettyihin artikkeleihin ja työkaluihin, jotta opit lisää. Jos et koodaa Go: lla tai C: llä, google ”Code complexity tool” plus ohjelmistokielesi (- kielesi). Löydät varmasti monia työkaluja.

saadaksesi lisää vinkkejä koodin laadun parantamiseen tutustu muutamiin muihin Codacyn blogikirjoituksiin.

lopuksi, jos haluat kattavan työkalun koodin laadun arviointiin ja joka auttaa kehittäjiäsi oppimaan ja kasvamaan, kokeile Codacya.

koodausta käyttävät tuhannet kehittäjät analysoimaan miljardeja koodirivejä joka päivä!

aloittaminen on helppoa-ja ilmaista! Vain käyttää GitHub, Bitbucket tai Google-tilin rekisteröityä.

ALOITA