របៀបអនុវត្តកម្មវិធីវិភាគកូដឋិតិវន្តនៅក្នុងគម្រោងកេរ្តិ៍ដំណែលដោយមិនធ្វើឱ្យក្រុមមានការរំខាន

ការសាកល្បងប្រើឧបករណ៍វិភាគកូដឋិតិវន្តគឺងាយស្រួល។ ប៉ុន្តែ​ដើម្បី​អនុវត្ត​វា ជាពិសេស​ក្នុង​ការ​អភិវឌ្ឍ​គម្រោង​ចាស់​ធំ ជំនាញ​ត្រូវ​បាន​ទាមទារ។ ជាមួយនឹងវិធីសាស្រ្តខុស អ្នកវិភាគអាចបន្ថែមការងារ បន្ថយល្បឿននៃការអភិវឌ្ឍន៍ និងបំបាក់ទឹកចិត្តក្រុម។ ចូរយើងនិយាយដោយសង្ខេបអំពីរបៀបធ្វើសមាហរណកម្មនៃការវិភាគឋិតិវន្តឱ្យបានត្រឹមត្រូវទៅក្នុងដំណើរការអភិវឌ្ឍន៍ ហើយចាប់ផ្តើមប្រើវាជាផ្នែកមួយនៃ CI/CD ។

សេចក្តីណែនាំ

ថ្មីៗនេះ ការចាប់អារម្មណ៍របស់ខ្ញុំត្រូវបានទាក់ទាញការបោះពុម្ពចាប់ផ្តើមជាមួយនឹងការវិភាគឋិតិវន្ត ដោយមិនធ្វើឱ្យក្រុមលើសលប់"។ ម៉្យាងវិញទៀត នេះជាអត្ថបទដ៏ល្អដែលគួរស្វែងយល់។ ម្យ៉ាងវិញទៀត វាហាក់ដូចជាខ្ញុំដែលវាមិនបានផ្តល់ចម្លើយពេញលេញអំពីរបៀបអនុវត្តការវិភាគឋិតិវន្តដោយគ្មានការឈឺចាប់នៅក្នុងគម្រោងដែលមានកេរ្តិ៍ដំណែលច្រើន អត្ថបទនិយាយថា អ្នកអាចរស់នៅជាមួយបំណុលបច្ចេកទេស និងធ្វើការតែជាមួយកូដថ្មី ប៉ុន្តែមិនមានចម្លើយចំពោះអ្វីដែលត្រូវធ្វើជាមួយបំណុលបច្ចេកទេសនេះនៅពេលក្រោយ។

ក្រុមការងារ PVS-Studio របស់យើងផ្តល់នូវទស្សនៈផ្ទាល់ខ្លួនលើប្រធានបទនេះ។ សូមក្រឡេកមើលថាតើបញ្ហានៃការណែនាំអ្នកវិភាគកូដឋិតិវន្តកើតឡើងជាទូទៅរបៀបយកឈ្នះបញ្ហានេះនិងវិធីបំបាត់បំណុលបច្ចេកទេសបន្តិចម្តង ៗ ដោយគ្មានការឈឺចាប់។

បញ្ហា

តាមក្បួនវាមិនពិបាកក្នុងការចាប់ផ្តើម និងមើលពីរបៀបដែលឧបករណ៍វិភាគឋិតិវន្តដំណើរការ [1] អ្នកអាចឃើញកំហុសគួរឱ្យចាប់អារម្មណ៍នៅក្នុងកូដ ឬសូម្បីតែភាពងាយរងគ្រោះដែលអាចគួរឱ្យខ្លាច។ អ្នកអាចជួសជុលអ្វីមួយបាន ប៉ុន្តែបន្ទាប់មកអ្នកសរសេរកម្មវិធីជាច្រើនបានបោះបង់។

អ្នកវិភាគឋិតិវន្តទាំងអស់ផ្តល់ភាពវិជ្ជមានមិនពិត។ នេះគឺជាលក្ខណៈនៃវិធីសាស្រ្តវិភាគកូដឋិតិវន្ត ហើយគ្មានអ្វីអាចធ្វើបានអំពីវាទេ។ ក្នុងករណីទូទៅ នេះគឺជាបញ្ហាដែលមិនអាចដោះស្រាយបាន ដែលត្រូវបានបញ្ជាក់ដោយទ្រឹស្តីបទអង្ករ [2] ក្បួនដោះស្រាយការរៀនម៉ាស៊ីននឹងមិនជួយទាំង [3] ទោះបីជាមនុស្សម្នាក់មិនអាចប្រាប់បានថា កូដនេះ ឬកូដនោះខុសក៏ដោយ នោះអ្នកមិនគួររំពឹងពីកម្មវិធីនេះទេ :)

