ការប្រើប្រាស់ Dependency ក្នុងការ​សរសេរសូហ្វវែរ៍

ក្នុងការ​សរសេរសូហ្វវែរ៍សព្វថ្ងៃនេះ យើងតែងតែប្រើកូដ ឫសូហ្វវែរ៍ដែលមានស្រាប់មកប្រើជាជាង​សរសេរ​ខ្លួន​ឯងទាំងអស់​ (Reuse)។ ហើយក្នុងការ​យក​កូដដែលមានស្រាប់លើអុីធឺណេត​មកប្រើនេះ (Package, Library ឫ Module) ដែលយើងហៅវាថា Dependency។ ការប្រើ Dependency នេះជួយឲ្យយើងអាច​សរសេរកូដបានលឿន និងងាយស្រួលជាងមុនដោយ​យកកូដដែលមានស្រាប់ដែលគេបានចែករំលែកជាលក្ខណៈ Open Source មកប្រើ​ទៅ​តាម​ការ​ដែល​យើង​ត្រូវការ។

អ្វីទៅជា Dependency ឲ្យប្រាកដ?

Dependency ជា​កូដដែលយើង​យកប្រើនៅក្នុង Project របស់យើងក្នុងលក្ខណៈ Package, Library ឫ Module ជំនួសឲ្យការដែលត្រូវ​សរសេរ​ខ្លួនឯង។

ជាទូទៅ​ស្ទើរតែ​គ្រប់ភាសាប្រូក្រាមីង​ទៅហើយ​ដែលមាន Registry ដែលអាចឲ្យប្រូក្រាមើរ៍អាចចែករំលែកកូដ​ដែល​គេ​សរសេរ​ហើយ​ឲ្យ​ទៅ​ប្រូក្រាមើរ៍ផ្សេងទៀតអាចប្រើបានយ៉ាងងាយស្រួល។

ឧទាហរណ៍៖

• ចាវ៉ាស្ក្រីបត៍ និងណូដមាន NPM ជា​ Registry។
• Golang មាន Pkg ជា​ Registry។
• Rust មាន​ Crates ជា​ Registry។
• Elixir និង Erlang មាន​ Hex ជាដើម។

នៅក្នុង Registry នីមួយៗមាន Package រាប់ម៉ឺនរាប់សែនដែលយើងអាច​យក​មក​ប្រើបាន។ Package មានច្រើនឫតិច វាអាស្រ័យទៅតាមប្រជាប្រិយភាព​របស់ភាសាប្រូក្រាមីងនីមួយៗ​។

ក្នុងភាសានីមួយៗគេតែងតែមាន Package Manager ដែលជួយឲ្យការយក Package មកប្រើមានភាពងាយស្រួលមែនទែន។ ស្រួលពេកដល់រហូតពេលត្រូវការធ្វើអ្វីមួយ យើងសឹងតែងតែយកកូដដែលគេសរសេរហើយស្រាប់មកប្រើដោយមិនដឹងខ្លួនទាំងដែលកូដនោះយើងអាច​សរសេរបានដោយខ្លួន​ឯងតែពីរបីបន្ទាត់ប៉ុណ្ណោះ។

ជាឧទារហណ៍​ Package មួយនៅក្នុង NPM ដែលមានឈ្មោះថា is-odd មានអ្នកទាញទៅប្រើរហូដដល់ជិតកន្លះលាន​ដងក្នុងមួយសប្ដាហ៍ទាំងដែលវាមិនចាំបាច់សោះ។ យើងអាច​សរសេរខ្លួន​ឯងបានដោយងាយស្រួលក្នុងមួយបន្ទាត់បានដូចខាងក្រោម តែបែជាគេទៅប្រើ Package ខាងក្រៅទៅវិញ។

const isOdd = (num) => num % 2 === 1;

នេះវាបញ្ជាក់ពីការប្រើប្រាស់ Dependency ច្រើនហួសហេតុដោយមិនខ្វល់ និងគិតថាចាំបាច់ដែរឫ​អត់។

