ការបកប្រែអត្ថបទដែលបានរៀបចំសម្រាប់និស្សិតវគ្គសិក្សា "ការអនុវត្ត និងឧបករណ៍ DevOps" នៅក្នុងគម្រោងអប់រំ OTUS ។

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

ហេតុអ្វីបានជាយើងនិយាយអំពីរឿងនេះ?

Matt Klein បានសរសេរអត្ថបទនេះ។ "Monorepos: សូមកុំ!"  (កំណត់សម្គាល់របស់អ្នកបកប្រែ៖ ការបកប្រែនៅលើ Habre "ឃ្លាំងសម្ងាត់៖ សូមកុំ") ខ្ញុំចូលចិត្ត Matt ខ្ញុំគិតថាគាត់ឆ្លាតណាស់ ហើយអ្នកគួរតែអានទស្សនៈរបស់គាត់។ ដើមឡើយគាត់បានបង្ហោះការស្ទង់មតិនៅលើ Twitter៖

ការបកប្រែ៖
ថ្ងៃចូលឆ្នាំថ្មីនេះ ខ្ញុំនឹងជជែកគ្នាអំពីរបៀបដែល monorepositories គួរឱ្យអស់សំណើច។ ឆ្នាំ 2019 ចាប់ផ្តើមដោយស្ងប់ស្ងាត់។ ក្នុងស្មារតីនេះ ខ្ញុំផ្តល់ជូនអ្នកនូវការស្ទង់មតិមួយ។ តើនរណាជាអ្នកនិយមជ្រុល? អ្នកគាំទ្រ៖
- ម៉ូណូរប៉ូ
- ច្រែះ
- ការស្ទង់មតិមិនត្រឹមត្រូវ / ទាំងពីរ

ចម្លើយ​របស់​ខ្ញុំ​គឺ "ខ្ញុំ​ជា​មនុស្ស​ទាំង​ពីរ​យ៉ាង​ពិត​ប្រាកដ"។ ជំនួសឱ្យការនិយាយអំពីរបៀបដែល Rust គឺជាថ្នាំ សូមក្រឡេកមើលមូលហេតុដែលខ្ញុំគិតថាគាត់ខុសអំពី monorepositories ។ បន្តិចអំពីខ្លួនអ្នក។ ខ្ញុំជា CTO នៃ Chef Software ។ យើងមានវិស្វករប្រហែល 100 នាក់ មូលដ្ឋានកូដនឹងត្រលប់មកវិញប្រហែល 11-12 ឆ្នាំ និងផលិតផលសំខាន់ៗចំនួន 4 ។ លេខកូដនេះខ្លះស្ថិតនៅក្នុង polyrepository (ទីតាំងចាប់ផ្តើមរបស់ខ្ញុំ) ខ្លះស្ថិតនៅក្នុង monorepository (ទីតាំងបច្ចុប្បន្នរបស់ខ្ញុំ)។

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

ខ្ញុំយល់ស្របនឹងផ្នែកដំបូងនៃចំណុចរបស់ Matt៖

ពីព្រោះតាមមាត្រដ្ឋាន monorepository នឹងដោះស្រាយបញ្ហាដូចគ្នាទាំងអស់ដែល polyrepository ដោះស្រាយ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះបង្ខំឱ្យអ្នកភ្ជាប់កូដរបស់អ្នកយ៉ាងតឹងរ៉ឹង ហើយទាមទារការខិតខំប្រឹងប្រែងមិនគួរឱ្យជឿដើម្បីបង្កើនទំហំនៃប្រព័ន្ធគ្រប់គ្រងកំណែរបស់អ្នក។

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

ខ្ញុំគិតថាអំណះអំណាងរបស់ Matt គឺស្រដៀងទៅនឹងទស្សនៈដែលចែករំលែកដោយវិស្វករជាច្រើន (និងអ្នកគ្រប់គ្រង) ដែលខ្ញុំគោរព។ វាកើតឡើងតាមទស្សនៈរបស់វិស្វករដែលធ្វើការលើសមាសភាគ ឬក្រុមដែលធ្វើការលើសមាសភាគ។ អ្នកឮរឿងដូចជា៖

• មូលដ្ឋានកូដគឺសំពីងសំពោង - ខ្ញុំមិនត្រូវការសារធាតុឥតប្រយោជន៍ទាំងអស់នេះទេ។
• វាពិបាកជាងក្នុងការធ្វើតេស្តព្រោះខ្ញុំត្រូវសាកល្បងសារធាតុញៀនទាំងអស់ដែលខ្ញុំមិនត្រូវការ។
• វាពិបាកជាងក្នុងការធ្វើការជាមួយភាពអាស្រ័យខាងក្រៅ។
• ខ្ញុំត្រូវការប្រព័ន្ធគ្រប់គ្រងកំណែនិម្មិតផ្ទាល់ខ្លួនរបស់ខ្ញុំ។