ភាពវិជ្ជមានក្លែងក្លាយមិនមែនជាបញ្ហាទេ ប្រសិនបើឧបករណ៍វិភាគឋិតិវន្តត្រូវបានកំណត់រចនាសម្ព័ន្ធរួចហើយ៖

• បិទសំណុំច្បាប់ហួសសម័យ;
• បិទការវិនិច្ឆ័យមិនពាក់ព័ន្ធមួយចំនួន;
• ប្រសិនបើយើងកំពុងនិយាយអំពី C ឬ C ++ នោះម៉ាក្រូត្រូវបានសម្គាល់ឡើងដែលមានរចនាសម្ព័ន្ធជាក់លាក់ដែលបណ្តាលឱ្យមានការព្រមានដែលគ្មានប្រយោជន៍លេចឡើងនៅគ្រប់កន្លែងដែលម៉ាក្រូបែបនេះត្រូវបានប្រើ។
• បានសម្គាល់មុខងារផ្ទាល់ខ្លួនដែលធ្វើសកម្មភាពស្រដៀងនឹងមុខងារប្រព័ន្ធ (អាណាឡូករបស់វា។ memcpy ឬ printf) [4];
• ដោយមានជំនួយពីមតិយោបល់ ភាពវិជ្ជមានមិនពិតត្រូវបានបិទ។
• ហើយដូច្នេះនៅលើ។

ក្នុងករណីនេះយើងអាចរំពឹងថានឹងមានកម្រិតទាបនៃភាពវិជ្ជមានមិនពិតនៅលើលំដាប់នៃ 10-15% [5] ម្យ៉ាងវិញទៀត ការព្រមានអំពីអ្នកវិភាគចំនួន 9 ក្នុងចំណោម 10 នឹងចង្អុលទៅបញ្ហាពិតប្រាកដនៅក្នុងកូដ ឬយ៉ាងហោចណាស់ "កូដដែលមានក្លិនខ្លាំង"។ យល់ស្រប សេណារីយ៉ូបែបនេះពិតជារីករាយខ្លាំងណាស់ ហើយអ្នកវិភាគគឺជាមិត្តពិតរបស់អ្នកសរសេរកម្មវិធី។

ការពិតនៅក្នុងគម្រោងធំមួយ រូបភាពដំបូងនឹងខុសគ្នាទាំងស្រុង។ ឧបករណ៍វិភាគបង្កើតការព្រមានរាប់រយ ឬរាប់ពាន់សម្រាប់កូដកេរ្តិ៍។ តើការព្រមានទាំងនេះមួយណាដែលពាក់ព័ន្ធ និងមួយណាមិនអាចទៅរួច វាមិនអាចយល់បានយ៉ាងឆាប់រហ័ស។ វាជាការមិនសមហេតុផលក្នុងការអង្គុយចុះ ហើយចាប់ផ្តើមដោះស្រាយជាមួយនឹងការព្រមានទាំងអស់នេះ ព្រោះការងារសំខាន់ក្នុងករណីនេះនឹងឈប់ជាច្រើនថ្ងៃ ឬច្រើនសប្តាហ៍។ តាមក្បួនមួយ ក្រុមមិនអាចមានលទ្ធភាពទិញសេណារីយ៉ូបែបនេះបានទេ។ វាក៏នឹងមានភាពខុសគ្នាជាច្រើនដែលធ្វើឲ្យខូចប្រវត្តិនៃការផ្លាស់ប្តូរ។ ហើយការកែសម្រួលទ្រង់ទ្រាយធំយ៉ាងឆាប់រហ័សនៃបំណែកមួយចំនួននៅក្នុងកូដនឹងនាំឱ្យមានការវាយអក្សរ និងកំហុសថ្មីៗដោយជៀសមិនរួច។

