ຂຸມ rabbit ໃນ 5 ຄໍາຫມັ້ນສັນຍາ

ຄວາມລຽບງ່າຍທີ່ຫຼູຫຼາຂອງ "ການແກ້ໄຂດ່ວນ"

ຜູ້​ພັດ​ທະ​ນາ​ທຸກ​ຄົນ​ຮູ້​ຈັກ​ເພງ siren ຂອງ "ການ​ປ່ຽນ​ແປງ​ຂະ​ຫນາດ​ນ້ອຍ​"​. ມັນເລີ່ມຕົ້ນຢ່າງບໍ່ມີເຫດຜົນພຽງພໍ: ລາຍງານຂໍ້ຜິດພາດເລັກນ້ອຍ, ການປັບແຕ່ງ UI ນ້ອຍໆ, ຫຼືການຮ້ອງຂໍຄຸນສົມບັດທີ່ເບິ່ງຄືວ່າງ່າຍດາຍ. ທ່ານຄາດຄະເນວ່າມັນຈະໃຊ້ເວລາສອງສາມຊົ່ວໂມງ, ບາງທີການຕົກລົງຄັ້ງດຽວ. ເຈົ້າເຊົາ, ໝັ້ນໃຈວ່າເຈົ້າຈະກັບມາເຮັດວຽກຫຼັກຂອງເຈົ້າກ່ອນອາຫານທ່ຽງ. ແຕ່ຫຼັງຈາກນັ້ນ, ທ່ານພົບວ່າຕົວທ່ານເອງຫ້າຄໍາຫມັ້ນສັນຍາທີ່ເລິກເຊິ່ງ, codebase ຕົ້ນສະບັບຂອງທ່ານເບິ່ງຄືວ່າເປັນຄວາມຊົງຈໍາທີ່ຫ່າງໄກ, ແລະ "ການແກ້ໄຂດ່ວນ" ຂອງທ່ານໄດ້ເຂົ້າໄປໃນໂຄງການ refactoring ເຕັມຮູບແບບ. ເຈົ້າໄດ້ລົ້ມຫົວລົງຂຸມກະຕ່າຍກ່ອນ.

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

ຄຳໝັ້ນສັນຍາ 1: ຈຸດທີ່ບໍ່ໄດ້ກັບຄືນມາ

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

ຄຳໝັ້ນສັນຍາ 2: ແກ້ໄຂຫົວຂໍ້ການເພິ່ງພາອາໄສ

ຄຳໝັ້ນສັນຍາທີສອງຂອງທ່ານອັບເດດຟັງຊັນບັນທຶກ. ແຕ່ລໍຖ້າ - ການທົດສອບສໍາລັບຟັງຊັນບັນທຶກນັ້ນລົ້ມເຫລວ. ມັນ turns ອອກການທົດສອບແມ່ນ hard-coded ເພື່ອຄາດຫວັງວ່າຮູບແບບວັນທີເກົ່າ, ບໍ່ຖືກຕ້ອງ. ທ່ານບໍ່ສາມາດອອກຈາກການທົດສອບທີ່ແຕກຫັກຢູ່ໃນ codebase, ດັ່ງນັ້ນຄໍາຫມັ້ນສັນຍາທີ່ສອງແມ່ນເກີດ: "ອັບເດດຫນ່ວຍການທົດສອບສໍາລັບຕົວບັນທຶກວັນທີ." ໃນປັດຈຸບັນທ່ານບໍ່ພຽງແຕ່ແກ້ໄຂ bug; ທ່ານ​ກໍາ​ລັງ​ປັບ​ປຸງ​ການ​ທົດ​ສອບ​. ນີ້ເປີດເຜີຍຄວາມຈິງທີ່ສໍາຄັນໃນການພັດທະນາຊອບແວ: ລະຫັດແມ່ນເວັບໄຊຕ໌ຂອງການເພິ່ງພາອາໄສ. ການຖູໃສ່ເສັ້ນໜຶ່ງ, ແນວໃດກໍ່ຕາມຂະຫນາດນ້ອຍ, ສາມາດແຍກສ່ວນທີ່ໃຫຍ່ກວ່າຂອງຜ້າໄດ້. ໃນລະບົບທີ່ບໍ່ແມ່ນໂມດູລາ, ນີ້ແມ່ນບ່ອນທີ່ຂອບເຂດເລີ່ມຕົ້ນທີ່ຈະປູມເປົ້າໂດຍບໍ່ສາມາດຄວບຄຸມໄດ້.

Commit 3: ການລໍ້ລວງສະຖາປັດຕະຍະກຳ

