សមាហរណកម្មបន្តជាការអនុវត្ត មិនមែន Jenkins ទេ។ Andrey Alexandrov

សូមពិភាក្សាអំពីមូលហេតុដែលឧបករណ៍ CI និង CI គឺជារឿងខុសគ្នាទាំងស្រុង។

តើការឈឺចាប់អ្វីដែល CI មានបំណងដើម្បីដោះស្រាយ តើគំនិតនេះមកពីណា អ្វីជាការបញ្ជាក់ចុងក្រោយបង្អស់ដែលវាដំណើរការ របៀបយល់ថាអ្នកមានការអនុវត្ត ហើយមិនមែនគ្រាន់តែដំឡើង Jenkins នោះទេ។

គំនិតនៃការបង្កើតរបាយការណ៍អំពីសមាហរណកម្មបន្តបានលេចឡើងកាលពីមួយឆ្នាំមុន នៅពេលដែលខ្ញុំទៅសម្ភាសន៍ និងស្វែងរកការងារធ្វើ។ ខ្ញុំបានពិភាក្សាជាមួយក្រុមហ៊ុន 10-15 មានតែក្រុមហ៊ុនមួយប៉ុណ្ណោះដែលអាចឆ្លើយយ៉ាងច្បាស់ថា CI ជាអ្វី និងពន្យល់ពីរបៀបដែលពួកគេដឹងថាពួកគេមិនមានវា។ អ្នកដែលនៅសល់កំពុងនិយាយមិនសមហេតុសមផលដែលមិនអាចយល់បានអំពី Jenkins :) មែនហើយ យើងមាន Jenkins វាបង្កើតបាន CI! ក្នុងអំឡុងពេលនៃរបាយការណ៍ ខ្ញុំនឹងព្យាយាមពន្យល់ពីអ្វីដែលជា Continuous Integration ពិតប្រាកដ ហើយហេតុអ្វីបានជា Jenkins និងឧបករណ៍ស្រដៀងគ្នាមានទំនាក់ទំនងខ្សោយខ្លាំងជាមួយរឿងនេះ។

ដូច្នេះ​តើ​អ្វី​ដែល​ជា​ធម្មតា​មក​ក្នុង​ចិត្ត​ពេល​ដែល​អ្នក​ឮ​ពាក្យ CI? មនុស្សភាគច្រើននឹងគិតពី Jenkins, Gitlab CI, Travis ជាដើម។

ទោះបីជាយើង google វាក៏ដោយ វានឹងផ្តល់ឱ្យយើងនូវឧបករណ៍ទាំងនេះ។

ប្រសិនបើអ្នកស៊ាំនឹងការសួរ បន្ទាប់មកភ្លាមៗបន្ទាប់ពីរាយបញ្ជីឧបករណ៍ ពួកគេនឹងប្រាប់អ្នកថា CI គឺនៅពេលដែលអ្នកបង្កើត និងដំណើរការការធ្វើតេស្តនៅក្នុង Pull Request for a commit។

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

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

ហើយពួកគេបានដោះស្រាយការឈឺចាប់នៃការធ្វើការរួមគ្នាជាក្រុម!

សូមក្រឡេកមើលឧទាហរណ៍នៃការលំបាកដែលអ្នកអភិវឌ្ឍន៍ជួបប្រទះនៅពេលអភិវឌ្ឍជាក្រុម។ នៅទីនេះយើងមានគម្រោងមួយ សាខាមេនៅក្នុង git និងអ្នកអភិវឌ្ឍន៍ពីរនាក់។

ហើយ​ពួក​គេ​បាន​ទៅ​ធ្វើ​ការ​ដូច​អ្នក​រាល់​គ្នា​បាន​ទម្លាប់​យូរ​មក​ហើយ។ យើង​បាន​យក​កិច្ចការ​មួយ​ក្នុង​គម្រោង​ដ៏​ធំ​នៃ​វត្ថុ បង្កើត​សាខា​លក្ខណៈ និង​សរសេរ​កូដ។

មួយបានបញ្ចប់មុខងារកាន់តែលឿន ហើយបញ្ចូលវាទៅក្នុងមេ។

ទីពីរត្រូវការពេលវេលាបន្ថែមទៀត វាបានបញ្ចូលគ្នានៅពេលក្រោយ ហើយបញ្ចប់ដោយជម្លោះ។ ឥឡូវនេះ ជំនួសឱ្យការសរសេរលក្ខណៈពិសេសដែលអាជីវកម្មត្រូវការ អ្នកអភិវឌ្ឍន៍ចំណាយពេលវេលា និងថាមពលរបស់គាត់ដើម្បីដោះស្រាយជម្លោះ។

វាកាន់តែលំបាកក្នុងការបញ្ចូលគ្នានូវមុខងាររបស់អ្នកជាមួយមេទូទៅ នោះយើងចំណាយពេលកាន់តែច្រើនលើវា។ ហើយខ្ញុំបានបង្ហាញរឿងនេះជាមួយនឹងឧទាហរណ៍ដ៏សាមញ្ញមួយ។ នេះគឺជាឧទាហរណ៍ដែលមានអ្នកអភិវឌ្ឍន៍តែ 2 នាក់ប៉ុណ្ណោះ ស្រមៃមើលប្រសិនបើមនុស្ស 10 ឬ 15 ឬ 100 នាក់នៅក្នុងក្រុមហ៊ុនមួយសរសេរទៅកាន់ឃ្លាំងមួយ។ អ្នកនឹងឆ្កួតដើម្បីដោះស្រាយជម្លោះទាំងអស់នេះ។

មានករណីខុសគ្នាបន្តិចបន្តួច។ យើងមានមេ និងអ្នកអភិវឌ្ឍន៍មួយចំនួនកំពុងធ្វើអ្វីមួយ។

ពួកគេបានបង្កើតមែកឈើមួយ។

មនុស្សម្នាក់បានស្លាប់ អ្វីគ្រប់យ៉ាងគឺល្អ គាត់ឆ្លងកាត់ភារកិច្ច។

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

ក្នុងអំឡុងពេលនេះ អ្នកអភិវឌ្ឍន៍ទីពីរបានធ្វើអ្វីមួយផ្សេងទៀត។

ទីមួយបានបញ្ចប់កិច្ចការទីបី។

ហើយបន្ទាប់ពីមួយរយៈក្រោយមក ការពិនិត្យរបស់គាត់ត្រូវបានសាកល្បង ហើយគាត់កំពុងព្យាយាមសម្រេច។ ដូច្នេះ​តើ​មាន​អ្វី​កើត​ឡើង? វាចាប់បានចំនួនដ៏ច្រើននៃជម្លោះ។ ហេតុអ្វី? ដោយសារតែខណៈពេលដែលសំណើទាញរបស់គាត់កំពុងព្យួរនៅក្នុងការពិនិត្យឡើងវិញនោះ មានរឿងជាច្រើនបានផ្លាស់ប្តូរនៅក្នុងកូដរួចហើយ។

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