ហើយសំខាន់បំផុត សកម្មភាពបែបនេះក្នុងការប្រយុទ្ធប្រឆាំងនឹងការព្រមានធ្វើឱ្យយល់បានតិចតួច។ យល់ស្របថាចាប់តាំងពីគម្រោងនេះបានដំណើរការដោយជោគជ័យអស់រយៈពេលជាច្រើនឆ្នាំមកនោះ ភាគច្រើននៃកំហុសសំខាន់ៗនៅក្នុងវាត្រូវបានជួសជុលរួចហើយ។ បាទ ការ​ជួសជុល​ទាំង​នេះ​មាន​តម្លៃ​ថ្លៃ​ណាស់ អ្នក​ត្រូវ​កែ​កំហុស ទទួល​បាន​មតិ​កែលម្អ​អវិជ្ជមាន​ពី​អ្នក​ប្រើ​អំពី​បញ្ហា​ជាដើម។ ឧបករណ៍វិភាគឋិតិវន្តនឹងជួយជួសជុលកំហុសទាំងនេះជាច្រើននៅដំណាក់កាលនៃការសរសេរកូដយ៉ាងឆាប់រហ័ស និងថោក។ ប៉ុន្តែនៅពេលនេះ វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត កំហុសទាំងនេះត្រូវបានជួសជុល ហើយអ្នកវិភាគភាគច្រើនរកឃើញកំហុសដែលមិនសំខាន់នៅក្នុងកូដចាស់។ កូដនេះប្រហែលជាមិនត្រូវបានប្រើទេ កម្រប្រើណាស់ ហើយកំហុសនៅក្នុងវាប្រហែលជាមិននាំឱ្យមានផលវិបាកគួរឱ្យកត់សម្គាល់នោះទេ។ ប្រហែលជាកន្លែងណាមួយស្រមោលពីប៊ូតុងមានពណ៌ខុស ប៉ុន្តែនេះមិនរារាំងនរណាម្នាក់ពីការប្រើប្រាស់ផលិតផលនោះទេ។

ជាការពិតណាស់សូម្បីតែកំហុសតូចតាចនៅតែជាកំហុស។ ហើយជួនកាលភាពងាយរងគ្រោះពិតប្រាកដមួយអាចត្រូវបានលាក់នៅពីក្រោយកំហុស។ ទោះយ៉ាងណាក៏ដោយ ដើម្បីលះបង់អ្វីៗគ្រប់យ៉ាង ហើយចំណាយពេលច្រើនថ្ងៃ/សប្តាហ៍ ដើម្បីដោះស្រាយបញ្ហាដែលបង្ហាញខ្លួនឯងថាខ្សោយ ហាក់ដូចជាគំនិតគួរឱ្យសង្ស័យ។

អ្នកសរសេរកម្មវិធីមើល មើល ក្រឡេកមើលការព្រមានទាំងអស់នេះនៅលើកូដការងារចាស់... ហើយពួកគេគិតថា៖ ចូរយើងធ្វើដោយគ្មានការវិភាគឋិតិវន្ត។ តោះទៅមុខងារថ្មីដែលមានប្រយោជន៍ក្នុងការសរសេរ។

នៅក្នុងវិធីមួយ, ពួកគេគឺត្រឹមត្រូវ។ ពួកគេជឿថា ដើម្បីចាប់ផ្តើមជាមួយ ពួកគេត្រូវតែកម្ចាត់ការព្រមានទាំងអស់នេះ។ ហើយមានតែពេលនោះទេដែលពួកគេនឹងអាចទទួលបានអត្ថប្រយោជន៍ពីការប្រើប្រាស់ជាប្រចាំនៃកម្មវិធីវិភាគកូដ។ បើមិនដូច្នេះទេ ការព្រមានថ្មីនឹងលិចចូលទៅក្នុងរបស់ចាស់ ហើយគ្មាននរណាម្នាក់នឹងយកចិត្តទុកដាក់ចំពោះពួកគេ។

នេះ​គឺ​ជា​ការ​ប្រៀប​ធៀប​ដូច​គ្នា​នឹង​ការ​ព្រមាន​ពី​អ្នក​ចងក្រង។ វាមិនមែនដោយគ្មានហេតុផលទេ ដែលវាត្រូវបានណែនាំឱ្យរក្សាចំនួនការព្រមានអ្នកចងក្រងនៅត្រឹម 0។ ប្រសិនបើមានការព្រមានចំនួន 1000 នោះនៅពេលដែលពួកគេក្លាយជា 1001 គ្មាននរណាម្នាក់នឹងយកចិត្តទុកដាក់ចំពោះបញ្ហានេះទេ ហើយវាមិនច្បាស់ថាត្រូវរកមើលកន្លែងណាថ្មីបំផុតនោះទេ។ ការព្រមាន។

