🥇បញ្ចូលការវិភាគឋិតិវន្តទៅក្នុងដំណើរការរបស់អ្នក ជាជាងប្រើវាដើម្បីស្វែងរកកំហុស

ខ្ញុំត្រូវបានជំរុញឱ្យសរសេរអត្ថបទនេះដោយចំនួនដ៏ច្រើននៃសម្ភារៈនៅលើការវិភាគឋិតិវន្តដែលកំពុងតែមកដល់ការចាប់អារម្មណ៍របស់ខ្ញុំកាន់តែខ្លាំងឡើង។ ជាដំបូង, នេះ។ ប្លុក PVS-studioដែលផ្សព្វផ្សាយខ្លួនវាយ៉ាងសកម្មនៅលើ Habre ដោយមានជំនួយពីការពិនិត្យឡើងវិញនូវកំហុសដែលបានរកឃើញដោយឧបករណ៍របស់ពួកគេនៅក្នុងគម្រោងប្រភពបើកចំហ។ ថ្មីៗនេះ PVS-studio បានអនុវត្ត ការគាំទ្រ Javaហើយជាការពិតណាស់ អ្នកអភិវឌ្ឍន៍ IntelliJ IDEA ដែលឧបករណ៍វិភាគដែលភ្ជាប់មកជាមួយគឺប្រហែលជាទំនើបបំផុតសម្រាប់ Java សព្វថ្ងៃនេះ។ មិនអាចនៅឆ្ងាយបានទេ។.

នៅពេលអានការពិនិត្យបែបនេះ អ្នកទទួលបានអារម្មណ៍ថាយើងកំពុងនិយាយអំពីវេទមន្ត elixir: ចុចប៊ូតុង ហើយនៅទីនេះវាគឺជា - បញ្ជីនៃពិការភាពមុនពេលភ្នែករបស់អ្នក។ វាហាក់បីដូចជាពេលដែលអ្នកវិភាគមានភាពប្រសើរឡើង កំហុសកាន់តែច្រើននឹងត្រូវបានរកឃើញដោយស្វ័យប្រវត្តិ ហើយផលិតផលដែលស្កែនដោយមនុស្សយន្តទាំងនេះនឹងកាន់តែប្រសើរឡើង និងកាន់តែប្រសើរឡើងដោយមិនមានការប្រឹងប្រែងណាមួយពីផ្នែករបស់យើងឡើយ។

ប៉ុន្តែមិនមាន elixir វេទមន្តទេ។ ខ្ញុំចង់និយាយអំពីអ្វីដែលជាធម្មតាមិនត្រូវបាននិយាយអំពីនៅក្នុងការប្រកាសដូចជា "នេះគឺជាអ្វីដែលមនុស្សយន្តរបស់យើងអាចរកឃើញ"៖ អ្វីដែលអ្នកវិភាគមិនអាចធ្វើ តួនាទី និងទីកន្លែងពិតប្រាកដរបស់ពួកគេនៅក្នុងដំណើរការចែកចាយកម្មវិធី និងរបៀបអនុវត្តពួកវាឱ្យបានត្រឹមត្រូវ។ .

Ratchet (ប្រភព៖ វិគីភីឌា).

អ្វីដែលអ្នកវិភាគឋិតិវន្តមិនអាចធ្វើបាន

តើការវិភាគកូដប្រភពគឺជាអ្វី តាមទស្សនៈជាក់ស្តែង? យើងផ្តល់កូដប្រភពមួយចំនួនជាការបញ្ចូល និងជាលទ្ធផល ក្នុងរយៈពេលដ៏ខ្លី (ខ្លីជាងការធ្វើតេស្តដែលកំពុងដំណើរការ) យើងទទួលបានព័ត៌មានមួយចំនួនអំពីប្រព័ន្ធរបស់យើង។ ដែនកំណត់ជាមូលដ្ឋាន និងមិនអាចគ្រប់គ្រងបានតាមគណិតវិទ្យាគឺថា យើងអាចទទួលបានព័ត៌មានតូចចង្អៀតគួរសមតាមវិធីនេះ។