វាប្រែថាប្រសិនបើយើងធ្វើការជាក្រុម ពោលគឺមិនមែនមនុស្សណាម្នាក់ដើរលេងក្នុងឃ្លាំងទេ ប៉ុន្តែមនុស្ស 5-10 នាក់ នោះយូរជាងយើងមិនបន្ថែមកូដរបស់យើងទៅមេ នោះយើងកាន់តែរងទុក្ខព្រោះយើងត្រូវការ។ អ្វីមួយបន្ទាប់មកបញ្ចូលគ្នា។ ហើយ​យើង​មាន​ជម្លោះ​កាន់​តែ​ច្រើន ហើយ​កំណែ​ចាស់​ដែល​យើង​ធ្វើ​ការ​ជាមួយ​យើង​កាន់​តែ​មាន​បញ្ហា។

ធ្វើ​អ្វី​ជាមួយ​គ្នា​ឈឺ​ចាប់! យើង​តែង​តែ​ដើរ​តាម​ផ្លូវ​គ្នា​ទៅ​វិញ​ទៅ​មក។

បញ្ហានេះត្រូវបានកត់សម្គាល់ជាង 20 ឆ្នាំមុន។ ខ្ញុំបានរកឃើញការលើកឡើងដំបូងនៃការអនុវត្តនៃការរួមបញ្ចូលជាបន្តបន្ទាប់ក្នុងការសរសេរកម្មវិធីខ្លាំង។

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

ឥឡូវនេះយើងនឹងវិភាគឃ្លា "ការរួមបញ្ចូលជាបន្ត" រៀងៗខ្លួន។ ប្រសិនបើយើងបកប្រែវាដោយផ្ទាល់ យើងទទួលបានការរួមបញ្ចូលជាបន្តបន្ទាប់។ ប៉ុន្តែ​ការ​បន្ត​វា​មិន​ច្បាស់​លាស់​ទេ​។ ប៉ុន្តែ​ការ​រួមបញ្ចូល​គ្នា​ប៉ុន្មាន​ក៏​មិន​ច្បាស់​ដែរ​។

ហើយនោះហើយជាមូលហេតុដែលខ្ញុំផ្តល់ឱ្យអ្នកនូវសម្រង់ពី Extreme Programming ឥឡូវនេះ។ ហើយយើងនឹងវិភាគពាក្យទាំងពីរដោយឡែកពីគ្នា។

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

សមាហរណកម្ម គឺនៅពេលដែលយើងយកសាខារបស់យើង ហើយបញ្ចូលវាជាមួយមេ យើងបញ្ចូលវាចូលគ្នា។ មានជម្រើសចុងក្រោយនៅពេលដែលយើងជាអ្នកអភិវឌ្ឍន៍ transbase ដែលជាកន្លែងដែលយើងខិតខំដើម្បីធានាថាយើងសរសេរភ្លាមៗទៅមេដោយគ្មានសាខាបន្ថែម។

ជាទូទៅ ការរួមបញ្ចូលមានន័យថាយកលេខកូដរបស់អ្នកហើយអូសវាទៅក្នុងមេ។

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

ហើយអ្នកអភិវឌ្ឍន៍ដែលបង្កើតអ្វីមួយគឺទទួលខុសត្រូវចំពោះអ្វីដែលគាត់បានធ្វើដើម្បីធ្វើឱ្យវាដំណើរការនិងមិនធ្វើឱ្យខូចអ្វីទាំងអស់។ នេះគឺជាកន្លែងដែលរឿងសាកល្បងជាធម្មតាចេញមក។ យើងចង់ដំណើរការការធ្វើតេស្តមួយចំនួនលើការប្តេជ្ញាចិត្តរបស់យើង ក្នុងការបញ្ចូលគ្នារបស់យើង ដើម្បីប្រាកដថាវាដំណើរការ។ ហើយនេះគឺជាកន្លែងដែល Jenkins អាចជួយអ្នកបាន។

ប៉ុន្តែជាមួយនឹងរឿង៖ ចូរធ្វើការកែប្រែឱ្យតូច អនុញ្ញាតឱ្យកិច្ចការតូចតាច បង្កើតបញ្ហា ហើយព្យាយាមបញ្ចូលវាទៅក្នុងមេភ្លាមៗ - គ្មាន Jenkins នឹងជួយនៅទីនេះទេ។ ដោយសារតែ Jenkins នឹងជួយអ្នកឱ្យដំណើរការការធ្វើតេស្តប៉ុណ្ណោះ។

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

សូមស្រមៃថាសម្រាប់ហេតុផលមួយចំនួនយើងនៅឆ្នាំ 2020 ដោយគ្មានអ៊ីនធឺណិត។ ហើយយើងធ្វើការក្នុងស្រុក។ យើងមិនមាន Jenkins ទេ។ នេះល្អណាស់។ អ្នកនៅតែអាចបន្តធ្វើសាខាក្នុងស្រុកបាន។ អ្នកសរសេរកូដខ្លះនៅក្នុងនោះ។ យើងបានបញ្ចប់កិច្ចការក្នុងរយៈពេល 3-4 ម៉ោង។ យើងបានប្តូរទៅជាមេ ធ្វើ git pull និងបញ្ចូលសាខារបស់យើងនៅទីនោះ។ រួចរាល់។ ប្រសិនបើអ្នកធ្វើបែបនេះញឹកញាប់ សូមអបអរសាទរ អ្នកមានសមាហរណកម្មបន្ត!

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

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

ប៉ុន្តែ តើ​យើង​មាន​ភស្តុតាង​ពាក់ព័ន្ធ​ណា​មួយ​នៅ​ពេល​នេះ​ដែល​ប្រាប់​យើង​ថា​ការ​វិនិយោគ​ក្នុង​ការ​អនុវត្ត​នេះ​មាន​ន័យ​ទេ?

រឿងដំបូងដែលចូលមកក្នុងគំនិតរបស់ខ្ញុំគឺរដ្ឋ DevOps ។ នេះ​ជា​ការ​សិក្សា​ដែល​បុរស​បាន​ធ្វើ​អស់​រយៈពេល​៧​ឆ្នាំ​មក​ហើយ។ ឥឡូវនេះពួកគេធ្វើវាជាអង្គការឯករាជ្យ ប៉ុន្តែនៅក្រោម Google ។

ហើយការសិក្សាឆ្នាំ 2018 របស់ពួកគេបានបង្ហាញពីការជាប់ទាក់ទងគ្នារវាងក្រុមហ៊ុនដែលព្យាយាមប្រើសាខាដែលមានអាយុកាលខ្លីដែលរួមបញ្ចូលយ៉ាងឆាប់រហ័ស រួមបញ្ចូលញឹកញាប់ និងមានសូចនាករប្រតិបត្តិការ IT កាន់តែប្រសើរ។

តើសូចនាករទាំងនេះជាអ្វី? ទាំងនេះគឺជាម៉ែត្រចំនួន 4 ដែលពួកគេយកពីក្រុមហ៊ុនទាំងអស់នៅក្នុងកម្រងសំណួររបស់ពួកគេ៖ ភាពញឹកញាប់នៃការដាក់ពង្រាយ ពេលវេលានាំមុខសម្រាប់ការផ្លាស់ប្តូរ ពេលវេលាដើម្បីស្ដារសេវាកម្មឡើងវិញ ការផ្លាស់ប្តូរអត្រាបរាជ័យ។