បើគ្រាន់តែប្រើ Dependency តើវាមានបញ្ហាអ្វីទៅ?

យើងបាននិយាយហើយថាការដែលយើងប្រើ Dependency គឺជាការដែលយើង​យក​កូដពីអ៉ីនធឺណិត​មក​ប្រើក្នុង Project របស់យើង។​ ថ្វីតែការធ្វើបែបនេះវាធ្វើឲ្យការងារ​របស់​យើងងាយស្រួូល និងលឿនជាងវិញក៏ពិតមែន តែកូដដែលយើង​យក​មក​ដាក់ចូលក្នុង Project របស់យើងនេះជាកូដដែល​សរសេរ​ដោយអ្នកណាក៏មិនដឹងនៅលើអ៉ីនធឺណិត យើងមិននឹងស្គាល់ផង។ អ៊ីចឹងវាមានន័យថាកម្មវិធីដែលយើង​សរសេរដំណើរការល្អ ឫមិនល្អ វាអាស្រ័យលើ Dependency ដែលយើងប្រើនោះ។ វាអាស្រ័យថា Dependency នោះមានកំហុស ឫដំណើការខុសប្រកតីតិចឫច្រើនដែរ។ បើយ៉ាងនេះ ​វាពិតជាគ្រោះថ្នាក់ណាស់ក្នុងការយក Dependency មកប្រើនីមួយៗ! បើយើងប្រើ Dependency កាន់តែច្រើន នោះហានិភ័យដែលយើងប្រឈម​ក៏វាកាន់តែច្រើនតាមនោះដែរ។

គួរមើលអ្វីខ្លះមុននឹងប្រើ Dependency ណាមួយ

ការប្រើ Dependency វា​ប្រឈម​នឹងហានីភ័យដែលអាចនឹងកើតឡើងដោយយើងអាចនឹងមិនគិតដល់ជាមុនបាន។ អ៊ីចឹងហើយមុននឹងប្រើ Package ណាមួយនោះ យើងគួរសិក្សាពីវាជាមុនបន្តិចសិន។ ពេលខ្លះបន្ទាប់ពីពិនិត្យមើល Package ដែលយើងនឹងប្រើនោះហើយ វាអាចនឹងមានបញ្ហាតិចតួច។ មិនអីនោះទេ យើងអាចប្រើវាបាន។ យើងអាច​សរសេរកូដដែលជួយកែបញ្ហាបន្តិចនឹងបាន។ តែបើមើលហើយ យើងឃើញមានបញ្ហាធំដំច្រើនដែលអាចនឹងកើតឡើងនោះ យើងប្រហែលជាមិនគួរប្រើ Package នោះទេ។ យើងអាចរក Package ដែលស្រឌៀង​មកប្រើជំនួស ឫបើអាច​សរសេរដោយខ្លួន​ឯងតែម្ដងក៏ល្អ។

បើអ៊ីចឹងយើងគួមើលអ្វីខ្លះទៅ? បើផ្អែកតាម​ឯកសារសិក្សាស្រាវជ្រាវ “Our Software Dependency Problem” របស់លោក Russ Cox ដែលគាត់បានបោះពុម្ភកាលពីឆ្នាំ 2019។ លោកបានធ្វើការនៅ Google ជាច្រើនឆ្នាំ ហើយលោកក៏ធ្លាប់ធ្វើការលើ​ Dependency សម្រាប់ភាសា Golang ផងដែរ។ លោកបានណែនាំឲ្យពិនិត្យមើលលើចំនុចដូចខាងក្រោមនេះ៖

1. ឌីហ្សាញ

យើងគួរពិនិត្យមើល Documentation របស់ Package ថាតើគេបានពន្យល់ពីរបៀបប្រើបានងាយស្រួលដែរឫទេ។ បើគេពន្យល់បានល្អ នោះវាមានន័យថាកូដដែលគេសរសេរ​មកនោះវាសាមញ្ញ និងអាចនឹងត្រូវបានគេ​សរសេរ​បានល្អ ហើយប្រហែលជាមិនសូវមានកំហុសច្រើនដែរ។

