Статикалық код анализаторын қолданып көру оңай. Бірақ оны жүзеге асыру үшін, әсіресе үлкен ескі жобаны әзірлеуде шеберлік қажет. Егер қате орындалса, анализатор жұмысты қосып, дамуды бәсеңдетуі және команданың мотивациясын төмендетуі мүмкін. Статикалық талдауды әзірлеу процесіне біріктіруге қалай дұрыс көзқараспен қарауға және оны CI/CD бөлігі ретінде пайдалануды бастауға қысқаша тоқталайық.
Кіріспе
Жақында менің назарымды басылымға аударды »". Бір жағынан, бұл танысуға тұрарлық жақсы мақала. Екінші жағынан, ол көп жобада статикалық талдауды ауыртпалықсыз қалай енгізуге болатыны туралы толық жауап бермеген сияқты. Мақалада техникалық қарызды қабылдауға және тек жаңа кодпен жұмыс істеуге болады делінген, бірақ кейінірек бұл техникалық қарызды не істеу керектігі туралы жауап жоқ.
Біздің PVS-Studio командасы осы тақырып бойынша өз көзқарасын ұсынады. Статикалық код анализаторын енгізу мәселесі бірінші кезекте қалай туындайтынын, бұл мәселені қалай жеңуге болатынын және техникалық қарызды біртіндеп қалай ауыртпалықсыз жоюға болатынын қарастырайық.
Мәселелер
Статикалық анализаторды іске қосу және оның қалай жұмыс істейтінін көру әдетте қиын емес []. Сіз кодта қызықты қателерді немесе тіпті қорқынышты ықтимал осалдықтарды көре аласыз. Сіз тіпті бір нәрсені түзете аласыз, бірақ содан кейін көптеген бағдарламашылар бас тартады.
Барлық статикалық анализаторлар жалған позитивтер шығарады. Бұл статикалық кодты талдау әдістемесінің ерекшелігі және бұл туралы ештеңе істеу мүмкін емес. Жалпы жағдайда бұл Райс теоремасымен расталғандай шешілмейтін мәселе []. Машиналық оқыту алгоритмдері де көмектеспейді []. Егер адам осы немесе басқа кодтың дұрыс емес екенін әрдайым айта алмаса да, оны бағдарламадан күтпеу керек :).
Статикалық анализатор әлдеқашан конфигурацияланған болса, жалған позитивтер проблема емес:
- Қатесіз ережелер жиыны өшірілді;
- Кейбір маңызды емес диагностикалар өшірілді;
- Егер біз C немесе C++ туралы айтатын болсақ, онда мұндай макростар қолданылған әрбір жерде пайдасыз ескертулердің пайда болуына әкелетін нақты құрылымдарды қамтитын макростар белгіленеді;
- Жүйе функцияларына ұқсас әрекеттерді орындайтын меншікті функциялар белгіленген (өзінің аналогы memcpy немесе printf) [];
- Пікірлер арқылы жалған позитивтер арнайы өшіріледі;
- Тағыда басқа.
Бұл жағдайда біз шамамен 10-15% жалған оң көрсеткішті күтуге болады []. Басқаша айтқанда, анализатордың 9 ескертуінің 10-ы кодтағы нақты ақаулықты немесе кем дегенде «өте иісті кодты» көрсетеді. Келісіңіз, бұл сценарий өте жағымды, ал анализатор бағдарламашының нағыз досы.
Шындығында, үлкен жобада бастапқы сурет мүлдем басқаша болады. Анализатор бұрынғы код үшін жүздеген немесе мыңдаған ескертулер шығарады. Бұл ескертулердің қайсысы маңызды, қайсысы маңызды емес екенін тез түсіну мүмкін емес. Осы ескертулердің барлығымен отыру және айналысуды бастау қисынсыз, өйткені бұл жағдайда негізгі жұмыс бірнеше күн немесе апта бойы тоқтайды. Әдетте, команда мұндай сценарийді көтере алмайды. Сондай-ақ өзгерістер тарихын бұзатын көптеген айырмашылықтар болады. Кодтағы көптеген фрагменттерді жылдам жаппай өңдеу сөзсіз жаңа әріптер мен қателерге әкеледі.
Ең бастысы, ескертулерге қарсы күрестегі мұндай ерліктің мағынасы жоқ. Жоба көптеген жылдар бойы сәтті жұмыс істеп келе жатқандықтан, ондағы маңызды қателердің көпшілігі түзетілгенімен келісесіз. Иә, бұл түзетулер өте қымбат болды, жөндеуге тура келді, қателер туралы теріс пайдаланушы пікірлерін алды және т.б. Статикалық анализатор кодтау кезеңінде осы қателердің көбін тез және арзан түзетуге көмектеседі. Бірақ қазіргі уақытта қандай да бір жолмен бұл қателер түзетілді және анализатор негізінен ескі кодтағы маңызды емес қателерді анықтайды. Бұл кодты қолдануға болмайды, ол өте сирек қолданылады және ондағы қате елеулі салдарға әкелмеуі мүмкін. Мүмкін бір жерде түйменің көлеңкесі дұрыс емес түс болуы мүмкін, бірақ бұл ешкімнің өнімді пайдалануына кедергі келтірмейді.
Әрине, кішігірім қателер де қателік болып табылады. Ал кейде қателік нақты осалдықты жасыруы мүмкін. Дегенмен, бәрінен бас тартып, өзін әрең көрсететін ақаулармен күресу үшін күндер/апталар өткізу күмәнді идея сияқты көрінеді.
Бағдарламашылар ескі жұмыс коды туралы осы ескертулердің бәрін қарайды, қараңыз, қараңыз ... Және олар ойлайды: біз статикалық талдаусыз жасай аламыз. Жаңа пайдалы функцияларды жазайық.
Өзінше, олар дұрыс. Олар алдымен осы ескертулердің барлығынан құтылу керек деп санайды. Сонда ғана олар код анализаторын тұрақты пайдаланудың пайдасын көре алады. Әйтпесе, жаңа ескертулер ескілерге батып кетеді және оларға ешкім назар аудармайды.
Бұл компилятордың ескертулерімен бірдей ұқсастық. Олар компиляторлық ескертулердің санын 0-де сақтауды ұсынатыны бекер емес. Егер 1000 ескерту болса, 1001 болғанда, оған ешкім назар аудармайды және бұл ең жаңа ескертуді қайдан іздеу керек екені белгісіз.
Бұл оқиғадағы ең нашар нәрсе - егер жоғарыдан біреу сізді статикалық код талдауын қолдануға мәжбүрлесе. Бұл команданың мотивациясын төмендетеді, өйткені олардың көзқарасы бойынша тек жолға түсетін қосымша бюрократиялық күрделілік болады. Анализатордың есептеріне ешкім қарамайды және барлық пайдалану тек «қағазда» болады. Анау. Ресми түрде талдау DevOps процесіне енгізілген, бірақ іс жүзінде бұл ешкімге пайда әкелмейді. Біз конференцияға қатысушылардан стендтерде егжей-тегжейлі әңгімелер естідік. Мұндай тәжірибе бағдарламашыларды статикалық талдау құралдарын ұзақ уақыт бойы, егер мәңгілік болмаса, пайдаланудан бас тартуы мүмкін.
Техникалық қарызды жүзеге асыру және жою
Шындығында, тіпті үлкен ескі жобаға статикалық талдауды енгізуде қиын немесе қорқынышты ештеңе жоқ.
CI / CD
Сонымен қатар, анализатор бірден үздіксіз даму процесінің бөлігі болуы мүмкін. Мысалы, PVS-Studio дистрибутивінде есепті қажетті пішімде ыңғайлы көруге арналған утилиталар және кодтың проблемалық бөлімдерін жазған әзірлеушілерге хабарландырулар бар. CI/CD жүйелерінен PVS-Studio-ны іске қосуға көбірек қызығушылық танытатындар үшін мен сізге сәйкес келетіндермен танысуды ұсынамын. құжаттар мен мақалалар топтамасы:
Бірақ кодты талдау құралдарын енгізудің алғашқы кезеңдерінде жалған позитивтердің көп саны туралы мәселеге оралайық.
Қолданыстағы техникалық қарызды түзету және жаңа ескертулермен жұмыс жасау
Қазіргі коммерциялық статикалық анализаторлар жаңа немесе өзгертілген кодта пайда болатын жаңа ескертулерді ғана зерттеуге мүмкіндік береді. Бұл механизмнің жүзеге асуы әртүрлі, бірақ мәні бір. PVS-Studio статикалық анализаторында бұл функция келесідей жүзеге асырылады.
Статикалық талдауды пайдалануды жылдам бастау үшін PVS-Studio пайдаланушыларына ескертулерді жаппай басу механизмін пайдалануды ұсынамыз []. Жалпы идея мынадай. Пайдаланушы анализаторды іске қосып, көптеген ескертулер алды. Көптеген жылдар бойы әзірленіп келе жатқан жоба тірі, дамып, ақша тауып жатқандықтан, есепте сыни ақауларды көрсететін ескертулер көп болмайды. Басқаша айтқанда, маңызды қателер қымбатырақ әдістерді қолдану арқылы немесе тұтынушылардың пікірлері арқасында әлдеқашан түзетілді. Тиісінше, анализатор қазіргі уақытта тапқан барлық нәрселерді техникалық қарыз деп санауға болады, оны дереу жоюға тырысу мүмкін емес.
Сіз PVS-Studio-ға бұл ескертулерді әзірге маңызды емес деп санауға болады (техникалық қарызды кейінірек сақтаңыз) және ол оларды енді көрсетпейді. Анализатор арнайы файл жасайды, онда ол әлі қызық емес қателер туралы ақпаратты сақтайды. Енді PVS-Studio тек жаңа немесе өзгертілген код үшін ескертулер береді. Оның үстіне, мұның бәрі ақылды түрде жүзеге асырылады. Егер, мысалы, бастапқы код файлының басына бос жол қосылса, онда анализатор шын мәнінде ештеңе өзгермегенін түсінеді және үнсіз қалады. Бұл белгілеу файлын нұсқаны басқару жүйесіне қоюға болады. Файл үлкен, бірақ бұл проблема емес, өйткені оны жиі сақтаудың қажеті жоқ.
Енді барлық бағдарламашылар тек жаңа немесе өзгертілген кодқа қатысты ескертулерді көреді. Осылайша, сіз келесі күннен бастап анализаторды қолдана бастай аласыз. Ал сіз кейінірек техникалық қарызға оралып, қателерді бірте-бірте түзеп, анализаторды конфигурациялай аласыз.
Осылайша, үлкен ескі жобада анализаторды енгізудің бірінші мәселесі шешілді. Енді техникалық қарызды не істеу керектігін анықтайық.
Қателерді түзету және рефакторингтер
Ең қарапайым және табиғи нәрсе - анализатордың жаппай басылған ескертулерін талдау үшін біраз уақыт бөлу және олармен бірте-бірте күресу. Бір жерде кодтағы қателерді түзету керек, бір жерде анализаторға кодтың проблемалық емес екенін айту үшін рефактор керек. Қарапайым мысал:
if (a = b)Көптеген C++ компиляторлары мен анализаторлары мұндай кодқа шағымданады, өйткені олардың шын мәнінде жазғысы келетін ықтималдығы жоғары. (a == b). Бірақ айтылмаған келісім бар және бұл әдетте құжаттамада атап өтіледі, егер қосымша жақшалар болса, онда бағдарламашы мұндай кодты әдейі жазған деп есептеледі және ант берудің қажеті жоқ. Мысалы, диагностикаға арналған PVS-Studio құжаттамасында келесі жол дұрыс және қауіпсіз деп есептелетіні анық жазылған:
if ((a = b))Тағы бір мысал. Бұл C++ кодында ұмытылған ба? Үзіліс немесе жоқ?
case A:
foo();
case B:
bar();
break;PVS-Studio анализаторы осы жерде ескерту береді . Бұл қате болмауы мүмкін, бұл жағдайда атрибутты қосу арқылы талдаушыға кеңес беру керек немесе мысалы __атрибут__((түсіру)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Мұндай код өзгерістері қатені түзетпейді деп айтуға болады. Иә, бұл дұрыс, бірақ ол екі пайдалы нәрсе жасайды. Біріншіден, анализатор есебі жалған позитивтерден құтылады. Екіншіден, код оны ұстаумен айналысатын адамдар үшін түсінікті болады. Және бұл өте маңызды! Тек осы үшін кодты түсінікті және техникалық қызмет көрсетуді жеңілдету үшін кішігірім рефакторингтер жүргізген жөн. Анализатор «үзіліс» қажет пе, жоқ па түсінбейтіндіктен, басқа бағдарламашыларға да түсініксіз болады.
Қателерді түзетуге және рефакторингтерге қосымша, сіз анық жалған анализатордың ескертулерін баса аласыз. Кейбір маңызды емес диагностикаларды өшіруге болады. Мысалы, біреу ескертулерді мағынасыз деп санайды өзгермелі/қос мәндерді салыстыру туралы. Ал кейбіреулер оларды маңызды және зерттеуге лайық деп жіктейді []. Қандай ескертулер маңызды болып саналады және қайсысы жоқ екенін әзірлеу тобы шешеді.
Жалған ескертулерді болдырмаудың басқа жолдары бар. Мысалы, макробелгілеу туралы бұрын айтылған. Мұның бәрі құжаттамада толығырақ сипатталған. Ең бастысы, егер сіз жалған позитивтермен жұмыс істеуге бірте-бірте және жүйелі түрде жақындасаңыз, оларда ештеңе жоқ екенін түсіну. Қызық емес ескертулердің басым көпшілігі конфигурациядан кейін жоғалып кетеді және тек мұқият зерттеуді және кодтағы кейбір өзгерістерді қажет ететін орындар ғана қалады.
Сондай-ақ, біз әрқашан клиенттерімізге қандай да бір қиындықтар туындаған жағдайда PVS-Studio орнатуға көмектесеміз. Сонымен қатар, біз өзіміз жалған ескертулерді жойып, қателерді түзететін жағдайлар болды []. Қалай болғанда да, мен кеңейтілген ынтымақтастықтың бұл нұсқасы да мүмкін екенін айтуды жөн көрдім :).
Ратчет әдісі
Статикалық анализатордың ескертуін жою арқылы код сапасын біртіндеп жақсартудың тағы бір қызықты тәсілі бар. Қорытындысы - ескертулер саны тек азаюы мүмкін.
Статикалық анализатор берген ескертулер саны жазылады. Сапа қақпасы енді операциялар санын көбейтпейтін кодты ғана енгізуге болатын етіп конфигурацияланған. Нәтижесінде дабыл санын бірте-бірте азайту процесі анализаторды реттеуден және қателерді түзетуден басталады.
Егер адам аздап алдағысы келсе де, оның жаңа кодындағы ескертулерді жою арқылы емес, ескі үшінші тарап кодын жақсарту арқылы сапа қақпасынан өтуді шешсе де, бұл қорқынышты емес. Бәрібір ратчет бір бағытта айналады, бірте-бірте ақаулар саны азаяды. Адам өзінің жаңа кемшіліктерін түзеткісі келмесе де, көршілес кодта бірдеңені жақсартуға тура келеді. Бір сәтте ескертулер санын азайтудың оңай жолдары аяқталады және нақты қателер түзетілетін сәт келеді.
Бұл әдістеме Иван Пономаревтің өте қызықты мақаласында толығырақ сипатталған «", оны код сапасын жақсартуға қызығушылық танытатын кез келген адамға оқуды ұсынамын.
Мақала авторының осы тақырып бойынша баяндамасы да бар: «".
қорытынды
Осы мақаладан кейін оқырмандар статикалық талдау құралдарын көбірек қабылдайды және оларды әзірлеу процесіне енгізгісі келеді деп үміттенемін. Сұрақтарыңыз болса, біз әрқашан дайынбыз PVS-Studio статикалық анализаторының пайдаланушылары және оны жүзеге асыруға көмектеседі.
Статикалық талдау шынымен де ыңғайлы және пайдалы бола ма деген басқа да әдеттегі күмәндер бар. Мен осы күмәндердің көпшілігін «PVS-Studio статикалық код анализаторын әзірлеу процесіне енгізудің себептері» басылымында жоюға тырыстым.].
Назарларыңызға рахмет, келіңіздер және PVS-Studio анализаторын қолданып көріңіз.
Қосымша сілтемелер
- Андрей Карпов.
- Уикипедия. .
- Андрей Карпов, Виктория Ханиева. .
- PVS-Studio. Құжаттама. .
- Андрей Карпов. .
- PVS-Studio. Құжаттама. .
- Иван Андряшин. .
- Павел Еремеев, Святослав Размыслов. .
- Андрей Карпов. .
Егер сіз осы мақаланы ағылшын тілінде сөйлейтін аудиториямен бөліскіңіз келсе, аударма сілтемесін пайдаланыңыз: Андрей Карпов. .
Ақпарат көзі: www.habr.com