របៀបបង្កើតគម្រោងប្រភពបើកចំហ

មហោស្រព IT នឹងប្រារព្ធឡើងនៅ St. Petersburg ក្នុងសប្តាហ៍នេះ។ បច្ចេកទេសរថភ្លើង. វាគ្មិនម្នាក់នឹងជា Richard Stallman ។ ប្រអប់សំបុត្រ ក៏ចូលរួមក្នុងពិធីបុណ្យផងដែរ ហើយជាការពិតណាស់ យើងមិនអាចព្រងើយកន្តើយចំពោះប្រធានបទនៃកម្មវិធីឥតគិតថ្លៃនោះទេ។ នោះហើយជាមូលហេតុដែលរបាយការណ៍មួយរបស់យើងត្រូវបានគេហៅថា “ពីសិប្បកម្មរបស់សិស្ស រហូតដល់គម្រោងប្រភពបើកចំហ។ បទពិសោធន៍ Embox”. វានឹងត្រូវបានឧទ្ទិសដល់ប្រវត្តិនៃការអភិវឌ្ឍន៍របស់ Embox ជាគម្រោងប្រភពបើកចំហ។ នៅក្នុងអត្ថបទនេះខ្ញុំចង់និយាយអំពីគំនិតសំខាន់ៗដែលតាមគំនិតរបស់ខ្ញុំមានឥទ្ធិពលលើការអភិវឌ្ឍន៍គម្រោងប្រភពបើកចំហ។ អត្ថបទដូចជារបាយការណ៍គឺផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួន។

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

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

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

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

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

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

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

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

សហគមន៍គឺជាគន្លឹះនៅក្នុងគម្រោងប្រភពបើកចំហ។ វាអនុញ្ញាតឱ្យអ្នកកាត់បន្ថយការចំណាយលើការគ្រប់គ្រងគម្រោងយ៉ាងច្រើន អភិវឌ្ឍ និងគាំទ្រគម្រោង។ យើង​អាច​និយាយ​បាន​ថា បើ​គ្មាន​សហគមន៍ គឺ​គ្មាន​គម្រោង opensource ទាល់​តែ​សោះ។

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

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

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

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

អ្នកប្រើប្រាស់ដំបូងនៃ Embox គឺនាយកដ្ឋានទ្រឹស្តី Cybernetics ។ ពួកគេបានស្នើឱ្យបង្កើតកម្មវិធីបង្កប់ជំនួសសម្រាប់ Lego Mindstorm ។ ហើយទោះបីជាទាំងនេះនៅតែជាអ្នកប្រើប្រាស់ក្នុងស្រុក (យើងអាចជួបជាមួយពួកគេដោយផ្ទាល់ និងពិភាក្សាអំពីអ្វីដែលពួកគេចង់បាន)។ ប៉ុន្តែវានៅតែជាបទពិសោធន៍ដ៏ល្អមួយ។ ជាឧទាហរណ៍ យើងបានបង្កើតការបង្ហាញដែលអាចបង្ហាញដល់អ្នកដទៃ ពីព្រោះមនុស្សយន្តមានភាពសប្បាយរីករាយ និងទាក់ទាញការចាប់អារម្មណ៍។ ជាលទ្ធផល យើងទទួលបានអ្នកប្រើប្រាស់ភាគីទីបីពិតប្រាកដ ដែលបានចាប់ផ្តើមសួរថាតើ Embox ជាអ្វី និងរបៀបប្រើប្រាស់វា។

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

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

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

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

ជាទូទៅ យើងបន្តទៅមុខយ៉ាងរលូនទៅកាន់ចំណុចសំខាន់ដែលអនុញ្ញាតឱ្យយើងនិយាយអំពីការបង្កើតគម្រោងប្រភពបើកចំហ - ការបង្កើតផលិតផលដែលនឹងដោះស្រាយបញ្ហារបស់អ្នកប្រើប្រាស់របស់វា។ ដូចដែលខ្ញុំបានពន្យល់ខាងលើ ទ្រព្យសម្បត្តិសំខាន់នៃគម្រោងប្រភពបើកចំហគឺសហគមន៍របស់វា។ លើសពីនេះទៅទៀត សមាជិកសហគមន៍គឺជាអ្នកប្រើប្រាស់ជាចម្បង។ ប៉ុន្តែតើពួកគេមកពីណានៅពេលដែលគ្មានអ្វីត្រូវប្រើ? ដូច្នេះវាប្រែថា ដូចគ្នានឹងគម្រោងដែលមិនមែនជាប្រភពបើកចំហដែរ អ្នកត្រូវផ្តោតលើការបង្កើត MVP (ផលិតផលដែលអាចសម្រេចបានអប្បបរមា) ហើយប្រសិនបើវាចាប់អារម្មណ៍អ្នកប្រើប្រាស់ នោះសហគមន៍នឹងលេចឡើងនៅជុំវិញគម្រោង។ ប្រសិនបើអ្នកចូលរួមក្នុងការបង្កើតសហគមន៍តែតាមរយៈ PR សហគមន៍ ការសរសេរវីគីជាភាសាទាំងអស់នៃពិភពលោក ឬដំណើរការការងារ git ត្រឹមត្រូវនៅលើ github នោះវាមិនទំនងមានបញ្ហានៅក្នុងដំណាក់កាលដំបូងនៃគម្រោងនោះទេ។ ជាការពិតណាស់នៅដំណាក់កាលសមស្របទាំងនេះមិនត្រឹមតែមានសារៈសំខាន់ប៉ុណ្ណោះទេប៉ុន្តែក៏ជារឿងចាំបាច់ផងដែរ។

សរុបសេចក្តី ខ្ញុំចង់បញ្ជាក់ អត្ថាធិប្បាយតាមគំនិតរបស់ខ្ញុំ ឆ្លុះបញ្ចាំងពីការរំពឹងទុករបស់អ្នកប្រើប្រាស់ពីគម្រោងប្រភពបើកចំហ៖

ខ្ញុំ​កំពុង​គិត​យ៉ាង​ហ្មត់ចត់​អំពី​ការ​ប្ដូរ​ទៅ​ប្រព័ន្ធ​ប្រតិបត្តិការ​នេះ (យ៉ាង​ហោច​ណាស់​ព្យាយាម។ ពួកគេ​កំពុង​តាម​រក​វា​យ៉ាង​សកម្ម និង​ធ្វើ​រឿង​ល្អ​ៗ)។

PS បើក បច្ចេកទេសរថភ្លើង យើងនឹងមានរបាយការណ៍ចំនួនបី។ មួយអំពីប្រភពបើកចំហ និងពីរអំពីបង្កប់ (ហើយមួយទៀតគឺជាក់ស្តែង)។ នៅឈរយើងនឹងធ្វើថ្នាក់មេលើការសរសេរកម្មវិធី microcontrollers ដោយប្រើ ប្រអប់សំបុត្រ. ដូចធម្មតា យើងនឹងនាំយក Hardware ហើយឱ្យអ្នកសរសេរកម្មវិធី។ វាក៏នឹងមានដំណើរស្វែងរក និងសកម្មភាពផ្សេងៗទៀតផងដែរ។ សូមអញ្ជើញមកពិធីបុណ្យនិងជំហររបស់យើងវានឹងមានភាពសប្បាយរីករាយ។

ប្រភព: www.habr.com