ຂ້ອຍໄດ້ຂຽນລະຫັດແບບມືອາຊີບເປັນເວລາຫຼາຍກວ່າຫ້າປີແລ້ວ. ສໍາລັບສີ່ປີທໍາອິດ, ຂ້າພະເຈົ້າບໍ່ເຄີຍສົນໃຈຂະຫນາດຂອງການຮ້ອງຂໍການດຶງ (PRs) ຂອງຂ້ອຍ. ຢ່າງໃດກໍຕາມ, ໃນປີກາຍນີ້, ຂ້າພະເຈົ້າໄດ້ຫັນປ່ຽນຈາກການສົ່ງ PRs ຂະຫນາດໃຫຍ່ທີ່ມີຫລາຍພັນເສັ້ນຂອງການປ່ຽນແປງເພື່ອທໍາລາຍພວກມັນເຂົ້າໄປໃນຂະຫນາດນ້ອຍກວ່າແລະສາມາດຈັດການໄດ້. ຜົນປະໂຫຍດຂອງການປ່ຽນແປງນີ້ແມ່ນມີຂະຫນາດໃຫຍ່, ແລະໃນ blog ນີ້, ຂ້າພະເຈົ້າຈະແບ່ງປັນຂໍ້ໄດ້ປຽບເຫຼົ່ານັ້ນ. ອີງຕາມ , ການຮ້ອງຂໍດຶງແມ່ນ: GitHub ການຮ້ອງຂໍດຶງແມ່ນການສະເຫນີທີ່ຈະລວມຊຸດການປ່ຽນແປງຈາກສາຂາຫນຶ່ງເຂົ້າໄປໃນອີກສາຂາຫນຶ່ງ. ໃນການຮ້ອງຂໍການດຶງ, ຜູ້ຮ່ວມມືສາມາດທົບທວນແລະປຶກສາຫາລືກ່ຽວກັບຊຸດການປ່ຽນແປງທີ່ສະເຫນີກ່ອນທີ່ພວກເຂົາຈະປະສົມປະສານການປ່ຽນແປງເຂົ້າໄປໃນ codebase ຕົ້ນຕໍ. ໂດຍພື້ນຖານແລ້ວ, ການຮ້ອງຂໍດຶງແມ່ນວິທີການຮ່ວມມື; ພວກເຮົາຄວນເຮັດທຸກຢ່າງທີ່ເປັນໄປໄດ້ເພື່ອເສີມຂະຫຍາຍການຮ່ວມມືນີ້. ວິທີຫນຶ່ງທີ່ມີປະສິດທິພາບເພື່ອປັບປຸງການຮ່ວມມືນີ້ແມ່ນເພື່ອຮັກສາ PRs ຂະຫນາດນ້ອຍ. ບໍ່ມີຄໍານິຍາມທົ່ວໄປທີ່ຈະແຍກຄວາມແຕກຕ່າງລະຫວ່າງ PR ຂະຫນາດນ້ອຍແລະຂະຫນາດໃຫຍ່. ການອີງໃສ່ພຽງແຕ່ຈໍານວນເສັ້ນທີ່ມີການປ່ຽນແປງແມ່ນບໍ່ພຽງພໍ, ຍ້ອນວ່າລະຫັດທີ່ຜະລິດແລະການທົດສອບອັດຕະໂນມັດສາມາດເຮັດໃຫ້ຈໍານວນເສັ້ນເພີ່ມຂຶ້ນ. ເມື່ອຂ້ອຍອ້າງເຖິງ PRs ຂະຫນາດນ້ອຍໃນບົດຄວາມນີ້, ຂ້ອຍຫມາຍຄວາມວ່າການແບ່ງ PR ຂະຫນາດໃຫຍ່ເຂົ້າໄປໃນຫຼາຍ PRs ຂະຫນາດນ້ອຍ, ມີເຫດຜົນ. ແຕ່ລະ PR ທີ່ນ້ອຍກວ່າຄວນຈະເປັນແບບດ່ຽວ, ສາມາດລວມເຂົ້າກັນໄດ້, ແລະສາມາດນຳໃຊ້ໄດ້. ຂ້ອຍບໍ່ສະຫນັບສະຫນູນການແບ່ງປັນປອມຄືກັບການແຍກ PR ເປັນສອງ, ອັນຫນຶ່ງມີລະຫັດທັງຫມົດແລະອີກອັນຫນຶ່ງທີ່ມີພຽງແຕ່ການທົດສອບ, ເນື່ອງຈາກວ່າວິທີການນີ້ບໍ່ສາມາດໃຫ້ຜົນປະໂຫຍດໃດໆທີ່ຂ້ອຍແບ່ງປັນຂ້າງລຸ່ມນີ້. ການທົບທວນຄືນປະສິດທິພາບ: ຂໍໃຫ້ນັກຂຽນໂປລແກລມທົບທວນຄືນລະຫັດ 10 ເສັ້ນ, ລາວຈະພົບເຫັນ 10 ບັນຫາ. ຂໍໃຫ້ລາວເຮັດ 500 ເສັ້ນແລະລາວຈະເວົ້າວ່າມັນເບິ່ງດີ. ໃນຂະນະທີ່ຕະຫລົກ, ຄໍາເວົ້ານີ້ເອົາຄວາມຈິງ. ບຸກຄົນທຸກຄົນແມ່ນຫຍຸ້ງກັບວຽກຂອງຕົນເອງ, ແລະເມື່ອທ່ານຂໍໃຫ້ຜູ້ໃດຜູ້ນຶ່ງທົບທວນຄືນ PR, ເຈົ້າກໍາລັງຂໍເວລາຂອງເຂົາເຈົ້າ. ການທົບທວນຄືນ PR ຮຽກຮ້ອງໃຫ້ນັກທົບທວນປ່ຽນສະພາບການຈາກການເຮັດວຽກຂອງຕົນເອງ, ແລະຖ້າການທົບທວນຄືນໃຊ້ເວລາຫຼາຍ, ມັນສາມາດເປັນສິ່ງທ້າທາຍສໍາລັບພວກເຂົາທີ່ຈະກັບຄືນໄປຫາວຽກງານຂອງພວກເຂົາ, ເຊິ່ງອາດຈະສົ່ງຜົນກະທົບຕໍ່ແຮງຈູງໃຈແລະຄວາມມຸ່ງຫມັ້ນໃນການທົບທວນຄືນ. PRs ຂະຫນາດນ້ອຍກວ່າ, ເຊິ່ງໃຊ້ເວລາພຽງແຕ່ປະມານ 20-30 ນາທີໃນການທົບທວນຄືນ, ແມ່ນງ່າຍຕໍ່ການແກ້ໄຂຫຼາຍເມື່ອທຽບໃສ່ກັບທີ່ສາມາດໃຊ້ເວລາ 2-3 ຊົ່ວໂມງ. ນອກຈາກນັ້ນ, PRs ຂະຫນາດໃຫຍ່ມັກຈະນໍາໄປສູ່ການກວດກາເພາະວ່າຂອບເຂດຄວາມສົນໃຈຂອງພວກເຮົາພຽງແຕ່ສາມາດຈັດການກັບຫຼາຍ, ແລະການກະໂດດລະຫວ່າງການປ່ຽນແປງຫຼາຍໃນ PR ດຽວສາມາດສັບສົນ. ຈາກປະສົບການຂອງຂ້ອຍ, PRs ຂະຫນາດນ້ອຍມີແນວໂນ້ມທີ່ຈະໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນທີ່ດີກວ່າແລະນໍາໄປສູ່ການສົນທະນາການອອກແບບທີ່ມີຄວາມຫມາຍຫຼາຍຂຶ້ນ. ການທົບທວນຄືນໄວຂຶ້ນ: ໃນຈຸດນີ້, ຂ້ອຍກໍາລັງຄິດທີ່ຈະເພີ່ມ PR ຂອງຂ້ອຍກັບໃຈຂອງຂ້ອຍໃນກໍລະນີທີ່ມັນຍັງຢູ່ໃນການທົບທວນຄືນຫຼັງຈາກທີ່ຂ້ອຍຫມົດໄປ. PRs ທີ່ຍາວກວ່າຕ້ອງການຄໍາຫມັ້ນສັນຍາທີ່ໃຊ້ເວລາທີ່ສໍາຄັນຈາກຜູ້ທົບທວນ, ເຮັດໃຫ້ພວກເຂົາບໍ່ຄ່ອຍຈະໄດ້ຮັບຄວາມສົນໃຈ - ໂດຍສະເພາະຖ້າພວກເຂົາບໍ່ຕິດກັບລັກສະນະທີ່ມີຜົນກະທົບສູງ. ໃນທາງກົງກັນຂ້າມ, PR ຂະຫນາດນ້ອຍໄດ້ຖືກທົບທວນຢ່າງໄວວາ, ຍ້ອນວ່າພວກເຂົາຕ້ອງການເວລາຂອງຜູ້ທົບທວນຫນ້ອຍລົງແລະມີຄວາມລົບກວນຫນ້ອຍ. ຄວາມໄວຂອງການທົບທວນຄືນນີ້ສາມາດເປັນສິ່ງສໍາຄັນສໍາລັບການບັນລຸເສັ້ນຕາຍຂອງໂຄງການ; ຂ້ອຍໄດ້ເຫັນໂຄງການຊັກຊ້າຍ້ອນວ່າຜູ້ທົບທວນອາວຸໂສບໍ່ສາມາດຈັດສັນເວລາສໍາລັບ PRs ຂະຫນາດໃຫຍ່ (ເຖິງແມ່ນວ່ານີ້ສາມາດເກີດຂຶ້ນກັບ PR ຂະຫນາດນ້ອຍ, ຄວາມສ່ຽງແມ່ນສູງກວ່າໂດຍປົກກະຕິກັບຂະຫນາດໃຫຍ່). Rework ຫນ້ອຍ: ການເຮັດ PR ຂະຫນາດໃຫຍ່ຄືນໃຫມ່ຫຼັງຈາກການປ່ຽນແປງການອອກແບບແມ່ນຄ້າຍຄືກັບການຈັດວາງເກົ້າອີ້ຊັ້ນເທິງໃນເຮືອທີ່ເຈົ້າຫາກໍ່ສ້າງ ... ແລະຫຼັງຈາກນັ້ນຈົມລົງ. ພວກເຮົາມີສະຖານະການທີ່ມີປະສົບການທັງຫມົດທີ່ຜູ້ໃດຜູ້ຫນຶ່ງຮັບຮູ້ໃນລະຫວ່າງການທົບທວນ PR ວ່າການອອກແບບທີ່ແຕກຕ່າງກັນຈະໄດ້ຮັບການຮັກສາໄວ້ແລະຫຼັກຖານໃນອະນາຄົດ, ແລະພວກເຮົາຈໍາເປັນຕ້ອງໃຊ້ເວລາເພີ່ມເຕີມໃນການເຮັດວຽກໃຫມ່ຂອງ PR ໂດຍອີງໃສ່ການອອກແບບໃຫມ່ (ບໍ່ໄດ້ເວົ້າວ່າພວກເຂົາຢູ່ໃນເຮືອຫມົດ. ກັບການອອກແບບທີ່ໄດ້ປະຕິບັດໃນເບື້ອງຕົ້ນ :p). ນີ້ແມ່ນທໍາມະຊາດຫຼາຍເພາະວ່າບາງຄັ້ງສິ່ງທີ່ຈະແຈ້ງຂຶ້ນເມື່ອທ່ານເຫັນພວກມັນຂຽນຢູ່ໃນລະຫັດ, ແລະທ່ານເລີ່ມສັງເກດເຫັນລັກສະນະທີ່ທ່ານອາດຈະພາດໃນລະຫວ່າງຂັ້ນຕອນການອອກແບບ. ດ້ວຍ PRs ຂະຫນາດໃຫຍ່, ນີ້ສາມາດເປັນບັນຫາທີ່ສໍາຄັນເພາະວ່າທ່ານຕ້ອງເຮັດວຽກໃຫມ່ຫຼາຍອົງປະກອບ, ແຕ່ດ້ວຍ PRs ຂະຫນາດນ້ອຍ, ມັນງ່າຍຕໍ່ການປ່ຽນແປງ. ສິ່ງທີ່ສໍາຄັນກວ່ານັ້ນ, ມີໂອກາດຫນ້ອຍທີ່ຈະເຮັດວຽກຄືນໃຫມ່ຍ້ອນວ່າຜູ້ທົບທວນມີແນວໂນ້ມທີ່ຈະກໍານົດບັນຫາໃນຕົ້ນປີແລະແກ້ໄຂມັນໃນ PRs ເບື້ອງຕົ້ນ, ອະນຸຍາດໃຫ້ PRs ຕໍ່ມາອີງໃສ່ການອອກແບບໃຫມ່. ການທົດສອບທີ່ດີກວ່າ: PRs ຂະຫນາດນ້ອຍຍັງມີປະໂຫຍດຕໍ່ເຈົ້າເປັນຜູ້ຂຽນຂອງ PR. ພວກເຂົາຊ່ວຍໃນການທົດສອບການປ່ຽນແປງທີ່ນ້ອຍລົງເລື້ອຍໆແທນທີ່ຈະທົດສອບໂຄງການທັງຫມົດໃນຄັ້ງດຽວ. ການທົດສອບການປ່ຽນແປງທີ່ນ້ອຍລົງເຮັດໃຫ້ການທົດສອບຄົບຖ້ວນສົມບູນຂອງແຕ່ລະອົງປະກອບຂອງລະບົບ, ດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ແມງໄມ້ການຜະລິດຫນ້ອຍລົງ. ນີ້ໃຊ້ກັບທັງການທົດສອບອັດຕະໂນມັດແລະການທົດສອບຄູ່ມືທີ່ປະຕິບັດໂດຍທ່ານຫຼືວິສະວະກອນ QA ທີ່ອຸທິດຕົນ. ຍິ່ງໄປກວ່ານັ້ນ, PRs ຂະຫນາດນ້ອຍຫຼຸດລົງຄວາມເປັນໄປໄດ້ຂອງກໍລະນີການທົດສອບທີ່ພາດໂອກາດ, ຍ້ອນວ່າທ່ານສາມາດສຸມໃສ່ຂອບເຂດຈໍາກັດຫຼາຍກວ່າລະບົບທັງຫມົດ. ການທົດສອບການຂຽນ? ມັນເບິ່ງຄືວ່າເປັນບັນຫາຂອງ Future Me. ຂ້ອຍໄດ້ເຫັນນັກພັດທະນາ (ລວມທັງຂ້ອຍໃນອະດີດ) ລັ່ງເລທີ່ຈະຂຽນການທົດສອບອັດຕະໂນມັດເນື່ອງຈາກການລົງທຶນທີ່ໃຊ້ເວລາທີ່ຮັບຮູ້ໂດຍບໍ່ມີມູນຄ່າ "ເບິ່ງເຫັນ" ທັນທີທັນໃດກັບຄຸນສົມບັດ / ຜະລິດຕະພັນ. PRs ຂະຫນາດນ້ອຍຫຼຸດຜ່ອນ friction ນີ້ໂດຍການຈໍາກັດຈໍານວນຂອງການທົດສອບທີ່ຕ້ອງການແລະໃຊ້ເວລາຂຽນໃຫ້ເຂົາເຈົ້າ. ການດີບັກທີ່ງ່າຍກວ່າ: ບໍ່ວ່າການທົດສອບຂອງທ່ານຢ່າງລະອຽດຫຼາຍປານໃດ, ແມງໄມ້ການຜະລິດຈະເກີດຂຶ້ນ! ຄວາມສາມາດໃນການແກ້ໄຂຂໍ້ຜິດພາດໃນການຜະລິດແມ່ນສໍາຄັນເພາະວ່າແມງໄມ້ການຜະລິດມີຜົນກະທົບໂດຍກົງຕໍ່ຜູ້ໃຊ້, ທຸລະກິດ, ຫຼືທັງສອງ. ດ້ວຍ PRs ຂະຫນາດໃຫຍ່, ພື້ນທີ່ຂອງການປ່ຽນແປງຍັງມີຂະຫນາດໃຫຍ່, ເຮັດໃຫ້ມັນໃຊ້ເວລາຫຼາຍແລະຍາກທີ່ຈະຊອກຫາສາເຫດຂອງບັນຫາຕ່າງໆ. ໃນທາງກົງກັນຂ້າມ, PRs ຂະຫນາດນ້ອຍມີລະຫັດຫນ້ອຍແລະດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ debugging ໄວຂຶ້ນ. Debugging ການປ່ຽນແປງຂະຫນາດນ້ອຍແມ່ນຄ້າຍຄືການຊອກຫາ typo; debugging ການປ່ຽນແປງອັນໃຫຍ່ຫຼວງແມ່ນຄ້າຍຄືການພິສູດຫນັງສື encyclopedia. ການນຳໃຊ້ຄຸນສົມບັດເປັນໄລຍະ: ສຸດທ້າຍແຕ່ບໍ່ໄດ້ຢ່າງຫນ້ອຍ, PRs ຂະຫນາດນ້ອຍຍັງເປັນປະໂຫຍດຕໍ່ຜູ້ຈັດການຜະລິດຕະພັນແລະຜູ້ໃຊ້ຂອງທ່ານ. ໂດຍການນໍາໃຊ້ PRs ຂະຫນາດນ້ອຍ, ທ່ານສາມາດສືບຕໍ່ຊຸກຍູ້ພາກສ່ວນຂອງລະບົບໄປສູ່ການຜະລິດ, ເຊິ່ງຊ່ວຍໃນການໄດ້ຮັບຄໍາຕິຊົມຈາກຜູ້ໃຊ້ເບື້ອງຕົ້ນແລະອະນຸຍາດໃຫ້ແກ້ໄຂຫຼັກສູດເບື້ອງຕົ້ນຖ້າຈໍາເປັນ. ການຂ້າມຄໍາຕິຊົມໃນຕອນຕົ້ນແມ່ນຄືກັບການແຕ່ງອາຫານຫ້າຄາບໂດຍບໍ່ໄດ້ລົດຊາດ - ທ່ານພຽງແຕ່ຫວັງວ່າມັນບໍ່ແມ່ນໄພພິບັດ. ຜົນປະໂຫຍດຂອງ PRs ຂະຫນາດນ້ອຍແມ່ນມີຈໍານວນຫລາຍ, ແລະຈຸດທີ່ໄດ້ກ່າວມາຂ້າງເທິງແມ່ນໃນບັນດາຜົນກະທົບທີ່ສຸດທີ່ຂ້ອຍໄດ້ປະສົບກັບສ່ວນບຸກຄົນ. ຖ້າທ່ານໄດ້ພົບກັບຂໍ້ໄດ້ປຽບອື່ນໆຂອງ PRs ຂະຫນາດນ້ອຍຫຼືສິ່ງທ້າທາຍທີ່ມີຂະຫນາດໃຫຍ່ກວ່າທີ່ຂ້ອຍບໍ່ໄດ້ກວມເອົາ, ໃຫ້ຄໍາເຫັນກັບຄວາມເຂົ້າໃຈຂອງເຈົ້າ. ຂ້ອຍຫວັງວ່າບົດຄວາມນີ້ຈະກະຕຸ້ນເຈົ້າໃຫ້ຮັບເອົາ PRs ຂະຫນາດນ້ອຍກວ່າ. ຖ້າເຈົ້າຢູ່ໃນເຮືອແລ້ວ, ຂ້ອຍຫວັງວ່າມັນຈະເສີມສ້າງຄຸນຄ່າຂອງການປະຕິບັດນີ້. ຂອບໃຈສໍາລັບການອ່ານ, ຈົນກ່ວາຄັ້ງຕໍ່ໄປ, ສືບຕໍ່ຂຽນລະຫັດແລະຢາກຮູ້ຢາກເຫັນ!
