របៀបដែលយើងបានបកប្រែ 10 លានបន្ទាត់នៃកូដ C ++ ទៅស្តង់ដារ C ++ 14 (ហើយបន្ទាប់មកទៅ C ++ 17)

មួយរយៈមុន (ក្នុងរដូវស្លឹកឈើជ្រុះឆ្នាំ 2016) ក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍កំណែបន្ទាប់នៃវេទិកាបច្ចេកវិទ្យា 1C: Enterprise សំណួរបានកើតឡើងនៅក្នុងក្រុមអភិវឌ្ឍន៍អំពីការគាំទ្រស្តង់ដារថ្មី C ++ ១ នៅក្នុងកូដរបស់យើង។ ការផ្លាស់ប្តូរទៅស្តង់ដារថ្មី ដូចដែលយើងសន្មត់ថានឹងអនុញ្ញាតឱ្យយើងសរសេររឿងជាច្រើនកាន់តែឆើតឆាយ សាមញ្ញ និងអាចទុកចិត្តបាន ហើយនឹងជួយសម្រួលដល់ការគាំទ្រ និងការថែរក្សាកូដ។ ហើយហាក់ដូចជាគ្មានអ្វីអស្ចារ្យនៅក្នុងការបកប្រែនោះទេ ប្រសិនបើមិនមែនសម្រាប់ទំហំនៃមូលដ្ឋានកូដ និងលក្ខណៈជាក់លាក់នៃកូដរបស់យើង។

សម្រាប់អ្នកដែលមិនដឹង 1C:Enterprise គឺជាបរិយាកាសមួយសម្រាប់ការអភិវឌ្ឍន៍យ៉ាងឆាប់រហ័សនៃកម្មវិធីអាជីវកម្មឆ្លងវេទិកា និងរយៈពេលដំណើរការសម្រាប់ការប្រតិបត្តិរបស់ពួកគេនៅលើ OSes និង DBMSs ផ្សេងៗគ្នា។ ជាទូទៅផលិតផលមាន៖

• ចង្កោមម៉ាស៊ីនមេកម្មវិធីដំណើរការលើ Windows និង Linux
• អតិថិជនធ្វើការជាមួយម៉ាស៊ីនមេតាមរយៈ http(s) ឬពិធីការប្រព័ន្ធគោលពីររបស់វាផ្ទាល់ ដំណើរការលើ Windows, Linux, macOS
• ម៉ាស៊ីនភ្ញៀវគេហទំព័រដំណើរការនៅក្នុង Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari browsers (សរសេរក្នុង JavaScript)
• បរិស្ថាន​អភិវឌ្ឍន៍ (អ្នកកំណត់រចនាសម្ព័ន្ធ) ដំណើរការលើ Windows, Linux, macOS
• ឧបករណ៍រដ្ឋបាល ម៉ាស៊ីនមេកម្មវិធីដំណើរការលើ Windows, Linux, macOS
• ម៉ាស៊ីនភ្ញៀវចល័តការភ្ជាប់ទៅម៉ាស៊ីនមេតាមរយៈ http(s) ដំណើរការលើឧបករណ៍ចល័តដែលដំណើរការប្រព័ន្ធប្រតិបត្តិការ Android, iOS, Windows
• វេទិកាចល័ត - ក្របខណ្ឌសម្រាប់បង្កើតកម្មវិធីទូរស័ព្ទក្រៅបណ្តាញដែលមានសមត្ថភាពក្នុងការធ្វើសមកាលកម្ម ដំណើរការលើ Android, iOS, Windows
• បរិស្ថានអភិវឌ្ឍន៍ 1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាសសរសេរជាភាសាចាវ៉ា
• ម៉ាស៊ីនមេ ប្រព័ន្ធអន្តរកម្ម

យើងព្យាយាមសរសេរកូដដូចគ្នាសម្រាប់ប្រព័ន្ធប្រតិបត្តិការផ្សេងៗគ្នាតាមដែលអាចធ្វើទៅបាន - មូលដ្ឋានកូដម៉ាស៊ីនមេគឺជារឿងធម្មតា 99% មូលដ្ឋានកូដអតិថិជនគឺប្រហែល 95% ។ វេទិកាបច្ចេកវិទ្យា 1C:Enterprise ត្រូវបានសរសេរជាចម្បងនៅក្នុង C++ ហើយលក្ខណៈកូដប្រហាក់ប្រហែលត្រូវបានផ្តល់ឱ្យខាងក្រោម៖

