គោលការណ៍សម្រាប់បង្កើតកម្មវិធីទំនើបពី NGINX ។ ផ្នែកទី 1

សួស្តីមិត្តភក្តិ។ នៅក្នុងការរំពឹងទុកនៃការចាប់ផ្តើមនៃវគ្គសិក្សា អ្នកអភិវឌ្ឍន៍កម្មវិធី PHP backendជាប្រពៃណី ចែករំលែកជាមួយអ្នកនូវការបកប្រែនៃសម្ភារៈមានប្រយោជន៍។

កម្មវិធីដោះស្រាយបញ្ហាកិច្ចការប្រចាំថ្ងៃកាន់តែច្រើនឡើងៗ ខណៈពេលដែលកាន់តែស្មុគស្មាញ។ ដូចដែល Marc Andressen ធ្លាប់បាននិយាយ វាស៊ីពិភពលោក។

ជាលទ្ធផល របៀបដែលកម្មវិធីត្រូវបានបង្កើត និងចែកចាយបានផ្លាស់ប្តូរយ៉ាងខ្លាំងក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ។ ទាំងនេះគឺជាការផ្លាស់ប្តូរនៃមាត្រដ្ឋាន tectonic ដែលបណ្តាលឱ្យមានសំណុំនៃគោលការណ៍។ គោលការណ៍ទាំងនេះបានបង្ហាញឱ្យឃើញថាមានប្រយោជន៍ក្នុងការបង្កើតក្រុម ការរចនា ការអភិវឌ្ឍន៍ និងការចែកចាយកម្មវិធីរបស់អ្នកដល់អ្នកប្រើប្រាស់ចុងក្រោយ។

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

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

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