ហើយជាដំបូង មានភាពជាប់ទាក់ទងគ្នានេះ យើងដឹងថាក្រុមហ៊ុនដែលវាស់វែងជាញឹកញាប់មានម៉ែត្រប្រសើរជាងមុន។ ហើយពួកគេមានការបែងចែកក្រុមហ៊ុនទៅជាប្រភេទជាច្រើន៖ ទាំងនេះគឺជាក្រុមហ៊ុនយឺតដែលផលិតអ្វីមួយយឺត អ្នកសំដែងមធ្យម អ្នកសំដែងខ្ពស់ និងឥស្សរជន។ ឥស្សរជនគឺ Netflix, Amazon ដែលមានល្បឿនលឿន ធ្វើអ្វីគ្រប់យ៉ាងបានរហ័ស ស្រស់ស្អាត និងមានប្រសិទ្ធភាព។

រឿងទីពីរដែលបានកើតឡើងកាលពីមួយខែមុន។ Technology Radar មានអត្ថបទដ៏អស្ចារ្យអំពី Gitflow ។ Gitflow គឺខុសពីអ្នកផ្សេងទៀតទាំងអស់ ដែលសាខារបស់វាមានអាយុវែង។ មាន​សាខា​ចេញ​ដែល​រស់​នៅ​ក្នុង​រយៈ​ពេល​យូរ និង​មាន​សាខា​ដែល​រស់​បាន​យូរ​ផង​ដែរ។ ការអនុវត្តនេះនៅបច្ចេកវិទ្យារ៉ាដាបានផ្លាស់ប្តូរទៅ កាន់។ ហេតុអ្វី? ដោយសារតែមនុស្សប្រឈមមុខនឹងការឈឺចាប់នៃការរួមបញ្ចូល។

ប្រសិនបើសាខារបស់អ្នករស់នៅបានយូរ វាជាប់គាំង រលួយ ហើយយើងចាប់ផ្តើមចំណាយពេលវេលាបន្ថែមទៀត ដើម្បីព្យាយាមផ្លាស់ប្តូរប្រភេទរបស់វា។

ហើយថ្មីៗនេះអ្នកនិពន្ធនៃ Gitflow បាននិយាយថាប្រសិនបើគោលដៅរបស់អ្នកគឺការរួមបញ្ចូលជាបន្ត ប្រសិនបើគោលដៅរបស់អ្នកគឺអ្នកចង់រមៀលឱ្យបានញឹកញាប់តាមដែលអាចធ្វើបាននោះ Gitflow គឺជាគំនិតអាក្រក់។ គាត់បានបន្ថែមដោយឡែកពីគ្នានៅក្នុងអត្ថបទថា ប្រសិនបើអ្នកមាន backend ដែលអ្នកអាចព្យាយាមសម្រាប់រឿងនេះ នោះ Gitflow គឺអស្ចារ្យសម្រាប់អ្នក ព្រោះ Gitflow នឹងធ្វើឱ្យអ្នកយឺត Gitflow នឹងបង្កើតបញ្ហាសម្រាប់អ្នកជាមួយនឹងការរួមបញ្ចូល។

នេះមិនមានន័យថា Gitflow អាក្រក់ ហើយមិនគួរប្រើទេ។ វាគឺសម្រាប់ឱកាសផ្សេងទៀត។ ឧទាហរណ៍ នៅពេលដែលអ្នកត្រូវការគាំទ្រកំណែជាច្រើននៃសេវាកម្ម ឬកម្មវិធី ឧ. ដែលជាកន្លែងដែលអ្នកត្រូវការជំនួយក្នុងរយៈពេលយូរ។

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

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

វាហាក់បីដូចជាយើងកំពុងធ្វើអ្វីមួយរួចហើយ វាហាក់បីដូចជាយើងកំពុងបញ្ចូលគ្នារួចហើយ ប៉ុន្តែតើយើងអាចយល់បានថាយើងនៅតែមានការរួមបញ្ចូលជាបន្តបន្ទាប់ ដែលយើងកំពុងបញ្ចូលគ្នាជាញឹកញាប់?

Jez Humble គឺជាអ្នកនិពន្ធសៀវភៅ Handbook, Accelerate, គេហទំព័រចែកចាយបន្ត និងសៀវភៅ Continuous Delivery។ គាត់ផ្តល់ជូនការធ្វើតេស្តនេះ៖

• លេខកូដរបស់វិស្វករទទួលបានទៅមេជារៀងរាល់ថ្ងៃ។
• រាល់ការប្តេជ្ញាចិត្ត អ្នកដំណើរការការធ្វើតេស្តឯកតា។
• ការសាងសង់នៅក្នុងមេបានធ្លាក់ចុះវាត្រូវបានជួសជុលក្នុងរយៈពេលប្រហែល 10 នាទី។

គាត់ស្នើឱ្យប្រើតេស្តបែបនេះ ដើម្បីប្រាកដថាអ្នកមានការអនុវត្តគ្រប់គ្រាន់។

ខ្ញុំ​រក​ឃើញ​ថា​ក្រោយ​មក​មាន​ភាព​ចម្រូង​ចម្រាស​បន្តិច។ នោះគឺប្រសិនបើអ្នកអាចជួសជុលវាក្នុងរយៈពេល 10 នាទី នោះអ្នកមានការរួមបញ្ចូលជាបន្តបន្ទាប់ វាស្តាប់ទៅដូចជាចម្លែកបន្តិចតាមគំនិតរបស់ខ្ញុំ ប៉ុន្តែវាសមហេតុផល។ ហេតុអ្វី? ព្រោះប្រសិនបើអ្នកបង្កកញឹកញាប់ វាមានន័យថាការផ្លាស់ប្តូររបស់អ្នកតូច។ ប្រសិនបើការផ្លាស់ប្តូរតូចមួយមានន័យថាការស្ថាបនាមេរបស់អ្នកត្រូវបានខូច នោះអ្នកអាចស្វែងរកឧទាហរណ៍បានយ៉ាងឆាប់រហ័សព្រោះការផ្លាស់ប្តូរគឺតូច។ នៅទីនេះអ្នកមានការរួមបញ្ចូលគ្នាតូចមួយ 20-30 បន្ទាត់នៅក្នុងវាបានផ្លាស់ប្តូរ។ ហើយតាមនោះ អ្នកអាចយល់បានយ៉ាងរហ័សថា មូលហេតុមកពីអ្វី ពីព្រោះការផ្លាស់ប្តូរមានទំហំតូច អ្នកមានតំបន់តូចមួយដើម្បីស្វែងរកបញ្ហា។

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

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

នេះ​ជា​ការ​ណែនាំ​សង្ខេប​អំពី​ការ​ធ្វើ​សមាហរណកម្ម​បន្ត។ នោះហើយជាអ្វីទាំងអស់ដែលមានចំពោះការអនុវត្តនេះ។ ខ្ញុំត្រៀមខ្លួនសម្រាប់សំណួរ។

ខ្ញុំនឹងសង្ខេបឡើងវិញដោយសង្ខេប៖

• សមាហរណកម្មបន្តមិនមែនជា Jenkins ទេ វាមិនមែនជា Gitlab ទេ។
• នេះមិនមែនជាឧបករណ៍ទេ វាគឺជាការអនុវត្តដែលយើងបញ្ចូលកូដរបស់យើងទៅក្នុងមេឱ្យបានញឹកញាប់តាមដែលអាចធ្វើទៅបាន។
• យើងធ្វើបែបនេះដើម្បីជៀសវាងការឈឺចាប់ដ៏ធំដែលកើតឡើងជាមួយនឹងការបញ្ចូលគ្នានាពេលអនាគត ពោលគឺយើងជួបប្រទះការឈឺចាប់បន្តិចបន្តួចនៅពេលនេះ ដើម្បីកុំឱ្យជួបប្រទះច្រើននៅពេលអនាគត។ នោះហើយជាចំណុចទាំងមូល។
• នៅផ្នែកខាងមានការទំនាក់ទំនងតាមរយៈកូដ ប៉ុន្តែខ្ញុំកម្រឃើញរឿងនេះណាស់ ប៉ុន្តែនេះក៏ជាអ្វីដែលវាត្រូវបានរចនាឡើងសម្រាប់ផងដែរ។

