Nilihamasishwa kuandika nakala hii kwa idadi kubwa ya nyenzo kwenye uchanganuzi tuli ambazo zinazidi kuja kwangu. Kwanza, hii , ambayo inajitangaza kikamilifu kwenye HabrΓ© kwa usaidizi wa ukaguzi wa makosa yaliyopatikana na zana yao katika miradi ya chanzo huria. Hivi majuzi PVS-studio imetekelezwa , na, kwa kweli, watengenezaji wa IntelliJ IDEA, ambao kichanganuzi chake kilichojengwa labda ndio cha juu zaidi kwa Java leo, .
Unaposoma hakiki kama hizo, unapata hisia kwamba tunazungumza juu ya elixir ya uchawi: bonyeza kitufe, na hapa ni - orodha ya kasoro mbele ya macho yako. Inaonekana wachanganuzi wanavyoboresha, hitilafu zaidi na zaidi zitapatikana kiotomatiki, na bidhaa zilizochanganuliwa na roboti hizi zitakuwa bora na bora zaidi, bila juhudi zozote kwa upande wetu.
Lakini hakuna elixirs za uchawi. Ningependa kuzungumza juu ya kile ambacho kwa kawaida hakizungumzwi katika machapisho kama vile "haya ndio mambo ambayo roboti yetu inaweza kupata": ni nini wachambuzi hawawezi kufanya, ni nini jukumu lao halisi na mahali katika mchakato wa uwasilishaji wa programu, na jinsi ya kuzitekeleza kwa usahihi. .
Ratchet (chanzo: ).
Kile ambacho wachambuzi tuli hawawezi kufanya
Uchambuzi wa msimbo wa chanzo ni nini, kutoka kwa mtazamo wa vitendo? Tunatoa baadhi ya msimbo wa chanzo kama ingizo, na kama pato, kwa muda mfupi (mfupi sana kuliko majaribio yanayoendeshwa) tunapata taarifa kuhusu mfumo wetu. Kizuizi cha kimsingi na kisichoweza kushindwa kihisabati ni kwamba tunaweza kupata tu tabaka finyu ya habari kwa njia hii.
Mfano maarufu zaidi wa shida ambayo haiwezi kutatuliwa kwa kutumia uchambuzi wa tuli ni : Hii ni nadharia inayothibitisha kuwa haiwezekani kuunda algoriti ya jumla inayoweza kuamua kutoka kwa msimbo wa chanzo wa programu ikiwa itazunguka au kuisha kwa muda mfupi. Ugani wa nadharia hii ni , ambayo inasema kwamba kwa sifa yoyote isiyo ya maana ya utendakazi zinazoweza kukokotwa, kubainisha kama programu kiholela hutathmini kazi iliyo na sifa kama hiyo ni tatizo lisiloweza kutatulika kialgorithmically. Kwa mfano, haiwezekani kuandika kichanganuzi ambacho kinaweza kuamua kutoka kwa msimbo wowote wa chanzo ikiwa programu inayochanganuliwa ni utekelezaji wa algoriti ambayo huhesabu, tuseme, squaring ya nambari kamili.
Kwa hivyo, utendaji wa wachambuzi wa tuli una vikwazo visivyoweza kushindwa. Kichanganuzi tuli hakitaweza kugundua katika visa vyote vitu kama vile, kwa mfano, kutokea kwa "ubaguzi wa null pointer" katika lugha zinazoruhusu thamani ya null, au katika hali zote kuamua kutokea kwa " sifa haipatikani" katika lugha zilizochapwa kwa nguvu. Yote ambayo mchambuzi wa hali ya juu zaidi anaweza kufanya ni kuonyesha kesi maalum, idadi ambayo, kati ya shida zote zinazowezekana na nambari yako ya chanzo, ni, bila kuzidisha, kushuka kwa bahari.
Uchambuzi tuli si kuhusu kutafuta hitilafu
Kutoka hapo juu, hitimisho ifuatavyo: uchambuzi wa tuli sio njia ya kupunguza idadi ya kasoro katika programu. Ningethubutu kusema: inapotumika kwa mradi wako kwa mara ya kwanza, itapata sehemu "za kuvutia" kwenye nambari, lakini, uwezekano mkubwa, haitapata kasoro zozote zinazoathiri ubora wa programu yako.
Mifano ya kasoro iliyopatikana kwa moja kwa moja na wachambuzi ni ya kuvutia, lakini hatupaswi kusahau kwamba mifano hii ilipatikana kwa skanning seti kubwa ya codebases kubwa. Kwa kanuni hiyo hiyo, wadukuzi ambao wana fursa ya kujaribu nywila kadhaa rahisi kwenye idadi kubwa ya akaunti hatimaye hupata akaunti hizo ambazo zina nenosiri rahisi.
Hii inamaanisha kuwa uchambuzi wa tuli haupaswi kutumiwa? Bila shaka hapana! Na kwa sababu hiyo hiyo inafaa kuangalia kila nywila mpya ili kuhakikisha kuwa imejumuishwa kwenye orodha ya kuacha ya nywila "rahisi".
Uchambuzi tuli ni zaidi ya kutafuta hitilafu
Kwa kweli, matatizo yaliyotatuliwa kivitendo na uchambuzi ni pana zaidi. Baada ya yote, kwa ujumla, uchambuzi wa tuli ni uthibitishaji wowote wa misimbo ya chanzo uliofanywa kabla ya kuzinduliwa. Hapa kuna baadhi ya mambo unayoweza kufanya:
- Kuangalia mtindo wa usimbaji katika maana pana ya neno. Hii ni pamoja na kuangalia umbizo, kutafuta matumizi ya mabano tupu/ziada, kuweka vizingiti kwenye vipimo kama vile idadi ya mistari/utata wa saiklomatiki wa mbinu, n.k. - chochote ambacho kinaweza kutatiza usomaji na udumishaji wa msimbo. Katika Java, zana kama hiyo ni Checkstyle, katika Python - flake8. Programu za darasa hili kawaida huitwa "linter".
- Sio tu nambari inayoweza kutekelezwa inayoweza kuchambuliwa. Faili za rasilimali kama vile JSON, YAML, XML, .properties zinaweza (na zinapaswa!) kukaguliwa kiotomatiki ili kubaini uhalali. Baada ya yote, ni bora kujua kwamba muundo wa JSON umevunjwa kutokana na baadhi ya manukuu ambayo hayajaoanishwa katika hatua ya awali ya uthibitishaji wa Ombi la Kuvuta kiotomatiki kuliko wakati wa utekelezaji wa jaribio au wakati wa kukimbia? Zana zinazofaa zinapatikana: k.m. , .
- Mkusanyiko (au uchanganuzi kwa lugha za programu zinazobadilika) pia ni aina ya uchanganuzi tuli. Kwa ujumla, watunzi wanaweza kutoa maonyo ambayo yanaonyesha matatizo na ubora wa msimbo wa chanzo na haipaswi kupuuzwa.
- Wakati mwingine mkusanyiko ni zaidi ya kuunda nambari inayoweza kutekelezwa. Kwa mfano, ikiwa una nyaraka katika umbizo , basi wakati wa kuibadilisha kuwa HTML/PDF kidhibiti cha AsciiDoctor () inaweza kutoa maonyo, kwa mfano, kuhusu viungo vya ndani vilivyovunjika. Na hii ni sababu nzuri ya kutokubali Ombi la Kuvuta na mabadiliko ya nyaraka.
- Kukagua tahajia pia ni aina ya uchanganuzi tuli. Huduma ina uwezo wa kuangalia tahajia sio tu katika hati, lakini pia katika misimbo ya chanzo cha programu (maoni na maandishi) katika lugha anuwai za programu, pamoja na C/C++, Java na Python. Hitilafu ya tahajia katika kiolesura cha mtumiaji au hati pia ni kasoro!
- Vipimo vya usanidi (kuhusu ni nini - tazama. ΠΈ ripoti), ingawa hutekelezwa katika muda wa majaribio wa kitengo kama vile pytest, kwa kweli pia ni aina ya uchanganuzi tuli, kwa kuwa hazitekelezi misimbo ya chanzo wakati wa utekelezaji wao.
Kama unavyoona, kutafuta hitilafu katika orodha hii kunachukua jukumu muhimu zaidi, na kila kitu kingine kinapatikana kwa kutumia zana huria huria.
Ni aina gani kati ya hizi za uchanganuzi tuli unapaswa kutumia katika mradi wako? Bila shaka, bora zaidi! Jambo kuu ni kutekeleza kwa usahihi, ambayo itajadiliwa zaidi.
Bomba la uwasilishaji kama kichujio cha hatua nyingi na uchanganuzi tuli kama hatua yake ya kwanza
Sitiari ya kawaida ya ujumuishaji endelevu ni njia ambayo mabadiliko hutiririka, kutoka mabadiliko ya msimbo wa chanzo hadi uwasilishaji hadi uzalishaji. Mlolongo wa kawaida wa hatua katika bomba hili inaonekana kama hii:
- uchambuzi tuli
- mkusanyiko
- vipimo vya kitengo
- vipimo vya ujumuishaji
- Vipimo vya UI
- ukaguzi wa mwongozo
Mabadiliko yaliyokataliwa katika hatua ya Nth ya bomba hayahamishwi hadi hatua ya N+1.
Kwa nini hasa kwa njia hii na si vinginevyo? Katika sehemu ya majaribio ya bomba, wanaojaribu watatambua piramidi ya majaribio inayojulikana sana.
Piramidi ya mtihani. Chanzo: Martin Fowler.
Chini ya piramidi hii ni vipimo ambavyo ni rahisi kuandika, kwa haraka kutekeleza, na hawana tabia ya kushindwa. Kwa hivyo, kunapaswa kuwa na zaidi yao, wanapaswa kufunika nambari zaidi na kutekelezwa kwanza. Juu ya piramidi, kinyume chake ni kweli, hivyo idadi ya ushirikiano na vipimo vya UI inapaswa kupunguzwa kwa kiwango cha chini kinachohitajika. Mtu katika mnyororo huu ndiye rasilimali ya gharama kubwa zaidi, polepole na isiyoaminika, kwa hivyo yuko mwisho kabisa na hufanya kazi tu ikiwa hatua za awali hazikupata kasoro yoyote. Hata hivyo, kanuni sawa hutumiwa kujenga bomba katika sehemu zisizohusiana moja kwa moja na kupima!
Ningependa kutoa mlinganisho kwa namna ya mfumo wa kuchuja maji wa hatua nyingi. Maji machafu (mabadiliko na kasoro) hutolewa kwa pembejeo; kwa pato lazima tupate maji safi, ambayo uchafuzi wote usiohitajika umeondolewa.
Kichujio cha hatua nyingi. Chanzo:
Kama unavyojua, vichungi vya kusafisha vimeundwa ili kila mteremko unaofuata uweze kuchuja sehemu inayozidi kuwa bora zaidi ya uchafu. Wakati huo huo, cascades ya utakaso mbaya zaidi ina upitishaji wa juu na gharama ya chini. Katika mlinganisho wetu, hii inamaanisha kuwa milango ya ubora wa pembejeo ni haraka, inahitaji juhudi kidogo kuanza, na yenyewe haina adabu zaidi katika kufanya kazi - na huu ndio mlolongo ambao hujengwa. Jukumu la uchanganuzi tuli, ambao, kama tunavyoelewa sasa, una uwezo wa kuondoa kasoro kubwa tu, ni jukumu la gridi ya "matope" mwanzoni mwa mteremko wa chujio.
Uchambuzi tuli peke yake hauboresha ubora wa bidhaa ya mwisho, kama vile "chujio cha matope" hakifanyi maji yanywe. Na hata hivyo, kwa kushirikiana na vipengele vingine vya bomba, umuhimu wake ni dhahiri. Ingawa katika kichujio cha hatua nyingi hatua za matokeo zina uwezo wa kunasa kila kitu ambacho hatua za uingizaji hufanya, ni wazi ni matokeo gani yatatokea kutokana na jaribio la kujihusisha na hatua za utakaso mzuri pekee, bila hatua za kuingiza.
Madhumuni ya "mtego wa matope" ni kupunguza misururu inayofuata kutoka kwa kukamata kasoro mbaya sana. Kwa mfano, kwa uchache, mtu anayekagua msimbo hapaswi kukengeushwa na msimbo ulioumbizwa vibaya na ukiukaji wa viwango vilivyowekwa vya usimbaji (kama vile mabano ya ziada au matawi yaliyowekwa ndani sana). Hitilafu kama vile NPE zinapaswa kunaswa na majaribio ya kitengo, lakini ikiwa hata kabla ya jaribio kichanganuzi kitatuonyesha kuwa hitilafu itatokea, hii itaharakisha urekebishaji wake.
Ninaamini sasa ni wazi kwa nini uchanganuzi tuli hauboresha ubora wa bidhaa ikiwa unatumiwa mara kwa mara, na unapaswa kutumiwa mara kwa mara ili kuchuja mabadiliko yenye kasoro kubwa. Swali la iwapo kutumia kichanganuzi tuli kutaboresha ubora wa bidhaa yako ni takribani sawa na kuuliza, "Je, maji yanayochukuliwa kutoka kwenye bwawa chafu yataboreshwa katika ubora wa kunywa ikiwa yatapitishwa kwenye colander?"
Utekelezaji katika mradi wa urithi
Swali muhimu la vitendo: jinsi ya kutekeleza uchambuzi wa tuli katika mchakato wa ujumuishaji unaoendelea kama "lango la ubora"? Katika kesi ya vipimo vya moja kwa moja, kila kitu ni dhahiri: kuna seti ya vipimo, kushindwa kwa yeyote kati yao ni sababu ya kutosha ya kuamini kwamba mkutano haukupita lango la ubora. Jaribio la kufunga lango kwa njia ile ile kulingana na matokeo ya uchambuzi wa tuli inashindwa: kuna maonyo mengi ya uchambuzi katika msimbo wa urithi, hutaki kuwapuuza kabisa, lakini pia haiwezekani kuacha kusafirisha bidhaa. kwa sababu tu ina maonyo ya kichanganuzi.
Inapotumiwa kwa mara ya kwanza, analyzer hutoa idadi kubwa ya maonyo kwenye mradi wowote, ambao wengi wao hauhusiani na utendaji mzuri wa bidhaa. Haiwezekani kurekebisha maoni haya yote mara moja, na mengi sio lazima. Baada ya yote, tunajua kwamba bidhaa zetu kwa ujumla hufanya kazi, hata kabla ya kuanzisha uchambuzi wa tuli!
Matokeo yake, wengi ni mdogo kwa matumizi ya mara kwa mara ya uchambuzi wa tuli, au kuitumia tu katika hali ya habari, wakati ripoti ya analyzer inatolewa tu wakati wa mkusanyiko. Hii ni sawa na kutokuwepo kwa uchambuzi wowote, kwa sababu ikiwa tayari tuna maonyo mengi, basi tukio la mwingine (bila kujali jinsi mbaya) wakati wa kubadilisha msimbo huenda bila kutambuliwa.
Njia zifuatazo za kuanzisha milango ya ubora zinajulikana:
- Kuweka kikomo kwa jumla ya idadi ya maonyo au idadi ya maonyo ikigawanywa na idadi ya mistari ya msimbo. Hii inafanya kazi vibaya, kwa sababu lango kama hilo huruhusu kwa uhuru mabadiliko na kasoro mpya kupita, mradi tu kikomo chao hakizidi.
- Kurekebisha, kwa wakati fulani, maonyo yote ya zamani katika msimbo kama yamepuuzwa, na kukataa kujenga maonyo mapya yanapotokea. Utendaji huu unatolewa na PVS-studio na baadhi ya rasilimali za mtandaoni, kwa mfano, Codacy. Sikuwa na nafasi ya kufanya kazi katika studio ya PVS, kama kwa uzoefu wangu na Codacy, shida yao kuu ni kwamba kuamua ni nini "zamani" na ni kosa gani "mpya" ni algorithm ngumu ambayo haifanyi kazi kila wakati. kwa usahihi, haswa ikiwa faili zimebadilishwa sana au kubadilishwa jina. Katika uzoefu wangu, Codacy inaweza kupuuza maonyo mapya katika ombi la kuvuta, wakati huo huo bila kupitisha ombi la kuvuta kutokana na maonyo ambayo hayakuhusiana na mabadiliko katika kanuni ya PR iliyotolewa.
- Kwa maoni yangu, suluhisho la ufanisi zaidi ni lile lililoelezwa katika kitabu "Mbinu ya kudanganya". Wazo la msingi ni kwamba idadi ya maonyo ya uchanganuzi tuli ni sifa ya kila toleo, na ni mabadiliko pekee yanayoruhusiwa ambayo hayaongezi jumla ya idadi ya maonyo.
Ratchet
Inafanya kazi kwa njia hii:
- Katika hatua ya awali, rekodi inafanywa katika metadata kuhusu kutolewa kwa idadi ya maonyo katika msimbo unaopatikana na wachanganuzi. Kwa hivyo, unapounda mkondo wa juu, msimamizi wako wa hazina haandiki tu "kutoa 7.0.2", lakini "toa 7.0.2 iliyo na maonyo 100500 ya mtindo wa ukaguzi." Ikiwa unatumia kidhibiti cha kina cha hazina (kama vile Artifactory), kuhifadhi metadata kama hiyo kuhusu toleo lako ni rahisi.
- Sasa kila ombi la kuvuta, linapojengwa, linalinganisha idadi ya maonyo yanayotokana na idadi ya maonyo yanayopatikana katika toleo la sasa. Ikiwa PR inasababisha kuongezeka kwa nambari hii, basi msimbo haupitishi lango la ubora kwa uchambuzi wa tuli. Ikiwa idadi ya maonyo itapungua au haibadilika, basi hupita.
- Katika toleo lijalo, nambari ya maonyo iliyohesabiwa upya itarekodiwa tena katika metadata ya toleo.
Kwa hivyo kidogo kidogo lakini kwa kasi (kama vile ratchet inafanya kazi), idadi ya maonyo itaelekea sifuri. Bila shaka, mfumo unaweza kudanganywa kwa kuanzisha onyo jipya, lakini kusahihisha ya mtu mwingine. Hii ni kawaida, kwa sababu kwa umbali mrefu hutoa matokeo: maonyo yanarekebishwa, kama sheria, sio mmoja mmoja, lakini katika kikundi cha aina fulani mara moja, na maonyo yote yanayoondolewa kwa urahisi huondolewa haraka sana.
Grafu hii inaonyesha jumla ya idadi ya maonyo ya Checkstyle kwa miezi sita ya uendeshaji wa "ratchet" kama hiyo . Idadi ya maonyo imepungua kwa amri ya ukubwa, na hii ilitokea kwa kawaida, sambamba na maendeleo ya bidhaa!
Ninatumia toleo lililorekebishwa la njia hii, nikihesabu maonyo kando na moduli ya mradi na zana ya uchambuzi, na kusababisha faili ya YAML iliyo na metadata ya ujenzi ambayo inaonekana kama hii:
celesta-sql:
checkstyle: 434
spotbugs: 45
celesta-core:
checkstyle: 206
spotbugs: 13
celesta-maven-plugin:
checkstyle: 19
spotbugs: 0
celesta-unit:
checkstyle: 0
spotbugs: 0
Katika mfumo wowote wa hali ya juu wa CI, ratchet inaweza kutekelezwa kwa zana zozote za uchanganuzi tuli bila kutegemea programu-jalizi na zana za wahusika wengine. Kila kichanganuzi hutoa ripoti yake katika maandishi rahisi au umbizo la XML ambalo ni rahisi kuchanganua. Kilichobaki ni kuandika mantiki muhimu katika hati ya CI. Unaweza kuona jinsi hii inatekelezwa katika miradi yetu ya chanzo huria kulingana na Jenkins na Artifactory au . Mifano zote mbili zinategemea maktaba : njia countWarnings() huhesabu vitambulisho vya xml katika faili zinazozalishwa na Checkstyle na Spotbugs kwa njia ya kawaida, na compareWarningMaps() hutumia ratchet sawa, ikitoa hitilafu wakati idadi ya maonyo katika aina yoyote ya aina inapoongezeka.
Utekelezaji wa kuvutia wa "ratchet" inawezekana kwa kuchambua tahajia ya maoni, maandishi ya maandishi na hati kwa kutumia aspell. Kama unavyojua, wakati wa kukagua tahajia, sio maneno yote yasiyojulikana kwa kamusi ya kawaida sio sahihi; yanaweza kuongezwa kwa kamusi ya mtumiaji. Ukiifanya kamusi maalum kuwa sehemu ya msimbo wa chanzo wa mradi, basi lango la ubora wa tahajia linaweza kutengenezwa kwa njia hii: kutumia aspell kwa kutumia kamusi ya kawaida na maalum. usipate makosa ya tahajia.
Kuhusu umuhimu wa kurekebisha toleo la analyzer
Kwa kumalizia, jambo la kuzingatia ni kwamba bila kujali jinsi unavyotekeleza uchambuzi kwenye bomba lako la utoaji, toleo la analyzer lazima lirekebishwe. Ikiwa unaruhusu kichanganuzi kusasisha kwa hiari, basi wakati wa kukusanya ombi linalofuata la kuvuta, kasoro mpya zinaweza "kuibuka" ambazo hazihusiani na mabadiliko ya nambari, lakini zinahusiana na ukweli kwamba mchambuzi mpya anaweza kupata kasoro zaidi - na hii itavunja mchakato wako wa kukubali maombi ya kuvuta. Kuboresha kichanganuzi kunapaswa kuwa kitendo cha kufahamu. Walakini, urekebishaji mgumu wa toleo la kila sehemu ya kusanyiko kwa ujumla ni hitaji la lazima na mada ya majadiliano tofauti.
Matokeo
- Uchambuzi tuli hautakupata hitilafu na hautaboresha ubora wa bidhaa yako kutokana na programu moja tu. Athari nzuri juu ya ubora inaweza kupatikana tu kwa matumizi yake ya mara kwa mara wakati wa mchakato wa kujifungua.
- Kupata hitilafu sio kazi kuu ya uchanganuzi hata kidogo; idadi kubwa ya vitendaji muhimu vinapatikana katika zana huria.
- Tekeleza milango ya ubora kulingana na matokeo ya uchanganuzi tuli katika hatua ya kwanza kabisa ya bomba la uwasilishaji, kwa kutumia "ratchet" kwa msimbo wa urithi.
marejeo
- ripoti juu ya njia tofauti za uchanganuzi wa nambari (sio tuli tu!)
Chanzo: mapenzi.com