អ្វីដែលអាក្រក់បំផុតនៅក្នុងរឿងនេះគឺប្រសិនបើនរណាម្នាក់ពីខាងលើបង្ខំអ្នកឱ្យប្រើការវិភាគកូដឋិតិវន្តនៅពេលនេះ។ នេះគ្រាន់តែជាការបំបាក់ទឹកចិត្តក្រុមប៉ុណ្ណោះ ព្រោះតាមទស្សនៈរបស់ពួកគេ វានឹងមានភាពស្មុគស្មាញផ្នែកការិយាធិបតេយ្យបន្ថែមទៀត ដែលមានតែនៅក្នុងផ្លូវប៉ុណ្ណោះ។ គ្មាននរណាម្នាក់នឹងមើលរបាយការណ៍អ្នកវិភាគទេ ហើយការប្រើប្រាស់ទាំងអស់នឹងមានតែ "នៅលើក្រដាស" ប៉ុណ្ណោះ។ ទាំងនោះ។ ជាផ្លូវការ ការវិភាគត្រូវបានបង្កើតឡើងនៅក្នុងដំណើរការ DevOps ប៉ុន្តែនៅក្នុងការអនុវត្ត វាមិនមានប្រយោជន៍សម្រាប់នរណាម្នាក់ឡើយ។ យើង​បាន​ឮ​រឿង​លម្អិត​នៅ​ក្នុង​ស្តង់​ពី​អ្នក​ចូលរួម​សន្និសីទ។ បទពិសោធន៍បែបនេះអាចមានរយៈពេលយូរ ប្រសិនបើមិនមានជារៀងរហូតទេ រារាំងអ្នកសរសេរកម្មវិធីពីការចូលរួមក្នុងឧបករណ៍វិភាគឋិតិវន្ត។

ការអនុវត្ត និងលុបបំបាត់បំណុលបច្ចេកទេស

តាមការពិត មិនមានអ្វីពិបាក ឬគួរឱ្យខ្លាចក្នុងការអនុវត្តការវិភាគឋិតិវន្ត សូម្បីតែនៅក្នុងគម្រោងចាស់ដ៏ធំមួយក៏ដោយ។

ស៊ីអាយ / ស៊ីឌី

ជាងនេះទៅទៀត ឧបករណ៍វិភាគអាចក្លាយជាផ្នែកមួយនៃដំណើរការអភិវឌ្ឍន៍ជាបន្តបន្ទាប់។ ឧទាហរណ៍ ឧបករណ៍ចែកចាយ PVS-Studio មានឧបករណ៍ប្រើប្រាស់សម្រាប់ងាយស្រួលមើលរបាយការណ៍ក្នុងទម្រង់ដែលអ្នកត្រូវការ និងការជូនដំណឹងសម្រាប់អ្នកអភិវឌ្ឍន៍ដែលបានសរសេរផ្នែកកូដដែលមានបញ្ហា។ សម្រាប់អ្នកដែលមានចំណាប់អារម្មណ៍ក្នុងការបើកដំណើរការ PVS-Studio ពីប្រព័ន្ធ CI/CD ខ្ញុំសូមណែនាំឱ្យអ្នកស្គាល់ខ្លួនអ្នកជាមួយនឹងអ្វីដែលពាក់ព័ន្ធ។ ផ្នែក ឯកសារ និងអត្ថបទមួយចំនួន៖

• PVS-Studio ទៅពពក: Azure Devops
• PVS-Studio ទៅពពក៖ Travis CI
• PVS-Studio ទៅពពក៖ GitLab CI/CD
• PVS-Studio ទៅពពក: CircleCI

ប៉ុន្តែសូមត្រលប់ទៅបញ្ហានៃចំនួនដ៏ច្រើននៃវិជ្ជមានមិនពិតនៅដំណាក់កាលដំបូងនៃការអនុវត្តឧបករណ៍វិភាគកូដ។

ជួសជុលបំណុលបច្ចេកទេសដែលមានស្រាប់ និងដោះស្រាយការជូនដំណឹងថ្មី។

ឧបករណ៍វិភាគឋិតិវន្តពាណិជ្ជកម្មទំនើបអនុញ្ញាតឱ្យអ្នកសិក្សាតែការព្រមានថ្មីដែលបង្ហាញនៅក្នុងកូដថ្មី ឬកែប្រែប៉ុណ្ណោះ។ ការអនុវត្តយន្តការនេះគឺខុសគ្នា ប៉ុន្តែខ្លឹមសារគឺដូចគ្នា។ នៅក្នុងឧបករណ៍វិភាគឋិតិវន្ត PVS-Studio មុខងារនេះត្រូវបានអនុវត្តដូចខាងក្រោម។

