ຢ່າຕົກລົງທີ່ຈະພັດທະນາສິ່ງທີ່ເຈົ້າບໍ່ເຂົ້າໃຈ

ນັບຕັ້ງແຕ່ຕົ້ນປີ 2018, ຂ້າພະເຈົ້າໄດ້ຖືຕໍາແຫນ່ງຜູ້ນໍາ / ນາຍຈ້າງ / ຜູ້ພັດທະນາຜູ້ນໍາໃນທີມ - ໂທຫາມັນຕາມທີ່ທ່ານຕ້ອງການ, ແຕ່ຈຸດສໍາຄັນແມ່ນຂ້ອຍຮັບຜິດຊອບທັງຫມົດສໍາລັບຫນຶ່ງໃນໂມດູນແລະສໍາລັບນັກພັດທະນາທັງຫມົດທີ່ເຮັດວຽກ. ສຸດມັນ. ຕໍາແຫນ່ງນີ້ເຮັດໃຫ້ຂ້ອຍມີທັດສະນະໃຫມ່ກ່ຽວກັບຂະບວນການພັດທະນາ, ຍ້ອນວ່າຂ້ອຍມີສ່ວນຮ່ວມໃນໂຄງການຫຼາຍຂຶ້ນແລະມີສ່ວນຮ່ວມຫຼາຍໃນການຕັດສິນໃຈ. ບໍ່ດົນມານີ້, ຂໍຂອບໃຈກັບທັງສອງສະຖານະການນີ້, ຂ້າພະເຈົ້າທັນທີທັນໃດຮູ້ວ່າມາດຕະການຄວາມເຂົ້າໃຈມີຜົນກະທົບລະຫັດແລະຄໍາຮ້ອງສະຫມັກ.

ຈຸດທີ່ຂ້ອຍຢາກເຮັດແມ່ນວ່າຄຸນນະພາບຂອງລະຫັດ (ແລະຜະລິດຕະພັນສຸດທ້າຍ) ມີຄວາມກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດກັບວິທີການຮູ້ວ່າຜູ້ທີ່ກໍາລັງອອກແບບແລະຂຽນລະຫັດແມ່ນກ່ຽວກັບສິ່ງທີ່ພວກເຂົາກໍາລັງເຮັດ.

ເຈົ້າອາດຈະຄິດໃນຕອນນີ້, “ຂອບໃຈ, Cap. ແນ່ນອນ, ມັນຈະດີທີ່ຈະເຂົ້າໃຈສິ່ງທີ່ທ່ານກໍາລັງຂຽນໂດຍທົ່ວໄປ. ຖ້າບໍ່ດັ່ງນັ້ນ, ເຈົ້າອາດຈະຈ້າງກຸ່ມລິງເພື່ອຕີກະແຈທີ່ຕົນເອງມັກແລະປ່ອຍໃຫ້ມັນຢູ່ນັ້ນ.” ແລະເຈົ້າຖືກຕ້ອງແທ້ໆ. ຕາມນັ້ນແລ້ວ, ຂ້າພະເຈົ້າຖືວ່າທ່ານຮັບຮູ້ວ່າການມີຄວາມຄິດທົ່ວໄປກ່ຽວກັບສິ່ງທີ່ທ່ານກໍາລັງເຮັດແມ່ນມີຄວາມຈໍາເປັນ. ນີ້ສາມາດເອີ້ນວ່າລະດັບຄວາມເຂົ້າໃຈຂອງສູນ, ແລະພວກເຮົາຈະບໍ່ວິເຄາະຢ່າງລະອຽດ. ພວກເຮົາຈະເບິ່ງຢ່າງລະອຽດກ່ຽວກັບສິ່ງທີ່ແນ່ນອນທີ່ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈແລະວ່າມັນມີຜົນກະທົບແນວໃດຕໍ່ການຕັດສິນໃຈທີ່ທ່ານເຮັດທຸກໆມື້. ຖ້າຂ້ອຍໄດ້ຮູ້ຈັກສິ່ງເຫຼົ່ານີ້ລ່ວງຫນ້າ, ມັນຈະຊ່ວຍປະຢັດເວລາເສຍເວລາຫຼາຍແລະລະຫັດທີ່ຫນ້າສົງໄສ.

