Koodikvaliteedi teemal on palju arutelusid, artikleid ja ajaveebe. Inimesed ütlevad - kasutage tehnikaid Testiga juhitud ! Igasuguse refaktoreerimise alustamiseks on testimine kohustuslik! Kõik see on tore, kuid oleme 2016. aastal ja kümme, viisteist ja isegi kakskümmend aastat tagasi loodi palju tooteid ja koodibaase, mis on endiselt tootmises. Pole saladus, et paljudel neist on pärandkood, mille testide katvus on madal.

Kuigi ma tahaksin alati olla tehnikamaailma esirinnas või isegi verisel kohal - tegeleda uute projektide ja tehnoloogiatega -, pole see kahjuks alati võimalik ja pean sageli tegelema aegunud süsteemidega. Mulle meeldib öelda, et kui areneda nullist, toimite loojana, luues uut ainet. Kuid kui töötate pärandkoodiga, olete nagu kirurg - teate, kuidas süsteem üldiselt töötab, kuid pole kunagi kindel, kas patsient tuleb 'operatsioonist' hästi välja. Ja kuna see on pärandkood, pole palju ajakohaseid teste, mida saaksite usaldada. See tähendab, et sageli on üks esimesi samme selle katmine testimisega. Täpsem on see, et mitte ainult katvuse pakkumiseks, vaid ka testkatte strateegia väljatöötamiseks.

Unustage 100% katvus. Testige nutikamalt, tuvastades klassid, mille purunemine on tõenäolisem. Piiksuma

Põhimõtteliselt oli mul vaja kindlaks teha, millised süsteemi osad (klassid / paketid) peame testidega kõigepealt katma, kus on vaja üksustestid, kus ülekuulamistestid oleksid kõige kasulikumad jne. Sellisele analüüsile lähenemiseks on palju viise ja see, mida olen kasutanud, ei pruugi olla parim, kuid sarnaneb automaatse lähenemisega. Kui minu lähenemisviis on rakendatud, võtab analüüsi enda tegemine vähe aega ja mis veelgi olulisem, see toob pärandkoodi analüüsimisse mõnusat lõbu.

Peamine mõte on siin analüüsida kahte mõõdikut - sidestamine (nt aferentne sidestamine või CA) ja keerukus (nt tsüklomaatiline keerukus).

Esimene mõõdab, mitu klassi meie klass mõõdab, nii et see annab meile põhimõtteliselt teada, kui lähedal mõni konkreetne klass on süsteemi südamele; mida rohkem on meie klassi kasutavaid klasse, seda olulisem on katta need testidega.

Teiselt poolt, kui klass on väga lihtne (nt sisaldab ainult konstandeid), siis kui seda kasutavad paljud teised süsteemi osad, pole selle jaoks nii oluline testi luua. Siit saab abi teine ​​mõõdik. Kui klass sisaldab palju loogikat, on tsüklomaatiline keerukus suur.

Sama loogikat saab rakendada ka vastupidiselt; Näiteks isegi kui klassi ei kasuta paljud klassid ja see esindab ainult ühte konkreetset kasutusjuhtumit, on siiski mõistlik katta see testidega, kui selle sisemine loogiline kasutamine on keeruline.

Siiski on olemas hoiatus: oletame, et meil on kaks klassi - üks, mille CA on 100 ja keerukus 2, ning teine, 60 ja keerukus 20. Kuigi mõõdikute summa on esimese jaoks suurem, peaksime katke esimene esimene. Seda seetõttu, et esimest klassi kasutavad paljud teised klassid, kuid see pole eriti keeruline. Teiselt poolt kasutavad teist klassi ka paljud teised klassid, kuid see on suhteliselt keerukam kui esimene klass.

krediitkaardi lisamise häkkimine

Kokkuvõtteks: peame tuvastama kõrge CA ja tsüklomaatilise keerukusega klassid. Matemaatilises mõttes vajate sobivusfunktsiooni, mida saab kasutada liigitusena. - f (CA, keerukus) - mille väärtused suurenevad koos CA ja keerukusega.

Üldiselt peaksid testkatvuse jaoks olema esmatähtsad klassid, mille kahe mõõdiku vahel on väikseimad erinevused.

Tööriistade leidmine kogu koodibaasi CA ja keerukuse arvutamiseks ning lihtsa viisi pakkumine selle teabe CSV-vormingus väljavõtmiseks osutus keerukaks. Otsingu käigus leidsin kaks tasuta tööriista, nii et oleks ebaõiglane neid mitte mainida:

• Ühendusmõõdikud: www.spinellis.gr/sw/ckjm/
• Keerukus: cyvis.sourceforge.net/

Väike matemaatika

Põhiprobleem on siin see, et meil on kaks kriteeriumi - CA ja tsüklomaatiline keerukus -, nii et peame need ühendama ja teisendama ühtseks skalaarväärtuseks. Kui meil oleks veidi teistsugune ülesanne - nt leida klass, kus meie kriteeriumid oleksid kõige halvemini kombineeritud, oleks meil klassikaline mitme eesmärgi optimeerimisprobleem:

Peame leidma punkti nn Pareto esiküljel (ülaltoodud fotol punane). Pareto komplekti huvitav asi on see, et iga komplekti punkt on lahendus optimeerimistestile. Iga kord, kui liigume mööda punast joont, peame pühenduma oma kriteeriumidele - kui üks paraneb, siis teine ​​halveneb. Seda nimetatakse skalariseerimiseks ja lõpptulemus sõltub sellest, kuidas seda tehakse.

Siin on palju tehnikaid, mida saame siin kasutada. Igal neist on omad plussid ja miinused. Kuid kõige populaarsemad on lineaarne skalarisatsioon ja see, mis põhineb a võrdluspunkt . Lineaarne on kõige lihtsam. Meie sobivusfunktsioon näeb välja nagu CA ja keerukuse lineaarne kombinatsioon:

f (CA, keerukus) = A × CA + B × keerukus

kus A ja B on mõned koefitsiendid.

Punkt, mis tähistab meie optimeerimisprobleemi lahendust, asub joonel (alloleval fotol sinine). Täpselt on see sinise joone ja punase Pareto rinde ristumiskoht. Meie algne probleem pole just optimeerimisprobleem. Kuid peame looma kategoriseerimise funktsiooni. Vaatleme oma kategoriseerimisfunktsiooni kahte väärtust, põhiliselt kahte väärtust veerus Rank.

milline järgmistest ei ole andmebaasi koondamise vältimise eeliseks?

R1 = A ∗ CA + B ∗ keerukus ja R2 = A ∗ CA + B ∗ keerukus

Mõned ülalpool kirjutatud valemid on sirgvõrrandid, veelgi enam, et need sirged on paralleelsed. Võttes arvesse rohkem kategoriseerimise väärtusi, on meil rohkem ridu ja seega rohkem punkte, kus Pareto joon lõikub siniste joontega (punktiiriga). Need punktid on klassid, mis vastavad kindlale kategoriseeritud väärtusele.

Kahjuks on selle lähenemisega probleem. Mis tahes rea (kategoriseeritud väärtus) jaoks on meil selles punktid, millel on väike CA ja väga suur keerukus (ja vastupidi). See paneb nimekirjas kohe esikohale punktid, millel on suur erinevus meetriliste väärtuste vahel, mida me täpselt soovisime vältida.

Teine võimalus skalariseerimiseks põhineb võrdluspunktil. Võrdluspunkt on punkt, millel on mõlema kriteeriumi maksimaalsed väärtused:

php teisendada utf-8-ks

(max (CA), max (keerukus))

Fitnessi funktsioon on võrdluspunkti ja andmepunktide vaheline kaugus:

f (CA, keerukus) = √ ((CA - CA)²+ (Keerukus - keerukus)²)

Võime mõelda sellest sobivusfunktsioonist kui ringist, mille kese on võrdluspunktis. Raadius on antud juhul kategooriate väärtus. Optimeerimisprobleemi lahenduseks saab punkt, kus ring puudutab Pareto rindeosa. Algse ülesande lahenduseks on punktide kogumid, mis vastavad erinevatele ringi raadiusele, nagu on näidatud järgmisel pildil (erinevate kategooriate ringide osad on näidatud siniste täppidega kõveratena):

See lähenemisviis käsitleb äärmuslikke väärtusi paremini, kuid siiski on kaks probleemi: Esiteks - ma sooviksin, et rohkem punkte oleks võrdluspunktide lähedal, et paremini lahendada lineaarse kombinatsiooniga kokku puutunud probleem. Teiseks - CA ja tsüklomaatiline keerukus on oma olemuselt erinevad ja neil on erinevad väärtuste komplektid, mistõttu peame need normaliseerima (nt nii, et mõlema mõõdiku kõik väärtused oleksid vahemikus 1 kuni 100)