ដើម្បីចាប់ផ្តើមប្រើការវិភាគឋិតិវន្តយ៉ាងឆាប់រហ័ស យើងស្នើឱ្យអ្នកប្រើប្រាស់ PVS-Studio ប្រើយន្តការទប់ស្កាត់ការព្រមានដ៏ធំ [6] គំនិតទូទៅមានដូចខាងក្រោម។ អ្នកប្រើប្រាស់បានបើកដំណើរការឧបករណ៍វិភាគ និងទទួលបានការព្រមានជាច្រើន។ ដោយសារគម្រោងដែលត្រូវបានបង្កើតឡើងជាច្រើនឆ្នាំនៅមានជីវិត អភិវឌ្ឍ និងរកលុយបាន នោះទំនងជានឹងមិនមានការព្រមានច្រើននៅក្នុងរបាយការណ៍ដែលបង្ហាញពីពិការភាពធ្ងន់ធ្ងរនោះទេ។ ម្យ៉ាងវិញទៀត កំហុសសំខាន់ៗត្រូវបានជួសជុលរួចហើយតាមមធ្យោបាយមួយ ឬមធ្យោបាយផ្សេងទៀតដោយមធ្យោបាយដែលមានតម្លៃថ្លៃជាង ឬអរគុណចំពោះមតិកែលម្អរបស់អតិថិជន។ ដូច្នោះហើយ អ្វីគ្រប់យ៉ាងដែលអ្នកវិភាគបានរកឃើញនៅពេលនេះ អាចចាត់ទុកថាជាបំណុលបច្ចេកទេស ដែលវាមិនសមហេតុផលក្នុងការព្យាយាមលុបបំបាត់ភ្លាមៗ។

អ្នកអាចប្រាប់ PVS-Studio ឱ្យពិចារណាការព្រមានទាំងនេះថាមិនពាក់ព័ន្ធសម្រាប់ពេលនេះ (ពន្យារពេលបំណុលបច្ចេកទេសនៅពេលក្រោយ) ហើយវានឹងមិនបង្ហាញពួកវាទៀតទេ។ អ្នកវិភាគបង្កើតឯកសារពិសេសមួយដែលវារក្សាទុកព័ត៌មានអំពីកំហុសដែលមិនគួរឱ្យចាប់អារម្មណ៍នាពេលបច្ចុប្បន្ន។ ហើយឥឡូវនេះ PVS-Studio នឹងចេញការព្រមានសម្រាប់តែកូដថ្មី ឬដែលបានកែប្រែប៉ុណ្ណោះ។ លើសពីនេះទៅទៀត ទាំងអស់នេះត្រូវបានអនុវត្តយ៉ាងឆ្លាតវៃ។ ឧទាហរណ៍ ប្រសិនបើបន្ទាត់ទទេត្រូវបានបន្ថែមទៅដើមនៃឯកសារដែលមានកូដប្រភព នោះអ្នកវិភាគយល់ថា តាមពិតគ្មានអ្វីផ្លាស់ប្តូរទេ ហើយនឹងនៅស្ងៀមដូចពីមុន។ ឯកសារសម្គាល់នេះអាចត្រូវបានដាក់ចូលទៅក្នុងប្រព័ន្ធត្រួតពិនិត្យកំណែ។ ឯកសារមានទំហំធំ ប៉ុន្តែវាមិនគួរឱ្យខ្លាចទេព្រោះវាច្រើនតែគ្មានន័យក្នុងការដាក់វាចុះ។

ឥឡូវនេះ អ្នកសរសេរកម្មវិធីទាំងអស់នឹងឃើញតែការព្រមានទាក់ទងនឹងកូដថ្មី ឬផ្លាស់ប្តូរប៉ុណ្ណោះ។ ដូច្នេះឧបករណ៍វិភាគអាចត្រូវបានប្រើដូចដែលពួកគេនិយាយចាប់ពីថ្ងៃបន្ទាប់។ ហើយវានឹងអាចត្រលប់ទៅបំណុលបច្ចេកទេសវិញនៅពេលក្រោយ ហើយកែកំហុសបន្តិចម្តងៗ និងសម្រួលអ្នកវិភាគ។

ដូច្នេះបញ្ហាដំបូងជាមួយនឹងការបញ្ចូលឧបករណ៍វិភាគទៅក្នុងគម្រោងចាស់ដ៏ធំមួយត្រូវបានដោះស្រាយ។ ឥឡូវនេះ ចូរយើងស្វែងយល់ថាតើត្រូវធ្វើអ្វីជាមួយបំណុលបច្ចេកទេស។

ជួសជុល និងកែកំហុស

វិធីសាមញ្ញបំផុត និងធម្មជាតិបំផុតគឺត្រូវទុកពេលមួយឡែកសិន ដើម្បីញែកការព្រមានរបស់អ្នកវិភាគដែលបានគាបសង្កត់យ៉ាងខ្លាំង ហើយដោះស្រាយជាបណ្តើរៗ។ កន្លែងណាមួយដែលអ្នកគួរជួសជុលកំហុសនៅក្នុងកូដ កន្លែងណាមួយអ្នកគួរតែ refactor ដើម្បីប្រាប់អ្នកវិភាគថាកូដមិនមានបញ្ហាទេ។ ឧទាហរណ៍សាមញ្ញ៖