ເຖິງແມ່ນວ່າທ່ານຈະບໍ່ເຫັນເສັ້ນດຽວຂອງລະຫັດຂ້າງລຸ່ມນີ້, ຂ້າພະເຈົ້າຍັງເຊື່ອວ່າທຸກສິ່ງທຸກຢ່າງທີ່ກ່າວນີ້ແມ່ນມີຄວາມສໍາຄັນຫຼາຍສໍາລັບການຂຽນລະຫັດທີ່ມີຄຸນນະພາບສູງ, ສະແດງອອກ.

ຄວາມເຂົ້າໃຈລະດັບທໍາອິດ: ເປັນຫຍັງມັນບໍ່ເຮັດວຽກ?

ນັກພັດທະນາມັກຈະບັນລຸລະດັບນີ້ໄວໃນການເຮັດວຽກຂອງເຂົາເຈົ້າ, ບາງຄັ້ງເຖິງແມ່ນວ່າບໍ່ມີການຊ່ວຍເຫຼືອຈາກຜູ້ອື່ນ - ຢ່າງຫນ້ອຍໃນປະສົບການຂອງຂ້ອຍ. ຈິນຕະນາການວ່າທ່ານໄດ້ຮັບລາຍງານ bug: ບາງຫນ້າທີ່ໃນແອັບພລິເຄຊັນບໍ່ເຮັດວຽກ, ມັນຈໍາເປັນຕ້ອງແກ້ໄຂ. ທ່ານຈະດໍາເນີນການແນວໃດ?

ໂຄງ​ການ​ມາດ​ຕະ​ຖານ​ເບິ່ງ​ຄື​ນີ້​:

1. ຊອກຫາຊິ້ນສ່ວນຂອງລະຫັດທີ່ເຮັດໃຫ້ເກີດບັນຫາ (ວິທີການເຮັດນີ້ແມ່ນຫົວຂໍ້ແຍກຕ່າງຫາກ, ຂ້ອຍກວມເອົາມັນຢູ່ໃນປື້ມຂອງຂ້ອຍກ່ຽວກັບລະຫັດມໍລະດົກ)
2. ປ່ຽນແປງຕົວຢ່າງນີ້
3. ໃຫ້ແນ່ໃຈວ່າ bug ໄດ້ຖືກແກ້ໄຂແລະບໍ່ມີຄວາມຜິດພາດ regression ເກີດຂຶ້ນ

ຕອນນີ້ໃຫ້ເຮົາສຸມໃສ່ຈຸດທີສອງ - ການປ່ຽນແປງລະຫັດ. ມີສອງວິທີການໃນຂະບວນການນີ້. ທໍາອິດແມ່ນການເຈາະເລິກສິ່ງທີ່ເກີດຂື້ນໃນລະຫັດປະຈຸບັນ, ກໍານົດຄວາມຜິດພາດແລະແກ້ໄຂມັນ. ອັນທີສອງ: ຍ້າຍໂດຍຄວາມຮູ້ສຶກ - ເພີ່ມ, ເວົ້າ, +1 ໄປຫາຄໍາຖະແຫຼງການທີ່ມີເງື່ອນໄຂຫຼື loop, ເບິ່ງວ່າຫນ້າທີ່ເຮັດວຽກຢູ່ໃນສະຖານະການທີ່ຕ້ອງການ, ຫຼັງຈາກນັ້ນລອງສິ່ງອື່ນ, ແລະອື່ນໆໃນການໂຄສະນາ infinitum.

ວິທີການທໍາອິດແມ່ນຖືກຕ້ອງ. ດັ່ງທີ່ Steve McConnell ອະທິບາຍໃນປື້ມລະຫັດຄົບຖ້ວນຂອງລາວ (ທີ່ຂ້າພະເຈົ້າແນະນໍາຢ່າງສູງ, ໂດຍວິທີທາງການ), ທຸກໆຄັ້ງທີ່ພວກເຮົາປ່ຽນບາງສິ່ງບາງຢ່າງໃນລະຫັດ, ພວກເຮົາຄວນຈະສາມາດຄາດເດົາໄດ້ຢ່າງຫມັ້ນໃຈວ່າມັນຈະສົ່ງຜົນກະທົບຕໍ່ຄໍາຮ້ອງສະຫມັກແນວໃດ. ຂ້ອຍອ້າງເຖິງຄວາມຊົງຈໍາ, ແຕ່ຖ້າ bugfix ບໍ່ເຮັດວຽກຕາມທີ່ເຈົ້າຄາດຫວັງ, ເຈົ້າຄວນຈະຕົກໃຈຫຼາຍແລະເຈົ້າຄວນຕັ້ງຄໍາຖາມກ່ຽວກັບແຜນການປະຕິບັດທັງຫມົດຂອງເຈົ້າ.