2. គុណភាពកូដ

ទៅបើមើលប្រភព​កូដដើម​របស់ Package (ជាទូទៅវានៅលើ Github) ហើយសាកអានលមើល។ យើងនឹងដឹងថាកូដដែលត្រូវ​សរសេរឡើង​មក​ដោយ​យកចិត្តទុក ច្បាស់លាស់ ហើយយើងអាចយល់វាបានដែរឫទេ។ ព្រោះថាពេលខ្លះយើងប្រហែលជាមកត្រូវព្យាយាមយល់វា ហើយនិងកែកំហុសដែលយើងជួបពេលយើងប្រើ Package ហ្នឹងឯង។

3. តេស្ត

តើ Package ដែលយើងនឹងប្រើនោះគេមានតេស្តដែរឫទេ? បើមាន តើតេស្តនោះជាតេស្តដែលតេស្តកូដបានគ្រប់គ្រាន់ដែរ​ឫ​អត់? តើយើងអាចរាន់តេស្តនេះបានទេ? បើអាចរាន់បាន តើជាប់គ្រប់ករណីដែរឫទេ? Package ដែលមានតេស្តល្អ វាមានន័យថា Package នោះមានគុណភាពល្អ និងមិនសូវមានកំហុសឆ្គងទៅតាមនោះដែរ។

4. Debugging

សាក​រកមើល Issue Tracker របស់ Package (ភាគច្រើននៅលើ Github) ហើយមើលថាតើមានគេរាយការណ៍ Bug ឫ បញ្ហាច្រើនដែរក៏អត់? មាន Issue ប៉ុន្មានដែលត្រូវបានគេកែ? មានកែថ្មីៗនេះទេ? បើមាន Issue ច្រើន តើគេបើក Issue នោះមកយូរប៉ុណ្ណាហើយជាដើម។ បើឃើញមានគេបើក Issue ច្រើន ហើយគេកែបានបិទ Issue បានលឿននោះជាការល្អណាស់។ តែបើមិនសូវមានចម្លើយទេ ហើយឃើញមានទុកបើកចោលច្រើននោះ គួរតែគិតមើលសិនដែរមុននឹងយក Package នោះមកប្រើ។

5. Maintenance

យើងគួរតែមើលប្រវត្តិ Commit របស់ Package។ តើគេបានធ្វើការលើ Package នេះមកយូរប៉ុណ្ណាហើយ? តើមានមនុស្សប៉ុន្មាននាក់ធ្វើការលើគម្រោង Package មួយហ្នឹង? ជាទូទៅ Package ដែលគេធ្វើការលើវាច្រើន គេនឹងបន្តអាប់ដេតវាបន្តទៀត។

6. ការប្រើប្រាស់

ការដែលមានគេប្រើ Package ច្រើនជារឿងល្អ។ លើសពីហ្នឹងទៀតមើលថាមាន Package ផ្សេងៗ​យក Package ដែលយើងគិតនឹងប្រើនេះទៅប្រើដែរឫទេ? បើមានគេប្រើកាន់តែច្រើន នោះវាកាន់តែល្អ។

ទី១នោះគឺបញ្ហាដែលអាចនឹងកើតមាននឹងត្រូវបាន​រកឃើញយ៉ាងឆាប់រហ័ស មានគេរាយការណ៍ពីបញ្ហាច្រើន ដែលជម្រុញឲ្យគេដោះស្រាយបានលឿន។ លើសពីនេះអ្នកដែលគាត់មានគំនិតល្អៗពេលដែលគាត់ប្រើ Package គាត់ក៏អាចលើកឡើង​មកជាសំនូមពរ ឫពេលខ្លះគាត់លើកឡើង​មកជា Pull Request តែម្ដងក៏មាន។