ឧទាហរណ៍ដ៏ល្បីល្បាញបំផុតនៃបញ្ហាដែលមិនអាចដោះស្រាយបានដោយប្រើការវិភាគឋិតិវន្តគឺ បញ្ហាបិទ៖ នេះគឺជាទ្រឹស្តីបទដែលបង្ហាញថាវាមិនអាចទៅរួចទេក្នុងការអភិវឌ្ឍក្បួនដោះស្រាយទូទៅដែលអាចកំណត់ពីកូដប្រភពនៃកម្មវិធីថាតើវានឹងរង្វិលជុំ ឬបញ្ចប់ក្នុងរយៈពេលកំណត់។ ផ្នែកបន្ថែមនៃទ្រឹស្តីបទនេះគឺ ទ្រឹស្តីបទរបស់អង្ករដែលចែងថាសម្រាប់ទ្រព្យសម្បត្តិមិនសំខាន់ណាមួយនៃមុខងារដែលអាចគណនាបាន ការកំណត់ថាតើកម្មវិធីបំពានវាយតំលៃមុខងារជាមួយទ្រព្យសម្បត្តិបែបនេះគឺជាបញ្ហាដែលមិនអាចដោះស្រាយបានតាមវិធីដោះស្រាយ។ ជាឧទាហរណ៍ វាមិនអាចទៅរួចទេក្នុងការសរសេរកម្មវិធីវិភាគដែលអាចកំណត់ពីកូដប្រភពណាមួយថាតើកម្មវិធីដែលកំពុងវិភាគគឺជាការអនុវត្តនៃក្បួនដោះស្រាយដែលគណនា squaring នៃចំនួនគត់។

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

ការវិភាគឋិតិវន្តមិនមែនអំពីការស្វែងរកកំហុសទេ។

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

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

តើនេះមានន័យថាមិនគួរប្រើការវិភាគឋិតិវន្តទេ? ជាការពិតណាស់មិនមែនទេ! ហើយសម្រាប់ហេតុផលដូចគ្នាដែលវាមានតម្លៃពិនិត្យមើលពាក្យសម្ងាត់ថ្មីនីមួយៗ ដើម្បីប្រាកដថាវាត្រូវបានបញ្ចូលក្នុងបញ្ជីបញ្ឈប់ពាក្យសម្ងាត់ "សាមញ្ញ"។

ការវិភាគឋិតិវន្តគឺច្រើនជាងការស្វែងរកកំហុស

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