Siin on väike nipp, mida saame esimese probleemi lahendamiseks rakendada - selle asemel, et vaadata CA-d ja tsüklomaatilist keerukust, võime vaadata nende ümberpööratud väärtusi. Sellisel juhul on võrdluspunktiks (0,0). Teise probleemi lahendamiseks saame mõõdikud normaliseerida minimaalse väärtuse abil. See näeb välja järgmine:

kus õppida c++

Normaliseeritud ja tagurpidi keerukus - NormKeerukus :

(1 + min (keerukus)) / (1 + keerukus) ∗ 100

Pööratud ja normaliseeritud vahelduvvool - NormCA :

(1 + min (CA)) / (1 + CA) ∗ 100

Märge: Lisasin 1, et veenduda, et jagamist 0. t-ga ei toimu

Järgmine pilt näitab pööratud väärtustega graafikut:

Lõplik kategoriseerimine

Jõuame viimase sammu juurde - kategooriate arvutamine. Nagu mainisin, kasutan võrdlusmeetodit, nii et peame vaid arvutama vektori pikkuse, normaliseerima selle ja tooma klassi ühikutesti loomise olulisuse üles. Siin on viimane valem:

Auaste (NormComplexity, NormCA) = 100 - √ (NormClexlexity²+ NormCA²) / √2

Rohkem statistikat

Mõtteid tahaksin lisada veel, kuid vaatame kõigepealt statistikat. Siin on siduri mõõdikute histogramm:

kuidas koguda Twitteri andmeid

Selle pildi jaoks on huvitav madala CA-ga klasside arv (0–2). Klassid, mille CA on 0, ei kasutata üldse või on kõrgetasemelised teenused. Need tähistavad lõpp-punkte TULI , nii et see on okei, kui meil on neid palju. Kuid klassid koos CA-ga ühes on need, mida otspunktid otseselt kasutavad ja meil on neid klasse rohkem kui lõpp-punkte. Mida see arhitektuuri / disaini seisukohalt tähendab?

Üldiselt tähendab see, et meil on skriptidele orienteeritud lähenemine - skriptime iga ärijuhtumi eraldi (me ei saa koodi uuesti kasutada, kuna ärijuhtumid on väga erinevad). Kui see nii on, siis on see kindlasti a lõhnakood ja me peame refrakteerima. Kui ei, siis tähendab see, et meie süsteemi sidusus on madal, sel juhul vajame ka refaktoreerimist, kuid sel juhul arhitektuuri refrakteerimist.

Ülaltoodud histogrammilt saame lisateavet selle kohta, et saame madalate sidestusklasside (CA väärtusega {0,1}) täielikult filtreerida klasside loendist, mida saab kasutada ühikutestidega. Samad klassid on aga head kandidaadid integreerimiseks / funktsionaalseks testimiseks.

Kõik skriptid ja ressursid, mida ma kasutasin, leiate sellest GitHubi hoidlast: ashalitkin / code-base-stats .

Kas töötab alati?

Mitte tingimata. Esiteks on see kõik staatiline analüüs, mitte käitusaeg. Kui klass filtreeritakse paljude teiste klasside hulgast, võib see olla märk, et seda kasutatakse palju, kuid see pole alati nii. Näiteks ei tea me, kas lõppkasutajad kasutavad seda funktsionaalsust palju. Teiseks, kui süsteemi ülesehitus ja kvaliteet on piisavalt head, on süsteemi erinevad osad / kihid kindlasti liideste vahel lahti ühendatud, nii et staatiline vahelduvvoolu analüüs ei anna meile tõelist pilti. See on vist üks peamisi põhjuseid, miks CA pole populaarne tööriist nagu Sonar. Õnneks on see meiega hästi, sest kui te meenutate, oleme huvitatud selle rakendamisest spetsiaalselt koledate vanade koodibaaside jaoks.

Üldiselt ütleksin, et käituse analüüs annaks paremaid tulemusi, kuid kahjuks on see palju kallim, aeganõudvam ja keerulisem, seega on meie lähenemine potentsiaalselt kasulik ja odavam alternatiiv.

Seotud: Ainulaadne esmane vastutus: suurepärase koodi retsept