ជាការពិតណាស់ ចំណុចទាំងអស់នេះគឺត្រឹមត្រូវណាស់។ វាកើតឡើងនៅក្នុងករណីទាំងពីរ - នៅក្នុង polyrepository ខ្ញុំមានសារធាតុឥតប្រយោជន៍ផ្ទាល់ខ្លួនរបស់ខ្ញុំ បន្ថែមពីលើអ្វីដែលត្រូវការសម្រាប់ build... ខ្ញុំក៏អាចត្រូវការសារធាតុឥតបានការផ្សេងទៀត។ ដូច្នេះខ្ញុំ "សាមញ្ញ" បង្កើតឧបករណ៍ដែលពិនិត្យមើលគម្រោងទាំងមូល។ ឬខ្ញុំបង្កើត monorepository ក្លែងក្លាយជាមួយ submodules ។ យើងអាចដើរជុំវិញនេះពេញមួយថ្ងៃ។ ប៉ុន្តែខ្ញុំគិតថា អាគុយម៉ង់របស់ Matt នឹកហេតុផលចម្បង ដែលខ្ញុំបានត្រឡប់យ៉ាងខ្លាំងចំពោះការពេញចិត្តនៃ monorepository:

វាបង្កឱ្យមានការទំនាក់ទំនង និងបង្ហាញពីបញ្ហា

នៅពេលដែលយើងបំបែកឃ្លាំង យើងបង្កើតបញ្ហាជាក់ស្តែងនៃការសម្របសម្រួល និងតម្លាភាព។ នេះត្រូវគ្នាទៅនឹងរបៀបដែលយើងគិតអំពីក្រុម (ជាពិសេសវិធីដែលសមាជិកម្នាក់ៗគិតអំពីពួកគេ)៖ យើងទទួលខុសត្រូវចំពោះសមាសធាតុជាក់លាក់មួយ។ យើងធ្វើការនៅដាច់ដោយឡែកពីគេ។ ព្រំដែនត្រូវបានជួសជុលនៅលើក្រុមរបស់ខ្ញុំ និងសមាសភាគដែលយើងកំពុងធ្វើការ។

នៅពេលដែលស្ថាបត្យកម្មកាន់តែស្មុគស្មាញ ក្រុមមួយមិនអាចគ្រប់គ្រងវាតែម្នាក់ឯងបានទៀតទេ។ វិស្វករតិចតួចណាស់ដែលមានប្រព័ន្ធទាំងមូលនៅក្នុងក្បាលរបស់ពួកគេ។ ចូរនិយាយថាអ្នកគ្រប់គ្រងសមាសភាគ A ដែលបានចែករំលែកដែលត្រូវបានប្រើដោយក្រុម B, C, និង D ។ ក្រុម A កំពុងកែលម្អ កែលម្អ API និងការផ្លាស់ប្តូរការអនុវត្តផ្ទៃក្នុងផងដែរ។ ជាលទ្ធផល ការផ្លាស់ប្តូរមិនត្រូវគ្នានឹងថយក្រោយទេ។ តើអ្នកមានដំបូន្មានអ្វីខ្លះ?

• ស្វែងរកកន្លែងទាំងអស់ដែល API ចាស់ត្រូវបានប្រើប្រាស់។
• តើមានកន្លែងដែល API ថ្មីមិនអាចប្រើបានទេ?
• តើអ្នកអាចជួសជុល និងសាកល្បងសមាសធាតុផ្សេងទៀត ដើម្បីប្រាកដថាវាមិនខូចទេ?
• តើក្រុមទាំងនេះអាចសាកល្បងការផ្លាស់ប្តូររបស់អ្នកឥឡូវនេះបានទេ?

សូមចំណាំថាសំណួរទាំងនេះគឺឯករាជ្យនៃប្រភេទឃ្លាំង។ អ្នកនឹងត្រូវស្វែងរកក្រុម B, C និង D។ អ្នកនឹងត្រូវនិយាយជាមួយពួកគេ ស្វែងរកពេលវេលា ស្វែងយល់ពីអាទិភាពរបស់ពួកគេ។ យ៉ាងហោចណាស់យើងសង្ឃឹមថាអ្នកនឹង។

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

