Jinsi ya kutekeleza kichanganuzi cha nambari tuli katika mradi wa urithi bila kuishusha timu

Ni rahisi kujaribu kichanganuzi cha msimbo tuli. Lakini kutekeleza, hasa katika maendeleo ya mradi mkubwa wa zamani, inahitaji ujuzi. Ikiwa imefanywa vibaya, kichanganuzi kinaweza kuongeza kazi, kupunguza kasi ya maendeleo, na kuishusha timu. Wacha tuzungumze kwa ufupi juu ya jinsi ya kukaribia ujumuishaji wa uchambuzi tuli katika mchakato wa ukuzaji na tuanze kuitumia kama sehemu ya CI/CD.

Utangulizi

Hivi majuzi umakini wangu ulivutiwa kwenye uchapishaji "Kuanza na Uchambuzi Tuli Bila Kuzidisha Timu". Kwa upande mmoja, hii ni nakala nzuri ambayo inafaa kufahamiana nayo. Kwa upande mwingine, inaonekana kwangu kwamba bado haitoi jibu kamili juu ya jinsi ya kutekeleza uchambuzi wa tuli katika mradi wenye mengi bila maumivu. Nakala hiyo inasema kwamba Unaweza kukubali deni la kiufundi na kufanya kazi kwa nambari mpya tu, lakini hakuna jibu la nini cha kufanya na deni hili la kiufundi baadaye.

Timu yetu ya PVS-Studio inatoa maoni yake juu ya mada hii. Wacha tuangalie jinsi shida ya kutekeleza kichanganuzi cha nambari tuli inatokea kwanza, jinsi ya kushinda shida hii, na jinsi ya kuondoa deni la kiufundi bila uchungu.

Mambo

Kwa kawaida si vigumu kuzindua na kuona jinsi kichanganuzi tuli kinavyofanya kazi [1]. Unaweza kuona makosa ya kuvutia au hata udhaifu unaoweza kutisha kwenye msimbo. Unaweza hata kurekebisha kitu, lakini watengenezaji programu wengi hukata tamaa.

Wachambuzi wote wa tuli hutoa chanya za uwongo. Hiki ni kipengele cha mbinu tuli ya uchanganuzi wa kanuni, na hakuna kinachoweza kufanywa kuihusu. Kwa ujumla, hili ni tatizo lisiloweza kutatuliwa, kama inavyothibitishwa na nadharia ya Rice [2]. Kanuni za kujifunza mashine hazitasaidia pia [3]. Hata kama mtu hawezi kusema kila wakati ikiwa hii au nambari hiyo sio sawa, basi haupaswi kutarajia hii kutoka kwa programu :).

Chanya za uwongo sio tatizo ikiwa kichanganuzi tuli tayari kimesanidiwa:

• Seti za sheria zisizo na maana zilizozimwa;
• Baadhi ya uchunguzi usio na umuhimu umezimwa;
• Ikiwa tunazungumza juu ya C au C ++, basi macros huwekwa alama ambayo yana miundo maalum ambayo husababisha maonyo yasiyofaa kuonekana katika kila mahali ambapo macros kama hizo hutumiwa;
• Kazi za kibinafsi zimewekwa alama ambazo hufanya vitendo sawa na kazi za mfumo (analog yake mwenyewe kumbukumbu au printf) [4];
• Chanya za uwongo zimezimwa haswa kwa kutumia maoni;
• Na kadhalika.

Katika kesi hii, tunaweza kutarajia kiwango cha chini cha chanya cha uwongo cha karibu 10-15% [5]. Kwa maneno mengine, maonyo 9 kati ya 10 ya kichanganuzi yataonyesha tatizo halisi katika msimbo, au angalau "misimbo yenye harufu kali." Kukubaliana, hali hii ni ya kupendeza sana, na analyzer ni rafiki wa kweli wa programu.