ເພື່ອສະຫຼຸບສິ່ງທີ່ໄດ້ກ່າວມາ, ເພື່ອປະຕິບັດການແກ້ໄຂຂໍ້ບົກພ່ອງທີ່ດີທີ່ບໍ່ເຮັດໃຫ້ລະຫັດຫຼຸດລົງ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈທັງໂຄງສ້າງທັງຫມົດຂອງລະຫັດແລະແຫຼ່ງຂອງບັນຫາສະເພາະ.

ຄວາມເຂົ້າໃຈລະດັບທີສອງ: ເປັນຫຍັງມັນເຮັດວຽກ?

ລະດັບນີ້ແມ່ນຄວາມເຂົ້າໃຈຫຼາຍຫນ້ອຍ intuitively ກ່ວາລະດັບທີ່ຜ່ານມາ. ຂ້ອຍ, ໃນຂະນະທີ່ຍັງເປັນນັກພັດທະນາຈົວ, ໄດ້ຮຽນຮູ້ມັນຂອບໃຈກັບເຈົ້ານາຍຂອງຂ້ອຍ, ແລະຕໍ່ມາໄດ້ອະທິບາຍຄວາມສໍາຄັນຂອງເລື່ອງໃຫ້ກັບຜູ້ໃຫມ່ເລື້ອຍໆ.

ເວລານີ້, ລອງຈິນຕະນາການວ່າທ່ານໄດ້ຮັບລາຍງານ bug ສອງຄັ້ງໃນເວລາດຽວກັນ: ທໍາອິດແມ່ນກ່ຽວກັບສະຖານະການ A, ທີສອງແມ່ນກ່ຽວກັບສະຖານະການ B. ໃນທັງສອງສະຖານະການ, ບາງສິ່ງບາງຢ່າງທີ່ຜິດພາດເກີດຂຶ້ນ. ຕາມ​ນັ້ນ​ແລ້ວ​, ທ່ານ​ຈະ​ແກ້​ໄຂ​ບັນ​ຫາ​ທໍາ​ອິດ​. ການນໍາໃຊ້ຫຼັກການທີ່ພວກເຮົາໄດ້ພັດທະນາສໍາລັບຄວາມເຂົ້າໃຈລະດັບ XNUMX, ທ່ານຂຸດລົງເລິກເຂົ້າໄປໃນລະຫັດທີ່ກ່ຽວຂ້ອງກັບບັນຫາ, ຄົ້ນຫາວ່າເປັນຫຍັງມັນເຮັດໃຫ້ແອັບພລິເຄຊັນປະຕິບັດວິທີທີ່ມັນເຮັດໃນສະຖານະການ A, ແລະເຮັດໃຫ້ການປັບຕົວທີ່ສົມເຫດສົມຜົນທີ່ຜົນໄດ້ຮັບທີ່ທ່ານຕ້ອງການ. . ທຸກສິ່ງທຸກຢ່າງແມ່ນດີຫຼາຍ.

ຈາກ​ນັ້ນ​ເຈົ້າ​ກ້າວ​ໄປ​ທີ່​ສະ​ຖາ​ນະ​ການ B. ເຈົ້າ​ເຮັດ​ຄືນ​ສະ​ຖາ​ນະ​ການ​ໃນ​ຄວາມ​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ເຮັດ​ໃຫ້​ເກີດ​ຄວາມ​ຜິດ​ພາດ​, ແຕ່​ຄວາມ​ແປກ​ໃຈ​! — ໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຕາມທີ່ມັນຄວນຈະເປັນ. ເພື່ອຢືນຢັນການຄາດເດົາຂອງທ່ານ, ທ່ານຍົກເລີກການປ່ຽນແປງທີ່ທ່ານເຮັດໃນຂະນະທີ່ເຮັດວຽກຢູ່ໃນ bug A, ແລະ bug B ກັບຄືນມາ. ການແກ້ໄຂຂໍ້ບົກພ່ອງຂອງເຈົ້າໄດ້ແກ້ໄຂບັນຫາທັງສອງຢ່າງ. ໂຊກດີ!

