ຢ່າປ່ອຍໃຫ້ລະຫັດທົດສອບເຂົ້າໄປໃນການຜະລິດ

TL;DR: ຫຼີກເວັ້ນການເພີ່ມ isTesting ຫຼືທຸງທີ່ຄ້າຍຄືກັນ.

ບັນຫາ 😔

• ຮົ່ວໄຫຼ abstraction
• ມົນລະພິດລະຫັດທີ່ບໍ່ແມ່ນທຸລະກິດ
• ລະຫັດທີ່ອ່ອນແອ
• ພຶດຕິກໍາທີ່ບໍ່ສອດຄ່ອງ
• ການເພິ່ງພາອາໄສທີ່ເຊື່ອງໄວ້
• ການດີບັກຍາກ
• ທຸງ Boolean
• ການທົດສອບທີ່ບໍ່ຫນ້າເຊື່ອຖື
• ລະຫັດການຜະລິດຂຶ້ນກັບ

ວິທີແກ້ 😃

1. ເອົາ ພຶດຕິກໍາ Ifs
2. ໃຊ້ສີດທີ່ເພິ່ງພາອາໄສ
3. ສ້າງແບບຈໍາລອງການບໍລິການພາຍນອກ (ຢ່າ ເຍາະເຍີ້ຍ ພວກມັນ)
4. ການຕັ້ງຄ່າແຍກຕ່າງຫາກ
5. ແຍກເຫດຜົນການທົດສອບ
6. ຮັກສາຂອບເຂດການປະພຶດທີ່ສະອາດ

ເຄື່ອງສ້ອມແປງ ⚙️

ບໍລິບົດ 💬

ເມື່ອທ່ານເພີ່ມທຸງເຊັ່ນ isTesting , ທ່ານປະສົມການທົດສອບແລະລະຫັດການຜະລິດ.

ນີ້ສ້າງເສັ້ນທາງທີ່ເຊື່ອງໄວ້ທີ່ມີການເຄື່ອນໄຫວພຽງແຕ່ໃນການທົດສອບ.

ນອກຈາກນັ້ນ, ທ່ານບໍ່ໄດ້ກວມເອົາລະຫັດການຜະລິດທີ່ແທ້ຈິງ.

ທ່ານມີຄວາມສ່ຽງຕໍ່ການປະຕິບັດການທົດສອບການຂົນສົ່ງໄປສູ່ການຜະລິດ, ນໍາໄປສູ່ແມງໄມ້ແລະພຶດຕິກໍາທີ່ບໍ່ສາມາດຄາດເດົາໄດ້.

ລະຫັດຕົວຢ່າງ 📖

ຜິດ ❌

 struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } }

👉ຖືກຕ້ອງ

 trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } }

ກວດພົບ 🔍

• [x] ເຄິ່ງອັດຕະໂນມັດ

ທ່ານສາມາດກວດພົບກິ່ນນີ້ໄດ້ໂດຍການຊອກຫາທຸງທີ່ມີເງື່ອນໄຂເຊັ່ນ: isTesting , ສະພາບແວດລ້ອມ == 'ທົດສອບ' , DEBUG_MODE , ແລະສໍານວນເຊັ່ນນີ້.

ເຫຼົ່ານີ້ຊີ້ໃຫ້ເຫັນວ່າພຶດຕິກໍາການທົດສອບແມ່ນຮົ່ວໄຫລເຂົ້າໄປໃນລະຫັດການຜະລິດ.

Tags 🏷️

• ການທົດສອບ

ລະດັບ 🔋

• [x] ລະດັບປານກາງ

ເປັນຫຍັງການປະທະກັນຈຶ່ງສຳຄັນ🗺️

ທ່ານຕ້ອງການການແຍກຢ່າງຊັດເຈນລະຫວ່າງການທົດສອບແລະລະຫັດການຜະລິດ.

ເມື່ອທ່ານປະສົມພວກມັນ, ທ່ານຈະທໍາລາຍ Bijection ແບບຫນຶ່ງຕໍ່ຫນຶ່ງລະຫວ່າງພຶດຕິກໍາຕົວຈິງແລະໂຄງການ.

ເນື່ອງຈາກສະພາບແວດລ້ອມເປັນຫນ່ວຍງານໃນໂລກທີ່ແທ້ຈິງ, ທ່ານຈໍາເປັນຕ້ອງສ້າງແບບຈໍາລອງໃຫ້ເຂົາເຈົ້າຢ່າງຊັດເຈນໃນ MAPPER .

ລຸ້ນ AI 🤖

ລະຫັດທີ່ສ້າງໂດຍ AI ມັກຈະແນະນໍາກິ່ນນີ້ໃນເວລາທີ່ທ່ານໃຊ້ hacks ໄວສໍາລັບການທົດສອບ.

ບາງເຄື່ອງມືແນະນໍາທຸງເຊັ່ນ isTesting ເພາະວ່າພວກເຂົາຈັດລໍາດັບຄວາມງ່າຍໃນການອອກແບບທີ່ເຫມາະສົມ.

ການກວດຫາ AI 🥃

ເຄື່ອງມື AI ສາມາດຈັບກິ່ນນີ້ໄດ້ຖ້າທ່ານຕັ້ງຄ່າພວກມັນເພື່ອທຸງເຫດຜົນຕາມເງື່ອນໄຂໂດຍອີງໃສ່ສະຖານະການທົດສອບ.

ລອງໃຊ້ພວກມັນ! 🛠

ຈືຂໍ້ມູນການ: ຜູ້ຊ່ວຍ AI ເຮັດຜິດພາດຫຼາຍ

ການເຕືອນທີ່ແນະນໍາ: ເອົາວິທີການ IsTesting ອອກແລະທົດແທນມັນໂດຍການສ້າງແບບຈໍາລອງສະພາບແວດລ້ອມ

ສະຫຼຸບ 🏁

ຫຼີກເວັ້ນການໃຊ້ທຸງ isTesting .

ໃຊ້ສີດການເພິ່ງພາອາໄສ ແລະສ້າງແບບຈໍາລອງສະພາບແວດລ້ອມເພື່ອຮັກສາເຫດຜົນການທົດສອບ ແລະການຜະລິດແຍກຕ່າງຫາກ.

ຄວາມສໍາພັນ 👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om

ຄຳປະຕິເສດ 📘

ກິ່ນລະຫັດແມ່ນ ຄວາມຄິດເຫັນ ຂອງຂ້ອຍ.

ສິນເຊື່ອ 🙏

ຮູບພາບໂດຍ Christian Gertenbach ໃນ Unsplash

ເມື່ອທ່ານເພີ່ມທຸງການທົດສອບ, ທ່ານທໍາລາຍຄວາມຫມັ້ນໃຈໃນການຜະລິດ.

Ward Cunningham

ບົດຄວາມນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງ CodeSmell Series.