Kwa kweli, katika mradi mkubwa, picha ya awali itakuwa tofauti kabisa. Kichanganuzi hutoa mamia au maelfu ya maonyo kwa msimbo wa urithi. Haiwezekani kuelewa haraka ni ipi kati ya maonyo haya ni muhimu na ambayo sio. Sio busara kukaa chini na kuanza kukabiliana na maonyo haya yote, kwani kazi kuu katika kesi hii itaacha kwa siku au wiki. Kwa kawaida, timu haiwezi kumudu hali kama hiyo. Pia kutakuwa na idadi kubwa ya tofauti zinazoharibu historia ya mabadiliko. Na uhariri wa haraka wa vipande vingi kwenye msimbo bila shaka utasababisha makosa na makosa mapya.

Na muhimu zaidi, kazi kama hiyo katika vita dhidi ya maonyo haina maana. Kubali kwamba kwa kuwa mradi umekuwa ukifanya kazi kwa mafanikio kwa miaka mingi, makosa mengi muhimu ndani yake tayari yamesahihishwa. Ndiyo, marekebisho haya yalikuwa ghali sana, ilibidi kutatuliwa, kupokea maoni hasi ya mtumiaji kuhusu hitilafu, na kadhalika. Kichanganuzi tuli kingesaidia kurekebisha makosa mengi katika hatua ya usimbaji, haraka na kwa bei nafuu. Lakini kwa sasa, kwa njia moja au nyingine, makosa haya yamewekwa, na analyzer hasa hutambua makosa yasiyo ya muhimu katika kanuni ya zamani. Nambari hii inaweza isitumike, inaweza kutumika mara chache sana, na hitilafu ndani yake inaweza kusababisha matokeo yanayoonekana. Labda mahali fulani kivuli kutoka kwenye kifungo ni rangi isiyofaa, lakini hii haiingilii na matumizi ya mtu yeyote wa bidhaa.

Bila shaka, hata makosa madogo bado ni makosa. Na wakati mwingine kosa linaweza kuficha udhaifu halisi. Walakini, kuacha kila kitu na kutumia siku/wiki kushughulika na kasoro ambazo hazijidhihirisha kabisa inaonekana kama wazo la kutia shaka.

Watayarishaji wa programu wanaangalia, angalia, angalia maonyo haya yote kuhusu msimbo wa zamani wa kufanya kazi ... Na wanafikiri: tunaweza kufanya bila uchambuzi wa tuli. Hebu twende tuandike utendakazi mpya muhimu.

Kwa njia yao wenyewe, wao ni sawa. Wanafikiri kwamba kwanza wanapaswa kwa namna fulani kuondokana na maonyo haya yote. Hapo ndipo wataweza kufaidika na matumizi ya mara kwa mara ya kichanganuzi cha msimbo. Vinginevyo, maonyo mapya yatazama tu katika ya zamani, na hakuna mtu atakayeyazingatia.

Huu ni mlinganisho sawa na maonyo ya mkusanyaji. Sio bila sababu kwamba wanapendekeza kuweka idadi ya maonyo ya mkusanyaji kwa 0. Ikiwa kuna maonyo 1000, basi wakati kuna 1001, hakuna mtu atakayezingatia, na haijulikani wapi kutafuta onyo hili jipya zaidi.

Jambo baya zaidi katika hadithi hii ni ikiwa mtu kutoka juu kwa wakati huu atakulazimisha kutumia uchanganuzi wa msimbo tuli. Hii itashusha timu tu, kwani kutoka kwa maoni yao kutakuwa na ugumu wa ziada wa ukiritimba ambao unaingia tu. Hakuna mtu atakayeangalia ripoti za analyzer, na matumizi yote yatakuwa tu "kwenye karatasi". Wale. Rasmi, uchambuzi umejengwa katika mchakato wa DevOps, lakini kwa mazoezi hii haifai mtu yeyote. Tulisikia hadithi za kina kwenye vibanda kutoka kwa waliohudhuria mkutano. Uzoefu kama huo unaweza kuwakatisha tamaa watengeneza programu kutumia zana za uchambuzi tuli kwa muda mrefu, ikiwa sio milele.

Utekelezaji na kuondoa madeni ya kiufundi

Kwa kweli, hakuna chochote vigumu au cha kutisha kuhusu kuanzisha uchambuzi wa tuli hata katika mradi mkubwa wa zamani.

CI / CD