ທ່ານບໍ່ໄດ້ນັບກ່ຽວກັບເລື່ອງນີ້ເລີຍ. ທ່ານໄດ້ມາເຖິງວິທີການແກ້ໄຂຂໍ້ຜິດພາດໃນສະຖານະການ A ແລະບໍ່ຮູ້ວ່າເປັນຫຍັງມັນຈຶ່ງເຮັດວຽກກັບສະຖານະການ B. ໃນຂັ້ນຕອນນີ້, ມັນເປັນການລໍ້ລວງຫຼາຍທີ່ຈະຄິດວ່າວຽກງານທັງສອງໄດ້ຖືກສໍາເລັດ. ນີ້ແມ່ນສົມເຫດສົມຜົນຫຼາຍ: ຈຸດແມ່ນເພື່ອລົບລ້າງຄວາມຜິດພາດ, ບໍ່ແມ່ນບໍ? ແຕ່ວຽກຍັງບໍ່ແລ້ວເທື່ອ: ເຈົ້າຍັງຕ້ອງຄິດອອກວ່າ ເປັນຫຍັງການກະທຳຂອງເຈົ້າຈຶ່ງແກ້ໄຂຂໍ້ຜິດພາດໃນສະຖານະການ B. ເປັນຫຍັງ? ເນື່ອງຈາກວ່າມັນອາດຈະເຮັດວຽກຢູ່ໃນຫຼັກການທີ່ບໍ່ຖືກຕ້ອງ, ແລະຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງຊອກຫາວິທີອື່ນ. ນີ້ແມ່ນບາງຕົວຢ່າງຂອງກໍລະນີດັ່ງກ່າວ:

• ເນື່ອງຈາກການແກ້ໄຂບໍ່ໄດ້ຖືກປັບໃຫ້ເຫມາະສົມກັບຄວາມຜິດພາດ B, ໂດຍຄໍານຶງເຖິງປັດໃຈທັງຫມົດ, ທ່ານອາດຈະມີຫນ້າທີ່ແຕກຫັກໂດຍບໍ່ຮູ້ຕົວ C.
• ມັນເປັນໄປໄດ້ວ່າຍັງມີ bug ທີສາມທີ່ລີ້ຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ກ່ຽວຂ້ອງກັບຫນ້າທີ່ດຽວກັນ, ແລະ bug ຂອງເຈົ້າແມ່ນຂຶ້ນກັບມັນສໍາລັບການປະຕິບັດງານທີ່ຖືກຕ້ອງຂອງລະບົບໃນສະຖານະການ B. ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ເບິ່ງ​ຄື​ວ່າ​ດີ​ໃນ​ປັດ​ຈຸ​ບັນ​, ແຕ່​ມື້​ຫນຶ່ງ bug ທີ​ສາມ​ນີ້​ຈະ​ໄດ້​ຮັບ​ການ​ສັງ​ເກດ​ແລະ​ການ​ແກ້​ໄຂ​. ຫຼັງຈາກນັ້ນ, ໃນສະຖານະການ B, ຄວາມຜິດພາດຈະເກີດຂຶ້ນອີກເທື່ອຫນຶ່ງ, ແລະມັນກໍ່ດີຖ້າມີພຽງແຕ່ມີ.

ທັງຫມົດນີ້ເພີ່ມຄວາມວຸ່ນວາຍກັບລະຫັດແລະມື້ຫນຶ່ງຈະຕົກຢູ່ໃນຫົວຂອງທ່ານ - ສ່ວນຫຼາຍແມ່ນໃນຊ່ວງເວລາທີ່ບໍ່ເຫມາະສົມທີ່ສຸດ. ເຈົ້າຈະຕ້ອງລວບລວມຄວາມຕັ້ງໃຈຂອງເຈົ້າເພື່ອບັງຄັບຕົວເອງໃຫ້ໃຊ້ເວລາເຂົ້າໃຈວ່າເປັນຫຍັງທຸກຢ່າງເບິ່ງຄືວ່າເຮັດວຽກ, ແຕ່ມັນກໍ່ຄຸ້ມຄ່າ.

ຄວາມເຂົ້າໃຈລະດັບທີສາມ: ເປັນຫຍັງມັນເຮັດວຽກ?