ទី២វិញនោះគឺថាយើងនឹងអាច​រកបានឧទាហរណ៍ពីការប្រើប្រាស់វាបានបន្ថែមទៀតពីលើឯកសារ​របស់ Package ព្រោះថាអ្នកដែលប្រើ Package នេះដែរអាចនឹង​សរសេរពីបទពិសោធន៍ការប្រើប្រាស់របស់គេជាប្លក់ ឫក៏ធ្វើជាវីដេអូបង្រៀនក៏ថាបាន។

7. សុវត្តិភាព

បើយើងត្រូវធ្វើសូហ្វវែរ៍ដែលត្រូវការសុវត្តិភាពខ្ពស់នោះ ការជ្រើសរើសប្រើ Package ណាមួយនោះយើងត្រូវតែពិនិត្យឲ្យច្បាស់លាស់សិន។ យើងគួរមើលថាតើ Package ធ្លាប់មានបញ្ហាទាក់ទងនឹងសុវត្តិភាពដែរឫទេ? ជាឧទាហរណ៍យើងអាចចូលមើលក្នុង NVD (National Vulnerability Database) ដែលជាកន្លែងតម្កល់ប្រវត្តិបញ្ហាសុវត្តិភាពសូហ្វវែរ៍ផ្សេងៗដែលយើងអាច​រកមើលបានតាមឆ្នាំ ឫអាច​រកបានតាម Keyword។

8. License

Package ភាគច្រើនជារបស់ Open Source ក៏ពិតមែនតែក៏ត្រូវមាន License ត្រឹមត្រូវដែរ។ License មានច្រើនប្រភេទជាឧទាហរណ៍ Apache License, BSD2, BSD3, GNU General Public License, GNU Library, MIT license និង Mozilla Public License ជាដើម ហើយ License នីមួយៗបានកំណត់សិទ្ធិ និងលក្ខខណ្ឌប្រើប្រាស់ផ្សេងៗគ្នា។​ អ៊ីចឹងហើយយើងគួរមើលថា License របស់ Package ត្រូវជាមួយនឹងបរិបទប្រើប្រាស់របស់យើងដែរឫក៏អត់។

9. Dependencies របស់ Package

ជាទូទៅ Package ដែលយើងនឹងប្រើជា Dependency ក៏អាចនឹងត្រូវការ Package ជាច្រើន​ផងដែរ ហើយគេហើយវាថា Transitive Dependencies ឫ Indirect Dependencies។ បញ្ហាដែលកើតមានក្នុង Transitive Dependencies ក៏អាចនឹងមាន​ផលប៉ះពាល់ដល់សូហ្វវែរ៍យើងដូច Dependency ដែលយើងប្រើផ្ទាល់ដែរ (វាអាស្រ័យលើថាគេបានចាត់ការកំហុសនោះបានល្អទេនោះក្នុង Package នោះ)។

ឧទាហរណ៍មួយ៖ កាលពីខែ មិនា ឆ្នាំ 2016 បណ្ណាល័យជាច្រើនរួមមានបណ្ណាល័យល្បីៗមួយចំនួនដូចជា Babel, Ember, React ប្រើ Package មួយឈ្មោះថា left-pad។ left-pad ជា Package ដែលជួយបន្ថែមខ្ទង់ឲ្យ string ហើយ Package នេះមានកូដតែ 8 បន្ទាត់ប៉ុណ្ណោះ។

// ការប្រើ left-pad
const leftPad = require('left-pad')

console.log(leftPad(1, 5, 0))
// "00001"

console.log(leftPad('d7', 4))
// "  d7"

ពេលនោះនៅសុខៗ ស្រាប់តែមានមនុស្សជាច្រើន (កន្លះផែនដី 😂) មិនអាចរាន់កូដ​របស់គេបានព្រោះដោយសារតែម្ចាស់ left-pad បានលុបវាចេញពី NPM។ ការលុប left-pad ចេញនេះបានប៉ះពេលអ្នកប្រើ Package ដោយផ្ទាល់ និងអ្នកប្រើ Package នេះដោយប្រយោលតាម Package ផ្សេងៗគេប្រើ។