if (a = b)

អ្នកចងក្រង និងអ្នកវិភាគ C ++ ភាគច្រើនស្បថចំពោះកូដបែបនេះ ព្រោះវាទំនងជាពួកគេចង់សរសេរ (a == ខ). ប៉ុន្តែមានកិច្ចព្រមព្រៀងដែលមិនបាននិយាយ ហើយជាធម្មតាវាត្រូវបានកត់សម្គាល់នៅក្នុងឯកសារថាប្រសិនបើមានតង្កៀបបន្ថែមនោះ វាត្រូវបានចាត់ទុកថាអ្នកសរសេរកម្មវិធីមានចេតនាសរសេរកូដបែបនេះ ហើយមិនចាំបាច់ស្បថឡើយ។ ឧទាហរណ៍នៅក្នុងឯកសារ PVS-Studio សម្រាប់ការធ្វើរោគវិនិច្ឆ័យ V559 (CWE-481) វាត្រូវបានសរសេរយ៉ាងច្បាស់លាស់ថា បន្ទាត់ខាងក្រោមនឹងត្រូវបានចាត់ទុកថាត្រឹមត្រូវ និងមានសុវត្ថិភាព៖

if ((a = b))

ឧទាហរណ៍មួយទៀត។ តើ​វា​ត្រូវ​បាន​គេ​បំភ្លេច​ចោល​ក្នុង​កូដ C++ នេះ​ឬ​ទេ? បំបែក ឬអត់?

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

អ្នកវិភាគ PVS-Studio នឹងចេញការព្រមាននៅទីនេះ V796 (CWE-484). ប្រហែលជានេះមិនមែនជាកំហុសទេ ក្នុងករណីនេះអ្នកគួរតែផ្តល់ការណែនាំដល់អ្នកវិភាគដោយបន្ថែមគុណលក្ខណៈ [[ធ្លាក់]] ឬឧទាហរណ៍ __គុណលក្ខណៈ__((ធ្លាក់)):

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

យើងអាចនិយាយបានថាការផ្លាស់ប្តូរកូដបែបនេះមិនជួសជុលកំហុសទេ។ បាទ វាគឺប៉ុន្តែវាធ្វើរឿងមានប្រយោជន៍ពីរ។ ទីមួយ របាយការណ៍អ្នកវិភាគកម្ចាត់ភាពវិជ្ជមានមិនពិត។ ទីពីរ កូដកាន់តែអាចយល់បានសម្រាប់អ្នកដែលពាក់ព័ន្ធនឹងការថែទាំរបស់វា។ ហើយនេះគឺសំខាន់ណាស់! សម្រាប់ជាប្រយោជន៍នៃការនេះតែម្នាក់ឯង វាមានតម្លៃរួចហើយដើម្បីធ្វើការជួសជុលតិចតួចដើម្បីធ្វើឱ្យកូដកាន់តែច្បាស់ និងងាយស្រួលក្នុងការថែទាំ។ ដោយសារវាមិនច្បាស់ចំពោះអ្នកវិភាគថាតើត្រូវការ "សម្រាក" ឬអត់នោះ វាក៏នឹងមិនអាចយល់បានចំពោះអ្នកសរសេរកម្មវិធីផ្សេងទៀត។

បន្ថែមពីលើការជួសជុលកំហុស និងការជួសជុលឡើងវិញ អ្នកអាចជ្រើសរើសការទប់ស្កាត់ការព្រមានរបស់អ្នកវិភាគមិនពិតយ៉ាងច្បាស់។ ការធ្វើរោគវិនិច្ឆ័យមិនពាក់ព័ន្ធមួយចំនួនអាចត្រូវបានបិទ។ ជាឧទាហរណ៍ នរណាម្នាក់ចាត់ទុកការព្រមានគ្មានន័យ V550 អំពីការប្រៀបធៀបតម្លៃអណ្តែត/ទ្វេ។ ហើយមាននរណាម្នាក់ចាត់ថ្នាក់ពួកគេថាមានសារៈសំខាន់ និងសក្តិសមក្នុងការសិក្សា [7] វាអាស្រ័យលើក្រុមអភិវឌ្ឍន៍ក្នុងការសម្រេចចិត្តថាតើការព្រមានណាមួយពាក់ព័ន្ធ និងមួយណាមិនពាក់ព័ន្ធ។