• 10 លានបន្ទាត់នៃកូដ C ++,
• 14 ពាន់ឯកសារ,
• 60 ពាន់ថ្នាក់,
• វិធីសាស្រ្តពាក់កណ្តាលលាន។

ហើយអ្វីៗទាំងអស់នេះត្រូវបកប្រែទៅជា C++14។ ថ្ងៃនេះយើងនឹងប្រាប់អ្នកពីរបៀបដែលយើងបានធ្វើនេះ និងអ្វីដែលយើងបានជួបប្រទះនៅក្នុងដំណើរការនេះ។

អេស

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

អ្វីដែលយើងមាន

ដំបូងឡើយ យើងបានសរសេរកូដសម្រាប់វេទិកា 1C:Enterprise 8 ដោយប្រើ Microsoft Visual Studio។ គម្រោងនេះបានចាប់ផ្តើមនៅដើមទសវត្សរ៍ឆ្នាំ 2000 ហើយយើងមានកំណែសម្រាប់តែ Windows ប៉ុណ្ណោះ។ តាមធម្មជាតិ ចាប់តាំងពីពេលនោះមក កូដត្រូវបានបង្កើតឡើងយ៉ាងសកម្ម យន្តការជាច្រើនត្រូវបានសរសេរឡើងវិញទាំងស្រុង។ ប៉ុន្តែកូដត្រូវបានសរសេរតាមស្តង់ដារឆ្នាំ 1998 ហើយឧទាហរណ៍ តង្កៀបមុំខាងស្តាំរបស់យើងត្រូវបានបំបែកដោយដកឃ្លា ដូច្នេះការចងក្រងនឹងទទួលបានជោគជ័យដូចនេះ៖

vector<vector<int> > IntV;

នៅឆ្នាំ 2006 ជាមួយនឹងការចេញផ្សាយកំណែវេទិកា 8.1 យើងបានចាប់ផ្តើមគាំទ្រលីនុច ហើយប្តូរទៅបណ្ណាល័យស្តង់ដារភាគីទីបី STLPport. ហេតុផលមួយក្នុងចំណោមហេតុផលសម្រាប់ការផ្លាស់ប្តូរគឺដើម្បីធ្វើការជាមួយជួរធំទូលាយ។ នៅក្នុងកូដរបស់យើង យើងប្រើ std::wstring ដែលផ្អែកលើប្រភេទ wchar_t ពេញ។ ទំហំរបស់វានៅក្នុងវីនដូគឺ 2 បៃហើយនៅក្នុងលីនុចលំនាំដើមគឺ 4 បៃ។ នេះបាននាំឱ្យមានភាពមិនឆបគ្នានៃពិធីការប្រព័ន្ធគោលពីររបស់យើងរវាងម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ ក៏ដូចជាទិន្នន័យជាប់លាប់ផ្សេងៗ។ ដោយប្រើជម្រើស gcc អ្នកអាចបញ្ជាក់ថាទំហំនៃ wchar_t កំឡុងពេលចងក្រងគឺ 2 បៃផងដែរ ប៉ុន្តែបន្ទាប់មកអ្នកអាចភ្លេចអំពីការប្រើបណ្ណាល័យស្តង់ដារពីកម្មវិធីចងក្រងព្រោះ វាប្រើ glibc ដែលនៅក្នុងវេនត្រូវបានចងក្រងសម្រាប់ wchar_t 4 បៃ។ ហេតុផលផ្សេងទៀតគឺការអនុវត្តកាន់តែប្រសើរឡើងនៃថ្នាក់ស្តង់ដារ ការគាំទ្រសម្រាប់តារាង hash និងសូម្បីតែការធ្វើត្រាប់តាមអត្ថន័យនៃការផ្លាស់ប្តូរនៅក្នុងកុងតឺន័រ ដែលយើងប្រើប្រាស់យ៉ាងសកម្ម។ ហើយហេតុផលមួយទៀត ដូចដែលពួកគេនិយាយចុងក្រោយ គឺការសម្តែងខ្សែអក្សរ។ យើងមានថ្នាក់ផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ខ្សែ, ដោយសារតែ ... ដោយសារភាពជាក់លាក់នៃកម្មវិធីរបស់យើង ប្រតិបត្តិការខ្សែអក្សរត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយ ហើយសម្រាប់ពួកយើង នេះគឺសំខាន់ណាស់។

