Миний анхааралд улам бүр нэмэгдэж буй статик шинжилгээний талаархи их хэмжээний материал намайг энэ нийтлэлийг бичихэд хүргэсэн. Нэгдүгээрт, энэ , энэ нь нээлттэй эхийн төслүүдэд хэрэглүүрээс нь олж илрүүлсэн алдааны тоймуудын тусламжтайгаар Habré дээр өөрийгөө идэвхтэй сурталчилдаг. Саяхан PVS-studio хэрэгжсэн , мөн мэдээжийн хэрэг, IntelliJ IDEA программыг хөгжүүлэгчид, түүний суурилуулсан анализатор нь Java-д орчин үеийн хамгийн дэвшилтэт хувилбар байж магадгүй юм. .
Ийм тоймыг уншиж байхдаа бид ид шидийн үрлийн тухай ярьж байгаа мэт мэдрэмж төрдөг: товчлуур дээр дар, энд байна - таны нүдний өмнө байгаа согогуудын жагсаалт. Анализаторууд сайжрах тусам алдаанууд автоматаар олдох бөгөөд эдгээр роботуудын сканнердсан бүтээгдэхүүн бидний хүчин чармайлтгүйгээр улам сайжирч байх шиг байна.
Гэхдээ ид шидийн үрэл гэж байдаггүй. "Манай роботын олж чадах зүйлс" гэх мэт нийтлэлүүдэд ихэвчлэн ярьдаггүй зүйлсийн талаар ярихыг хүсч байна: анализаторууд юу хийж чадахгүй, програм хангамжийг хүргэх үйл явцад тэдний бодит үүрэг, байр суурь юу вэ, тэдгээрийг хэрхэн зөв хэрэгжүүлэх вэ? .
Ратчет (эх сурвалж: ).
Статик анализатор хэзээ ч хийж чадахгүй зүйл
Практик талаасаа эх кодын шинжилгээ гэж юу вэ? Бид зарим эх кодыг оролт, гаралт болгон богино хугацаанд (туршилт хийхээс хамаагүй богино хугацаанд) системийнхээ талаар зарим мэдээллийг олж авдаг. Суурь бөгөөд математикийн хувьд даван туулах боломжгүй хязгаарлалт нь бид ийм аргаар зөвхөн нэлээд нарийн ангиллын мэдээллийг олж авах боломжтой юм.
Статик шинжилгээг ашиглан шийдвэрлэх боломжгүй асуудлын хамгийн алдартай жишээ бол : Энэ нь программ нь хязгаарлагдмал хугацаанд давтагдах эсвэл дуусах эсэхийг эх кодоос нь тодорхойлох ерөнхий алгоритм боловсруулах боломжгүйг нотлох теорем юм. Энэ теоремын өргөтгөл нь , энэ нь тооцоолж болохуйц функцүүдийн үл хамаарах шинж чанаруудын хувьд дурын програм нь ийм шинж чанартай функцийг үнэлж байгаа эсэхийг тодорхойлох нь алгоритмын хувьд шийдвэрлэх боломжгүй асуудал юм. Жишээлбэл, анализ хийж буй програм нь бүхэл тооны квадратыг тооцдог алгоритмын хэрэгжилт мөн эсэхийг ямар ч эх кодоос тодорхойлох анализатор бичих боломжгүй юм.
Тиймээс статик анализаторын үйл ажиллагаа нь даван туулах боломжгүй хязгаарлалттай байдаг. Статик анализатор нь бүх тохиолдолд, жишээлбэл, null утгыг зөвшөөрдөг хэл дээр "нэг заагч үл хамаарах зүйл" тохиолдох, эсвэл бүх тохиолдолд "болсныг тодорхойлох боломжгүй" гэсэн зүйлийг хэзээ ч илрүүлж чадахгүй. шинж чанар олдсонгүй" гэж динамикаар бичсэн хэлээр бичнэ. Хамгийн дэвшилтэт статик анализаторын хийж чадах зүйл бол онцгой тохиолдлуудыг тодруулах явдал бөгөөд тэдгээрийн тоо нь таны эх кодтой холбоотой бүх асуудлуудын дунд хэтрүүлэггүйгээр хувин дээр дусал юм.
Статик дүн шинжилгээ нь алдаа олох тухай биш юм
Дээрхээс дүгнэлт нь: статик дүн шинжилгээ нь програмын согогийн тоог бууруулах хэрэгсэл биш юм. Танай төсөлд анх удаа хэрэглэгдэх үед энэ нь кодын "сонирхолтой" газруудыг олох болно, гэхдээ таны програмын чанарт нөлөөлөх ямар ч согогийг олохгүй байх магадлалтай.
Анализаторын автоматаар илрүүлсэн согогийн жишээнүүд нь гайхалтай боловч эдгээр жишээнүүд нь том хэмжээний кодын санг сканнердсанаар олдсон гэдгийг мартаж болохгүй. Үүнтэй ижил зарчмаар олон тооны данс дээр хэд хэдэн энгийн нууц үгийг туршиж үзэх боломжтой хакерууд эцэст нь энгийн нууц үгтэй дансуудыг олдог.
Энэ нь статик шинжилгээг ашиглах ёсгүй гэсэн үг үү? Мэдээж үгүй! Яг ижил шалтгаанаар шинэ нууц үг бүрийг "энгийн" нууц үгүүдийн жагсаалтад оруулсан эсэхийг шалгах хэрэгтэй.
Статик шинжилгээ нь алдаа хайхаас илүү юм
Үнэн хэрэгтээ, дүн шинжилгээ хийх замаар бодитоор шийдсэн асуудлууд илүү өргөн хүрээтэй байдаг. Эцсийн эцэст, статик шинжилгээ нь эх кодыг эхлүүлэхээс өмнө хийсэн аливаа шалгалт юм. Та дараах зүйлсийг хийж болно:
- Энэ үгийн өргөн утгаараа кодчиллын хэв маягийг шалгах. Үүнд форматыг шалгах, хоосон/нэмэлт хаалт ашиглах, мөрийн тоо/ аргын мөчлөгийн нарийн төвөгтэй байдал гэх мэт хэмжигдэхүүн дээр босго тогтоох зэрэг - кодын уншигдах, хадгалахад саад учруулж болзошгүй бүх зүйл орно. Java хэл дээр ийм хэрэгсэл нь Checkstyle, Python дээр - flake8 юм. Энэ ангиллын программуудыг ихэвчлэн "linters" гэж нэрлэдэг.
- Зөвхөн гүйцэтгэх кодыг шинжлэх боломжгүй. JSON, YAML, XML, .properties гэх мэт нөөц файлууд хүчинтэй эсэхийг автоматаар шалгах боломжтой (мөн байх ёстой!). Эцсийн эцэст, туршилтын гүйцэтгэл эсвэл ажиллах хугацаа гэхээсээ илүүтэйгээр татах хүсэлтийг автоматаар баталгаажуулах эхний үе шатанд зарим хосгүй ишлэлээс болж JSON бүтэц эвдэрсэн гэдгийг олж мэдсэн нь дээр үү? Тохиромжтой хэрэгслүүд байдаг: жишээ нь. , .
- Эмхэтгэл (эсвэл динамик програмчлалын хэлийг задлан шинжлэх) нь статик шинжилгээний нэг төрөл юм. Ерөнхийдөө хөрвүүлэгчид нь эх кодын чанартай холбоотой асуудлуудыг илтгэх анхааруулга гаргах чадвартай бөгөөд үүнийг үл тоомсорлож болохгүй.
- Заримдаа эмхэтгэл нь зөвхөн гүйцэтгэх кодыг эмхэтгэхээс илүү байдаг. Жишээлбэл, хэрэв танд форматын баримт бичиг байгаа бол , дараа нь үүнийг HTML/PDF болгон хувиргах мөчид AsciiDoctor зохицуулагч () тухайлбал, эвдэрсэн дотоод холбоосуудын талаар анхааруулга өгч болно. Энэ нь баримт бичгийн өөрчлөлттэй хамт татах хүсэлтийг хүлээн авахгүй байх сайн шалтгаан юм.
- Үг үсгийн алдаа шалгах нь мөн статик шинжилгээний нэг төрөл юм. Хэрэгсэл нь зөвхөн баримт бичигт төдийгүй C/C++, Java, Python зэрэг програмчлалын янз бүрийн хэл дээрх програмын эх код (тайлбар болон үг хэллэг)-ийн зөв бичгийн алдааг шалгах чадвартай. Хэрэглэгчийн интерфэйс эсвэл баримт бичгийн зөв бичгийн алдаа нь бас алдаа юм!
- Тохиргооны тестүүд (тэдгээр нь юу болохыг харна уу. и тайлангууд) хэдийгээр pytest гэх мэт нэгжийн туршилтын хугацаанд гүйцэтгэгддэг боловч тэдгээрийг гүйцэтгэх явцад эх кодыг гүйцэтгэдэггүй тул статик шинжилгээний нэг төрөл юм.
Таны харж байгаагаар энэ жагсаалтаас алдаа хайх нь хамгийн чухал үүрэг гүйцэтгэдэггүй бөгөөд бусад бүх зүйлийг үнэгүй нээлттэй эх сурвалжийн хэрэгслээр ашиглах боломжтой.
Та төсөлдөө эдгээр статик анализын алийг нь ашиглах ёстой вэ? Мэдээжийн хэрэг, илүү их байх тусмаа сайн! Хамгийн гол нь үүнийг зөв хэрэгжүүлэх явдал бөгөөд үүнийг цаашид хэлэлцэх болно.
Хүргэлтийн шугам хоолой нь олон үе шаттай шүүлтүүр, статик шинжилгээ нь эхний шат юм
Тасралтгүй интеграцчлалын сонгодог зүйрлэл бол эх кодыг өөрчлөхөөс эхлээд үйлдвэрлэлд хүргэх хүртэлх урсгалыг өөрчлөх хоолой юм. Энэ дамжуулах хоолойн үе шатуудын стандарт дараалал дараах байдалтай байна.
- статик шинжилгээ
- эмхэтгэл
- нэгжийн туршилтууд
- интеграцийн тестүүд
- UI тестүүд
- гараар шалгах
Дамжуулах хоолойн N-р шатанд татгалзсан өөрчлөлтүүдийг N+1 шат руу шилжүүлэхгүй.
Яагаад яг ийм замаар, өөрөөр биш гэж? Дамжуулах хоолойн туршилтын хэсэгт шалгагчид сайн мэддэг туршилтын пирамидыг таних болно.
Туршилтын пирамид. Эх сурвалж: Мартин Фаулер.
Энэхүү пирамидын доод хэсэгт бичихэд хялбар, гүйцэтгэхэд хурдан, бүтэлгүйтэх хандлагагүй тестүүд байдаг. Тиймээс тэд илүү олон байх ёстой, тэд илүү олон кодыг хамарч, эхлээд гүйцэтгэх ёстой. Пирамидын дээд талд эсрэгээрээ байгаа тул интеграцийн болон UI тестийн тоог шаардлагатай хамгийн бага хэмжээнд хүртэл багасгах хэрэгтэй. Энэ гинжин хэлхээнд байгаа хүн бол хамгийн үнэтэй, удаан, найдваргүй нөөц учраас тэр хамгийн төгсгөлд байгаа бөгөөд өмнөх үе шатанд ямар нэгэн согог илрээгүй тохиолдолд л ажлыг гүйцэтгэдэг. Гэсэн хэдий ч туршилттай шууд холбоогүй хэсгүүдэд дамжуулах хоолойг барихад ижил зарчмуудыг ашигладаг!
Би олон үе шаттай ус шүүх систем хэлбэрээр аналогийг санал болгохыг хүсч байна. Бохир ус (гажигтай өөрчлөлтүүд) оролтод нийлүүлдэг; гаралтын үед бид бүх хүсээгүй бохирдуулагчийг устгасан цэвэр ус авах ёстой.
Олон үе шаттай шүүлтүүр. Эх сурвалж:
Та бүхний мэдэж байгаагаар цэвэрлэх шүүлтүүрүүд нь дараагийн каскад бүр бохирдуулагчийн илүү нарийн хэсгийг шүүж чаддаг байхаар хийгдсэн байдаг. Үүний зэрэгцээ бүдүүлэг цэвэршүүлэх каскадууд нь илүү өндөр дамжуулалттай, бага өртөгтэй байдаг. Бидний зүйрлэвэл, энэ нь оролтын чанарын хаалга нь илүү хурдан, эхлүүлэхэд бага хүчин чармайлт шаарддаг, үйл ажиллагааны хувьд өөрсдөө илүү мадаггүй зөв байдаг гэсэн үг бөгөөд энэ нь тэдгээрийг барих дараалал юм. Одоо бидний ойлгож байгаагаар зөвхөн хамгийн том согогийг арилгах чадвартай статик шинжилгээний үүрэг бол шүүлтүүрийн цувааны эхэн үеийн "шавар" сүлжээний үүрэг юм.
"Шавар шүүлтүүр" нь усыг ууж болдоггүйтэй адил статик шинжилгээ нь эцсийн бүтээгдэхүүний чанарыг сайжруулдаггүй. Гэсэн хэдий ч дамжуулах хоолойн бусад элементүүдтэй хамт түүний ач холбогдол нь тодорхой юм. Хэдийгээр олон үе шаттай шүүлтүүрт гаралтын үе шатууд нь оролтын үе шатуудын хийдэг бүх зүйлийг барьж авах чадвартай боловч оролтын үе шатгүйгээр зөвхөн нарийн цэвэршүүлэх үе шатуудыг хийх оролдлого нь ямар үр дагаварт хүргэх нь тодорхой юм.
"Шаврын урхи" -ын зорилго нь дараагийн каскадуудыг маш том согогоос ангижруулах явдал юм. Жишээлбэл, кодыг шалгаж байгаа хүн хамгийн багадаа буруу форматлагдсан код, тогтоосон кодчилолын стандартыг зөрчсөн (нэмэлт хаалт эсвэл хэт гүн үүрлэсэн салбар гэх мэт) зэргээс болж анхаарал сарниулах ёсгүй. NPE гэх мэт алдаануудыг нэгжийн туршилтаар илрүүлэх ёстой, гэхдээ тест хийхээс өмнө анализатор алдаа гарах нь гарцаагүй гэдгийг зааж өгсөн бол энэ нь түүнийг засахад ихээхэн хурдасгах болно.
Статик шинжилгээ нь яагаад хааяа хэрэглэвэл бүтээгдэхүүний чанарыг сайжруулдаггүй, мөн ноцтой согогтой өөрчлөлтүүдийг шүүж авахын тулд байнга ашиглах ёстой нь тодорхой болсон гэж би бодож байна. Статик анализатор ашигласнаар бүтээгдэхүүнийхээ чанар сайжирна уу гэсэн асуулт нь “Бохир цөөрмөөс авсан усыг коландаар дамжуулбал ундны чанар сайжрах уу?” гэдэгтэй ойролцоо асуулт юм.
Хуучин төсөл болгон хэрэгжүүлэх
Практик чухал асуулт: статик шинжилгээг "чанарын хаалга" болгон тасралтгүй нэгтгэх үйл явцад хэрхэн хэрэгжүүлэх вэ? Автомат туршилтын хувьд бүх зүйл тодорхой байна: олон тооны туршилтууд байдаг, тэдгээрийн аль нэг нь бүтэлгүйтсэн нь угсралт чанарын хаалгыг даваагүй гэж үзэх хангалттай шалтгаан юм. Статик шинжилгээний үр дүнд үндэслэн хаалгыг ижил аргаар суулгах оролдлого бүтэлгүйтэв: хуучин кодонд дүн шинжилгээ хийх олон анхааруулга байгаа тул та тэдгээрийг бүрмөсөн үл тоомсорлохыг хүсэхгүй байгаа ч бүтээгдэхүүний тээвэрлэлтийг зогсоох боломжгүй юм. Учир нь энэ нь анализаторын анхааруулгыг агуулдаг.
Анх удаа ашиглах үед анализатор нь аливаа төсөл дээр асар олон тооны анхааруулга үүсгэдэг бөгөөд тэдгээрийн дийлэнх нь бүтээгдэхүүний зөв үйл ажиллагаатай холбоогүй байдаг. Эдгээр бүх тайлбарыг нэг дор засах боломжгүй бөгөөд олон нь шаардлагагүй юм. Эцсийн эцэст, манай бүтээгдэхүүн бүхэлдээ статик шинжилгээг нэвтрүүлэхээс өмнө ажилладаг гэдгийг бид мэднэ!
Үүний үр дүнд ихэнх нь статик анализыг хааяа ашиглах, эсвэл угсрах явцад анализаторын тайлан гаргах үед зөвхөн мэдээллийн горимд ашигладаг. Энэ нь ямар ч дүн шинжилгээ хийгдээгүйтэй адил юм, учир нь хэрэв бидэнд олон анхааруулга байгаа бол кодыг өөрчлөх үед өөр (хэчнээн ноцтой байсан ч) гарч ирэх нь анзаарагдахгүй болно.
Чанарын хаалгыг нэвтрүүлэх дараах аргуудыг мэддэг.
- Нийт анхааруулгын тоо буюу анхааруулгын тоог кодын мөрийн тоонд хуваасан хязгаарлалтыг тогтоох. Энэ нь муу ажилладаг, учир нь ийм хаалга нь хязгаараас хэтрээгүй тохиолдолд шинэ согогтой өөрчлөлтүүдийг чөлөөтэй нэвтрүүлэх боломжийг олгодог.
- Тодорхой мөчид кодын бүх хуучин сэрэмжлүүлгийг үл тоомсорлож, шинэ сэрэмжлүүлэг гарах үед бүтээхээс татгалздаг. Энэ функцийг PVS-studio болон зарим онлайн эх сурвалжууд, жишээлбэл, Codacy хангадаг. Надад PVS студид ажиллах боломж байгаагүй, учир нь Codacy-тэй хийсэн туршлагын хувьд тэдний гол асуудал бол "хуучин" гэж юу болохыг, "шинэ" алдаа гэж юу болохыг тодорхойлох нь үргэлж ажилладаггүй нэлээд төвөгтэй алгоритм юм. зөв, ялангуяа файлуудыг их хэмжээгээр өөрчилсөн эсвэл нэрийг нь өөрчилсөн тохиолдолд. Миний туршлагаас харахад Codacy нь татах хүсэлтийн шинэ сэрэмжлүүлгийг үл тоомсорлож болох бөгөөд нэгэн зэрэг тухайн PR-ын кодын өөрчлөлттэй холбоогүй анхааруулгын улмаас татах хүсэлтийг дамжуулдаггүй.
- Миний бодлоор хамгийн үр дүнтэй шийдлийг номонд тайлбарласан болно "хэрэглэх арга". Үндсэн санаа нь статик шинжилгээний анхааруулгын тоо нь хувилбар бүрийн өмч бөгөөд зөвхөн нийт анхааруулгын тоог нэмэгдүүлэхгүй өөрчлөлтийг хийхийг зөвшөөрдөг.
Ратчет
Энэ нь дараах байдлаар ажилладаг:
- Эхний шатанд анализаторуудын олсон код дахь анхааруулгын тоог гаргах тухай мета өгөгдөлд тэмдэглэл хийдэг. Тиймээс, таныг дээд тал руу барих үед таны репозиторын менежер зүгээр л "7.0.2 хувилбар" биш, харин "7.0.2 хяналтын хэв маягийн анхааруулга агуулсан хувилбар 100500" гэж бичдэг. Хэрэв та дэвшилтэт репозиторын менежер (Artifactory гэх мэт) ашигладаг бол хувилбарынхаа мета өгөгдлийг хадгалахад хялбар байдаг.
- Одоо татах хүсэлт бүрийг бүтээхдээ үүссэн анхааруулгын тоог одоогийн хувилбарт байгаа анхааруулгын тоотой харьцуулдаг. Хэрэв PR нь энэ тоог нэмэгдүүлэхэд хүргэдэг бол код нь статик шинжилгээнд чанарын хаалгыг дамжуулдаггүй. Хэрэв анхааруулгын тоо буурах эсвэл өөрчлөгдөхгүй бол энэ нь дамждаг.
- Дараагийн хувилбар дээр дахин тооцоолсон анхааруулгын тоог хувилбарын мета өгөгдөлд дахин бүртгэнэ.
Тиймээс бага багаар боловч тогтвортой (ратчет ажиллах гэх мэт) анхааруулгын тоо тэг болох хандлагатай байна. Мэдээжийн хэрэг, шинэ сэрэмжлүүлгийг нэвтрүүлж, харин өөр хэн нэгнийг засч залруулах замаар системийг хуурч болно. Энэ нь хэвийн үзэгдэл юм, учир нь хол зайд энэ нь үр дүнг өгдөг: сэрэмжлүүлгийг дүрмээр бол дангаар нь биш, харин тодорхой төрлийн бүлэгт нэг дор засч, амархан арилгадаг бүх анхааруулгыг хурдан арилгадаг.
Энэхүү график нь ийм "ратчет" асаалттай зургаан сарын турш ажилласан Checkstyle-ийн нийт анхааруулгыг харуулж байна . Анхааруулгын тоо хэмжээ дарааллаар буурсан бөгөөд энэ нь бүтээгдэхүүн боловсруулахтай зэрэгцэн байгалийн жамаар болсон!
Би энэ аргын өөрчилсөн хувилбарыг ашиглаж, төслийн модуль болон шинжилгээний хэрэгслээр анхааруулгыг тусад нь тоолж, дараах байдлаар харагдах мета өгөгдөл бүхий YAML файлыг бий болгож байна:
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
Ямар ч дэвшилтэт CI системд ратчетыг залгаас болон гуравдагч талын хэрэгслүүдэд найдахгүйгээр статик шинжилгээний хэрэгсэл болгон ашиглаж болно. Анализатор бүр дүн шинжилгээ хийхэд хялбар энгийн текст эсвэл XML форматаар өөрийн тайланг гаргадаг. CI скриптэд шаардлагатай логикийг бичих л үлдлээ. Үүнийг Jenkins болон Artifactory дээр үндэслэсэн манай нээлттэй эхийн төслүүдээс хэрхэн хэрэгжүүлж байгааг харж болно буюу . Хоёр жишээ нь номын сангаас хамаарна : арга countWarnings() Checkstyle болон Spotbugs-ийн үүсгэсэн файлууд дахь xml хаягуудыг ердийн аргаар тоолдог compareWarningMaps() ижил ратчетыг хэрэгжүүлдэг бөгөөд аль нэг ангилалд анхааруулах тоо нэмэгдэхэд алдаа гаргадаг.
"Ратчет" -ын сонирхолтой хэрэглүүр нь aspell ашиглан тайлбар, текстийн үсэг, баримт бичгийн зөв бичгийн дүрмийг шинжлэх боломжтой юм. Таны мэдэж байгаагаар зөв бичгийн дүрмийг шалгахдаа стандарт толь бичигт үл мэдэгдэх бүх үгс буруу байдаггүй бөгөөд тэдгээрийг хэрэглэгчийн толь бичигт нэмж оруулах боломжтой. Хэрэв та төслийн эх кодын нэг хэсэг нь захиалгат толь бичиг хийвэл зөв бичгийн чанарын хаалгыг дараах байдлаар томъёолж болно: стандарт болон захиалгат толь бичигтэй aspell-ийг ажиллуулна. үсгийн алдаа олдохгүй.
Анализаторын хувилбарыг засахын ач холбогдлын талаар
Дүгнэж хэлэхэд, анхаарах зүйл бол хүргэх дамжуулах хоолойд шинжилгээг хэрхэн хэрэгжүүлж байгаагаас үл хамааран анализаторын хувилбарыг засах ёстой. Хэрэв та анализаторыг аяндаа шинэчлэхийг зөвшөөрвөл дараагийн татах хүсэлтийг угсарч байх үед шинэ согогууд нь кодын өөрчлөлттэй холбоогүй, харин шинэ анализатор илүү олон согогийг олох боломжтой болсонтой холбоотой шинэ согогууд гарч ирж магадгүй юм. Энэ нь таны татах хүсэлтийг хүлээн авах үйл явцыг эвдэх болно. Анализаторыг шинэчлэх нь ухамсартай үйлдэл байх ёстой. Гэсэн хэдий ч угсралтын бүрэлдэхүүн хэсэг бүрийн хувилбарыг хатуу бэхлэх нь ерөнхийдөө зайлшгүй шаардлагатай шаардлага бөгөөд тусдаа хэлэлцүүлгийн сэдэв юм.
үр дүн нь
- Статик шинжилгээ нь танд алдаа олохгүй бөгөөд нэг удаагийн хэрэглээний үр дүнд таны бүтээгдэхүүний чанарыг сайжруулахгүй. Чанарт эерэг нөлөө үзүүлэх нь зөвхөн хүргэх явцад байнга ашиглах замаар л хүрч чадна.
- Алдаа хайх нь шинжилгээний гол ажил биш бөгөөд ихэнх ашигтай функцуудыг нээлттэй эх сурвалжийн хэрэгслүүдэд ашиглах боломжтой.
- Хүргэлтийн шугамын эхний үе шатанд статик шинжилгээний үр дүнд үндэслэн хуучин кодын "ратчет" ашиглан чанарын хаалгыг хэрэгжүүлэх.
лавлагаа
- Кодын шинжилгээний янз бүрийн аргуудын талаар тайлан (зөвхөн статик биш!)
Эх сурвалж: www.habr.com