Статик кодын анализаторыг туршиж үзэхэд хялбар байдаг. Гэхдээ үүнийг хэрэгжүүлэхийн тулд, ялангуяа хуучин том төслийг боловсруулахад ур чадвар шаарддаг. Хэрэв буруу хийсэн бол анализатор нь ажил нэмж, хөгжлийг удаашруулж, багийн урам зоригийг бууруулж болно. Статик шинжилгээг хөгжүүлэх үйл явцад хэрхэн зөв зохистойгоор хандаж, CI/CD-ийн нэг хэсэг болгон ашиглаж эхлэх талаар товч ярилцъя.
Танилцуулга
Саяхан миний анхаарлыг нийтлэлд татсан "". Нэг талаас, энэ нь танилцах нь зүйтэй сайн нийтлэл юм. Нөгөө талаар, энэ нь маш их төсөлд статик шинжилгээ хэрхэн өвдөлтгүй хэрэгжүүлэх талаар бүрэн хариулт өгөөгүй хэвээр байх шиг байна. Энэ нийтлэлд та техникийн өрийг хүлээн зөвшөөрч, зөвхөн шинэ код дээр ажиллах боломжтой гэж бичсэн боловч дараа нь энэ техникийн өрийг яах вэ гэсэн хариулт алга байна.
Манай PVS-Studio баг энэ сэдвээр өөрийн үзэл бодлыг санал болгож байна. Статик кодын анализаторыг хэрэгжүүлэх асуудал эхний ээлжинд хэрхэн үүсч, энэ асуудлыг хэрхэн даван туулах, техникийн өрийг хэрхэн өвдөлтгүй аажмаар арилгах талаар авч үзье.
Асуудал
Статик анализаторыг ажиллуулж, хэрхэн ажиллаж байгааг харах нь ихэвчлэн хэцүү биш юм []. Та кодонд сонирхолтой алдаа эсвэл бүр аймшигтай эмзэг байдлыг харж болно. Та ямар нэг зүйлийг засч залруулж чадна, гэхдээ дараа нь олон програмистууд бууж өгдөг.
Бүх статик анализаторууд хуурамч эерэг үр дүн гаргадаг. Энэ бол статик кодын шинжилгээний аргачлалын онцлог бөгөөд энэ талаар юу ч хийж чадахгүй. Ерөнхий тохиолдолд энэ нь шийдэгдээгүй асуудал бөгөөд Райсын теоремоор батлагдсан []. Машин сургалтын алгоритмууд бас тус болохгүй []. Хэдийгээр хүн энэ эсвэл тэр код буруу эсэхийг үргэлж хэлж чадахгүй байсан ч програмаас үүнийг хүлээх ёсгүй :).
Хэрэв статик анализатор аль хэдийн тохируулагдсан бол худал эерэг гарах нь асуудал биш юм.
- Үл хамаарах дүрмийн багцыг идэвхгүй болгосон;
- Зарим хамааралгүй оношлогоо идэвхгүй болсон;
- Хэрэв бид C эсвэл C++-ийн тухай ярьж байгаа бол ийм макро ашигладаг газар бүрт хэрэггүй анхааруулга гарч ирдэг тусгай бүтэц агуулсан макронууд тэмдэглэгдсэн байдаг;
- Системийн функцтэй төстэй үйлдлүүдийг гүйцэтгэдэг өөрийн функцуудыг тэмдэглэсэн болно (өөрийн аналог memcpy буюу хэвлэх) [];
- Сэтгэгдэл ашиглан хуурамч эерэг мэдээллийг тусгайлан идэвхгүй болгосон;
- Тиймээ.
Энэ тохиолдолд бид 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-студио. Баримт бичиг. .
- Андрей Карпов. .
- PVS-студио. Баримт бичиг. .
- Иван Андряшин. .
- Павел Еремеев, Святослав Размыслов. .
- Андрей Карпов. .
Хэрэв та энэ нийтлэлийг англи хэлээр ярьдаг үзэгчидтэй хуваалцахыг хүсвэл орчуулгын холбоосыг ашиглана уу: Андрей Карпов. .
Эх сурвалж: www.habr.com