Statik kod analizatorunu sınamaq asandır. Ancaq onu həyata keçirmək, xüsusən də böyük bir köhnə layihənin hazırlanmasında bacarıq tələb edir. Səhv edilərsə, analizator iş əlavə edə, inkişafı ləngidə və komandanı motivasiya edə bilər. Statik analizin inkişaf prosesinə inteqrasiyasına necə düzgün yanaşmaq və onu CI/CD-nin bir hissəsi kimi istifadə etməyə başlayaq haqqında qısaca danışaq.
Giriş
Bu yaxınlarda diqqətimi nəşrə cəlb etdim "". Bir tərəfdən oxumağa dəyər yaxşı məqalədir. Digər tərəfdən, mənə elə gəlir ki, çoxlu irsi olan bir layihədə statik analizin ağrısız şəkildə həyata keçirilməsinə dair hələ də tam cavab vermir. Məqalədə deyilir ki, texniki borcu qəbul edə və yalnız yeni kod üzərində işləyə bilərsiniz, lakin sonradan bu texniki borcla nə edəcəyinə cavab yoxdur.
PVS-Studio komandamız bu mövzu ilə bağlı fikirlərini təqdim edir. Statik kod analizatorunun tətbiqi probleminin ilk növbədə necə yarandığına, bu problemi necə aradan qaldıracağına və texniki borcun ağrısız şəkildə tədricən aradan qaldırılmasına baxaq.
Məsələlər
Statik analizatorun necə işlədiyini işə salmaq və görmək adətən çətin deyil []. Kodda maraqlı səhvlər və ya hətta qorxulu potensial zəifliklər görə bilərsiniz. Siz hətta bir şeyi düzəldə bilərsiniz, amma sonra bir çox proqramçı imtina edir.
Bütün statik analizatorlar yanlış pozitiv çıxarır. Bu, statik kod təhlili metodologiyasının xüsusiyyətidir və bununla bağlı heç nə etmək olmaz. Ümumi halda bu, Rays teoremi ilə təsdiqləndiyi kimi həll olunmayan problemdir []. Maşın öyrənmə alqoritmləri də kömək etməyəcək []. İnsan hər zaman bu və ya digər kodun səhv olub-olmadığını deyə bilməsə belə, proqramdan bunu gözləməməlisiniz :).
Əgər statik analizator artıq konfiqurasiya olunubsa, yanlış pozitivlər problem yaratmır:
- Qeyri-müvafiq qayda dəstlərini söndürdü;
- Bəzi uyğun olmayan diaqnostika deaktiv edilib;
- Əgər biz C və ya C++ dillərindən danışırıqsa, onda belə makroların istifadə olunduğu hər yerdə faydasız xəbərdarlıqların görünməsinə səbəb olan xüsusi konstruksiyaları ehtiva edən makrolar qeyd olunur;
- Sistem funksiyalarına oxşar hərəkətləri yerinə yetirən öz funksiyaları qeyd olunur (öz analoqu memcpy və ya printf) [];
- Yanlış pozitivlər şərhlərdən istifadə edərək xüsusi olaraq deaktiv edilir;
- Və s.
Bu halda, biz təxminən 10-15% aşağı yalan müsbət nisbəti gözləmək olar []. Başqa sözlə, analizatorun 9 xəbərdarlığından 10-u koddakı real problemi və ya ən azı “kəskin qoxulu kodu” göstərəcək. Razılaşın, bu ssenari son dərəcə xoşdur və analizator proqramçının əsl dostudur.
Reallıqda böyük bir layihədə ilkin mənzərə tamamilə fərqli olacaq. Analizator köhnə kod üçün yüzlərlə və ya minlərlə xəbərdarlıq verir. Bu xəbərdarlıqlardan hansının aktual, hansının uyğun olmadığını tez başa düşmək mümkün deyil. Bütün bu xəbərdarlıqlarla oturub məşğul olmağa başlamaq məntiqsizdir, çünki bu vəziyyətdə əsas iş günlərlə və ya həftələrlə dayanacaq. Tipik olaraq, bir komanda belə bir ssenarini ödəyə bilməz. Dəyişiklik tarixini pozan çoxlu sayda fərqlər də olacaq. Və koddakı bu qədər fraqmentin sürətli kütləvi redaktəsi istər-istəməz yeni yazı xətaları və xətalarla nəticələnəcək.
Və ən əsası, xəbərdarlıqlara qarşı mübarizədə belə bir şücaət çox az məna kəsb edir. Razılaşın ki, layihə uzun illər uğurla fəaliyyət göstərdiyindən, ondakı kritik səhvlərin çoxu artıq düzəldilib. Bəli, bu düzəlişlər çox bahalı idi, sazlanmalı idi, səhvlər haqqında mənfi istifadəçi rəyi aldı və s. Statik analizator bu səhvlərin çoxunu kodlaşdırma mərhələsində tez və ucuz şəkildə düzəltməyə kömək edəcək. Amma hazırda bu və ya digər şəkildə bu xətalar aradan qaldırılıb və analizator əsasən köhnə kodda kritik olmayan səhvləri aşkar edir. Bu kod istifadə olunmaya bilər, çox nadir hallarda istifadə edilə bilər və onda bir səhv nəzərə çarpan nəticələrə səbəb olmaya bilər. Ola bilsin ki, haradasa düymənin kölgəsi yanlış rəngdədir, lakin bu, heç kimin məhsuldan istifadəsinə mane olmur.
Təbii ki, kiçik səhvlər belə yenə də səhvdir. Və bəzən bir səhv real zəifliyi gizlədə bilər. Bununla belə, hər şeydən vaz keçərək, özünü çox az büruzə verən qüsurlarla məşğul olmaq üçün günlər/həftələr keçirmək şübhəli bir fikir kimi görünür.
Proqramçılar baxır, baxır, köhnə iş kodu ilə bağlı bütün bu xəbərdarlıqlara baxır... Və düşünürlər: statik analiz olmadan da edə bilərik. Gəlin bəzi yeni faydalı funksiyalar yazaq.
Özlərinə görə haqlıdırlar. Fikirləşirlər ki, əvvəlcə bütün bu xəbərdarlıqlardan birtəhər yaxa qurtarmaq lazımdır. Yalnız bundan sonra onlar kod analizatorunun müntəzəm istifadəsindən faydalana biləcəklər. Əks halda, yeni xəbərdarlıqlar sadəcə olaraq köhnələrin içində boğulacaq və heç kim onlara əhəmiyyət verməyəcək.
Bu, kompilyator xəbərdarlıqları ilə eyni analogiyadır. Səbəbsiz deyil ki, onlar kompilyator xəbərdarlıqlarının sayını 0-da saxlamağı tövsiyyə edirlər.Əgər 1000 xəbərdarlıq varsa, 1001 olanda heç kim buna əhəmiyyət verməyəcək və bu ən yeni xəbərdarlığı harada axtarmaq lazım olduğu bəlli deyil.
Bu hekayədəki ən pis şey, yuxarıdan kimsənin sizi statik kod analizindən istifadə etməyə məcbur etməsidir. Bu, komandanı yalnız ruhdan salacaq, çünki onların nöqteyi-nəzərindən əlavə bürokratik mürəkkəblik yaranacaq ki, bu da yalnız maneə törədir. Heç kim analizatorun hesabatlarına baxmayacaq və bütün istifadə yalnız "kağız üzərində" olacaq. Bunlar. Formal olaraq, təhlil DevOps prosesində qurulur, lakin praktikada bunun heç kimə faydası yoxdur. Biz konfrans iştirakçılarından stendlərdə ətraflı hekayələr eşitdik. Belə bir təcrübə proqramçıları statik analiz alətlərindən həmişəlik olmasa da, uzun müddət istifadə etməkdən çəkindirə bilər.
Texniki borcun həyata keçirilməsi və aradan qaldırılması
Əslində, hətta böyük bir köhnə layihədə statik analizin tətbiqi ilə bağlı çətin və ya qorxulu bir şey yoxdur.
CI / CD
Üstəlik, analizator dərhal davamlı inkişaf prosesinin bir hissəsinə çevrilə bilər. Məsələn, PVS-Studio paylanması hesabata lazım olan formatda rahat baxmaq üçün kommunal proqramları və kodun problemli hissələrini yazan tərtibatçılara bildirişləri ehtiva edir. CI/CD sistemlərindən PVS-Studio-nu işə salmaqda daha çox maraqlananlar üçün sizə müvafiq proqramlarla tanış olmağı tövsiyə edirəm. sənədlər və bir sıra məqalələr:
Lakin gəlin kod analizi alətlərinin tətbiqinin ilk mərhələlərində çoxlu sayda yanlış pozitivlər məsələsinə qayıdaq.
Mövcud texniki borcun düzəldilməsi və yeni xəbərdarlıqlarla məşğul olmaq
Müasir kommersiya statik analizatorları yalnız yeni və ya dəyişdirilmiş kodda görünən yeni xəbərdarlıqları öyrənməyə imkan verir. Bu mexanizmin həyata keçirilməsi müxtəlifdir, lakin mahiyyət eynidir. PVS-Studio statik analizatorunda bu funksionallıq aşağıdakı kimi həyata keçirilir.
Statik analizdən tez istifadə etməyə başlamaq üçün PVS-Studio istifadəçilərinə xəbərdarlıqların kütləvi şəkildə basdırılması mexanizmindən istifadə etməyi təklif edirik []. Ümumi fikir aşağıdakı kimidir. İstifadəçi analizatoru işə saldı və bir çox xəbərdarlıq aldı. Uzun illər inkişafda olan bir layihə canlı olduğundan, inkişaf etməkdə və pul qazandığından, çox güman ki, hesabatda kritik qüsurları göstərən bir çox xəbərdarlıq olmayacaq. Başqa sözlə, kritik səhvlər artıq bu və ya digər şəkildə daha bahalı metodlardan istifadə etməklə və ya müştərilərin rəyləri sayəsində aradan qaldırılıb. Müvafiq olaraq, analizatorun hazırda tapdığı hər şey texniki borc hesab edilə bilər, onu dərhal aradan qaldırmağa çalışmaq qeyri-mümkündür.
Siz PVS-Studio-ya deyə bilərsiniz ki, bu xəbərdarlıqları hələlik əhəmiyyətsiz hesab etsin (texniki borcu sonraya saxla) və o, artıq onları göstərməyəcək. Analizator hələ maraqlı olmayan səhvlər haqqında məlumatı saxladığı xüsusi fayl yaradır. İndi PVS-Studio yalnız yeni və ya dəyişdirilmiş kod üçün xəbərdarlıq edəcək. Üstəlik, bütün bunlar ağıllı şəkildə həyata keçirilir. Məsələn, mənbə kodu faylının əvvəlinə boş sətir əlavə edilərsə, o zaman analizator başa düşür ki, əslində heç nə dəyişməyib və susmağa davam edəcək. Bu işarələmə faylı versiyaya nəzarət sisteminə daxil edilə bilər. Fayl böyükdür, lakin bu problem deyil, çünki onu tez-tez saxlamağın mənası yoxdur.
İndi bütün proqramçılar yalnız yeni və ya dəyişdirilmiş kodla bağlı xəbərdarlıqları görəcəklər. Beləliklə, analizatordan, necə deyərlər, növbəti gündən istifadə etməyə başlaya bilərsiniz. Və daha sonra texniki borclara qayıda bilərsiniz və tədricən səhvləri düzəldə və analizatoru konfiqurasiya edə bilərsiniz.
Beləliklə, böyük bir köhnə layihədə analizatorun tətbiqi ilə bağlı ilk problem həll edildi. İndi texniki borcla nə edəcəyimizi anlayaq.
Baq düzəlişləri və refaktorinqlər
Ən sadə və ən təbii şey, kütləvi şəkildə basdırılmış analizator xəbərdarlıqlarını təhlil etmək və tədricən onlarla məşğul olmaq üçün bir az vaxt ayırmaqdır. Haradasa koddakı səhvləri düzəltməli, haradasa analizatora kodun problemli olmadığını bildirmək üçün refaktor etməlisiniz. Sadə misal:
if (a = b)Əksər C++ kompilyatorları və analizatorları bu koddan şikayətlənirlər, çünki onların həqiqətən yazmaq istəməsi ehtimalı yüksəkdir. (a == b). Amma sözsüz razılaşma var və bu adətən sənədləşmədə qeyd olunur ki, əgər əlavə mötərizələr varsa, o zaman proqramçının belə kodu qəsdən yazdığı hesab edilir və söyüş söyməyə ehtiyac yoxdur. Məsələn, diaqnostika üçün PVS-Studio sənədlərində aşağıdakı xəttin düzgün və təhlükəsiz sayılacağı açıq şəkildə yazılmışdır:
if ((a = b))Başqa bir misal. Bu C++ kodunda unudulubmu? sındırmaq ya yox?
case A:
foo();
case B:
bar();
break;PVS-Studio analizatoru burada xəbərdarlıq edəcək . Bu, xəta olmaya bilər, bu halda atribut əlavə etməklə təhlilçiyə ipucu verməlisiniz və ya məsələn __atribut__((sonra)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;Demək olar ki, bu cür kod dəyişiklikləri səhvi düzəltmir. Bəli, bu doğrudur, lakin iki faydalı iş görür. Birincisi, analizator hesabatı yanlış pozitivlərdən xilas olur. İkincisi, kodun saxlanması ilə məşğul olan insanlar üçün daha başa düşülən olur. Və bu çox vacibdir! Yalnız bunun üçün kodu daha aydın və saxlanmasını asanlaşdırmaq üçün kiçik refaktorinqlər aparmağa dəyər. Analizator "fasilə" lazım olub-olmadığını başa düşmədiyi üçün digər proqramçılar üçün də aydın olmayacaq.
Səhvlərin düzəldilməsi və refaktorinqlərə əlavə olaraq, açıq-aydın yalançı analizator xəbərdarlıqlarını xüsusi olaraq yatıra bilərsiniz. Bəzi uyğun olmayan diaqnostikalar deaktiv edilə bilər. Məsələn, kimsə xəbərdarlıqların mənasız olduğunu düşünür float/ikiqat dəyərlərin müqayisəsi haqqında. Bəziləri isə onları vacib və öyrənilməyə layiq []. Hansı xəbərdarlıqların uyğun, hansının olmadığı isə inkişaf qrupunun qərarından asılıdır.
Yanlış xəbərdarlıqların qarşısını almaq üçün başqa yollar da var. Məsələn, əvvəllər makro işarələmə haqqında danışıldı. Bütün bunlar sənədlərdə daha ətraflı təsvir edilmişdir. Ən əsası başa düşmək lazımdır ki, əgər yalnış pozitivlərlə işləməyə tədricən və sistematik şəkildə yanaşsanız, onların heç bir qəbahəti yoxdur. Maraqsız xəbərdarlıqların böyük əksəriyyəti konfiqurasiyadan sonra yox olur və yalnız həqiqətən diqqətli öyrənmə və kodda bəzi dəyişikliklər tələb edən yerlər qalır.
Həmçinin, hər hansı bir çətinlik yaranarsa, biz həmişə müştərilərimizə PVS-Studio-nun qurulmasında kömək edirik. Üstəlik, yanlış xəbərdarlıqları özümüz aradan qaldırdığımız və səhvləri düzəltdiyimiz hallar oldu []. Hər halda, uzunmüddətli əməkdaşlıq üçün bu variantın da mümkün olduğunu qeyd etmək qərarına gəldim :).
Ratchet üsulu
Statik analizator xəbərdarlığını aradan qaldıraraq kodun keyfiyyətini tədricən yaxşılaşdırmaq üçün başqa maraqlı bir yanaşma var. Əsas odur ki, xəbərdarlıqların sayı yalnız azala bilər.
Statik analizator tərəfindən verilən xəbərdarlıqların sayı qeyd olunur. Keyfiyyət qapısı elə konfiqurasiya edilmişdir ki, indi yalnız əməliyyatların sayını artırmayan kodu daxil edə bilərsiniz. Nəticədə, siqnalların sayının tədricən azaldılması prosesi analizatorun tənzimlənməsi və səhvlərin düzəldilməsi ilə başlayır.
Bir insan bir az fırıldaq etmək istəsə və yeni kodundakı xəbərdarlıqları aradan qaldırmaqla deyil, köhnə üçüncü tərəf kodunu təkmilləşdirməklə keyfiyyət qapısından keçməyə qərar versə belə, bu qorxulu deyil. Eyni zamanda, cırcır bir istiqamətdə fırlanır və tədricən qüsurların sayı azalacaq. Bir şəxs özünün yeni qüsurlarını düzəltmək istəməsə belə, yenə də qonşu kodda nəyisə təkmilləşdirməli olacaq. Bir nöqtədə, xəbərdarlıqların sayını azaltmağın asan yolları sona çatır və real səhvlərin düzəldiləcəyi bir məqam gəlir.
Bu metodologiya İvan Ponomarevin çox maraqlı məqaləsində daha ətraflı təsvir edilmişdir.", kod keyfiyyətinin yaxşılaşdırılması ilə maraqlanan hər kəsə oxumağı tövsiyə edirəm.
Məqalə müəllifinin bu mövzuda hesabatı da var: "".
Nəticə
Ümid edirəm ki, bu məqalədən sonra oxucular statik analiz alətlərini daha çox qəbul edəcək və onları inkişaf prosesinə tətbiq etmək istəyəcəklər. Hər hansı bir sualınız varsa, biz həmişə hazırıq PVS-Studio statik analizatorumuzun istifadəçiləri və onun həyata keçirilməsində kömək edin.
Statik analizin həqiqətən rahat və faydalı ola biləcəyinə dair başqa tipik şübhələr də var. Bu şübhələrin əksəriyyətini “PVS-Studio statik kod analizatorunu inkişaf prosesinə daxil etməyin səbəbləri” adlı nəşrdə dağıtmağa çalışdım.].
Diqqətiniz üçün təşəkkür edirəm və gəlin və PVS-Studio analizatorunu sınayın.
Əlavə bağlantılar
- Andrey Karpov.
- Vikipediya. .
- Andrey Karpov, Viktoriya Xaniyeva. .
- PVS-Studio. Sənədlər. .
- Andrey Karpov. .
- PVS-Studio. Sənədlər. .
- İvan Andryaşin. .
- Pavel Eremeev, Svyatoslav Razmıslov. .
- Andrey Karpov. .
Bu məqaləni ingilisdilli auditoriya ilə bölüşmək istəyirsinizsə, tərcümə linkindən istifadə edin: Andrey Karpov. .
Mənbə: www.habr.com