Aidha, analyzer inaweza mara moja kufanywa sehemu ya mchakato wa maendeleo endelevu. Kwa mfano, usambazaji wa PVS-Studio una huduma za kutazama ripoti kwa urahisi katika umbizo unayohitaji, na arifa kwa wasanidi programu ambao waliandika sehemu zenye matatizo za msimbo. Kwa wale ambao wanapenda zaidi kuzindua PVS-Studio kutoka kwa mifumo ya CI/CD, ninapendekeza ujitambulishe na zinazolingana. sehemu nyaraka na mfululizo wa makala:

• PVS-Studio huenda kwenye mawingu: Azure Devops
• PVS-Studio huenda kwa mawingu: Travis CI
• PVS-Studio huenda kwa mawingu: GitLab CI/CD
• PVS-Studio huenda kwa mawingu: CircleCI

Lakini hebu turudi kwenye suala la idadi kubwa ya chanya za uongo katika hatua za kwanza za kutekeleza zana za uchambuzi wa kanuni.

Kurekebisha deni la kiufundi lililopo na kushughulikia maonyo mapya

Vichanganuzi vya kisasa vya tuli vya kibiashara hukuruhusu kusoma maonyo mapya tu ambayo yanaonekana katika nambari mpya au iliyobadilishwa. Utekelezaji wa utaratibu huu unatofautiana, lakini kiini ni sawa. Katika kichanganuzi tuli cha PVS-Studio, utendakazi huu unatekelezwa kama ifuatavyo.

Ili kuanza haraka kutumia uchanganuzi tuli, tunapendekeza watumiaji wa PVS-Studio watumie utaratibu wa kukandamiza maonyo kwa wingi [6]. Wazo la jumla ni lifuatalo. Mtumiaji alizindua kichanganuzi na akapokea maonyo mengi. Kwa kuwa mradi ambao umekuwa katika maendeleo kwa miaka mingi uko hai, unakuza na kutengeneza pesa, basi kuna uwezekano mkubwa hakutakuwa na maonyo mengi katika ripoti inayoonyesha kasoro kubwa. Kwa maneno mengine, hitilafu muhimu tayari zimerekebishwa kwa njia moja au nyingine kwa kutumia njia za gharama kubwa au shukrani kwa maoni kutoka kwa wateja. Ipasavyo, kila kitu ambacho analyzer hupata sasa kinaweza kuchukuliwa kuwa deni la kiufundi, ambalo haliwezekani kujaribu kuondoa mara moja.

Unaweza kuwaambia PVS-Studio kuzingatia maonyo haya kuwa hayana umuhimu kwa sasa (hifadhi deni la kiufundi kwa baadaye), na haitawaonyesha tena. Mchambuzi huunda faili maalum ambapo huhifadhi habari kuhusu makosa ambayo bado hayajapendeza. Na sasa PVS-Studio itatoa maonyo kwa nambari mpya au iliyobadilishwa tu. Aidha, haya yote yanatekelezwa kwa busara. Ikiwa, kwa mfano, mstari usio na tupu umeongezwa kwa mwanzo wa faili ya msimbo wa chanzo, basi analyzer anaelewa kuwa, kwa kweli, hakuna kitu kilichobadilika, na kitaendelea kuwa kimya. Faili hii ya alama inaweza kuwekwa katika mfumo wa udhibiti wa toleo. Faili ni kubwa, lakini hii sio tatizo, kwani hakuna uhakika wa kuhifadhi mara nyingi.

Sasa watayarishaji programu wote wataona maonyo yanayohusiana tu na msimbo mpya au uliobadilishwa. Kwa hivyo, unaweza kuanza kutumia analyzer, kama wanasema, kutoka siku inayofuata. Na unaweza kurudi kwa madeni ya kiufundi baadaye, na hatua kwa hatua kurekebisha makosa na kusanidi analyzer.

Kwa hiyo, tatizo la kwanza na utekelezaji wa analyzer katika mradi mkubwa wa zamani umetatuliwa. Sasa hebu tuone nini cha kufanya na madeni ya kiufundi.

Marekebisho ya hitilafu na urekebishaji upya