ខ្សែអក្សររបស់យើងគឺផ្អែកលើគំនិតបង្កើនប្រសិទ្ធភាពខ្សែអក្សរដែលបានបង្ហាញនៅដើមទសវត្សរ៍ឆ្នាំ 2000 Andrei Alexandrescu. ក្រោយមក នៅពេលដែល Alexandrescu ធ្វើការនៅ Facebook តាមការណែនាំរបស់គាត់ បន្ទាត់មួយត្រូវបានប្រើនៅក្នុងម៉ាស៊ីន Facebook ដែលធ្វើការលើគោលការណ៍ស្រដៀងគ្នា (សូមមើលបណ្ណាល័យ ល្ងីល្ងើ).

បន្ទាត់របស់យើងបានប្រើបច្ចេកវិទ្យាបង្កើនប្រសិទ្ធភាពសំខាន់ពីរ៖

1. សម្រាប់តម្លៃខ្លី សតិបណ្ដោះអាសន្នខាងក្នុងនៅក្នុងវត្ថុខ្សែអក្សរខ្លួនឯងត្រូវបានប្រើ (មិនទាមទារការបែងចែកអង្គចងចាំបន្ថែមទេ)។
2. សម្រាប់អ្នកផ្សេងទៀតទាំងអស់ មេកានិចត្រូវបានប្រើប្រាស់ ចម្លងនៅលើសរសេរ. តម្លៃ​ខ្សែអក្សរ​ត្រូវ​បាន​រក្សា​ទុក​នៅ​កន្លែង​មួយ ហើយ​បញ្ជរ​យោង​ត្រូវ​បាន​ប្រើ​កំឡុង​ពេល​ការ​ចាត់តាំង/ការ​កែប្រែ។

ដើម្បីបង្កើនល្បឿននៃការចងក្រងវេទិកា យើងបានដកចេញនូវការអនុវត្តស្ទ្រីមពីវ៉ារ្យ៉ង់ STLPport របស់យើង (ដែលយើងមិនបានប្រើ) វាផ្តល់ឱ្យយើងនូវការចងក្រងលឿនជាងប្រហែល 20% ។ ក្រោយមក យើងត្រូវប្រើប្រាស់មានកំណត់ ការជម្រុញ. Boost ធ្វើឱ្យការប្រើប្រាស់ស្ទ្រីមយ៉ាងខ្លាំង ជាពិសេសនៅក្នុង APIs សេវាកម្មរបស់វា (ឧទាហរណ៍ សម្រាប់ការចូល) ដូច្នេះយើងត្រូវកែប្រែវាដើម្បីលុបការប្រើប្រាស់ស្ទ្រីមចេញ។ នេះ​ជា​ការ​លំបាក​សម្រាប់​យើង​ក្នុង​ការ​ផ្ទេរ​ទៅ​កំណែ​ថ្មី​នៃ Boost។

វិធីទីបី

នៅពេលផ្លាស់ទីទៅស្តង់ដារ C ++ 14 យើងបានពិចារណាជម្រើសដូចខាងក្រោម:

1. ធ្វើបច្ចុប្បន្នភាព STLPport ដែលយើងកែប្រែទៅស្តង់ដារ C ++14 ។ ជម្រើសគឺពិបាកណាស់ព្រោះ ... ការគាំទ្រសម្រាប់ STLPport ត្រូវបានបញ្ឈប់នៅឆ្នាំ 2010 ហើយយើងនឹងត្រូវបង្កើតកូដរបស់វាទាំងអស់ដោយខ្លួនឯង។
2. ការផ្លាស់ប្តូរទៅការអនុវត្ត STL ផ្សេងទៀតដែលត្រូវគ្នាជាមួយ C++14 ។ វាជាការចង់បានយ៉ាងខ្លាំងដែលការអនុវត្តនេះគឺសម្រាប់ Windows និង Linux ។
3. នៅពេលចងក្រងសម្រាប់ OS នីមួយៗ សូមប្រើបណ្ណាល័យដែលបានបង្កើតឡើងនៅក្នុងកម្មវិធីចងក្រងដែលត្រូវគ្នា។