10. តេស្ត Dependency

បើយើងសម្រេចថានឹងប្រើ Package ហ្នឹងមួយហើយ យើងគួរតែសរសេរតេស្តមុខងារ​របស់ Package ដែលយើងនឹងប្រើក្នុងគម្រោង​របស់​យើង។ ការ​សរសេរតេស្ដនេះនឹងជួយឲ្យយើងយល់ពីមុខងារ​របស់ Package កាន់តែច្បាស់ថាវាដូចអ្វីដែលយើងត្រូវការដែរឫក៏អត់។ ការដែលមានតេស្ដសម្រាប់ Package ក៏នឹងជួយយើងពេលក្រោយដែរពេលដែល Package ចេញកំណែថ្មីយើងនឹងអាចដឹងភ្លាមថាកំណែថ្មីនេះនៅរក្សារមុខងារដែលយើងត្រូវការ​ឫ​អត់ផងដែរ។

11. Abstract Dependency

ការដែលយើងប្រើ Dependency ណាមួយនោះមិនមែនបានន៏យថាយើងនឹងត្រូវប្រើវារហូតនោះទេ។ ពេលក្រោយៗ​មក យើងអាចនឹងត្រូវជំនួស Package ដោយអ្វីផ្សេងដែលល្អជាងនេះ ឫពេលក្រោយមក Package ដែលយើងប្រើមានបញ្ហាសុវត្ថិភាពដែលបង្ខំឲ្យយើងត្រូវឈប់ប្រើវា។ យើងអាចនឹងមិនដឹងមុនទេ។ អ៊ីចឹងហើយយើងគួរធ្វើយ៉ាងណាដើម្បីឲ្យយើងអាចប្ដូរ ឫឈប់ប្រើវាបានងាយស្រួលបាន។

បើសិនជាយើងប្រើ Package នេះនៅច្រើនកន្លែងក្នុងកូដ​របស់យើងនេះ ពេលយើងត្រូវប្ដូរទៅ Package ផ្សេង ឫចង់ឈប់ប្រើវានោះ យើងនឹងត្រូវទៅកែកូដនៅច្រើនកន្លែងដែលជារឿងលំបាកមួយ។ អ្វីដែលយើងអាចធ្វើបាននោះគឺយើងអាច​សរសេរ wrapper មួយសម្រាប់មុខងារដែលយើងត្រូវការពី Package។ ជំនួសឲ្យការហៅមុខងារ​របស់ Package មកប្រើផ្ទាល់ យើងគ្រាន់តែប្រើ wrapper ជំនួសវិញជាការស្រេច។ ពេលយើងត្រូវជំនួស Package ពេលក្រោយ យើងគ្រាន់តែកែ wrapper ក៏ហើយរួចរាល់ទៅហើយ។ នេះហើយគុណតម្លៃនៃ Abstraction។

12. ដាក់ Dependency ឲ្យដំណើរការក្នុង Process មួយដាច់ដោយឡែក

ការដាក់ Package ឲ្យដំណើរការក្នុង Process ដាច់ដោយឡែកជារឿងល្អណាស់គឺថាវានឹងកាត់បន្ថាយហានិភ័យដែលអាចបង្កឡើងដោយ Package នោះ។

ជាឧទាហរណ៍ ប្រៅស័រ Google Chrome អាចឲ្យអ្នកប្រើអាចថែមមុខងារបន្ថែមជា Dependency ចូលក្នុងប្រៅស័របានដែលគេហៅវាថា Extension។ Extension នីមួយៗត្រូវដំណើរការក្នុង Sandbox មួយដែលរាន់ក្នុង Process ដាច់ដោយឡែកពីប្រៅស័រ និង Extension ផ្សេងទៀត។ ការធ្វើបែបនេះ គេអាចជៀសផុតពីបញ្ហា ឫហានិភ័យទាក់ទងនឹងសុវត្តិភាពដែលបង្កឡើងដោយ Extension នោះបានព្រោះថា Extension នឹងមិនអាចចូលដល់ក្នុងមេម៉ូរីទាំងមូល​របស់ប្រៅស័របានទេ ហើយគេក៏អាចកំណត់សិទ្ធិហៅមុខងារផ្សេងៗ​របស់ប្រព័ន្ធប្រត្តិបត្តិការបាន​ផងដែរ។