Jambo rahisi na la asili zaidi ni kutenga muda wa kuchambua maonyo ya kichanganuzi yaliyokandamizwa sana na kuyashughulikia hatua kwa hatua. Mahali pengine unapaswa kurekebisha makosa katika nambari, mahali fulani unapaswa kurekebisha tena kumwambia mchambuzi kuwa nambari hiyo haina shida. Mfano rahisi:

if (a = b)

Wasanifu na wachambuzi wengi wa C++ wanalalamika juu ya nambari kama hiyo, kwani kuna uwezekano mkubwa kwamba walitaka kuandika. (a == b). Lakini kuna makubaliano ambayo hayajasemwa, na hii kawaida huzingatiwa katika nyaraka, kwamba ikiwa kuna mabano ya ziada, basi inachukuliwa kuwa mpangaji wa programu aliandika kwa makusudi kanuni hiyo, na hakuna haja ya kuapa. Kwa mfano, katika nyaraka za PVS-Studio kwa ajili ya uchunguzi V559 (CWE-481) imeandikwa wazi kwamba mstari ufuatao utazingatiwa kuwa sahihi na salama:

if ((a = b))

Mfano mwingine. Je, imesahaulika katika msimbo huu wa C++? kuvunja au siyo?

case A:
  foo();
case B:
  bar();
  break;

Mchanganuzi wa PVS-Studio atatoa onyo hapa V796 (CWE-484). Hili linaweza lisiwe kosa, kwa hali ambayo unapaswa kumpa kichanganuzi kidokezo kwa kuongeza sifa [[fallthrough]] au kwa mfano __sifa__((fallthrough)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

Inaweza kusema kuwa mabadiliko kama haya ya nambari hayarekebishi mdudu. Ndiyo, hii ni kweli, lakini inafanya mambo mawili muhimu. Kwanza, ripoti ya mchambuzi huondoa chanya za uwongo. Pili, kanuni hiyo inaeleweka zaidi kwa watu wanaohusika katika matengenezo yake. Na hii ni muhimu sana! Kwa hili pekee, inafaa kutekeleza urekebishaji mdogo ili kufanya msimbo kuwa wazi na rahisi kudumisha. Kwa kuwa kichanganuzi hakielewi ikiwa "mapumziko" inahitajika au la, pia itakuwa wazi kwa waandaaji wa programu wenzake.

Kando na urekebishaji wa hitilafu na urekebishaji upya, unaweza kukandamiza maonyo dhahiri ya uchanganuzi wa uwongo. Baadhi ya uchunguzi usio na umuhimu unaweza kuzimwa. Kwa mfano, mtu anadhani maonyo hayana maana V550 kuhusu kulinganisha maadili ya kuelea/mara mbili. Na wengine wanaziainisha kuwa muhimu na zinazostahili kusomwa [7]. Ni maonyo yapi yanachukuliwa kuwa muhimu na ambayo sio ni juu ya timu ya maendeleo kuamua.

Kuna njia zingine za kukandamiza arifa za uwongo. Kwa mfano, markup macro ilitajwa hapo awali. Yote hii imeelezewa kwa undani zaidi katika nyaraka. Jambo muhimu zaidi ni kuelewa kwamba ikiwa hatua kwa hatua na kwa utaratibu unakaribia kufanya kazi na chanya za uwongo, hakuna chochote kibaya nao. Idadi kubwa ya maonyo yasiyovutia hupotea baada ya kusanidi, na ni sehemu tu ambazo zinahitaji uchunguzi wa uangalifu na mabadiliko kadhaa katika msimbo husalia.

Pia, sisi huwasaidia wateja wetu kusanidi PVS-Studio ikiwa matatizo yoyote yatatokea. Kwa kuongezea, kulikuwa na visa wakati sisi wenyewe tuliondoa maonyo ya uwongo na kusahihisha makosa [8]. Ikiwezekana, niliamua kutaja kuwa chaguo hili la ushirikiano wa kupanuliwa pia linawezekana :).

Mbinu ya Ratchet

Есть и другой интересный подход к тому, чтобы постепенно улучшать качество кода, устраняя предупреждение статического анализатора. Суть в том, что количество предупреждений может только уменьшаться.