មានវិធីផ្សេងទៀតដើម្បីទប់ស្កាត់ការជូនដំណឹងមិនពិត។ ជាឧទាហរណ៍ ការសម្គាល់ម៉ាក្រូត្រូវបានលើកឡើងពីមុន។ ទាំងអស់នេះត្រូវបានពិពណ៌នាលម្អិតបន្ថែមទៀតនៅក្នុងឯកសារ។ អ្វីដែលសំខាន់បំផុតគឺត្រូវយល់ថា ប្រសិនបើអ្នកចូលទៅជិតការងារបន្តិចម្តងៗ និងជាប្រព័ន្ធជាមួយនឹងភាពវិជ្ជមានមិនពិតនោះ វាមិនមានអ្វីខុសជាមួយពួកគេនោះទេ។ ការព្រមានដែលមិនចាប់អារម្មណ៍ភាគច្រើនបាត់បន្ទាប់ពីការកំណត់រចនាសម្ព័ន្ធ ហើយមានតែកន្លែងប៉ុណ្ណោះដែលទាមទារការសិក្សាយ៉ាងប្រុងប្រយ័ត្ន និងការផ្លាស់ប្តូរមួយចំនួននៅក្នុងកូដ។

ដូចគ្នានេះផងដែរ យើងតែងតែជួយអតិថិជនរបស់យើងក្នុងការដំឡើង PVS-Studio ប្រសិនបើមានការលំបាកណាមួយ។ លើស​ពី​នេះ​ទៅ​ទៀត មាន​ករណី​នៅ​ពេល​យើង​ខ្លួន​ឯង​បាន​លុប​បំបាត់​ការ​ព្រមាន​មិន​ពិត និង​កែ​កំហុស [8] ក្នុងករណីដែលខ្ញុំបានសម្រេចចិត្តនិយាយថាជម្រើសបែបនេះសម្រាប់កិច្ចសហប្រតិបត្តិការបន្ថែមគឺអាចធ្វើទៅបាន :) ។

វិធីសាស្ត្រ Ratchet

មានវិធីសាស្រ្តគួរឱ្យចាប់អារម្មណ៍មួយផ្សេងទៀតដើម្បីកែលម្អគុណភាពនៃកូដបន្តិចម្តងៗដោយលុបបំបាត់ការព្រមានអំពីឧបករណ៍វិភាគឋិតិវន្ត។ ចំណុចសំខាន់គឺថាចំនួននៃការព្រមានអាចថយចុះតែប៉ុណ្ណោះ។

ចំនួននៃការព្រមានដែលចេញដោយអ្នកវិភាគឋិតិវន្តត្រូវបានជួសជុល។ ច្រកគុណភាពត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមរបៀបដែលឥឡូវនេះអ្នកអាចដាក់បានតែលេខកូដដែលមិនបង្កើនចំនួននៃការទស្សនា។ ជាលទ្ធផលដំណើរការនៃការថយចុះបន្តិចម្តង ៗ នៃចំនួនកេះត្រូវបានចាប់ផ្តើមដោយការកែតម្រូវឧបករណ៍វិភាគនិងកែតម្រូវកំហុស។

ទោះបីជាមនុស្សម្នាក់ចង់បន្លំបន្តិចហើយសម្រេចចិត្តឆ្លងកាត់ច្រកទ្វារគុណភាពមិនមែនដោយការលុបបំបាត់ការព្រមាននៅក្នុងលេខកូដថ្មីរបស់គាត់នោះទេប៉ុន្តែដោយការកែលម្អលេខកូដភាគីទីបីចាស់នេះមិនគួរឱ្យខ្លាចនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ ratchet បង្វិលក្នុងទិសដៅមួយ ហើយបន្តិចម្តងៗចំនួននៃពិការភាពនឹងថយចុះ។ ទោះបីជាមនុស្សម្នាក់មិនចង់ជួសជុលពិការភាពថ្មីរបស់ពួកគេក៏ដោយក៏ពួកគេនៅតែត្រូវកែលម្អអ្វីមួយនៅក្នុងលេខកូដប្រទេសជិតខាង។ នៅចំណុចខ្លះ មធ្យោបាយងាយស្រួលក្នុងការកាត់បន្ថយចំនួននៃការព្រមានត្រូវបានបញ្ចប់ ហើយនៅពេលនោះមកនៅពេលដែលកំហុសពិតប្រាកដនឹងត្រូវបានជួសជុល។

