paint-brush
ພະລັງອັນໃຫຍ່ຫຼວງຂອງການຮ້ອງຂໍດຶງຂະຫນາດນ້ອຍ: ເຮັດແນວໃດພວກເຂົາປັບປຸງການທົບທວນຄືນແລະເລັ່ງການພັດທະນາໂດຍ@garvitgupta
320 ການອ່ານ
320 ການອ່ານ

ພະລັງອັນໃຫຍ່ຫຼວງຂອງການຮ້ອງຂໍດຶງຂະຫນາດນ້ອຍ: ເຮັດແນວໃດພວກເຂົາປັບປຸງການທົບທວນຄືນແລະເລັ່ງການພັດທະນາ

ໂດຍ Garvit Gupta5m2024/11/09
Read on Terminal Reader

ຍາວເກີນໄປ; ອ່ານ

ຜົນປະໂຫຍດຂອງ PRs ຂະຫນາດນ້ອຍແມ່ນມີຈໍານວນຫລາຍ, ແລະຈຸດທີ່ໄດ້ກ່າວມາຂ້າງເທິງແມ່ນໃນບັນດາຜົນກະທົບທີ່ສຸດທີ່ຂ້ອຍໄດ້ປະສົບກັບສ່ວນບຸກຄົນ. ຖ້າທ່ານໄດ້ພົບກັບຂໍ້ໄດ້ປຽບອື່ນໆຂອງ PRs ຂະຫນາດນ້ອຍຫຼືສິ່ງທ້າທາຍທີ່ມີຂະຫນາດໃຫຍ່ທີ່ຂ້ອຍບໍ່ໄດ້ກວມເອົາ, ໃຫ້ຄໍາເຫັນກັບຄວາມເຂົ້າໃຈຂອງເຈົ້າ.
featured image - ພະລັງອັນໃຫຍ່ຫຼວງຂອງການຮ້ອງຂໍດຶງຂະຫນາດນ້ອຍ: ເຮັດແນວໃດພວກເຂົາປັບປຸງການທົບທວນຄືນແລະເລັ່ງການພັດທະນາ
Garvit Gupta HackerNoon profile picture

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


ຂອບໃຈສໍາລັບການອ່ານ, ຈົນກ່ວາຄັ້ງຕໍ່ໄປ, ສືບຕໍ່ຂຽນລະຫັດແລະຢາກຮູ້ຢາກເຫັນ!