សំណួរ

អ្វីដែលត្រូវធ្វើជាមួយកិច្ចការដែលមិនរលួយ?

រលួយ។ មាន​បញ្ហា​អ្វី? តើ​អ្នក​អាច​ផ្តល់​ជា​ឧទាហរណ៍​ថា​មាន​កិច្ចការ​មួយ​ហើយ​វា​មិន​ត្រូវ​បាន​បំផ្លាញ​ទេ?

មានកិច្ចការដែលមិនអាចបំបែកចេញពីពាក្យ "ទាំងស្រុង" ជាឧទាហរណ៍ ការងារដែលត្រូវការជំនាញជ្រៅជ្រះ ហើយដែលពិតជាអាចដោះស្រាយបានក្នុងរយៈពេលមួយខែ ដើម្បីសម្រេចបាននូវលទ្ធផលដែលអាចរំលាយបាន។

ប្រសិនបើខ្ញុំយល់អ្នកបានត្រឹមត្រូវ នោះមានកិច្ចការធំ និងស្មុគស្មាញខ្លះ លទ្ធផលដែលអាចមើលឃើញត្រឹមតែមួយខែ?

បាទ​វា​គឺ​ត្រឹមត្រូវ។ បាទ/ចាស វាអាចវាយតម្លៃលទ្ធផលមិនលឿនជាងមួយខែ។

ល្អ ជាទូទៅនេះមិនមែនជាបញ្ហាទេ។ ហេតុអ្វី? ដោយសារតែក្នុងករណីនេះនៅពេលដែលយើងនិយាយអំពី twigs យើងមិននិយាយអំពី twig ដែលមានលក្ខណៈពិសេសមួយ។ លក្ខណៈពិសេសអាចមានទំហំធំនិងស្មុគស្មាញ។ ពួកវាអាចប៉ះពាល់ដល់សមាសធាតុមួយចំនួនធំ។ ហើយប្រហែលជាយើងមិនអាចធ្វើវាទាំងស្រុងនៅក្នុងសាខាតែមួយបានទេ។ នេះល្អណាស់។ យើងគ្រាន់តែត្រូវការបំបែករឿងនេះចុះ។ ប្រសិនបើលក្ខណៈពិសេសមួយមិនទាន់រួចរាល់ទាំងស្រុងទេ នេះមិនមានន័យថាបំណែកមួយចំនួននៃកូដរបស់វាមិនអាចបញ្ចូលចូលគ្នាបានទេ។ អ្នកបានបន្ថែម និយាយថា ការធ្វើចំណាកស្រុក ហើយមានដំណាក់កាលមួយចំនួននៅក្នុងមុខងារនេះ។ ចូរនិយាយថាអ្នកមានដំណាក់កាលមួយ - ធ្វើចំណាកស្រុក បន្ថែមវិធីសាស្រ្តថ្មី។ ហើយអ្នកអាចវាស់វែងរបស់ទាំងនេះជារៀងរាល់ថ្ងៃ។

ល្អ តើ​មាន​ចំណុច​អ្វី​នោះ?

តើ​ការ​សម្លាប់​របស់​តូច​ៗ​ជា​រៀង​រាល់​ថ្ងៃ​មាន​រឿង​អ្វី?

បាទ។

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

សូមអរគុណ បញ្ហាត្រូវបានបិទ!

(Oleg Soroka) តើខ្ញុំអាចបន្ថែមបានទេ? អ្នកនិយាយបានត្រឹមត្រូវ ខ្ញុំគ្រាន់តែចង់បន្ថែមមួយឃ្លា។

ដូច្នេះ។

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

យើងបាននិយាយអំពីរង្វាស់ 4 ដែលបែងចែកក្រុមហ៊ុនជោគជ័យពីក្រុមហ៊ុនដែលយឺតយ៉ាវ។ យើង​នៅ​តែ​ត្រូវ​រស់​នៅ​ដើម្បី​មើល​ម៉ែត្រ​ទាំង ៤ នេះ។ ប្រសិនបើការងារជាមធ្យមរបស់អ្នកចំណាយពេលមួយខែដើម្បីបញ្ចប់ នោះខ្ញុំនឹងផ្តោតលើម៉ែត្រនេះជាមុនសិន។ ខ្ញុំនឹងបន្ថយវាទៅ 4 ថ្ងៃដំបូង។ ហើយបន្ទាប់ពីនោះខ្ញុំចាប់ផ្តើមគិតអំពី បន្ត។

តើខ្ញុំយល់អ្នកបានត្រឹមត្រូវទេថា អ្នកគិតថាជាទូទៅគ្មានចំណុចណាមួយក្នុងការវិនិយោគលើការអនុវត្តវិស្វកម្មទេ ប្រសិនបើកិច្ចការណាមួយត្រូវចំណាយពេលមួយខែដើម្បីបញ្ចប់?

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

ហើយតើអ្នកមានជម្រើសអ្វី? ប្រសិនបើអ្នកបង្វិលលេខកូដមកវិញ នោះវាមិនអាចដំណើរការជាមួយមូលដ្ឋានទិន្នន័យដែលបានធ្វើបច្ចុប្បន្នភាពនេះទៀតទេ។

មូលដ្ឋានគ្រាន់តែផ្លាស់ទីទៅមុខបាទ។

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

ដើម្បីធ្វើជាម្ចាស់នៃការអនុវត្តពេញលេញដែលគាំទ្រដល់ការរួមបញ្ចូលជាបន្តបន្ទាប់ និងការចែកចាយបន្ត វាមិនគ្រប់គ្រាន់ទេក្នុងការរៀនពីរបៀបសរសេរ .... ទីមួយវាអាចមានច្រើននៃពួកវាវានឹងមិនអាចអនុវត្តបាន។ លើសពីនេះ មានការអនុវត្តជាច្រើនទៀតដូចជា Scientific ។ មានការអនុវត្តបែបនេះ GitHub បានពេញនិយមវាក្នុងពេលតែមួយ។ នេះគឺជាពេលដែលអ្នកមានទាំងកូដចាស់ និងកូដថ្មីដំណើរការក្នុងពេលតែមួយ។ នេះគឺជាពេលដែលអ្នកបង្កើតមុខងារដែលមិនទាន់បានបញ្ចប់ ប៉ុន្តែវាអាចត្រឡប់តម្លៃមួយចំនួន៖ ជាមុខងារ ឬជា Rest API។ អ្នកប្រតិបត្តិទាំងកូដថ្មី និងកូដចាស់ ហើយប្រៀបធៀបភាពខុសគ្នារវាងពួកវា។ ហើយប្រសិនបើមានភាពខុសប្លែកគ្នា នោះអ្នកកត់ត្រាព្រឹត្តិការណ៍នេះ។ វិធីនេះអ្នកដឹងថាអ្នកមានមុខងារថ្មីដែលត្រៀមរួចជាស្រេចដើម្បីដាក់លើមុខងារចាស់ ប្រសិនបើអ្នកមិនមានភាពខុសគ្នារវាងមុខងារទាំងពីរសម្រាប់ពេលជាក់លាក់ណាមួយ។