វិធីសាស្រ្តនេះត្រូវបានពិពណ៌នាលម្អិតបន្ថែមទៀតនៅក្នុងអត្ថបទគួរឱ្យចាប់អារម្មណ៍មួយដោយ Ivan Ponomarev "អនុវត្តការវិភាគឋិតិវន្តទៅក្នុងដំណើរការ ជាជាងស្វែងរកកំហុសជាមួយវា។" ដែលខ្ញុំសូមណែនាំដល់អ្នកគ្រប់គ្នាដែលចាប់អារម្មណ៍ក្នុងការធ្វើអោយប្រសើរឡើងនូវគុណភាពនៃកូដ។

អ្នកនិពន្ធអត្ថបទក៏មានរបាយការណ៍អំពីប្រធានបទនេះផងដែរ៖ការវិភាគឋិតិវន្តឥតឈប់ឈរ".

សេចក្តីសន្និដ្ឋាន

ខ្ញុំសង្ឃឹមថាបន្ទាប់ពីអត្ថបទនេះ អ្នកអាននឹងកាន់តែមានភាពរួសរាយរាក់ទាក់ចំពោះឧបករណ៍វិភាគឋិតិវន្ត ហើយចង់អនុវត្តវានៅក្នុងដំណើរការអភិវឌ្ឍន៍។ ប្រសិនបើអ្នកមានសំណួរណាមួយ យើងត្រៀមខ្លួនជានិច្ច ណែនាំ អ្នកប្រើប្រាស់ឧបករណ៍វិភាគឋិតិវន្ត PVS-Studio និងជួយក្នុងការអនុវត្តរបស់វា។

មានការសង្ស័យធម្មតាផ្សេងទៀតថាតើការវិភាគឋិតិវន្តពិតជាអាចងាយស្រួល និងមានប្រយោជន៍។ ខ្ញុំបានព្យាយាមលុបបំបាត់ការសង្ស័យទាំងនេះនៅក្នុងការបោះពុម្ពផ្សាយ "ហេតុផលដើម្បីណែនាំអ្នកវិភាគកូដឋិតិវន្ត PVS-Studio ទៅក្នុងដំណើរការអភិវឌ្ឍន៍" [9].

សូមអរគុណចំពោះការយកចិត្តទុកដាក់របស់អ្នកហើយមក ទាញយក ហើយសាកល្បងឧបករណ៍វិភាគ PVS-Studio ។

តំណភ្ជាប់បន្ថែម

1. Andrey Karpov ។ តើធ្វើដូចម្តេចដើម្បីមើលឃើញការព្រមានគួរឱ្យចាប់អារម្មណ៍ដែលបង្កើតឡើងដោយអ្នកវិភាគ PVS-Studio សម្រាប់កូដ C និង C++ យ៉ាងរហ័ស?
2. Wikipedia ។ ទ្រឹស្ដីស្រូវ.
3. Andrey Karpov, Victoria Khanieva ។ ការប្រើប្រាស់ Machine Learning ក្នុងការវិភាគឋិតិវន្តនៃកូដប្រភពកម្មវិធី.
4. pvs-studio ។ ឯកសារ។ ការកំណត់រោគវិនិច្ឆ័យបន្ថែម.
5. Andrey Karpov ។ លក្ខណៈរបស់អ្នកវិភាគ PVS-Studio លើឧទាហរណ៍នៃបណ្ណាល័យស្នូល EFL, 10-15% វិជ្ជមានមិនពិត.
6. pvs-studio ។ ឯកសារ។ ការបង្ក្រាបដ៏ធំនៃសារអ្នកវិភាគ.
7. លោក Ivan Andryashin ។ អំពីរបៀបដែលយើងបានសាកល្បងការវិភាគឋិតិវន្តលើគម្រោងរបស់យើងនៃការក្លែងធ្វើការអប់រំនៃការវះកាត់សរសៃឈាមចុង X-ray.
8. Pavel Eremeev, Svyatoslav Razmyslov ។ របៀបដែលក្រុម PVS-Studio កែលម្អលេខកូដ Unreal Engine.
9. Andrey Karpov ។ Причины внедрить в процесс разработки статический анализатор кода PVS-Studio.

ប្រសិនបើអ្នកចង់ចែករំលែកអត្ថបទនេះជាមួយទស្សនិកជនដែលនិយាយភាសាអង់គ្លេស សូមប្រើតំណភ្ជាប់ការបកប្រែ៖ Andrey Karpov ។ របៀបណែនាំអ្នកវិភាគកូដឋិតិវន្តនៅក្នុងគម្រោងកេរដំណែលមួយ និងមិនធ្វើឱ្យក្រុមបាក់ទឹកចិត្ត.

ប្រភព: www.habr.com