13. បើនៅតែគិតថាការប្រើ Dependency អាចនឹងជួបបញ្ហាច្រើន ជៀសវាងប្រើវាតែម្ដង

ចូរចាំប្រយោគមួយមុនពេលដែលយើងយក Package ណាមួយ​មកប្រើ។ ពាក្យនោះគឺ “You don’t need <package-name> just for <function you need>”។ ពាក្យនេះនឹងជួួយឲ្យយើងរើសប្រើតែ Package ណាដែលចាំបាច់ប៉ុណ្ណោះ។

ពេលខ្លះទៅអ្វីដែលយើងត្រូវការមិនមែន Package នោះទាំងមូលទេ ឫការប្រើ Package ទាំងមូលមានបញ្ហាច្រើន ឫមួយ Package មានបញ្ហាសុវត្តិភាពដែលគេបាន​រកឃើញ និងដាក់ចូល NVD ហើយយើងគ្រាន់តែផ្នែកមួយនៃ Package ប៉ុណ្ណោះ។ ក្នង​ករណីនេះ យើងអាចមានជម្រើសដូចជា៖

• Copy កូដដែលត្រូវការ​មកដាក់ចូលក្នុង Project យើងផ្ទាល់
• Clone Package មកកែហើយដាក់វាប្រើជា Local Package
• Clone មកកែបញ្ហាហើយដាក់សំណើរចូលទៅ Package ដើមវិញជា Pull Request
• Clone មកកែ នឹងទុកតែមុខងារដែលចាំបាច់ហើយធ្វើវាទៅជា​ Package ថ្មីមួយទៀតក៏បាន

វាមានជម្រើសច្រើនដែលយើងអាចធ្វើបាន ហើយយើងអាចរើស​យក​ជម្រើសណាមួយក៏បានទៅតាមកាលៈទេសៈជាក់ស្ដែង។

14. អាប់ហ្គ្រេដ Dependency

យើងតែងតែនិយាយថា “បើកូដវាដើរហើយ កុំប៉ះពាល់វា!” ជារឿងពិត តែពេលមានកំណែថ្មីពី Package ដែលយើងប្រើ សំណួរកើតឡើងនោះគឺ “តើយើងគួរអាប់ហ្គ្រេដ​មកកំណែថ្មីដែរឫទេ?” មុខងារដែលយើងប្រើអាចនឺងនៅតែដដែល ហើយឥឡូវកូដវាដើរហើយ ចាំបាច់អីយើងត្រូវអាប់ហ្គ្រេដនោះ? មិនអញ្ចឹង!

ត្រូវ! តែការអាប់ហ្គ្រេដ Dependency មកប្រើកំណែថ្មីមានអត្ថប្រយោជន៍ 2 ធំៗ៖

• ទីមួយនោះគឺ កំណែថ្មីអាចនឹងមានមុខងារថ្មីដែលវាល្អជាងមុខងារដែលយើងកំពុងតែប្រើ ឫគេបានកែបញ្ហាផ្សេងៗជាពិសេសបញ្ហាទាក់ទងនឹងសុវត្តិភាព។
• ទីពីរវិញនោះគឺ ចង់មិនចង់យូរទៅមុខទៅ យើងនឹងត្រូវអាប់ហ្គ្រេដដដែលនៅទីបំផុត។ ហើយយើងអាចជៀសផុតពីការដែលយើងត្រូវកែរកូដច្រើនពេលដែលយើងអាប់ហ្គ្រេដជារឿយៗ។ ចូរចាំថាការកែកូដច្រើនស្មើរនឹងភាគ​រយដែលមានបញ្ហាច្រើនដែលអាចកើតមានដែរ។