Idadi ya maonyo iliyotolewa na kichanganuzi tuli imerekodiwa. Lango la ubora limeundwa kwa njia ambayo sasa unaweza tu kuingiza msimbo ambao hauongeza idadi ya shughuli. Matokeo yake, mchakato wa kupunguza hatua kwa hatua idadi ya kengele huanza kwa kurekebisha analyzer na kurekebisha makosa.

Hata ikiwa mtu anataka kudanganya kidogo na kuamua kupitisha lango la ubora sio kwa kuondoa maonyo katika nambari yake mpya, lakini kwa kuboresha nambari ya zamani ya mtu wa tatu, hii sio ya kutisha. Vivyo hivyo, ratchet huzunguka kwa mwelekeo mmoja, na hatua kwa hatua idadi ya kasoro itapungua. Hata ikiwa mtu hataki kurekebisha kasoro zake mpya, bado atalazimika kuboresha kitu katika nambari ya jirani. Wakati fulani, njia rahisi za kupunguza idadi ya maonyo huisha, na inakuja wakati ambapo mende halisi itarekebishwa.

Mbinu hii imeelezewa kwa undani zaidi katika nakala ya kuvutia sana ya Ivan Ponomarev "Tekeleza uchanganuzi tuli katika mchakato, badala ya kuutumia kutafuta hitilafu", ambayo ninapendekeza kusoma kwa mtu yeyote anayetaka kuboresha ubora wa nambari.

Mwandishi wa makala hiyo pia ana ripoti juu ya mada hii: "Uchambuzi wa tuli unaoendelea".

Hitimisho

Natumaini kwamba baada ya makala hii, wasomaji watakubali zaidi zana za uchambuzi tuli na watataka kuzitekeleza katika mchakato wa maendeleo. Ikiwa una maswali yoyote, tuko tayari kila wakati ushauri watumiaji wa kichanganuzi chetu tuli cha PVS-Studio na usaidizi katika utekelezaji wake.

Kuna mashaka mengine ya kawaida kuhusu kama uchanganuzi tuli unaweza kweli kuwa rahisi na muhimu. Nilijaribu kuondoa mashaka haya mengi katika uchapishaji "Sababu za kutambulisha kichanganuzi cha kanuni tuli cha PVS-Studio katika mchakato wa ukuzaji" [9].

Asante kwa umakini wako na uje download na jaribu kichanganuzi cha PVS-Studio.

Viungo vya ziada

1. Andrey Karpov. Ninawezaje kuona haraka maonyo ya kupendeza ambayo kichanganuzi cha PVS-Studio hutoa kwa nambari ya C na C++?
2. Wikipedia. Nadharia ya Rice.
3. Andrey Karpov, Victoria Khanieva. Kutumia kujifunza kwa mashine katika uchanganuzi tuli wa msimbo wa chanzo cha programu.
4. PVS-Studio. Nyaraka. Mipangilio ya ziada ya uchunguzi.
5. Andrey Karpov. Sifa za kichanganuzi cha PVS-Studio kwa kutumia mfano wa Maktaba za EFL Core, 10-15% chanya za uwongo..
6. PVS-Studio. Nyaraka. Ukandamizaji mkubwa wa ujumbe wa analyzer.
7. Ivan Andryashin. Kuhusu jinsi tulivyojaribu uchanganuzi tuli kwenye mradi wetu wa kiigaji cha elimu cha upasuaji wa endovascular wa X-ray.
8. Pavel Eremeev, Svyatoslav Razmyslov. Jinsi timu ya PVS-Studio ilivyoboresha msimbo wa Unreal Engine.
9. Andrey Karpov. Sababu za kutambulisha kichanganuzi tuli cha msimbo PVS-Studio katika mchakato wa ukuzaji.

Ikiwa ungependa kushiriki makala hii na hadhira inayozungumza Kiingereza, tafadhali tumia kiungo cha kutafsiri: Andrey Karpov. Jinsi ya kutambulisha kichanganuzi cha nambari tuli katika mradi wa urithi na sio kukatisha tamaa timu.

Chanzo: mapenzi.com