កុំយល់ព្រមក្នុងការអភិវឌ្ឍន៍អ្វីដែលអ្នកមិនយល់

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

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

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

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

កម្រិតដំបូងនៃការយល់ដឹង: ហេតុអ្វីបានជាវាមិនដំណើរការ?

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

គ្រោងការណ៍ស្តង់ដារមើលទៅដូចនេះ:

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

ឥឡូវនេះសូមផ្តោតលើចំណុចទីពីរ - ធ្វើការផ្លាស់ប្តូរកូដ។ មានវិធីសាស្រ្តពីរសម្រាប់ដំណើរការនេះ។ ទីមួយគឺត្រូវស្វែងយល់អំពីអ្វីដែលកំពុងកើតឡើងនៅក្នុងកូដបច្ចុប្បន្ន កំណត់អត្តសញ្ញាណកំហុស និងជួសជុលវា។ ទីពីរ៖ ផ្លាស់ទីដោយអារម្មណ៍ - បន្ថែម និយាយថា +1 ទៅសេចក្តីថ្លែងការណ៍តាមលក្ខខណ្ឌ ឬរង្វិលជុំ មើលថាតើមុខងារដំណើរការក្នុងសេណារីយ៉ូដែលចង់បាន ឬអត់ បន្ទាប់មកសាកល្បងអ្វីផ្សេងទៀត ហើយដូច្នេះនៅលើការផ្សាយពាណិជ្ជកម្មគ្មានដែនកំណត់។

វិធីសាស្រ្តដំបូងគឺត្រឹមត្រូវ។ ដូចដែល Steve McConnell ពន្យល់នៅក្នុងសៀវភៅរបស់គាត់ Code Complete (ដែលខ្ញុំសូមផ្តល់អនុសាសន៍យ៉ាងខ្លាំង) រាល់ពេលដែលយើងផ្លាស់ប្តូរអ្វីមួយនៅក្នុងកូដ យើងគួរតែអាចទស្សន៍ទាយដោយទំនុកចិត្តថាតើវានឹងប៉ះពាល់ដល់កម្មវិធីយ៉ាងដូចម្តេច។ ខ្ញុំកំពុងដកស្រង់ចេញពីការចងចាំ ប៉ុន្តែប្រសិនបើការកែកំហុសមិនដំណើរការដូចដែលអ្នកបានរំពឹងទុក អ្នកគួរតែមានការតក់ស្លុតយ៉ាងខ្លាំង ហើយអ្នកគួរតែសួរសំណួរអំពីផែនការសកម្មភាពទាំងមូលរបស់អ្នក។

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

កម្រិតទីពីរនៃការយល់ដឹង: ហេតុអ្វីបានជាវាដំណើរការ?

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

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

បន្ទាប់មកអ្នកបន្តទៅសេណារីយ៉ូ ខ។ អ្នកធ្វើសេណារីយ៉ូម្តងទៀតក្នុងគោលបំណងបង្កកំហុស ប៉ុន្តែ - ភ្ញាក់ផ្អើល! - ឥឡូវនេះអ្វីៗដំណើរការដូចដែលវាគួរតែ។ ដើម្បីបញ្ជាក់ការស្មានរបស់អ្នក អ្នកមិនធ្វើវិញនូវការផ្លាស់ប្តូរដែលអ្នកបានធ្វើ ខណៈពេលដែលកំពុងធ្វើការលើបញ្ហា A ហើយកំហុស B ត្រលប់មកវិញ។ ការកែកំហុសរបស់អ្នកបានដោះស្រាយបញ្ហាទាំងពីរ។ សំណាង!

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

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

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

កម្រិតទីបីនៃការយល់ដឹង: ហេតុអ្វីបានជាវាដំណើរការ?

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

ដើម្បីធ្វើឱ្យវាកាន់តែច្បាស់ សូមក្រឡេកមើលឧទាហរណ៍មួយ៖ ម៉ូឌុលរបស់អ្នកត្រូវការធ្វើឱ្យត្រូវគ្នាជាមួយមុខងារ X។ អ្នកមិនសូវស្គាល់មុខងារ X ទេ ប៉ុន្តែអ្នកត្រូវបានគេប្រាប់ថាដើម្បីឱ្យត្រូវគ្នាជាមួយវា អ្នកត្រូវប្រើក្របខ័ណ្ឌ F ផ្សេងទៀត។ ម៉ូឌុលដែលរួមបញ្ចូលជាមួយ X ដំណើរការយ៉ាងពិតប្រាកដជាមួយគាត់។

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

ហើយនៅពេលណាមួយ អ្នកស្រាប់តែដឹង - ឬប្រហែលជាបានឮពីនរណាម្នាក់ - នោះប្រហែលជាក្របខ័ណ្ឌ F នឹងមិនផ្តល់ឱ្យអ្នកនូវភាពឆបគ្នាជាមួយនឹងលក្ខណៈពិសេស X ទាល់តែសោះ។ ប្រហែលជាពេលវេលា និងការខិតខំប្រឹងប្រែងទាំងអស់ត្រូវបានដាក់ខុសទាំងស្រុងចំពោះរឿងនោះ។

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

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

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

កម្រិតយល់ដឹងទី៤៖ ???

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

ប្រភព: www.habr.com