ດ້ວຍການຜ່ານການທົດສອບ, ທ່ານຄວນເຮັດ. ແຕ່ຕອນນີ້ເຈົ້າກໍາລັງເບິ່ງລະຫັດ. ຟັງຊັນທີ່ເຈົ້າຫາກໍແກ້ໄຂແມ່ນສ່ວນໜຶ່ງຂອງໂມດູນຜົນປະໂຫຍດທີ່ໃຫຍ່ກວ່າທີ່ຮູ້ສຶກວ່າ… ສັບສົນ. "ເຫດຜົນການຈັດການວັນທີທັງຫມົດນີ້ແມ່ນກະແຈກກະຈາຍຢູ່ໃນສາມໄຟລ໌ທີ່ແຕກຕ່າງກັນ," ທ່ານຄິດວ່າ. "ມັນຈະສະອາດຫຼາຍຖ້າຂ້ອຍລວມມັນເຂົ້າໄປໃນບໍລິການດຽວທີ່ມີຊື່ດີ." ການລໍ້ລວງທີ່ຈະ refactor ສໍາລັບຄວາມບໍລິສຸດສະຖາປັດຕະແມ່ນມີອໍານາດ. ຄໍາຫມັ້ນສັນຍາສາມແມ່ນສໍາຄັນຫນຶ່ງ: "Refactor date utility into a centralized service." ດຽວນີ້ເຈົ້າໄດ້ຍ້າຍອອກໄປໄກກວ່າການແກ້ໄຂຂໍ້ບົກຜ່ອງເດີມແລ້ວ. ທ່ານ​ກຳ​ລັງ​ອອກ​ແບບ​ສ່ວນ​ໜຶ່ງ​ຂອງ​ລະ​ບົບ​ຄືນ​ໃໝ່, ແລະ​ດ້ວຍ​ການ​ອອກ​ແບບ​ນັ້ນ​ຈະ​ມີ​ຄວາມ​ສັບ​ສົນ​ໃໝ່ ແລະ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ຂອງ​ຄວາມ​ຜິດ​ພາດ.

Commit 4 & 5: The Domino Effect

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

• ຂໍ້ບົກພ່ອງເບື້ອງຕົ້ນ: ວັນທີດຽວສະແດງບໍ່ຖືກຕ້ອງ.
• ຜົນສຸດທ້າຍ: ຫ້ອງຮຽນ DateService ໃໝ່, ອັບເດດເປັນ 4 ໂມດູນທີ່ແຕກຕ່າງກັນ, ແລະແກ້ໄຂສຳລັບ 3 ຊຸດທົດສອບທີ່ແຕກຫັກ.
• ເວລາທີ່ໃຊ້: 1.5 ມື້ແທນທີ່ຈະເປັນ 1.5 ຊົ່ວໂມງ.
• ຄ່າໃຊ້ຈ່າຍທີ່ເບິ່ງບໍ່ເຫັນ: ຄຸນສົມບັດທີ່ຊັກຊ້າ, ການປ່ຽນບໍລິບົດສໍາລັບທີມງານທັງໝົດ, ແລະຄວາມສ່ຽງຕໍ່ການເຊື່ອມໂຍງ.

"ຂຸມກະຕ່າຍບໍ່ແມ່ນສັນຍານຂອງຄວາມບໍ່ມີຄວາມສາມາດ; ມັນເປັນອາການຂອງລະບົບທີ່ຂອບເຂດທີ່ບໍ່ຊັດເຈນ. ປະສິດທິພາບທີ່ແທ້ຈິງແມ່ນມາຈາກ modularity, ບ່ອນທີ່ການປ່ຽນແປງໃນຫນ້າທີ່ທຸລະກິດຫນຶ່ງບໍ່ໄດ້ບັງຄັບໃຫ້ມີການກໍ່ສ້າງໃຫມ່."

ການກໍ່ສ້າງ Guardrails ດ້ວຍ Mewayz

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

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

ຄຳຖາມທີ່ຖາມເລື້ອຍໆ

ຄວາມລຽບງ່າຍທີ່ຫຼູຫຼາຂອງ "ການແກ້ໄຂດ່ວນ"

ຜູ້​ພັດ​ທະ​ນາ​ທຸກ​ຄົນ​ຮູ້​ຈັກ​ເພງ siren ຂອງ "ການ​ປ່ຽນ​ແປງ​ຂະ​ຫນາດ​ນ້ອຍ​"​. ມັນເລີ່ມຕົ້ນຢ່າງບໍ່ມີເຫດຜົນພຽງພໍ: ລາຍງານຂໍ້ຜິດພາດເລັກນ້ອຍ, ການປັບແຕ່ງ UI ນ້ອຍໆ, ຫຼືການຮ້ອງຂໍຄຸນສົມບັດທີ່ເບິ່ງຄືວ່າງ່າຍດາຍ. ທ່ານຄາດຄະເນວ່າມັນຈະໃຊ້ເວລາສອງສາມຊົ່ວໂມງ, ບາງທີການຕົກລົງຄັ້ງດຽວ. ເຈົ້າເຊົາ, ໝັ້ນໃຈວ່າເຈົ້າຈະກັບມາເຮັດວຽກຫຼັກຂອງເຈົ້າກ່ອນອາຫານທ່ຽງ. ແຕ່ຫຼັງຈາກນັ້ນ, ທ່ານພົບວ່າຕົວທ່ານເອງຫ້າຄໍາຫມັ້ນສັນຍາທີ່ເລິກເຊິ່ງ, codebase ຕົ້ນສະບັບຂອງທ່ານເບິ່ງຄືວ່າເປັນຄວາມຊົງຈໍາທີ່ຫ່າງໄກ, ແລະ "ການແກ້ໄຂດ່ວນ" ຂອງທ່ານໄດ້ເຂົ້າໄປໃນໂຄງການ refactoring ເຕັມຮູບແບບ. ເຈົ້າໄດ້ລົ້ມຫົວລົງຂຸມກະຕ່າຍກ່ອນ.