នៅក្នុង monorepository ការទទួលខុសត្រូវត្រូវបានផ្លាស់ប្តូរតាមលំនាំដើម។ ក្រុម A ផ្លាស់ប្តូរសមាសធាតុរបស់ពួកគេ ហើយប្រសិនបើមិនប្រុងប្រយ័ត្នទេ បំបែក B, C និង D ភ្លាមៗ។ នេះនាំឱ្យ B, C និង D បង្ហាញខ្លួននៅមាត់ទ្វារ A ដោយឆ្ងល់ថាហេតុអ្វីបានជាក្រុម A បំបែកការជួបប្រជុំគ្នា។ នេះបង្រៀន A ថាពួកគេមិនអាចរំលងបញ្ជីរបស់ខ្ញុំខាងលើបានទេ។ ពួកគេត្រូវតែនិយាយអំពីអ្វីដែលពួកគេនឹងធ្វើ។ តើ B, C និង D អាចផ្លាស់ទីបានទេ? ចុះប្រសិនបើ B និង C អាច ប៉ុន្តែ D ត្រូវបានទាក់ទងយ៉ាងជិតស្និទ្ធទៅនឹងផលប៉ះពាល់នៃអាកប្បកិរិយារបស់ក្បួនដោះស្រាយចាស់?

បន្ទាប់មកយើងត្រូវនិយាយអំពីរបៀបដែលយើងនឹងចេញពីស្ថានភាពនេះ:

1. ការគាំទ្រសម្រាប់ APIs ខាងក្នុងច្រើន ហើយនឹងសម្គាល់ក្បួនដោះស្រាយចាស់ថាត្រូវបានបដិសេធរហូតដល់ D អាចឈប់ប្រើវា។
2. ការ​គាំទ្រ​សម្រាប់​កំណែ​ចេញ​ផ្សាយ​ជា​ច្រើន, មួយ​ជាមួយ​នឹង​ចំណុច​ប្រទាក់​ចាស់, មួយ​ជាមួយ​នឹង​ថ្មី។
3. ពន្យារពេលការចេញផ្សាយការផ្លាស់ប្តូររបស់ A រហូតដល់ B, C, និង D អាចទទួលយកបានក្នុងពេលដំណាលគ្នា។

ឧបមាថាយើងបានជ្រើសរើស 1 APIs ជាច្រើន។ ក្នុងករណីនេះយើងមានលេខកូដពីរ។ ចាស់និងថ្មី។ ងាយស្រួលក្នុងស្ថានភាពខ្លះ។ យើងពិនិត្យមើលលេខកូដចាស់ត្រឡប់មកវិញ សម្គាល់វាថាបានបដិសេធ ហើយយល់ព្រមលើកាលវិភាគដកចេញជាមួយក្រុម D។ ដូចគ្នាបេះបិទសម្រាប់ឃ្លាំងពហុ និងម៉ូណូ។

ដើម្បីចេញផ្សាយកំណែច្រើន យើងត្រូវការសាខាមួយ។ ឥឡូវនេះយើងមានសមាសភាគពីរ - A1 និង A2 ។ ក្រុម B និង C ប្រើ A2 និង D ប្រើ A1 ។ យើងត្រូវការសមាសធាតុទាំងអស់ដើម្បីត្រៀមខ្លួនសម្រាប់ការចេញផ្សាយ ពីព្រោះការអាប់ដេតសុវត្ថិភាព និងការជួសជុលកំហុសផ្សេងទៀតអាចត្រូវបានទាមទារ មុនពេល D អាចបន្តទៅមុខបាន។ នៅក្នុង polyrepository យើងអាចលាក់វានៅក្នុងសាខាដែលមានអាយុកាលយូរដែលមានអារម្មណ៍ល្អ។ នៅក្នុង monorepository យើងបង្ខំឱ្យបង្កើតកូដនៅក្នុងម៉ូឌុលថ្មីមួយ។ ក្រុម D នឹងនៅតែត្រូវធ្វើការផ្លាស់ប្តូរទៅសមាសភាគ "ចាស់" ។ អ្នកគ្រប់គ្នាអាចមើលឃើញតម្លៃដែលយើងកំពុងបង់នៅទីនេះ - ឥឡូវនេះយើងមានលេខកូដពីរដងច្រើនជាង ហើយការកែកំហុសណាមួយដែលអនុវត្តចំពោះ A1 និង A2 ត្រូវតែអនុវត្តចំពោះពួកគេទាំងពីរ។ ជាមួយនឹងវិធីសាស្រ្តនៃការបំបែកនៅក្នុង polyrepository នេះត្រូវបានលាក់នៅពីក្រោយ cherry-pick ។ យើង​ចាត់​ទុក​ការ​ចំណាយ​ទាប​ជាង​ព្រោះ​មិន​មាន​ការ​ចម្លង។ តាមទស្សនៈជាក់ស្តែង ការចំណាយគឺដូចគ្នា៖ អ្នកនឹងបង្កើត ចេញផ្សាយ និងរក្សាមូលដ្ឋានកូដដែលដូចគ្នាបេះបិទចំនួនពីរ រហូតដល់អ្នកអាចលុបមួយក្នុងចំណោមពួកវាបាន។ ភាពខុសគ្នាគឺថាជាមួយនឹង monorepository ការឈឺចាប់នេះគឺដោយផ្ទាល់និងអាចមើលឃើញ។ នេះកាន់តែអាក្រក់ ហើយនោះជាការល្អ។