ជម្រើសទីមួយត្រូវបានច្រានចោលទាំងស្រុង ដោយសារតែការងារច្រើនពេក។

យើងបានគិតអំពីជម្រើសទីពីរសម្រាប់ពេលខ្លះ; ចាត់ទុកថាជាបេក្ខជន libc++ប៉ុន្តែនៅពេលនោះវាមិនដំណើរការនៅក្រោម Windows ទេ។ ដើម្បីច្រក libc++ ទៅកាន់ Windows អ្នកនឹងត្រូវធ្វើការងារជាច្រើន - ឧទាហរណ៍ សរសេរអ្វីគ្រប់យ៉ាងដោយខ្លួនឯងដែលទាក់ទងនឹងខ្សែស្រឡាយ ការធ្វើសមកាលកម្មខ្សែស្រឡាយ និងអាតូមិក ចាប់តាំងពី libc++ បានប្រើនៅក្នុងតំបន់ទាំងនេះ។ POSIX API.

ហើយយើងបានជ្រើសរើសវិធីទីបី។

ដំណើរផ្លាស់ប្តូរ

ដូច្នេះ យើងត្រូវជំនួសការប្រើប្រាស់ STLPort ជាមួយនឹងបណ្ណាល័យនៃកម្មវិធីចងក្រងដែលត្រូវគ្នា (Visual Studio 2015 for Windows, gcc 7 for Linux, clang 8 for macOS)។

ជាសំណាងល្អ កូដរបស់យើងត្រូវបានសរសេរជាចម្បងតាមការណែនាំ ហើយមិនប្រើល្បិចឆ្លាតវៃគ្រប់ប្រភេទ ដូច្នេះការផ្លាស់ប្តូរទៅកាន់បណ្ណាល័យថ្មីដំណើរការដោយរលូន ដោយមានជំនួយពីស្គ្រីបដែលជំនួសឈ្មោះប្រភេទ ថ្នាក់ ចន្លោះឈ្មោះ និងរួមបញ្ចូលនៅក្នុងប្រភព ឯកសារ។ ការធ្វើចំណាកស្រុកបានប៉ះពាល់ដល់ឯកសារប្រភពចំនួន 10 (ក្នុងចំណោម 000)។ wchar_t ត្រូវបានជំនួសដោយ char14_t; យើងបានសម្រេចចិត្តបោះបង់ចោលការប្រើប្រាស់ wchar_t ពីព្រោះ char000_t យក 16 បៃនៅលើ OS ទាំងអស់ ហើយមិនធ្វើឱ្យខូចកូដភាពត្រូវគ្នារវាង Windows និង Linux ទេ។

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

ដូច្នេះ ការធ្វើចំណាកស្រុកកូដត្រូវបានបញ្ចប់ កូដត្រូវបានចងក្រងសម្រាប់ប្រព័ន្ធប្រតិបត្តិការទាំងអស់។ ដល់ពេលធ្វើតេស្តហើយ។

ការធ្វើតេស្តបន្ទាប់ពីការផ្លាស់ប្តូរបានបង្ហាញពីការធ្លាក់ចុះនៃការអនុវត្ត (នៅកន្លែងខ្លះរហូតដល់ 20-30%) និងការកើនឡើងនៃការប្រើប្រាស់អង្គចងចាំ (រហូតដល់ 10-15%) បើប្រៀបធៀបទៅនឹងកំណែចាស់នៃកូដ។ ជាពិសេស នេះគឺដោយសារតែដំណើរការល្អបំផុតនៃខ្សែស្តង់ដារ។ ដូច្នេះ យើង​ត្រូវ​ប្រើ​បន្ទាត់​ដែល​បាន​កែប្រែ​បន្តិច​ម្ដង​ទៀត​។