តាមរយៈការអនុវត្តគោលការណ៍ទាំងនេះ អ្នកនឹងឃើញខ្លួនអ្នកទាញយកអត្ថប្រយោជន៍ពីនិន្នាការចុងក្រោយបំផុតក្នុងការអភិវឌ្ឍន៍កម្មវិធី រួមទាំង DevOps ដល់ការអភិវឌ្ឍន៍ និងការចែកចាយកម្មវិធី ការប្រើប្រាស់កុងតឺន័រ (ឧទាហរណ៍ Dockers) និង​ក្របខ័ណ្ឌ​ការ​រៀបចំ​កុងតឺន័រ (ឧទាហរណ៍ Kubernetes) ការប្រើប្រាស់សេវាមីក្រូ (រួមទាំងស្ថាបត្យកម្មមីក្រូសេវាកម្ម NGINX и រចនាសម្ព័ន្ធទំនាក់ទំនងបណ្តាញ សម្រាប់កម្មវិធី microservice ។

តើកម្មវិធីទំនើបគឺជាអ្វី?

កម្មវិធីទំនើប? ជង់ទំនើប? តើ "ទំនើប" មានន័យយ៉ាងណា?

អ្នកអភិវឌ្ឍន៍ភាគច្រើនមានតែគំនិតទូទៅអំពីអ្វីដែលកម្មវិធីទំនើបមាន ដូច្នេះហើយចាំបាច់ត្រូវកំណត់និយមន័យនេះឱ្យបានច្បាស់លាស់។

កម្មវិធីទំនើបគាំទ្រអតិថិជនជាច្រើន មិនថាវាជាចំណុចប្រទាក់អ្នកប្រើបណ្ណាល័យ React JavaScript កម្មវិធីទូរស័ព្ទ Android ឬ iOS ឬកម្មវិធីដែលភ្ជាប់ទៅ API ផ្សេងទៀត។ កម្មវិធីទំនើបបង្កប់ន័យចំនួនអតិថិជនមិនកំណត់ ដែលវាផ្តល់ទិន្នន័យ ឬសេវាកម្ម។

កម្មវិធីទំនើបផ្តល់ API ដើម្បីចូលប្រើទិន្នន័យ និងសេវាកម្មដែលបានស្នើសុំ។ API គួរតែមិនអាចផ្លាស់ប្តូរបាន និងថេរ ហើយមិនត្រូវបានសរសេរជាពិសេសសម្រាប់សំណើជាក់លាក់ណាមួយពីអតិថិជនជាក់លាក់នោះទេ។ API មាននៅលើ HTTP(S) និងផ្តល់នូវការចូលប្រើមុខងារទាំងអស់ដែលមាននៅក្នុង GUI ឬ CLI ។

ទិន្នន័យត្រូវតែមាននៅក្នុងទម្រង់ដែលអាចធ្វើអន្តរកម្មដែលអាចទទួលយកបានជាទូទៅដូចជា JSON ជាដើម។ API លាតត្រដាងវត្ថុ និងសេវាកម្មតាមរបៀបស្អាត និងរៀបចំ ដូចជា RESTful API ឬ GraphQL ផ្តល់នូវចំណុចប្រទាក់សមរម្យ។

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

កំណែពេញនិយមនៃជង់ប្រភេទនេះគឺផ្អែកលើ កោះជ្វា, ពស់ថ្លាន់, ថ្នាំង, Ruby ព្រម, កម្មវិធី PHP и Go. ស្ថាបត្យកម្មខ្នាតតូច NGINX តំណាងឱ្យឧទាហរណ៍នៃជង់ទំនើបដែលបានអនុវត្តជាភាសានីមួយៗដែលបានរៀបរាប់។

សូមចំណាំថាយើងមិនតស៊ូមតិលើវិធីសាស្រ្តមីក្រូសេវាទាំងស្រុងនោះទេ។ មនុស្សជាច្រើននៃអ្នកកំពុងធ្វើការជាមួយ monoliths ដែលត្រូវវិវឌ្ឍ ខណៈពេលដែលអ្នកផ្សេងទៀតកំពុងដោះស្រាយជាមួយកម្មវិធី SOA ដែលកំពុងពង្រីក និងវិវឌ្ឍទៅជាកម្មវិធី microservice ។ នៅតែមានកម្មវិធីផ្សេងទៀតកំពុងឆ្ពោះទៅរកកម្មវិធីដែលមិនមានម៉ាស៊ីនមេ ហើយខ្លះកំពុងអនុវត្តបន្សំនៃខាងលើ។ គោលការណ៍ដែលបានរៀបរាប់នៅក្នុងអត្ថបទអនុវត្តចំពោះប្រព័ន្ធនីមួយៗដោយមានការកែប្រែបន្តិចបន្តួចប៉ុណ្ណោះ។

គោលការណ៍

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

គោលការណ៍មួយស្តាប់ទៅដូចជា "បង្កើតកម្មវិធីតូច" ចូរយើងហៅវាទៅ គោលការណ៍នៃភាពតូចតាច. មានកម្មវិធីស្មុគស្មាញមិនគួរឱ្យជឿដែលត្រូវបានបង្កើតឡើងដោយផ្នែកផ្លាស់ទីជាច្រើន។ ម្យ៉ាងវិញទៀត ការបង្កើតកម្មវិធីពីសមាសធាតុតូចៗដែលដាច់ចេញពីគ្នា ធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការរចនា ថែទាំ និងធ្វើការជាមួយវាទាំងមូល។ (ចំណាំ​ថា​យើង​បាន​និយាយ​ថា "ធ្វើឱ្យ​សាមញ្ញ" មិនមែន "ធ្វើឱ្យ​សាមញ្ញ")។

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

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

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

សូមក្រឡេកមើលគោលការណ៍ទាំងបីនេះឱ្យកាន់តែលម្អិត។

គោលការណ៍នៃភាពតូចតាច

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

កម្មវិធី decompose សម្រាប់ហេតុផលដូចខាងក្រោម:

• កាត់បន្ថយបន្ទុកការយល់ដឹងលើអ្នកអភិវឌ្ឍន៍;
• ការបង្កើនល្បឿននិងភាពសាមញ្ញនៃការធ្វើតេស្ត;
• ការដឹកជញ្ជូនលឿននៃការផ្លាស់ប្តូរនៅក្នុងកម្មវិធី។

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

ដូច្នេះនេះគឺជាវិធីបីយ៉ាងដើម្បីកាត់បន្ថយបន្ទុកនៃការយល់ដឹង៖

1. កាត់បន្ថយពេលវេលាដែលពួកគេត្រូវពិចារណានៅពេលបង្កើតមុខងារថ្មី - ពេលវេលាកាន់តែខ្លី បន្ទុកការយល់ដឹងកាន់តែទាប។
2. កាត់បន្ថយចំនួនកូដដែលការងារម្តងត្រូវបានអនុវត្ត - កូដតិច - បន្ទុកតិច។
3. សម្រួលដំណើរការនៃការធ្វើការផ្លាស់ប្តូរបន្ថែមទៅលើកម្មវិធី។

កាត់បន្ថយពេលវេលាអភិវឌ្ឍន៍

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

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

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

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

មូលដ្ឋានកូដតូច

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

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

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

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

ការផ្លាស់ប្តូរបន្តិចម្តង ៗ

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

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

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

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

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

ចុងបញ្ចប់នៃផ្នែកទីមួយ។

ឆាប់ៗនេះ យើងនឹងបោះពុម្ពផ្នែកទីពីរនៃការបកប្រែ ហើយឥឡូវនេះយើងកំពុងរង់ចាំមតិយោបល់របស់អ្នក ហើយអញ្ជើញអ្នកមក ថ្ងៃបើកដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃនេះនៅម៉ោង 20.00 ។

ប្រភព: www.habr.com