អ៊ីចឹងហើយយើងគួរទុកពេលមួយមួយផ្នែកសម្រាប់សិក្សាពី Dependency ដែលយើងត្រូវអាប់ហ្គ្រេដ។ ហើយសម្រាប់ការងារនេះយើងអាចប្រើរបស់ជំនួយបានផងដែរ សម្រាប់ Daseveny ខ្ញុំប្រើ Dependabot។

15. ឃ្លាំមើល និងពិនិត្យមើល Dependency

ចុងក្រោយគេនោះគឺបើយើងសម្រេចប្រើ Package មួយហ្នឹងហើយ ហើយវាដំណើរការល្អហើយនៅក្នុង​សូហ្វវែរ៍​ដែល​យើង​សរសេរ​ហើយ យើងមិនទាន់អស់ភារៈកិច្ច​យើងនៅឡើយទេ។ យើងគួរតែនៅតាមតានវាជារឿយៗ ហើយបើឃើញមានបញ្ហាមិនប្រកតីអ្វីមួយនោះ យើងត្រូវគិតឡើងវិញហើយថាយើងនៅប្រើវាបានតទៀតដែរឫទេ។

យើងគួរតែប្រើកំណែដែលយើងបានសិក្សាថានឹងប្រើ ដោយធ្វើឲ្យប្រាកដថាបើយើងប្រើកំណែទី 1 នោះអ្វីដែល Packager Manager ទាញមកឲ្យយើងនោះគឺកំណែទី 1 ពិតមែន មិនមែនកំណែណាផ្សេងទេ។ អ្វីដែលយើងត្រូវធ្វើនោះគឺ “Pin Dependency”។

ជាឧទាហរណ៍សម្រាប់ណូដនោះយើងមាន package.json ដែលជាហ្វាល់ដែលយើងអាចប្រាប់ NPM ថាយើងត្រូវការ Package ណាខ្លះជា Dependency។ ហើយសម្រាប់ Package នីមួយៗយើងអាចប្រាប់បានថាយើងប្រើកំណែណាបាន។ សម្រាប់ការកំណត់កំណែដែលយើងត្រូវការនេះ យើងអាចមាន​ជម្រើសដូចជា៖

• បើយើងចង់បានតែ Patch Update នោះយើងអាចកំណត់ជា <package-name>: 1.0 ឫ <package-name>: 1.0.x ឫ <package-name>: ~1.0.0 (~ អានថា Tilde ឫ ថីលដា) នោះ NPM នឹង​យកតែ Patch Update តែប៉ុណ្ណោះ។
• បើយើងចង់បាន New Feature មិនមែនកំណែដែលមានកូដ Backward Incompatible នោះយើងអាចកំណត់ជា <package-name>: 1 ឫ <package-name>: 1.x ឫ <package-name>: ^1.0.0 (^ អានថា Caret ឫ ខារេត)។
• បើយើងចង់ Pin Dependency វិញនោះយើងអាចកំណត់កំណែជាក់ស្ដែងតែម្ដង។ ឧទាហរណ៍ <package-name>: 1.0.2 នឹងច្បាស់ថាយើងនឹងមិនប្រើកំណែផ្សេងខុសពី 1.0.2 នោះទេ។

បន្ថែមពីលើកំណត់កំណែនេះផងដែរ Package Manager ភាគច្រើនក៏មានហ្វាល់មួយទៀតដើម្បីកត់កូដ​របស់ Package ជា Hash ផងដែរ។ បើក្នុងណូដ គេហៅហ្វាល់នោះថា package-lock.json ហ្នឹងឯង។ រាល់ពេលដែលយើង Install Dependency នោះវានឹងឆែកមើលថា Source Code ដែលទទួលបានដូចគ្នានឹងការ Install លើកមុនដែរឫ​អត់តាមរយះ Hash ហ្នឹង​ផងដែរ។

សរុបសេចក្ដី

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

ឯកសារយោង៖ Our Software Dependency Problem by Russ Cox (January 23, 2019)