ពិនិត្យរចនាប័ទ្មសរសេរកូដក្នុងន័យទូលំទូលាយនៃពាក្យ។ នេះរួមបញ្ចូលទាំងការពិនិត្យមើលទម្រង់ ការស្វែងរកការប្រើប្រាស់វង់ក្រចកទទេ/បន្ថែម ការកំណត់កម្រិតលើម៉ែត្រ ដូចជាចំនួនបន្ទាត់/ភាពស្មុគស្មាញនៃវដ្តនៃវិធីសាស្ត្រជាដើម។ នៅក្នុង Java ឧបករណ៍បែបនេះគឺ Checkstyle នៅក្នុង Python - flake8 ។ កម្មវិធីនៃថ្នាក់នេះត្រូវបានគេហៅថាជាធម្មតាថាជា "ស្រទាប់"។
មិនត្រឹមតែប៉ុណ្ណោះកូដដែលអាចប្រតិបត្តិបានអាចត្រូវបានវិភាគ។ ឯកសារធនធានដូចជា JSON, YAML, XML, .properties អាច (និងគួរ!) ត្រូវបានពិនិត្យដោយស្វ័យប្រវត្តិសម្រាប់សុពលភាព។ យ៉ាងណាមិញ វាជាការប្រសើរក្នុងការស្វែងយល់ថារចនាសម្ព័ន្ធ JSON ត្រូវបានខូចដោយសារតែសម្រង់ដែលមិនផ្គូផ្គងមួយចំនួននៅដំណាក់កាលដំបូងនៃការផ្ទៀងផ្ទាត់ការស្នើសុំទាញដោយស្វ័យប្រវត្តិជាងអំឡុងពេលដំណើរការសាកល្បង ឬពេលដំណើរការ? ឧបករណ៍សមស្របអាចរកបាន៖ ឧ. យ៉ាមលលីន, JSONLint.
ការចងក្រង (ឬញែកសម្រាប់ភាសាសរសេរកម្មវិធីថាមវន្ត) ក៏ជាប្រភេទនៃការវិភាគឋិតិវន្តផងដែរ។ ជាទូទៅ អ្នកចងក្រងមានសមត្ថភាពផលិតការព្រមានដែលបង្ហាញពីបញ្ហាជាមួយនឹងគុណភាពកូដប្រភព ហើយមិនគួរត្រូវបានអើពើឡើយ។
ពេលខ្លះការចងក្រងគឺលើសពីការចងក្រងកូដដែលអាចប្រតិបត្តិបាន។ ឧទាហរណ៍ ប្រសិនបើអ្នកមានឯកសារក្នុងទម្រង់ វេជ្ជបណ្ឌិត Asciiបន្ទាប់មកនៅពេលបង្វែរវាទៅជា HTML/PDF អ្នកដោះស្រាយ AsciiDoctor (កម្មវិធីជំនួយ Maven) អាចចេញការព្រមាន ឧទាហរណ៍អំពីតំណភ្ជាប់ខាងក្នុងដែលខូច។ ហើយនេះគឺជាហេតុផលដ៏ល្អមួយដែលមិនទទួលយកសំណើរទាញជាមួយនឹងការផ្លាស់ប្តូរឯកសារ។
ការពិនិត្យអក្ខរាវិរុទ្ធក៏ជាប្រភេទនៃការវិភាគឋិតិវន្តផងដែរ។ ឧបករណ៍ប្រើប្រាស់ អក្ខរាវិរុទ្ធ អាចពិនិត្យអក្ខរាវិរុទ្ធមិនត្រឹមតែនៅក្នុងឯកសារប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងនៅក្នុងកូដប្រភពកម្មវិធី (មតិយោបល់ និងព្យញ្ជនៈ) ជាភាសាសរសេរកម្មវិធីផ្សេងៗ រួមទាំង C/C++, Java និង Python ផងដែរ។ កំហុសអក្ខរាវិរុទ្ធនៅក្នុងចំណុចប្រទាក់អ្នកប្រើ ឬឯកសារក៏ជាកំហុសមួយដែរ!
ការធ្វើតេស្តការកំណត់រចនាសម្ព័ន្ធ (អំពីអ្វីដែលពួកគេមាន - សូមមើល។ នេះ и នេះ របាយការណ៍) ទោះបីជាត្រូវបានប្រតិបត្តិក្នុងដំណើរការសាកល្បងឯកតាដូចជា pytest ក៏ដោយ តាមពិតក៏ជាប្រភេទនៃការវិភាគឋិតិវន្តដែរ ដោយសារពួកគេមិនប្រតិបត្តិកូដប្រភពកំឡុងពេលប្រតិបត្តិរបស់ពួកគេ។

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

តើការវិភាគឋិតិវន្តប្រភេទណាខ្លះដែលអ្នកគួរប្រើក្នុងគម្រោងរបស់អ្នក? ពិតណាស់កាន់តែល្អ! រឿងសំខាន់គឺត្រូវអនុវត្តវាឱ្យបានត្រឹមត្រូវដែលនឹងត្រូវបានពិភាក្សាបន្ថែមទៀត។

បំពង់ចែកចាយជាតម្រងពហុដំណាក់កាល និងការវិភាគឋិតិវន្តជាដំណាក់កាលដំបូងរបស់វា។

ពាក្យប្រៀបធៀបបុរាណសម្រាប់ការរួមបញ្ចូលជាបន្តបន្ទាប់គឺជាបំពង់បង្ហូរប្រេងដែលតាមរយៈការផ្លាស់ប្តូរលំហូរ ពីការផ្លាស់ប្តូរកូដប្រភពរហូតដល់ការចែកចាយរហូតដល់ការផលិត។ លំដាប់ស្តង់ដារនៃដំណាក់កាលនៅក្នុងបំពង់នេះមើលទៅដូចនេះ៖

ការវិភាគឋិតិវន្ត
អូហូ
ការធ្វើតេស្តឯកតា
ការធ្វើតេស្តរួមបញ្ចូល
ការធ្វើតេស្ត UI
ការត្រួតពិនិត្យដោយដៃ

ការផ្លាស់ប្តូរដែលត្រូវបានបដិសេធនៅដំណាក់កាលទី N នៃបំពង់មិនត្រូវបានផ្ទេរទៅដំណាក់កាល N + 1 ទេ។