មានការអនុវត្តបែបនេះរាប់រយ។ ខ្ញុំស្នើឱ្យចាប់ផ្តើមជាមួយនឹងការអភិវឌ្ឍន៍ transbase ។ នាងមិនមែន 100% លើសមាហរណកម្មបន្តទេ ប៉ុន្តែការអនុវត្តគឺដូចគ្នា មនុស្សម្នាក់មិនអាចរស់នៅបានល្អដោយគ្មានមួយផ្សេងទៀត។

តើអ្នកបានផ្តល់ការអភិវឌ្ឍន៍ transbase ជាឧទាហរណ៍មួយដែលអ្នកអាចឃើញការអនុវត្ត ឬតើអ្នកណែនាំមនុស្សឱ្យចាប់ផ្តើមប្រើ transbase debelopment ដែរឬទេ?

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

ការរលួយគឺជាឧបករណ៍មួយរបស់ស្ថាបត្យករ។ ដំបូង​យើង​ធ្វើ​ការ​វិភាគ បន្ទាប់​មក​បំបែក​ខ្លួន បន្ទាប់​មក​សំយោគ បន្ទាប់​មក​ធ្វើ​សមាហរណកម្ម។ ហើយនេះជារបៀបដែលអ្វីៗដំណើរការសម្រាប់យើង។ ហើយ​យើង​នៅ​តែ​ត្រូវ​ការ​រីក​ចម្រើន​ទៅ​ជា​ការ​ធ្វើ​សមាហរណកម្ម​បន្ត​តាម​រយៈ​ការ​រលួយ។ សំណួរកើតឡើងនៅដំណាក់កាលទី 1 ហើយយើងកំពុងនិយាយអំពីដំណាក់កាលទី 4 រួចហើយ ពោលគឺឧស្សាហ៍យើងធ្វើសមាហរណកម្មកាន់តែល្អ។ វានៅតែលឿនពេកក្នុងការធ្វើដូចនេះ វាជាការប្រសើរណាស់ក្នុងការកាត់បន្ថយ monolith របស់អ្នកជាមុនសិន។

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

មាន​សំណួរ​មួយ​ពី​ការ​ជជែក៖ "ប្រសិន​បើ​ការ​ពិនិត្យ​ជា​កាតព្វកិច្ច​និង​ប្រើ​ពេល​យូរ ប្រហែល​ជា​មួយ​ថ្ងៃ ឬ​ច្រើន​ជាង​នេះ?"

អ្នកមានបញ្ហាជាមួយការអនុវត្ត។ ការពិនិត្យឡើងវិញមិនគួរមានរយៈពេលមួយថ្ងៃ ឬច្រើនជាងនេះទេ។ នេះ​ជា​រឿង​ដូច​គ្នា​នឹង​សំណួរ​មុន​ដែរ គ្រាន់​តែ​ស្រទន់​បន្តិច។ ប្រសិនបើ​ការ​ពិនិត្យ​បន្ត​រយៈពេល​មួយ​ថ្ងៃ នោះ​ទំនង​ជា​ការ​ពិនិត្យ​នេះ​នឹង​មាន​ការ​ផ្លាស់​ប្តូរ​ដ៏​ធំ​មួយ​ចំនួន។ នេះមានន័យថាវាត្រូវតែធ្វើឱ្យតូចជាងមុន។ នៅក្នុងការអភិវឌ្ឍន៍ transbase ដែល Oleg បានផ្តល់អនុសាសន៍ មានរឿងមួយហៅថាការពិនិត្យឡើងវិញជាបន្ត។ គំនិតរបស់នាងគឺថាយើងធ្វើសំណើតូចមួយក្នុងគោលបំណង ពីព្រោះយើងព្យាយាមបញ្ចូលគ្នាឥតឈប់ឈរ និងបន្តិចម្ដងៗ។ ដូច្នេះហើយ សំណើទាញផ្លាស់ប្តូរអរូបីមួយ ឬ 10 បន្ទាត់។ សូមអរគុណចំពោះការវាយតម្លៃនេះ វាចំណាយពេលយើងពីរបីនាទី។

ប្រសិនបើការពិនិត្យឡើងវិញចំណាយពេលមួយថ្ងៃ ឬច្រើនជាងនេះ មានអ្វីមួយខុសប្រក្រតី។ ទីមួយ អ្នកអាចមានបញ្ហាខ្លះជាមួយស្ថាបត្យកម្ម។ ឬនេះគឺជាបំណែកធំនៃកូដ 1 បន្ទាត់ឧទាហរណ៍។ ឬស្ថាបត្យកម្មរបស់អ្នកគឺស្មុគ្រស្មាញដែលមនុស្សម្នាក់មិនអាចយល់វាបាន។ នេះ​ជា​បញ្ហា​មួយ​ចំហៀង​បន្តិច ប៉ុន្តែ​ក៏​ត្រូវ​ដោះស្រាយ​ដែរ។ ប្រហែល​ជា​មិន​ចាំបាច់​មាន​ការ​ពិនិត្យ​មើល​ទាល់​តែ​សោះ។ យើងក៏ត្រូវគិតអំពីរឿងនេះដែរ។ ការពិនិត្យឡើងវិញគឺជារឿងដែលធ្វើឱ្យអ្នកយឺត។ ជាទូទៅវាមានគុណសម្បត្តិរបស់វា ប៉ុន្តែអ្នកត្រូវយល់ពីមូលហេតុដែលអ្នកកំពុងធ្វើវា។ តើនេះជាមធ្យោបាយសម្រាប់អ្នកក្នុងការបញ្ជូនព័ត៌មានបានលឿន តើនេះជាមធ្យោបាយសម្រាប់អ្នកកំណត់ស្តង់ដារខ្លះនៅខាងក្នុងឬយ៉ាងណា? ហេតុអ្វីបានជាអ្នកត្រូវការវា? ពីព្រោះការពិនិត្យឡើងវិញត្រូវធ្វើយ៉ាងឆាប់រហ័ស ឬលុបចោលទាំងស្រុង។ វាដូចជាការអភិវឌ្ឍន៍ transbase - រឿងគឺស្រស់ស្អាតខ្លាំងណាស់ ប៉ុន្តែសម្រាប់តែបុរសពេញវ័យប៉ុណ្ណោះ។

ទាក់​ទង​នឹង​ម៉ែត្រ​ទាំង ៤ ខ្ញុំ​នៅ​តែ​ណែនាំ​ឲ្យ​ដក​វា​ចេញ ដើម្បី​យល់​ថា​វា​នាំ​ទៅ​រក​អ្វី។ មើល​លេខ មើល​រូប​អី​ក៏​អាក្រក់​ម្ល៉េះ។

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

វា​ស្មុគស្មាញ។ ប្រសិនបើអ្នកចង់អានរឿងអំពីលក្ខណៈពិសេសបិទបើកឱ្យកាន់តែលម្អិត ខ្ញុំសូមណែនាំវាយ៉ាងខ្លាំង https://trunkbaseddevelopment.com/. ហើយមានអត្ថបទដ៏អស្ចារ្យមួយដោយ Martin Fowler អំពីលក្ខណៈពិសេសបិទបើក៖ តើមានប្រភេទអ្វី វដ្តជីវិត។ល។ មុខងារបិទបើកមានភាពស្មុគស្មាញ។