ຄວາມເຂົ້າໃຈທີ່ຜ່ານມາຂອງຂ້ອຍກ່ຽວຂ້ອງກັບລະດັບນີ້ຢ່າງແນ່ນອນ, ແລະມັນອາດຈະເປັນສິ່ງທີ່ເຮັດໃຫ້ຂ້ອຍໄດ້ຮັບຜົນປະໂຫຍດຫຼາຍທີ່ສຸດຖ້າຂ້ອຍໄດ້ເຂົ້າໃຈຄວາມຄິດນີ້ກ່ອນຫນ້ານີ້.

ເພື່ອເຮັດໃຫ້ມັນຊັດເຈນຂຶ້ນ, ໃຫ້ເບິ່ງຕົວຢ່າງ: ໂມດູນຂອງທ່ານຕ້ອງການເຮັດໃຫ້ເຂົ້າກັນໄດ້ກັບຟັງຊັນ X. ທ່ານບໍ່ຄຸ້ນເຄີຍກັບຟັງຊັນ X ໂດຍສະເພາະ, ແຕ່ທ່ານໄດ້ຖືກບອກວ່າເພື່ອໃຫ້ເຂົ້າກັນໄດ້, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ກອບ F. ໂມດູນທີ່ປະສົມປະສານກັບ X ເຮັດວຽກຢ່າງແທ້ຈິງກັບລາວ.

ລະຫັດຂອງທ່ານບໍ່ໄດ້ຕິດຕໍ່ກັບກອບ F ທັງຫມົດນັບຕັ້ງແຕ່ມື້ທໍາອິດຂອງຊີວິດຂອງມັນ, ດັ່ງນັ້ນການປະຕິບັດມັນຈະບໍ່ງ່າຍຫຼາຍ. ນີ້ຈະມີຜົນສະທ້ອນທີ່ຮ້າຍແຮງສໍາລັບບາງສ່ວນຂອງໂມດູນ. ຢ່າງໃດກໍຕາມ, ທ່ານຖິ້ມຕົວທ່ານເອງເຂົ້າໄປໃນການພັດທະນາ: ທ່ານໃຊ້ເວລາຫຼາຍອາທິດໃນການຂຽນລະຫັດ, ການທົດສອບ, ເປີດຕົວຮຸ່ນທົດລອງ, ການໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນ, ການແກ້ໄຂຄວາມຜິດພາດການຖົດຖອຍ, ຄົ້ນພົບອາການແຊກຊ້ອນທີ່ຄາດບໍ່ເຖິງ, ບໍ່ຕອບສະຫນອງກໍານົດເວລາທີ່ກໍານົດໄວ້ໃນເບື້ອງຕົ້ນ, ຂຽນລະຫັດເພີ່ມເຕີມ, ການທົດສອບ, ການສື່ສານຄໍາຄຶດຄໍາເຫັນ, ການແກ້ໄຂຄວາມຜິດພາດ regression - ທັງຫມົດນີ້ເພື່ອປະຕິບັດກອບ F.

ແລະໃນບາງຈຸດທີ່ເຈົ້າຮູ້ຢ່າງກະທັນຫັນ - ຫຼືອາດຈະໄດ້ຍິນຈາກບາງຄົນ - ບາງທີກອບ F ຈະບໍ່ເຮັດໃຫ້ເຈົ້າເຂົ້າກັນໄດ້ກັບຄຸນສົມບັດ X ເລີຍ.

ບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນເກີດຂຶ້ນຄັ້ງດຽວໃນຂະນະທີ່ເຮັດວຽກກ່ຽວກັບໂຄງການທີ່ຂ້າພະເຈົ້າຮັບຜິດຊອບ. ເປັນຫຍັງເລື່ອງນີ້ເກີດຂຶ້ນ? ເນື່ອງຈາກວ່າຂ້ອຍມີຄວາມເຂົ້າໃຈຫນ້ອຍກ່ຽວກັບຫນ້າທີ່ X ແມ່ນຫຍັງແລະມັນກ່ຽວຂ້ອງກັບກອບ F. ຂ້ອຍຄວນເຮັດແນວໃດ? ຂໍໃຫ້ຜູ້ທີ່ມອບຫມາຍວຽກງານການພັດທະນາໃຫ້ອະທິບາຍຢ່າງຈະແຈ້ງວ່າວິທີການທີ່ມີຈຸດປະສົງນໍາໄປສູ່ຜົນໄດ້ຮັບທີ່ຕ້ອງການ, ແທນທີ່ຈະພຽງແຕ່ເວົ້າຄືນສິ່ງທີ່ໄດ້ເຮັດສໍາລັບໂມດູນອື່ນໆຫຼືເອົາຄໍາຂອງພວກເຂົາສໍາລັບມັນວ່ານີ້ແມ່ນສິ່ງທີ່ຄຸນສົມບັດ X ຕ້ອງເຮັດ.