ហេតុអ្វីបានជាតាមវិធីនេះ ហើយមិនដូច្នេះ? នៅក្នុងផ្នែកសាកល្បងនៃបំពង់បង្ហូរប្រេង អ្នកសាកល្បងនឹងទទួលស្គាល់ពីរ៉ាមីតសាកល្បងដ៏ល្បី។

សាកល្បងពីរ៉ាមីត។ ប្រភព៖ អត្ថបទ Martin Fowler ។

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

ខ្ញុំចង់ផ្តល់ជូននូវភាពស្រដៀងគ្នាមួយនៅក្នុងទម្រង់នៃប្រព័ន្ធចម្រោះទឹកពហុដំណាក់កាល។ ទឹកកខ្វក់ (ការផ្លាស់ប្តូរជាមួយនឹងពិការភាព) ត្រូវបានផ្គត់ផ្គង់ទៅការបញ្ចូល;

តម្រងពហុដំណាក់កាល។ ប្រភព៖ វិគីមេឌាទូទៅ

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

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

គោលបំណងនៃ "អន្ទាក់ភក់" គឺដើម្បីបំបាត់ការធ្លាក់ជាបន្តបន្ទាប់ពីការចាប់យកពិការភាពធ្ងន់ធ្ងរ។ ជាឧទាហរណ៍ យ៉ាងហោចណាស់ អ្នកដែលធ្វើការពិនិត្យកូដមិនគួរត្រូវបានរំខានដោយកូដដែលបានធ្វើទ្រង់ទ្រាយមិនត្រឹមត្រូវ និងការបំពានលើស្តង់ដារការសរសេរកូដដែលបានបង្កើតឡើង (ដូចជាវង់ក្រចកបន្ថែម ឬសាខាដែលដាក់បញ្ចូលយ៉ាងជ្រៅពេក)។ កំហុសដូចជា NPEs គួរតែត្រូវបានចាប់បានដោយការធ្វើតេស្តឯកតា ប៉ុន្តែប្រសិនបើសូម្បីតែមុនពេលធ្វើតេស្ត អ្នកវិភាគបង្ហាញយើងថាកំហុសនឹងកើតឡើង វានឹងបង្កើនល្បឿនការជួសជុលរបស់វាយ៉ាងខ្លាំង។

ឥឡូវនេះខ្ញុំជឿថាវាច្បាស់ហើយថាហេតុអ្វីបានជាការវិភាគឋិតិវន្តមិនធ្វើអោយគុណភាពនៃផលិតផលប្រសើរឡើង ប្រសិនបើប្រើម្តងម្កាល ហើយគួរតែត្រូវបានប្រើជានិច្ចដើម្បីត្រងការផ្លាស់ប្តូរដែលមានពិការភាពសរុប។ សំណួរថាតើការប្រើឧបករណ៍វិភាគឋិតិវន្តនឹងកែលម្អគុណភាពនៃផលិតផលរបស់អ្នកគឺស្មើនឹងការសួរថា "តើទឹកដែលយកចេញពីស្រះកខ្វក់នឹងត្រូវបានកែលម្អគុណភាពនៃការផឹកដែរឬទេ ប្រសិនបើវាត្រូវបានឆ្លងកាត់ colander ដែរឬទេ?"

ការអនុវត្តទៅក្នុងគម្រោងកេរ្តិ៍ដំណែល

សំណួរជាក់ស្តែងសំខាន់មួយ៖ របៀបអនុវត្តការវិភាគឋិតិវន្តទៅក្នុងដំណើរការសមាហរណកម្មបន្តជា “ច្រកទ្វារគុណភាព”? នៅក្នុងករណីនៃការធ្វើតេស្តដោយស្វ័យប្រវត្តិអ្វីគ្រប់យ៉ាងគឺជាក់ស្តែង: មានសំណុំនៃការធ្វើតេស្តការបរាជ័យនៃពួកគេណាមួយគឺជាហេតុផលគ្រប់គ្រាន់ដើម្បីជឿថាការជួបប្រជុំគ្នាមិនបានឆ្លងកាត់ច្រកទ្វារគុណភាព។ ការប៉ុនប៉ងដំឡើងច្រកតាមវិធីដូចគ្នាដោយផ្អែកលើលទ្ធផលនៃការវិភាគឋិតិវន្តបានបរាជ័យ៖ មានការព្រមានអំពីការវិភាគច្រើនពេកនៅក្នុងកូដកេរ្តិ៍ដំណែល អ្នកមិនចង់ព្រងើយកន្តើយទាំងស្រុងនោះទេ ប៉ុន្តែវាក៏មិនអាចទៅរួចទេក្នុងការបញ្ឈប់ការដឹកជញ្ជូនផលិតផលផងដែរ។ ដោយសារតែវាមានការព្រមានរបស់អ្នកវិភាគ។

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

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