ទីបំផុតយើងឈានដល់ចំណុចទីបី។ ការពន្យាពេលចេញផ្សាយ។ វាអាចទៅរួចដែលថាការផ្លាស់ប្តូរដែលធ្វើឡើងដោយ A នឹងធ្វើអោយជីវិតរបស់ក្រុម A. ប្រសើរឡើង ប៉ុន្តែមិនមែនជារឿងបន្ទាន់នោះទេ។ តើយើងអាចពន្យាពេលបានទេ? នៅក្នុង polyrepository យើងរុញវាដើម្បីខ្ទាស់វត្ថុបុរាណ។ ជា​ការ​ពិត​ណាស់​យើង​កំពុង​ប្រាប់​រឿង​នេះ​ទៅ​ក្រុម D. គ្រាន់​តែ​នៅ​លើ​កំណែ​ចាស់​រហូត​ដល់​អ្នក​តាម​ទាន់! នេះកំណត់អ្នកឱ្យលេងមនុស្សកំសាក។ ក្រុម A បន្តធ្វើការលើសមាសធាតុរបស់ពួកគេដោយមិនអើពើនឹងការពិតដែលថាក្រុម D កំពុងប្រើកំណែដែលហួសសម័យកាន់តែខ្លាំង (នោះជាបញ្ហារបស់ក្រុម D ពួកគេល្ងង់) ។ ទន្ទឹមនឹងនេះដែរ ក្រុម D និយាយអំពីអាកប្បកិរិយាមិនចេះខ្វល់ខ្វាយរបស់ក្រុម A ចំពោះស្ថេរភាពកូដ ប្រសិនបើពួកគេនិយាយអំពីវាទាល់តែសោះ។ ខែកន្លងផុតទៅ។ ទីបំផុតក្រុម D សម្រេចចិត្តពិនិត្យមើលលទ្ធភាពនៃការអាប់ដេត ប៉ុន្តែ A មានតែការផ្លាស់ប្តូរបន្ថែមទៀតប៉ុណ្ណោះ។ ក្រុម A ស្ទើរតែមិនចាំថានៅពេលណា ឬរបៀបដែលពួកគេបានបំបែក D។ ការធ្វើឱ្យប្រសើរកាន់តែឈឺចាប់ ហើយនឹងចំណាយពេលយូរជាងនេះ។ ដែលបញ្ជូនវាបន្ថែមទៀតចុះក្រោមជង់អាទិភាព។ ដល់​ថ្ងៃ​ហ្នឹង​យើង​មាន​បញ្ហា​សន្តិសុខ​នៅ A ដែល​បង្ខំ​ឲ្យ​យើង​ធ្វើ​សាខា។ ក្រុម A ត្រូវតែត្រលប់ទៅពេលវេលាវិញ ស្វែងរកចំណុចនៅពេលដែល D មានស្ថេរភាព ដោះស្រាយបញ្ហានៅទីនោះ ហើយរៀបចំវាឱ្យរួចរាល់សម្រាប់ការចេញផ្សាយ។ នេះ​ជា​ជម្រើស​ពិត​ដែល​មនុស្ស​ធ្វើ ហើយ​វា​ជា​ការ​អាក្រក់​បំផុត​រហូត​មក​ដល់​ពេល​នេះ។ វាហាក់ដូចជាល្អសម្រាប់ទាំងក្រុម A និងក្រុម D ដរាបណាយើងអាចមិនអើពើគ្នាទៅវិញទៅមក។

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

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

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

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកណាជាអ្នកនិយមជ្រុលជាងគេ? អ្នកគាំទ្រ៖

• ម៉ូណូរប៉ូ

• ច្រែះ

• ការស្ទង់មតិមិនត្រឹមត្រូវ / ទាំងពីរ

អ្នកប្រើប្រាស់ 33 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ៧៨ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com