ຄຳໝັ້ນສັນຍາ 1: ຈຸດທີ່ບໍ່ໄດ້ກັບຄືນມາ

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

ຄຳໝັ້ນສັນຍາ 2: ແກ້ໄຂຫົວຂໍ້ການເພິ່ງພາອາໄສ

ຄຳໝັ້ນສັນຍາທີສອງຂອງທ່ານອັບເດດຟັງຊັນບັນທຶກ. ແຕ່ລໍຖ້າ - ການທົດສອບສໍາລັບຟັງຊັນບັນທຶກນັ້ນລົ້ມເຫລວ. ມັນ turns ອອກການທົດສອບແມ່ນ hard-coded ເພື່ອຄາດຫວັງວ່າຮູບແບບວັນທີເກົ່າ, ບໍ່ຖືກຕ້ອງ. ທ່ານບໍ່ສາມາດອອກຈາກການທົດສອບທີ່ແຕກຫັກຢູ່ໃນ codebase, ດັ່ງນັ້ນຄໍາຫມັ້ນສັນຍາທີ່ສອງແມ່ນເກີດ: "ອັບເດດຫນ່ວຍການທົດສອບສໍາລັບຕົວບັນທຶກວັນທີ." ໃນປັດຈຸບັນທ່ານບໍ່ພຽງແຕ່ແກ້ໄຂ bug; ທ່ານ​ກໍາ​ລັງ​ປັບ​ປຸງ​ການ​ທົດ​ສອບ​. ນີ້ເປີດເຜີຍຄວາມຈິງທີ່ສໍາຄັນໃນການພັດທະນາຊອບແວ: ລະຫັດແມ່ນເວັບໄຊຕ໌ຂອງການເພິ່ງພາອາໄສ. ການຖູໃສ່ເສັ້ນໜຶ່ງ, ແນວໃດກໍ່ຕາມຂະຫນາດນ້ອຍ, ສາມາດແຍກສ່ວນທີ່ໃຫຍ່ກວ່າຂອງຜ້າໄດ້. ໃນລະບົບທີ່ບໍ່ແມ່ນໂມດູລາ, ນີ້ແມ່ນບ່ອນທີ່ຂອບເຂດເລີ່ມຕົ້ນທີ່ຈະປູມເປົ້າໂດຍບໍ່ສາມາດຄວບຄຸມໄດ້.

Commit 3: ການລໍ້ລວງສະຖາປັດຕະຍະກຳ

ດ້ວຍການຜ່ານການທົດສອບ, ທ່ານຄວນເຮັດ. ແຕ່ຕອນນີ້ເຈົ້າກໍາລັງເບິ່ງລະຫັດ. ຟັງຊັນທີ່ເຈົ້າຫາກໍແກ້ໄຂແມ່ນສ່ວນໜຶ່ງຂອງໂມດູນຜົນປະໂຫຍດທີ່ໃຫຍ່ກວ່າທີ່ຮູ້ສຶກວ່າ… ສັບສົນ. "ເຫດຜົນການຈັດການວັນທີທັງຫມົດນີ້ແມ່ນກະແຈກກະຈາຍຢູ່ໃນສາມໄຟລ໌ທີ່ແຕກຕ່າງກັນ," ທ່ານຄິດວ່າ. "ມັນຈະສະອາດຫຼາຍຖ້າຂ້ອຍລວມມັນເຂົ້າໄປໃນບໍລິການດຽວທີ່ມີຊື່ດີ." ການລໍ້ລວງທີ່ຈະ refactor ສໍາລັບຄວາມບໍລິສຸດສະຖາປັດຕະແມ່ນມີອໍານາດ. ຄໍາຫມັ້ນສັນຍາສາມແມ່ນສໍາຄັນຫນຶ່ງ: "Refactor date utility into a centralized service." ດຽວນີ້ເຈົ້າໄດ້ຍ້າຍອອກໄປໄກກວ່າການແກ້ໄຂຂໍ້ບົກຜ່ອງເດີມແລ້ວ. ທ່ານ​ກຳ​ລັງ​ອອກ​ແບບ​ສ່ວນ​ໜຶ່ງ​ຂອງ​ລະ​ບົບ​ຄືນ​ໃໝ່, ແລະ​ດ້ວຍ​ການ​ອອກ​ແບບ​ນັ້ນ​ຈະ​ມີ​ຄວາມ​ສັບ​ສົນ​ໃໝ່ ແລະ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ຂອງ​ຄວາມ​ຜິດ​ພາດ.

Commit 4 & 5: The Domino Effect

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