វិធីសាស្រ្តខាងក្រោមនៃការណែនាំច្រកទ្វារគុណភាពត្រូវបានគេស្គាល់:

កំណត់ដែនកំណត់លើចំនួនសរុបនៃការព្រមាន ឬចំនួននៃការព្រមានដែលបែងចែកដោយចំនួនបន្ទាត់នៃកូដ។ នេះដំណើរការមិនល្អទេ ពីព្រោះច្រកទ្វារបែបនេះអនុញ្ញាតដោយសេរីនូវការផ្លាស់ប្តូរដែលមានពិការភាពថ្មីឆ្លងកាត់ ដរាបណាដែនកំណត់របស់វាមិនត្រូវបានលើស។
ជួសជុលនៅពេលជាក់លាក់មួយ ការព្រមានចាស់ទាំងអស់នៅក្នុងកូដដែលមិនត្រូវបានអើពើ និងបដិសេធមិនបង្កើតនៅពេលដែលការព្រមានថ្មីកើតឡើង។ មុខងារនេះត្រូវបានផ្តល់ដោយ PVS-studio និងធនធានអនឡាញមួយចំនួន ឧទាហរណ៍ Codacy ។ ខ្ញុំមិនមានឱកាសធ្វើការនៅក្នុង PVS-studio ទេ ដូចជាបទពិសោធន៍របស់ខ្ញុំជាមួយ Codacy បញ្ហាចម្បងរបស់ពួកគេគឺការកំណត់ថាអ្វីជា "ចាស់" ហើយអ្វីដែលជា "ថ្មី" error គឺជាក្បួនដោះស្រាយស្មុគស្មាញដែលមិនតែងតែដំណើរការ។ ត្រឹមត្រូវ ជាពិសេសប្រសិនបើឯកសារត្រូវបានកែប្រែ ឬប្តូរឈ្មោះយ៉ាងខ្លាំង។ តាមបទពិសោធន៍របស់ខ្ញុំ Codacy អាចនឹងព្រងើយកន្តើយនឹងការព្រមានថ្មីនៅក្នុងសំណើរទាញមួយ ខណៈពេលដែលក្នុងពេលតែមួយមិនឆ្លងកាត់សំណើទាញដោយសារតែការព្រមានដែលមិនទាក់ទងទៅនឹងការផ្លាស់ប្តូរកូដនៃ PR ដែលបានផ្តល់ឱ្យ។
តាមគំនិតរបស់ខ្ញុំ ដំណោះស្រាយដ៏មានប្រសិទ្ធភាពបំផុតគឺការពិពណ៌នានៅក្នុងសៀវភៅ ការដឹកជញ្ជូនបន្ត "វិធីសាស្រ្តនៃការតោង" ។ គំនិតជាមូលដ្ឋានគឺថាចំនួននៃការព្រមានអំពីការវិភាគឋិតិវន្តគឺជាទ្រព្យសម្បត្តិនៃការចេញផ្សាយនីមួយៗ ហើយមានតែការផ្លាស់ប្តូរប៉ុណ្ណោះដែលត្រូវបានអនុញ្ញាតដែលមិនបង្កើនចំនួនសរុបនៃការព្រមាន។

Ratchet

វាដំណើរការតាមវិធីនេះ៖