ហើយអ្នកនៅតែមិនទាន់បានឆ្លើយសំណួរថា "តើ Jenkins ត្រូវការឬអត់?"

Jenkins មិនចាំបាច់ក្នុងករណីណាក៏ដោយ។ ជាក់ស្តែង ឧបករណ៍៖ Jenkins, Gitlab នឹងនាំមកជូនអ្នកនូវភាពងាយស្រួល។ អ្នក​នឹង​ឃើញ​ថា​ការ​ជួប​ជុំ​ត្រូវ​បាន​ជួប​ប្រជុំ​គ្នា​ឬ​មិន​បាន​ជួប​ប្រជុំ​គ្នា​។ ពួកគេអាចជួយអ្នកបាន ប៉ុន្តែពួកគេនឹងមិនផ្តល់ឱ្យអ្នកនូវការអនុវត្តទេ។ ពួកគេគ្រាន់តែអាចផ្តល់ឱ្យអ្នកនូវរង្វង់មួយ - យល់ព្រម មិនមែន Ok ។ ហើយបន្ទាប់មក ប្រសិនបើអ្នកក៏សរសេរតេស្តដែរ ព្រោះប្រសិនបើគ្មានការធ្វើតេស្តទេ នោះវាស្ទើរតែគ្មានន័យ។ ដូច្នេះវាចាំបាច់ព្រោះវាងាយស្រួលជាង ប៉ុន្តែជាទូទៅអ្នកអាចរស់នៅដោយគ្មានវា អ្នកនឹងមិនបាត់បង់ច្រើននោះទេ។

នោះគឺប្រសិនបើអ្នកមានការអនុវត្ត តើនោះមានន័យថាអ្នកមិនត្រូវការវាទេ?

នោះជាសិទ្ធិ។ ខ្ញុំសូមណែនាំការធ្វើតេស្ត Jez Humble ។ នៅទីនោះ ខ្ញុំមានអាកប្បកិរិយាមិនច្បាស់លាស់ចំពោះចំណុចចុងក្រោយ។ ប៉ុន្តែជាទូទៅ ប្រសិនបើអ្នកមានរបស់បីយ៉ាង អ្នកបញ្ចូលចូលគ្នាឥតឈប់ឈរ អ្នកដំណើរការការធ្វើតេស្តលើការប្តេជ្ញាចិត្តនៅក្នុងមេ អ្នកជួសជុលយ៉ាងឆាប់រហ័សនៅក្នុងមេ នោះប្រហែលជាអ្នកមិនត្រូវការអ្វីផ្សេងទៀតទេ។

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

មិនថាវាគួរតែជានោះទេ វាពិតជាល្អណាស់ព្រោះវានឹងធ្វើឱ្យជីវិតកាន់តែងាយស្រួលដូចគ្នា។ ដរាបណាយើងធ្វើការជាមួយកូដ មិនមែនជាមួយស្គ្រីប bash ទេ ប៉ុន្តែយើងមានកូដធម្មតា។

ឈប់ ឈប់ ស្គ្រីប bash ក៏ជាកូដដែរ។ កុំប៉ះស្នេហ៍ចាស់។

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

ដរាបណាយើងធ្វើការជាមួយហេដ្ឋារចនាសម្ព័ន្ធជាកូដ យើងទទួលបានបញ្ហាដូចគ្នាទាំងអស់ជាមួយអ្នកអភិវឌ្ឍន៍។ កាលពីប៉ុន្មានខែមុន ខ្ញុំបានជួបប្រទះស្ថានភាពមួយដែលសហសេវិកម្នាក់បានផ្ញើសំណើរសុំទាញ 1 បន្ទាត់មកខ្ញុំ។ ហើយអ្នកសម្រាកនៅការពិនិត្យឡើងវិញរយៈពេល 000 ម៉ោង។ បញ្ហាដូចគ្នាកើតឡើង។ វានៅតែជាកូដ។ ហើយវានៅតែជាការសហការ។ យើងជាប់គាំងជាមួយនឹងសំណើទាញ ហើយយើងជាប់គាំងជាមួយនឹងការពិតដែលថាយើងកំពុងដោះស្រាយជម្លោះដែលបញ្ចូលគ្នាដូចគ្នានៅក្នុង bash តែមួយ។

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

បើមានអ្នកផ្សេងមានចម្ងល់?

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

(Oleg) បាទ ត្រឹមត្រូវហើយ។ ការអនុវត្តនេះគឺអាចប្រៀបធៀបបានក្នុងកិច្ចខិតខំប្រឹងប្រែងទៅនឹងការអនុវត្តការផ្លាស់ប្តូរវប្បធម៌ធ្ងន់ធ្ងរផ្សេងទៀត។ រឿងពិបាកបំផុតក្នុងការយកឈ្នះគឺទម្លាប់ ជាពិសេសទម្លាប់អាក្រក់។ ហើយប្រសិនបើដើម្បីអនុវត្តការអនុវត្តនេះ ការផ្លាស់ប្តូរដ៏ធ្ងន់ធ្ងរនៃទម្លាប់របស់អ្នកនៅជុំវិញអ្នកគឺត្រូវបានទាមទារ៖ អ្នកអភិវឌ្ឍន៍ ការគ្រប់គ្រង អ្នកគ្រប់គ្រងផលិតកម្ម បន្ទាប់មកការភ្ញាក់ផ្អើលកំពុងរង់ចាំអ្នក។

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

ប្រសិនបើអ្នកធ្វើសមាហរណកម្មបន្ត 10 ដងក្នុងមួយថ្ងៃបន្ទាប់មក 10 ដងត្រូវគុណនឹង 30 នាទី។ ហើយនេះលើសពីចំនួនម៉ោងធ្វើការរបស់អ្នកគ្រប់គ្រងការចេញផ្សាយនេះ។ គាត់គ្រាន់តែធុញទ្រាន់នឹងការធ្វើវា។ មានការចំណាយថេរសម្រាប់ការអនុវត្តមួយចំនួន។ អស់ហើយ។

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

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

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

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

នៅទីនេះអ្នកឈានដល់ការសន្និដ្ឋានថាដំបូងអ្នកត្រូវតែមានការយល់ដឹងអំពីអ្វីដែលអ្នកត្រូវធ្វើ។ ពិភពលោក​មិន​ល្អ​ទេ ហើយ​ផលិតផល​ក៏​មិន​ល្អ​ដែរ។

បាទ រឿងទាំងនេះមានទំនាក់ទំនងគ្នាទៅវិញទៅមក។

អាជីវកម្ម​ក៏​មិន​តែង​តែ​យល់​ថា​ពួកគេ​ត្រូវ​ធ្វើ​បែប​នេះ​ដែរ។

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

(Dmitry) ខ្ញុំនឹងអានការបំភ្លឺពីការជជែក៖ “ប៉ុន្តែយើងត្រូវការការគ្របដណ្តប់ការធ្វើតេស្តជាច្រើននៅកម្រិតផ្សេងៗគ្នា។ តើត្រូវបែងចែកពេលវេលាប៉ុន្មានសម្រាប់ការធ្វើតេស្ត? វា​ថ្លៃ​បន្តិច ហើយ​ត្រូវ​ចំណាយ​ពេល​ច្រើន»។

