អ្នកអភិវឌ្ឍសូហ្វ្វែរ អ្នកដឹកនាំបច្ចេកទេស (tech lead) និងវិស្វករ DevOps ភាគច្រើនចាប់ផ្តើមអាជីពរបស់ខ្លួនជាអ្នកសាងសង់។

ពួកគេសាងសង់ប្រព័ន្ធ កម្មវិធី សមាសភាគ ស្បែកគេហទំព័រ (theme) ទម្រង់គំរូ ម៉ូឌុល និងបំពង់ដំណើរការ (pipeline)។ ពួកគេកែសម្រួលប្លង់ដើម្បីឱ្យល្អបំផុត ដោះស្រាយករណីពិសេស រក្សាភាពឆបគ្នា ហើយរុញប្រព័ន្ធឱ្យទៅមុខម្តងមួយ commit។ ការងារនេះត្រូវការភាពច្បាស់លាស់ ជាក់ស្តែង និងបច្ចេកទេសជ្រៅជ្រះ។

ប៉ុន្តែដល់ចំណុចមួយ មានអ្វីមួយផ្លាស់ប្តូរ។

អ្នកជំនាញដ៏ល្អបំផុតមិនឈប់សាងសង់ទេ ប៉ុន្តែពួកគេចាប់ផ្តើមគិតជាប្រព័ន្ធ។

ពីអ្នកសាងសង់ ទៅជាអ្នកគិតជាប្រព័ន្ធ

ការផ្លាស់ប្តូរ៖ ពីលទ្ធផល ទៅច្បាប់

ក្នុងនាមជាអ្នកសាងសង់ ការផ្តោតសំខាន់គឺលើលទ្ធផល៖ សមាសភាគ ទម្រង់គំរូ ទំព័រ មុខងារ បណ្ណាល័យ និងកម្មវិធី។

ក្នុងនាមជាអ្នកគិតជាប្រព័ន្ធ ការផ្តោតប្តូរទៅលើច្បាប់៖ ការកំណត់ដែនកម្រិត អន្តរកម្ម និងរង្វង់មតិត្រឡប់ (feedback loop)។

ជំនួសឱ្យការសួរថា «សមាសភាគនេះមើលទៅដូចម្តេច?» អ្នកគិតជាប្រព័ន្ធសួរសំណួរផ្សេង៖ តើច្បាប់អ្វីគ្រប់គ្រងសមាសភាគនេះ? តើអ្វីខ្លះត្រូវបានអនុញ្ញាតឱ្យទាក់ទងជាមួយវា? តើវាមានអាកប្បកិរិយាយ៉ាងណាពេលមានការផ្លាស់ប្តូរ? តើបំណងដើមអាចរស់រានមានជីវិតតាមពេលវេលាដោយរបៀបណា?

ការផ្លាស់ប្តូរនេះនាំទៅរកប្រព័ន្ធភ្នាក់ងារ (agentic systems) ដោយធម្មជាតិ។

នៅពេលដែលការរចនាលែងឋិតិវន្ត

ប្រព័ន្ធរចនាទំនើបបានបង្កប់តក្កវិជ្ជារួចហើយ៖ token កំណត់ដែនកម្រិត សមាសភាគកំណត់រចនាសម្ព័ន្ធ ហើយទម្រង់គំរូកំណត់អាកប្បកិរិយា។

ប៉ុន្តែប្រព័ន្ធភាគច្រើននៅតែពឹងលើការសម្របសម្រួលដោយមនុស្សយ៉ាងខ្លាំង។

ភ្នាក់ងារ AI នាំមកនូវគំរូផ្សេង ដែលប្រព័ន្ធអាចអនុវត្តច្បាប់របស់ខ្លួនឯង ផ្ទៀងផ្ទាត់ការសម្រេចចិត្តជាបន្តបន្ទាប់ ឆ្លើយតបតាមបរិបទ និងសម្របសម្រួលគ្នាផ្ទៃក្នុង។

នេះគឺជាចំណុចដែលការរចនាវិវត្តពីឯកសារ ទៅជាតក្កវិជ្ជាដែលអាចដំណើរការបាន។

ទិសដៅដែលកំពុងឆ្ពោះទៅ

ពេលនេះការផ្តោតគឺលើការអនុវត្តគំនិតទាំងនេះក្នុងប្រព័ន្ធពិតប្រាកដដែលកំពុងដំណើរការ មិនមែនជាការពិសោធន៍ទេ ប៉ុន្តែជាមូលដ្ឋានគ្រឹះ។

១. ការរួមបញ្ចូលភ្នាក់ងារ AI កាន់តែជ្រៅជាមួយឧបករណ៍រចនា (Figma)

ឆ្ពោះទៅរកប្រព័ន្ធរចនាបែបភ្នាក់ងារ

ឧបករណ៍រចនាមិនគួរជាផ្ទាំងគំនូរអកម្មទេ។

គោលដៅគឺរួមបញ្ចូលភ្នាក់ងារ AI ជាមួយ Figma ដែលយល់ពី design token និងដែនកម្រិតរបស់សមាសភាគ ផ្ទៀងផ្ទាត់ការសម្រេចចិត្តភ្លាមៗ បកប្រែបំណងរចនាទៅជាច្បាប់កម្រិតប្រព័ន្ធ ហើយធ្វើជាអ្នកសហការ មិនមែនគ្រាន់តែជាអ្នកនាំចេញ (exporter) ទេ។