នៅដំណាក់កាលដំបូង កំណត់ត្រាមួយត្រូវបានធ្វើឡើងនៅក្នុងទិន្នន័យមេតាអំពីការចេញផ្សាយចំនួននៃការព្រមាននៅក្នុងកូដដែលបានរកឃើញដោយអ្នកវិភាគ។ ដូច្នេះ នៅពេលអ្នកបង្កើតចរន្ត អ្នកគ្រប់គ្រងឃ្លាំងរបស់អ្នកសរសេរមិនត្រឹមតែ "ចេញផ្សាយ 7.0.2" ប៉ុណ្ណោះទេ ប៉ុន្តែ "ចេញផ្សាយ 7.0.2 ដែលមានការព្រមាន 100500 checkstyle ។" ប្រសិនបើអ្នកប្រើកម្មវិធីគ្រប់គ្រងឃ្លាំងកម្រិតខ្ពស់ (ដូចជា Artifactory) ការរក្សាទុកទិន្នន័យមេតាបែបនេះអំពីការចេញផ្សាយរបស់អ្នកគឺងាយស្រួល។
ឥឡូវនេះ សំណើទាញនីមួយៗ នៅពេលសាងសង់ ប្រៀបធៀបចំនួននៃការព្រមានលទ្ធផលជាមួយនឹងចំនួននៃការព្រមានដែលមាននៅក្នុងការចេញផ្សាយបច្ចុប្បន្ន។ ប្រសិនបើ PR នាំឱ្យមានការកើនឡើងនៃចំនួននេះ នោះលេខកូដមិនឆ្លងកាត់ច្រកគុណភាពសម្រាប់ការវិភាគឋិតិវន្តទេ។ ប្រសិនបើចំនួននៃការព្រមានថយចុះ ឬមិនផ្លាស់ប្តូរ នោះវាឆ្លងកាត់។
នៅការចេញផ្សាយបន្ទាប់ ចំនួនការព្រមានដែលបានគណនាឡើងវិញនឹងត្រូវបានកត់ត្រាម្តងទៀតនៅក្នុងទិន្នន័យមេតានៃការចេញផ្សាយ។

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

ក្រាហ្វនេះបង្ហាញពីចំនួនសរុបនៃការព្រមាន Checkstyle សម្រាប់រយៈពេលប្រាំមួយខែនៃប្រតិបត្តិការនៃ "ratchet" បែបនេះនៅលើ គម្រោងមួយក្នុងចំណោមគម្រោង OpenSource របស់យើង។. ចំនួននៃការព្រមានបានថយចុះតាមលំដាប់នៃរ៉ិចទ័រ ហើយវាបានកើតឡើងដោយធម្មជាតិ ស្របនឹងការអភិវឌ្ឍផលិតផល!

ខ្ញុំប្រើកំណែដែលបានកែប្រែនៃវិធីសាស្ត្រនេះ ដោយរាប់ដោយឡែកពីគ្នានូវការព្រមានដោយម៉ូឌុលគម្រោង និងឧបករណ៍វិភាគ ជាលទ្ធផលនៅក្នុងឯកសារ 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 កម្រិតខ្ពស់ណាមួយ ratchet អាចត្រូវបានអនុវត្តសម្រាប់ឧបករណ៍វិភាគឋិតិវន្តណាមួយដោយមិនពឹងផ្អែកលើកម្មវិធីជំនួយ និងឧបករណ៍ភាគីទីបី។ អ្នកវិភាគនីមួយៗបង្កើតរបាយការណ៍ផ្ទាល់ខ្លួនជាអត្ថបទសាមញ្ញ ឬទម្រង់ XML ដែលងាយស្រួលវិភាគ។ អ្វីដែលនៅសល់គឺត្រូវសរសេរតក្កវិជ្ជាចាំបាច់នៅក្នុងស្គ្រីប CI ។ អ្នកអាចមើលឃើញពីរបៀបដែលវាត្រូវបានអនុវត្តនៅក្នុងគម្រោងប្រភពបើកចំហរបស់យើងដោយផ្អែកលើ Jenkins និង Artifactory នៅទីនេះ ឬ នៅទីនេះ. ឧទាហរណ៍ទាំងពីរអាស្រ័យលើបណ្ណាល័យ ratchetlib៖ វិធីសាស្រ្ត countWarnings() រាប់ស្លាក xml នៅក្នុងឯកសារដែលបង្កើតដោយ Checkstyle និង Spotbugs តាមវិធីធម្មតា និង compareWarningMaps() អនុវត្ត ratchet ដូចគ្នាដោយបោះកំហុសនៅពេលដែលចំនួននៃការព្រមាននៅក្នុងប្រភេទណាមួយកើនឡើង។

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

អំពីសារៈសំខាន់នៃការជួសជុលកំណែឧបករណ៍វិភាគ

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

ការរកឃើញ

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