(Oleg) នេះគឺជាការយល់ខុសបុរាណ។ គួរតែមានការធ្វើតេស្តគ្រប់គ្រាន់ដើម្បីឱ្យអ្នកមានទំនុកចិត្ត។ ការធ្វើសមាហរណកម្មបន្តមិនមែនជារឿងដែល 100% នៃការធ្វើតេស្តត្រូវបានធ្វើជាមុនទេ ហើយមានតែបន្ទាប់មកអ្នកចាប់ផ្តើមអនុវត្តការអនុវត្តនេះ។ សមាហរណកម្មបន្តកាត់បន្ថយបន្ទុកនៃការយល់ដឹងរបស់អ្នក ដោយសារតែការផ្លាស់ប្តូរនីមួយៗដែលអ្នកឃើញដោយភ្នែករបស់អ្នកគឺច្បាស់ណាស់ ដែលអ្នកយល់ថាវានឹងធ្វើឱ្យខូចអ្វីមួយឬអត់ ទោះបីជាមិនមានការធ្វើតេស្តក៏ដោយ។ អ្នកអាចសាកល្បងវាបានយ៉ាងលឿននៅក្នុងក្បាលរបស់អ្នក ដោយសារតែការផ្លាស់ប្តូរមានតិចតួច។ ទោះបីជាអ្នកមានតែអ្នកសាកល្បងដោយដៃក៏ដោយ ក៏វាកាន់តែងាយស្រួលសម្រាប់ពួកគេផងដែរ។ អ្នក​បាន​ចេញ​ទៅ​ក្រៅ​ហើយ​និយាយ​ថា​៖ «មើល តើ​មាន​អ្វី​ខូច​ឬ? ពួក​គេ​បាន​ពិនិត្យ​មើល ហើយ​និយាយ​ថា “ទេ គ្មាន​អ្វី​ខូច​ទេ”។ ដោយសារតែអ្នកសាកល្បងដឹងពីកន្លែងដែលត្រូវរកមើល។ អ្នក​មាន​ការ​ប្តេជ្ញា​ចិត្ត​មួយ​ដែល​ទាក់ទង​នឹង​បំណែក​នៃ​កូដ។ ហើយនេះត្រូវបានកេងប្រវ័ញ្ចដោយអាកប្បកិរិយាជាក់លាក់។

នៅទីនេះអ្នកពិតជាបានតុបតែង។

(Dmitry) ខ្ញុំមិនយល់ស្របនៅទីនេះទេ។ មានការអនុវត្តមួយ - ការអភិវឌ្ឍន៍ដោយសាកល្បង ដែលនឹងជួយសង្រ្គោះអ្នកពីបញ្ហានេះ។

(Oleg) មែនហើយ ខ្ញុំមិនទាន់បានទៅដល់ចំណុចនោះទេ។ ការបំភាន់ដំបូងគឺថាអ្នកត្រូវសរសេរ 100% នៃការធ្វើតេស្តឬអ្នកមិនចាំបាច់ធ្វើសមាហរណកម្មបន្តទាល់តែសោះ។ វា​មិន​ពិត​ទេ។ នេះគឺជាការអនុវត្តស្របគ្នាពីរ។ ហើយពួកគេមិនអាស្រ័យដោយផ្ទាល់ទេ។ ការគ្របដណ្តប់លើការធ្វើតេស្តរបស់អ្នកគួរតែល្អបំផុត។ ល្អបំផុត - នេះមានន័យថាអ្នកខ្លួនឯងមានទំនុកចិត្តថាគុណភាពនៃមេដែលម្ចាស់របស់អ្នកនៅតែមានបន្ទាប់ពីការប្តេជ្ញាចិត្តអនុញ្ញាតឱ្យអ្នកចុចប៊ូតុង "ដាក់ពង្រាយ" ដោយទំនុកចិត្តនៅល្ងាចថ្ងៃសុក្រស្រវឹង។ តើអ្នកសម្រេចបាននេះដោយរបៀបណា? តាមរយៈការត្រួតពិនិត្យ តាមរយៈការគ្របដណ្តប់ តាមរយៈការតាមដានដ៏ល្អ។

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

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

ចូរយើងត្រឡប់ទៅវិញបន្តិចទៅ សមាហរណកម្មបន្ត។ យើងបានរត់ចេញទៅរកការអនុវត្តដ៏ស្មុគស្មាញខុសគ្នាបន្តិច។

ហើយការបំភាន់ទីពីរគឺថា MVP ពួកគេនិយាយថាត្រូវធ្វើយ៉ាងឆាប់រហ័ស ដូច្នេះការធ្វើតេស្តមិនចាំបាច់នៅទីនោះទាល់តែសោះ។ មិនប្រាកដក្នុងវិធីនោះទេ។ ការពិតគឺថានៅពេលអ្នកសរសេររឿងរបស់អ្នកប្រើនៅក្នុង MVP អ្នកអាចអភិវឌ្ឍវានៅលើបាល់ ពោលគឺអ្នកបានលឺថាមានរឿងរបស់អ្នកប្រើប្រាស់មួយចំនួន ហើយរត់ទៅសរសេរកូដវាភ្លាមៗ ឬអ្នកអាចធ្វើការដោយប្រើ TDD ។ ហើយយោងទៅតាម TDD ដូចដែលការអនុវត្តបង្ហាញ វាមិនចំណាយពេលយូរនោះទេ ពោលគឺការធ្វើតេស្តគឺជាផលប៉ះពាល់។ ការអនុវត្ត TDD មិនមែននិយាយអំពីការធ្វើតេស្តទេ។ ទោះបីជាអ្វីហៅថា Test Driven Development ក៏ដោយ វាមិនមែននិយាយអំពីការធ្វើតេស្តទាល់តែសោះ។ នេះក៏ជាវិធីសាស្រ្តស្ថាបត្យកម្មផងដែរ។ នេះ​ជា​វិធីសាស្ត្រ​មួយ​ដើម្បី​សរសេរ​អ្វី​ដែល​ត្រូវ​ការ ហើយ​មិន​សរសេរ​អ្វី​ដែល​មិន​ត្រូវ​ការ។ នេះ​ជា​ការ​អនុវត្ត​ដោយ​ផ្តោត​លើ​ការ​គិត​ឡើងវិញ​បន្ទាប់​ពី​ការ​បង្កើត​ស្ថាបត្យកម្ម​កម្មវិធី។

ដូច្នេះហើយ វាមិនងាយស្រួលទេក្នុងការកម្ចាត់ការបំភាន់ទាំងនេះ។ MVP និងការធ្វើតេស្តមិនផ្ទុយគ្នាទេ។ ផ្ទុយទៅវិញ ប្រសិនបើអ្នកធ្វើ MVP ដោយប្រើការអនុវត្ត TDD នោះអ្នកនឹងធ្វើវាបានប្រសើរជាង និងលឿនជាងប្រសិនបើអ្នកធ្វើវាដោយមិនបាច់ហាត់ទាល់តែសោះ ប៉ុន្តែនៅលើបាល់មួយ។