លក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍នៃការអនុវត្តកុងតឺន័រនៅក្នុងបណ្ណាល័យដែលបានបង្កប់ក៏ត្រូវបានបង្ហាញផងដែរ: ទទេ (ដោយគ្មានធាតុ) std::map និង std:: កំណត់ពីបណ្ណាល័យដែលភ្ជាប់មកជាមួយបែងចែកអង្គចងចាំ។ ហើយដោយសារតែលក្ខណៈពិសេសនៃការអនុវត្ត នៅកន្លែងខ្លះនៅក្នុងកូដ ធុងទទេជាច្រើននៃប្រភេទនេះត្រូវបានបង្កើតឡើង។ ធុងផ្ទុកអង្គចងចាំស្តង់ដារត្រូវបានបែងចែកបន្តិចបន្តួចសម្រាប់ធាតុ root មួយ ប៉ុន្តែសម្រាប់ពួកយើង វាបានប្រែក្លាយថាមានសារៈសំខាន់ - នៅក្នុងសេណារីយ៉ូមួយចំនួន ដំណើរការរបស់យើងបានធ្លាក់ចុះយ៉ាងខ្លាំង ហើយការប្រើប្រាស់អង្គចងចាំបានកើនឡើង (បើប្រៀបធៀបទៅនឹង STLPort) ។ ដូច្នេះហើយ នៅក្នុងកូដរបស់យើង យើងបានជំនួសកុងតឺន័រទាំងពីរប្រភេទនេះពីបណ្ណាល័យដែលភ្ជាប់មកជាមួយដោយការអនុវត្តរបស់ពួកគេពី Boost ដែលកុងតឺន័រទាំងនេះមិនមានលក្ខណៈពិសេសនេះ ហើយបញ្ហានេះបានដោះស្រាយបញ្ហាជាមួយនឹងការថយចុះ និងបង្កើនការប្រើប្រាស់អង្គចងចាំ។

ដូចដែលជាញឹកញាប់កើតឡើងបន្ទាប់ពីការផ្លាស់ប្តូរទ្រង់ទ្រាយធំនៅក្នុងគម្រោងធំ ការសរសេរឡើងវិញដំបូងនៃកូដប្រភពមិនដំណើរការដោយគ្មានបញ្ហាទេ ហើយជាពិសេសនៅទីនេះ ការគាំទ្រសម្រាប់កម្មវិធីកែកំហុសក្នុងការអនុវត្តវីនដូគឺមានប្រយោជន៍។ មួយជំហានម្តងៗ យើងឈានទៅមុខ ហើយនៅនិទាឃរដូវឆ្នាំ 2017 (កំណែ 8.3.11 1C:Enterprise) ការធ្វើចំណាកស្រុកត្រូវបានបញ្ចប់។

លទ្ធផល

ការផ្លាស់ប្តូរទៅស្តង់ដារ C ++14 បានចំណាយពេលប្រហែល 6 ខែ។ ភាគច្រើន អ្នកអភិវឌ្ឍន៍ម្នាក់ (ប៉ុន្តែមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់ខ្លាំង) បានធ្វើការលើគម្រោង ហើយនៅដំណាក់កាលចុងក្រោយ អ្នកតំណាងក្រុមដែលទទួលខុសត្រូវលើផ្នែកជាក់លាក់ដែលបានចូលរួមនៅក្នុង - UI, ចង្កោមម៉ាស៊ីនមេ, ការអភិវឌ្ឍន៍ និងឧបករណ៍គ្រប់គ្រងជាដើម។

ការផ្លាស់ប្តូរនេះបានធ្វើឱ្យការងាររបស់យើងកាន់តែងាយស្រួលលើការផ្លាស់ប្តូរទៅកំណែចុងក្រោយបំផុតនៃស្តង់ដារ។ ដូច្នេះ កំណែ 1C: សហគ្រាស 8.3.14 (នៅក្នុងការអភិវឌ្ឍន៍ ការចេញផ្សាយដែលបានគ្រោងទុកនៅដើមឆ្នាំក្រោយ) ត្រូវបានផ្ទេរទៅស្តង់ដាររួចហើយ។ C++ ១៧.