នេះរុញការរចនាទៅកាន់ដំណាក់កាលមុន ដែលបំណងត្រូវបានរក្សាទុក មិនមែនត្រូវទស្សន៍ទាយនៅពេលក្រោយទេ។

២. ការគ្រប់គ្រងភ្នាក់ងារ AI ដែលអាចពង្រីកខ្នាតបាន

គោលដៅ៖ ភ្នាក់ងារ ១៥០ មួយសម្រាប់មួយសមាសភាគ

ជំនួសឱ្យ AI ទូទៅតែមួយ ក្រុមការងារកំពុងឆ្ពោះទៅរកភ្នាក់ងារឯកទេសជាច្រើន។

សមាសភាគនីមួយៗមានភ្នាក់ងារផ្ទាល់ខ្លួន ដែលមានការទទួលខុសត្រូវច្បាស់លាស់ ព្រំដែនច្បាស់លាស់ និងដឹងអំពីសមាសភាគដែលពាក់ព័ន្ធ។

នេះឆ្លុះបញ្ចាំងពីរបៀបដែលប្រព័ន្ធដែលមានសុខភាពល្អពង្រីកខ្នាត គឺតាមរយៈឯកទេសភាវូបនីយកម្ម ការសម្របសម្រួល និងកិច្ចសន្យា (contract) ដែលច្បាស់លាស់។

៣. ភ្នាក់ងារដែលមានជំនាញ ឧបករណ៍ និងកម្មវិធីជំនួយពិតប្រាកដ

ភ្នាក់ងារត្រូវតែអាចធ្វើសកម្មភាពបាន។

នោះមានន័យថាត្រូវបំពាក់ឱ្យពួកគេនូវជំនាញ (ការវែកញែកអំពីភាពងាយស្រួលប្រើ ការផ្ទៀងផ្ទាត់ការរចនា ការយល់ដឹងអំពីប្រសិទ្ធភាព) ឧបករណ៍ (linter កម្មវិធីរត់តេស្ត API រចនា) និងកម្មវិធីជំនួយ (Storybook, Drupal, CI pipeline, ការរួមបញ្ចូល Figma)។

ភ្នាក់ងារគ្មានឧបករណ៍គ្រាន់តែជាទ្រឹស្តី។ ភ្នាក់ងារមានឧបករណ៍ក្លាយជាផ្នែកមួយនៃប្រព័ន្ធខ្លួនឯង។

៤. ការធ្វើតេស្តទទួលយកមុខងារស្វ័យប្រវត្តិដែលឆ្លាតជាងមុន

ជំរុញដោយ AI និងយល់ពីបំណង

ការធ្វើតេស្តបែបប្រពៃណីពិនិត្យលទ្ធផល។ ការធ្វើតេស្តដែលជំរុញដោយភ្នាក់ងារយល់ពីអាកប្បកិរិយា។

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

ការធ្វើតេស្តក្លាយជាស្រទាប់មួយទៀតនៃបញ្ញារបស់ប្រព័ន្ធ។

TDD និង BDD ក្នុងយុគសម័យ AI៖ ហេតុអ្វីភ្នាក់ងារ AI ទាមទារការអភិវឌ្ឍដោយធ្វើតេស្តមុនកាន់តែច្រើន ១០០%

ហេតុអ្វីបានជាសំខាន់

ក្រុមការងារកំពុងសាងសង់ប្រព័ន្ធដែលនៅស្ថិតស្ថេរយូរជាងអ្នកបង្កើតរបស់វា សម្របខ្លួនជាបន្តបន្ទាប់ និងដឹកនាំការសម្រេចចិត្តរចនារយៈពេលវែងទៅមុខ។

ក្នុងពិភពលោកបែបនេះ ការគ្រប់គ្រងដោយដៃមិនអាចពង្រីកខ្នាតបានទេ។ ប៉ុន្តែច្បាប់ដែលកំណត់បានល្អអាច។

អ្នករចនា អ្នកអភិវឌ្ឍ និងភ្នាក់ងារ AI ត្រូវតែធ្វើការក្នុងក្របខ័ណ្ឌតក្កវិជ្ជាតែមួយ គឺប្រព័ន្ធរួមមួយនៃដែនកម្រិត និងបំណង។

ការផ្លាស់ប្តូរពីអ្នកសាងសង់ទៅអ្នកគិតជាប្រព័ន្ធ មិនមែនអំពីការបោះបង់ការអនុវត្តទេ។ វាគឺអំពីការមើលឃើញថាប្រព័ន្ធមានច្រើនជាងការប្រមូលផ្តុំនៃផ្នែកនានា។

ជំហានបន្ទាប់គឺការរចនាច្បាប់ដែលអនុញ្ញាតឱ្យប្រព័ន្ធវែកញែក សម្របខ្លួន និងវិវត្ត។

អ្នកអភិវឌ្ឍសូហ្វ្វែរ អ្នកដឹកនាំបច្ចេកទេស និងវិស្វករ DevOps ដែលធ្វើការផ្លាស់ប្តូរនេះ មិនត្រឹមតែសាងសង់ទេ ពួកគេកំពុងសាងសង់លក្ខខណ្ឌសម្រាប់ឱ្យប្រព័ន្ធសាងសង់ខ្លួនឯង។