នេះគឺជាគំនិតដែលមិនច្បាស់ និងស្មុគស្មាញ។ នៅពេលដែលអ្នកឮថាឥឡូវនេះខ្ញុំនឹងសរសេរការសាកល្បងបន្ថែមទៀត ហើយក្នុងពេលតែមួយខ្ញុំនឹងធ្វើអ្វីមួយដែលលឿនជាងនេះ វាស្តាប់ទៅដូចជាមិនគ្រប់គ្រាន់ទាល់តែសោះ។

(Dmitry) មនុស្សជាច្រើននៅទីនេះ នៅពេលដែលពួកគេហៅ MVP មនុស្សខ្ជិលក្នុងការសរសេរអ្វីធម្មតា។ ហើយទាំងនេះនៅតែខុសគ្នា។ មិនចាំបាច់បង្វែរ MVP ទៅជារឿងអាក្រក់មួយចំនួនដែលមិនដំណើរការនោះទេ។

បាទ បាទ អ្នកនិយាយត្រូវ។

ហើយភ្លាមៗនោះ MVP នៅក្នុងផលិតផល។

ជារៀងរហូត។

ហើយ TDD ស្តាប់ទៅមិនធម្មតាទេ នៅពេលអ្នកឮថាអ្នកសរសេរតេស្ត ហើយហាក់ដូចជាធ្វើការងារកាន់តែច្រើន។ វាស្តាប់ទៅចម្លែកណាស់ ប៉ុន្តែតាមពិតវាប្រែចេញលឿន និងស្អាតជាងវិធីនេះ។ នៅពេលអ្នកសរសេរការសាកល្បង អ្នកគិតច្រើនក្នុងក្បាលរបស់អ្នករួចហើយអំពីអ្វីដែលលេខកូដនឹងត្រូវបានហៅ និងរបៀប ក៏ដូចជាអាកប្បកិរិយាដែលយើងរំពឹងពីវា។ អ្នកមិនគ្រាន់តែនិយាយថាខ្ញុំសរសេរមុខងារខ្លះហើយវាធ្វើអ្វីមួយនោះទេ។ ដំបូង​អ្នក​គិត​ថា​នាង​មាន​លក្ខខណ្ឌ​បែប​នេះ នាង​នឹង​ត្រូវ​បាន​គេ​ហៅ​តាម​វិធី​បែប​នេះ​។ អ្នកគ្របដណ្តប់វាជាមួយនឹងការធ្វើតេស្ត ហើយពីនេះអ្នកយល់ពីរបៀបដែលចំណុចប្រទាក់របស់អ្នកនឹងមើលទៅខាងក្នុងកូដរបស់អ្នក។ នេះមានឥទ្ធិពលយ៉ាងខ្លាំងទៅលើស្ថាបត្យកម្ម។ លេខកូដរបស់អ្នកនឹងក្លាយទៅជាម៉ូឌុលកាន់តែច្រើនដោយស្វ័យប្រវត្តិ ពីព្រោះដំបូងអ្នកព្យាយាមយល់ពីរបៀបដែលអ្នកនឹងសាកល្បងវា ហើយគ្រាន់តែសរសេរវាប៉ុណ្ណោះ។

អ្វីដែលបានកើតឡើងចំពោះខ្ញុំជាមួយ TDD គឺថានៅចំណុចខ្លះខ្ញុំបានជួលអ្នកណែនាំ Ruby នៅពេលដែលខ្ញុំនៅតែជាអ្នកសរសេរកម្មវិធី Ruby ។ ហើយគាត់និយាយថា "តោះធ្វើវាយោងទៅតាម TDD" ។ ខ្ញុំ​គិត​ថា​៖ ​«​មែន​ហើយ ឥឡូវ​ខ្ញុំ​ត្រូវ​សរសេរ​អ្វី​បន្ថែម​ទៀត»។ ហើយយើងបានយល់ព្រមថាក្នុងរយៈពេលពីរសប្តាហ៍ ខ្ញុំនឹងសរសេរកូដការងារទាំងអស់នៅក្នុង Python ដោយប្រើ TDD ។ ពីរ​សប្តាហ៍​ក្រោយ​មក ខ្ញុំ​បាន​ដឹង​ថា​ខ្ញុំ​មិន​ចង់​ត្រឡប់​ទៅ​វិញ​ទេ។ បន្ទាប់ពីពីរសប្តាហ៍នៃការព្យាយាមអនុវត្តវាគ្រប់ទីកន្លែង អ្នកដឹងថាវាកាន់តែងាយស្រួលសម្រាប់អ្នកក្នុងការគិត។ ប៉ុន្តែនេះមិនច្បាស់ទេ ដូច្នេះខ្ញុំសូមណែនាំអ្នកគ្រប់គ្នាថា ប្រសិនបើអ្នកមានអារម្មណ៍ថា TDD ពិបាក ចំណាយពេលវេលា និងមិនចាំបាច់ សូមសាកល្បងប្រើវាត្រឹមតែពីរសប្តាហ៍ប៉ុណ្ណោះ។ ពីរនាក់គឺគ្រប់គ្រាន់សម្រាប់ខ្ញុំ។

(Dmitry) យើងអាចពង្រីកគំនិតនេះពីទស្សនៈនៃប្រតិបត្តិការហេដ្ឋារចនាសម្ព័ន្ធ។ មុន​ពេល​យើង​ដាក់​ឱ្យ​ដំណើរការ​អ្វី​ដែល​ថ្មី យើង​ធ្វើ​ការ​ត្រួត​ពិនិត្យ​បន្ទាប់​មក​បើក​ដំណើរការ។ ក្នុងករណីនេះ ការត្រួតពិនិត្យក្លាយជាការធ្វើតេស្តធម្មតាសម្រាប់យើង។ ហើយមានការអភិវឌ្ឍន៍តាមរយៈការត្រួតពិនិត្យ។ ប៉ុន្តែស្ទើរតែគ្រប់គ្នានិយាយថាវាវែង ខ្ញុំខ្ជិល ខ្ញុំបានបង្កើតសេចក្តីព្រាងបណ្តោះអាសន្ន។ ប្រសិនបើយើងធ្វើការត្រួតពិនិត្យធម្មតា យើងយល់ពីស្ថានភាពនៃប្រព័ន្ធ CI ។ ហើយប្រព័ន្ធ CI មានការត្រួតពិនិត្យច្រើន។ យើងយល់ពីស្ថានភាពនៃប្រព័ន្ធ យើងយល់ពីអ្វីដែលមាននៅខាងក្នុង។ ហើយក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍ យើងគ្រាន់តែបង្កើតប្រព័ន្ធដើម្បីឱ្យវាឈានដល់ស្ថានភាពដែលចង់បាន។

ការអនុវត្តទាំងនេះត្រូវបានគេស្គាល់ជាយូរមកហើយ។ យើងបានពិភាក្សារឿងនេះកាលពី 4 ឆ្នាំមុន។ ប៉ុន្តែក្នុងរយៈពេល 4 ឆ្នាំជាក់ស្តែងគ្មានអ្វីផ្លាស់ប្តូរទេ។

ប៉ុន្តែ​ក្នុង​កំណត់​ត្រា​នេះ ខ្ញុំ​ស្នើ​ឲ្យ​បញ្ចប់​ការ​ពិភាក្សា​ជា​ផ្លូវ​ការ។

វីដេអូ (បញ្ចូលជាធាតុមេឌៀ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួនមិនដំណើរការទេ)៖

https://youtu.be/zZ3qXVN3Oic

ប្រភព: www.habr.com