បន្ទាប់ពីការធ្វើចំណាកស្រុក អ្នកអភិវឌ្ឍន៍មានជម្រើសកាន់តែច្រើន។ ប្រសិនបើពីមុនយើងមានកំណែកែប្រែផ្ទាល់ខ្លួនរបស់យើងនៃ STL និងមួយ std namespace ឥឡូវនេះយើងមានថ្នាក់ស្តង់ដារពីបណ្ណាល័យចងក្រងដែលភ្ជាប់មកជាមួយនៅក្នុង std namespace ក្នុង stdx namespace - បន្ទាត់ និងកុងតឺន័ររបស់យើងបានធ្វើឱ្យប្រសើរសម្រាប់កិច្ចការរបស់យើងនៅក្នុងការជំរុញ - the កំណែចុងក្រោយបំផុតនៃការជំរុញ។ ហើយអ្នកអភិវឌ្ឍន៍ប្រើថ្នាក់ទាំងនោះដែលសមស្របបំផុតដើម្បីដោះស្រាយបញ្ហារបស់គាត់។

ការអនុវត្ត "ដើម" នៃអ្នកសាងសង់ផ្លាស់ទីក៏ជួយក្នុងការអភិវឌ្ឍន៍ផងដែរ (ផ្លាស់ទីអ្នកសាងសង់) សម្រាប់ថ្នាក់មួយចំនួន។ ប្រសិនបើ class មាន move constructor ហើយ class នេះត្រូវបានដាក់ក្នុង container នោះ STL បង្កើនប្រសិទ្ធភាពការចម្លងធាតុនៅក្នុង container (ឧទាហរណ៍ នៅពេលដែល container ត្រូវបានពង្រីក ហើយវាចាំបាច់ក្នុងការផ្លាស់ប្តូរសមត្ថភាព និង relocate memory)។

ហោះទៅក្នុងមួន

ប្រហែលជាផលវិបាកមិនល្អបំផុត (ប៉ុន្តែមិនសំខាន់) នៃការធ្វើចំណាកស្រុកគឺថាយើងប្រឈមមុខនឹងការកើនឡើងនៃបរិមាណ ឯកសារ objហើយ​លទ្ធផល​ពេញលេញ​នៃ​ការ​បង្កើត​ជាមួយ​នឹង​ឯកសារ​កម្រិត​មធ្យម​ទាំងអស់​បាន​ចាប់ផ្តើម​យក​ទំហំ 60-70 GB។ ឥរិយាបថនេះគឺដោយសារតែលក្ខណៈពិសេសរបស់បណ្ណាល័យស្ដង់ដារទំនើប ដែលមិនសូវសំខាន់ចំពោះទំហំនៃឯកសារសេវាកម្មដែលបានបង្កើត។ នេះមិនប៉ះពាល់ដល់ប្រតិបត្តិការនៃកម្មវិធីដែលបានចងក្រងនោះទេ ប៉ុន្តែវាបណ្តាលឱ្យមានការរអាក់រអួលមួយចំនួនក្នុងការអភិវឌ្ឍន៍ ជាពិសេសវាបង្កើនពេលវេលាចងក្រង។ តម្រូវការសម្រាប់ទំហំថាសឥតគិតថ្លៃនៅលើម៉ាស៊ីនមេបង្កើត និងនៅលើម៉ាស៊ីនអ្នកអភិវឌ្ឍន៍ក៏កំពុងកើនឡើងផងដែរ។ អ្នកអភិវឌ្ឍន៍របស់យើងធ្វើការលើកំណែជាច្រើននៃវេទិកាស្របគ្នា ហើយឯកសារកម្រិតមធ្យមរាប់រយជីហ្គាបៃជួនកាលបង្កើតការលំបាកក្នុងការងាររបស់ពួកគេ។ បញ្ហា​នេះ​មិន​សប្បាយចិត្ត ប៉ុន្តែ​មិន​ធ្ងន់ធ្ងរ​ទេ យើង​បាន​ពន្យារពេល​ដំណោះស្រាយ​សម្រាប់​ពេលនេះ​។ យើងកំពុងពិចារណាបច្ចេកវិទ្យាជាជម្រើសមួយក្នុងចំណោមជម្រើសសម្រាប់ដោះស្រាយវា។ ការកសាងឯកភាព (ជាពិសេស Google ប្រើវានៅពេលបង្កើតកម្មវិធីរុករក Chrome) ។

ប្រភព: www.habr.com