ປະສົບການຂອງໂຄງການນີ້ໄດ້ສອນຂ້ອຍໃຫ້ປະຕິເສດທີ່ຈະເລີ່ມຕົ້ນຂະບວນການພັດທະນາຈົນກ່ວາພວກເຮົາເຂົ້າໃຈຢ່າງຈະແຈ້ງວ່າເປັນຫຍັງພວກເຮົາຖືກຮ້ອງຂໍໃຫ້ເຮັດບາງສິ່ງທີ່ແນ່ນອນ. ປະຕິເສດທັນທີ. ເມື່ອທ່ານໄດ້ຮັບວຽກງານ, ແຮງກະຕຸ້ນທໍາອິດແມ່ນໃຫ້ປະຕິບັດທັນທີເພື່ອບໍ່ໃຫ້ເສຍເວລາ. ແຕ່ນະໂຍບາຍ "ຢຸດໂຄງການຈົນກ່ວາພວກເຮົາເຂົ້າໄປໃນລາຍລະອຽດທັງຫມົດ" ສາມາດຫຼຸດຜ່ອນເວລາເສຍເວລາໂດຍຄໍາສັ່ງຂອງຂະຫນາດ.

ເຖິງແມ່ນວ່າພວກເຂົາພະຍາຍາມສ້າງຄວາມກົດດັນຕໍ່ເຈົ້າ, ເພື່ອບັງຄັບເຈົ້າໃຫ້ເລີ່ມເຮັດວຽກ, ເຖິງແມ່ນວ່າເຈົ້າບໍ່ເຂົ້າໃຈເຫດຜົນສໍາລັບການນີ້, ຕ້ານທານ. ກ່ອນອື່ນ ໝົດ, ພິຈາລະນາວ່າເປັນຫຍັງເຈົ້າຈຶ່ງຖືກມອບໃຫ້ວຽກດັ່ງກ່າວ, ແລະຕັດສິນໃຈວ່ານີ້ແມ່ນເສັ້ນທາງທີ່ຖືກຕ້ອງກັບເປົ້າ ໝາຍ. ຂ້ອຍຕ້ອງຮຽນຮູ້ທັງໝົດນີ້ດ້ວຍວິທີທີ່ຍາກ - ຂ້ອຍຫວັງວ່າຕົວຢ່າງຂອງຂ້ອຍຈະເຮັດໃຫ້ຊີວິດງ່າຍຂຶ້ນສໍາລັບຜູ້ທີ່ອ່ານເລື່ອງນີ້.

ຄວາມເຂົ້າໃຈລະດັບສີ່: ???

ມີສະເຫມີຫຼາຍທີ່ຈະຮຽນຮູ້ໃນການຂຽນໂປລແກລມ, ແລະຂ້າພະເຈົ້າເຊື່ອວ່າຂ້າພະເຈົ້າພຽງແຕ່ scratched ດ້ານຂອງຫົວຂໍ້ຂອງຄວາມເຂົ້າໃຈ. ລະດັບຄວາມເຂົ້າໃຈອື່ນໃດທີ່ທ່ານຄົ້ນພົບໃນໄລຍະປີຂອງການເຮັດວຽກກັບລະຫັດ? ການຕັດສິນໃຈອັນໃດທີ່ທ່ານໄດ້ເຮັດນັ້ນມີຜົນກະທົບທາງບວກຕໍ່ຄຸນນະພາບຂອງລະຫັດແລະຄໍາຮ້ອງສະຫມັກ? ການ​ຕັດສິນ​ໃຈ​ອັນ​ໃດ​ທີ່​ເຮັດ​ຜິດ​ແລະ​ໄດ້​ສອນ​ບົດຮຽນ​ອັນ​ລ້ຳ​ຄ່າ​ໃຫ້​ເຈົ້າ? ແບ່ງປັນປະສົບການຂອງທ່ານໃນຄໍາເຫັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com