ປະຕິບັດການວິເຄາະສະຖິດເຂົ້າໄປໃນຂະບວນການ, ແທນທີ່ຈະໃຊ້ມັນເພື່ອຊອກຫາແມງໄມ້

ຂ້າພະເຈົ້າໄດ້ຮັບການກະຕຸ້ນໃຫ້ຂຽນບົດຄວາມນີ້ໂດຍວັດສະດຸຈໍານວນຫລາຍກ່ຽວກັບການວິເຄາະ static ທີ່ກໍາລັງເຂົ້າມາໃນຄວາມສົນໃຈຂອງຂ້ອຍ. ປະການທໍາອິດ, ນີ້ ບລັອກ PVS-studio, ເຊິ່ງສົ່ງເສີມຕົນເອງຢ່າງຈິງຈັງໃນHabre ດ້ວຍການຊ່ວຍເຫຼືອຂອງການທົບທວນຄືນຄວາມຜິດພາດທີ່ພົບເຫັນໂດຍເຄື່ອງມືຂອງພວກເຂົາໃນໂຄງການແຫຼ່ງເປີດ. ບໍ່ດົນມານີ້ PVS-studio ໄດ້ປະຕິບັດ ສະຫນັບສະຫນູນ Java, ແລະ, ແນ່ນອນ, ຜູ້ພັດທະນາ IntelliJ IDEA, ເຊິ່ງຕົວວິເຄາະຂອງຕົວມັນເອງອາດຈະເປັນແບບພິເສດທີ່ສຸດສໍາລັບ Java ໃນມື້ນີ້, ບໍ່ສາມາດຢູ່ຫ່າງໆ.

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

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

Ratchet (ແຫຼ່ງ: wikipedia).

ສິ່ງທີ່ນັກວິເຄາະສະຖິດບໍ່ເຄີຍສາມາດເຮັດໄດ້

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

ຕົວຢ່າງທີ່ມີຊື່ສຽງທີ່ສຸດຂອງບັນຫາທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ໂດຍໃຊ້ການວິເຄາະສະຖິດແມ່ນ ບັນຫາການປິດ: ນີ້ແມ່ນທິດສະດີບົດທີ່ພິສູດວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະພັດທະນາ algorithm ທົ່ວໄປທີ່ສາມາດກໍານົດຈາກ source code ຂອງໂຄງການວ່າມັນຈະ loop ຫຼືຢຸດໃນເວລາທີ່ກໍານົດ. ສ່ວນຂະຫຍາຍຂອງທິດສະດີບົດນີ້ແມ່ນ ທິດສະດີບົດຂອງເຂົ້າ, ເຊິ່ງລະບຸວ່າສໍາລັບຄຸນສົມບັດທີ່ບໍ່ແມ່ນເລື່ອງເລັກໆນ້ອຍໆຂອງຟັງຊັນທີ່ສາມາດຄິດໄລ່ໄດ້, ການກໍານົດວ່າໂຄງການ arbitrary ປະເມີນການທໍາງານທີ່ມີຄຸນສົມບັດດັ່ງກ່າວເປັນບັນຫາ intractable algorithmically. ຕົວຢ່າງ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຂຽນຕົວວິເຄາະທີ່ສາມາດກໍານົດຈາກລະຫັດແຫຼ່ງໃດກໍ່ຕາມວ່າໂຄງການທີ່ຖືກວິເຄາະແມ່ນການປະຕິບັດຂອງສູດການຄິດໄລ່, ເວົ້າ, squaring ຂອງຈໍານວນເຕັມ.

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

ການວິເຄາະຄົງທີ່ບໍ່ແມ່ນກ່ຽວກັບການຊອກຫາແມງໄມ້

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

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

ນີ້ຫມາຍຄວາມວ່າການວິເຄາະ static ບໍ່ຄວນຖືກນໍາໃຊ້? ແນ່ນອນບໍ່! ແລະດ້ວຍເຫດຜົນດຽວກັນແທ້ໆທີ່ມັນເປັນມູນຄ່າການກວດສອບແຕ່ລະລະຫັດຜ່ານໃຫມ່ເພື່ອໃຫ້ແນ່ໃຈວ່າມັນຖືກລວມຢູ່ໃນບັນຊີລາຍຊື່ຢຸດຂອງລະຫັດຜ່ານ "ງ່າຍດາຍ".

ການວິເຄາະຄົງທີ່ແມ່ນຫຼາຍກ່ວາການຊອກຫາແມງໄມ້

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

• ການກວດສອບຮູບແບບການເຂົ້າລະຫັດໃນຄວາມຫມາຍກວ້າງທີ່ສຸດຂອງຄໍາ. ນີ້ປະກອບມີທັງການກວດສອບການຈັດຮູບແບບ, ຊອກຫາການນໍາໃຊ້ວົງເລັບເປົ່າ / ພິເສດ, ກໍານົດຂອບເຂດກ່ຽວກັບການວັດແທກເຊັ່ນ: ຈໍານວນເສັ້ນ / ຄວາມສັບສົນຂອງວົງຈອນຂອງວິທີການ, ແລະອື່ນໆ - ສິ່ງໃດແດ່ທີ່ອາດຈະຂັດຂວາງການອ່ານແລະການຮັກສາລະຫັດ. ໃນ Java, ເຄື່ອງມືດັ່ງກ່າວແມ່ນ Checkstyle, ໃນ Python - flake8. ໂຄງການຂອງຫ້ອງຮຽນນີ້ມັກຈະເອີ້ນວ່າ "linters".
• ບໍ່ພຽງແຕ່ລະຫັດປະຕິບັດສາມາດວິເຄາະໄດ້. ໄຟລ໌ຊັບພະຍາກອນເຊັ່ນ JSON, YAML, XML, .properties ສາມາດ (ແລະຄວນ!) ຖືກກວດສອບຄວາມຖືກຕ້ອງໂດຍອັດຕະໂນມັດ. ຫຼັງຈາກທີ່ທັງຫມົດ, ມັນດີກວ່າທີ່ຈະຄົ້ນພົບວ່າໂຄງສ້າງ JSON ຖືກທໍາລາຍເນື່ອງຈາກຄໍາເວົ້າທີ່ບໍ່ໄດ້ຈັບຄູ່ຢູ່ໃນຂັ້ນຕອນຕົ້ນຂອງການກວດສອບການຮ້ອງຂໍການດຶງອັດຕະໂນມັດຫຼາຍກວ່າໃນລະຫວ່າງການປະຕິບັດການທົດສອບຫຼືເວລາແລ່ນ? ເຄື່ອງມືທີ່ເຫມາະສົມແມ່ນມີຢູ່: e.g. YAMLlint, JSONLint.
• ການລວບລວມ (ຫຼືການແຍກວິເຄາະສໍາລັບພາສາການຂຽນໂປລແກລມແບບເຄື່ອນໄຫວ) ຍັງເປັນປະເພດຂອງການວິເຄາະສະຖິດ. ໂດຍທົ່ວໄປແລ້ວ, compilers ມີຄວາມສາມາດຜະລິດຄໍາເຕືອນທີ່ຊີ້ໃຫ້ເຫັນເຖິງບັນຫາທີ່ມີຄຸນນະພາບຂອງລະຫັດແຫຼ່ງແລະບໍ່ຄວນຖືກລະເລີຍ.
• ບາງຄັ້ງການລວບລວມແມ່ນຫຼາຍກ່ວາພຽງແຕ່ການລວບລວມລະຫັດປະຕິບັດ. ຕົວຢ່າງ, ຖ້າທ່ານມີເອກະສານໃນຮູບແບບ ທ່ານໝໍ Ascii, ຫຼັງຈາກນັ້ນໃນປັດຈຸບັນຂອງການປ່ຽນເປັນ HTML / PDF ຜູ້ຈັດການ AsciiDoctor (ປັpluginກອິນ Maven) ສາມາດອອກຄໍາເຕືອນ, ຕົວຢ່າງ, ກ່ຽວກັບການເຊື່ອມຕໍ່ພາຍໃນທີ່ແຕກຫັກ. ແລະນີ້ແມ່ນເຫດຜົນທີ່ດີທີ່ຈະບໍ່ຍອມຮັບການຮ້ອງຂໍດຶງກັບການປ່ຽນແປງເອກະສານ.
• ການກວດສອບການສະກົດຄໍາຍັງເປັນປະເພດຂອງການວິເຄາະສະຖິດ. ປະໂຫຍດ ການສະກົດຄໍາ ສາມາດກວດສອບການສະກົດຄໍາບໍ່ພຽງແຕ່ຢູ່ໃນເອກະສານ, ແຕ່ຍັງຢູ່ໃນລະຫັດແຫຼ່ງຂອງໂປລແກລມ (ຄໍາເຫັນແລະຕົວຫນັງສື) ໃນພາສາການຂຽນໂປຼແກຼມຕ່າງໆ, ລວມທັງ C / C ++, Java ແລະ Python. ຄວາມຜິດພາດການສະກົດຄໍາຢູ່ໃນສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ຫຼືເອກະສານຍັງເປັນຂໍ້ບົກພ່ອງ!
• ການທົດສອບການຕັ້ງຄ່າ (ກ່ຽວກັບສິ່ງທີ່ພວກເຂົາເປັນ - ເບິ່ງ. ນີ້ и ນີ້ ບົດລາຍງານ), ເຖິງແມ່ນວ່າການປະຕິບັດໃນການທົດສອບຫນ່ວຍງານ runtime ເຊັ່ນ pytest, ໃນຄວາມເປັນຈິງຍັງເປັນປະເພດຂອງການວິເຄາະ static, ເນື່ອງຈາກວ່າພວກເຂົາເຈົ້າບໍ່ໄດ້ປະຕິບັດລະຫັດແຫຼ່ງໃນລະຫວ່າງການປະຕິບັດຂອງເຂົາເຈົ້າ.

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

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

ທໍ່ສົ່ງເປັນການກັ່ນຕອງຫຼາຍຂັ້ນຕອນແລະການວິເຄາະ static ເປັນຂັ້ນຕອນທໍາອິດຂອງຕົນ

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

1. ການວິເຄາະສະຖິດ
2. ການລວບລວມ
3. ການ​ທົດ​ສອບ​ຫົວ​ຫນ່ວຍ​
4. ການ​ທົດ​ສອບ​ການ​ເຊື່ອມ​ໂຍງ​
5. ການທົດສອບ UI
6. ກວດ​ສອບ​ຄູ່​ມື​

ການ​ປ່ຽນ​ແປງ​ທີ່​ຖືກ​ປະ​ຕິ​ເສດ​ໃນ​ຂັ້ນ​ຕອນ Nth ຂອງ​ທໍ່​ບໍ່​ໄດ້​ຖືກ​ຍົກ​ຍ້າຍ​ໄປ​ຂັ້ນ N+1.

ເປັນ​ຫຍັງ​ແນ່​ນອນ​ວິ​ທີ​ການ​ນີ້​ແລະ​ບໍ່​ດັ່ງ​ນັ້ນ​? ໃນສ່ວນການທົດສອບຂອງທໍ່, ຜູ້ທົດສອບຈະຮັບຮູ້ pyramid ການທົດສອບທີ່ມີຊື່ສຽງ.

ທົດສອບ pyramid. ທີ່ມາ: ບົດຄວາມ Martin Fowler.

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

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

ການກັ່ນຕອງຫຼາຍຂັ້ນຕອນ. ທີ່ມາ: ວິກິພີເດຍ

ດັ່ງທີ່ທ່ານຮູ້, ການກັ່ນຕອງການທໍາຄວາມສະອາດໄດ້ຖືກອອກແບບເພື່ອໃຫ້ແຕ່ລະ cascade ຕໍ່ມາສາມາດກັ່ນຕອງອອກສ່ວນຫນຶ່ງຂອງການປົນເປື້ອນເພີ່ມເຕີມ. ໃນເວລາດຽວກັນ, cascades ຂອງ purification coarser ມີ throughput ສູງແລະຄ່າໃຊ້ຈ່າຍຕ່ໍາ. ໃນການປຽບທຽບຂອງພວກເຮົາ, ນີ້ຫມາຍຄວາມວ່າປະຕູທີ່ມີຄຸນນະພາບການປ້ອນຂໍ້ມູນແມ່ນໄວຂຶ້ນ, ຕ້ອງການຄວາມພະຍາຍາມຫນ້ອຍທີ່ຈະເລີ່ມຕົ້ນ, ແລະຕົວມັນເອງແມ່ນ unpretentious ຫຼາຍໃນການດໍາເນີນງານ - ແລະນີ້ແມ່ນລໍາດັບທີ່ພວກມັນຖືກສ້າງຂຶ້ນ. ບົດບາດຂອງການວິເຄາະສະຖິດ, ເຊິ່ງ, ດັ່ງທີ່ພວກເຮົາເຂົ້າໃຈໃນປັດຈຸບັນ, ມີຄວາມສາມາດທີ່ຈະກໍາຈັດພຽງແຕ່ຂໍ້ບົກພ່ອງທີ່ຮ້າຍແຮງທີ່ສຸດ, ແມ່ນບົດບາດຂອງຕາຂ່າຍໄຟຟ້າ "ຂີ້ຕົມ" ໃນຕອນຕົ້ນຂອງທໍ່ການກັ່ນຕອງ.

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

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

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

ການຈັດຕັ້ງປະຕິບັດເຂົ້າໃນໂຄງການມໍລະດົກ

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

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

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

ວິທີການແນະນໍາປະຕູທີ່ມີຄຸນນະພາບຕໍ່ໄປນີ້ແມ່ນເປັນທີ່ຮູ້ຈັກ:

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

Ratchet

ມັນເຮັດວຽກແບບນີ້:

1. ໃນຂັ້ນຕອນເບື້ອງຕົ້ນ, ການບັນທຶກແມ່ນເຮັດຢູ່ໃນ metadata ກ່ຽວກັບການປ່ອຍຕົວຂອງຈໍານວນຄໍາເຕືອນໃນລະຫັດທີ່ພົບໂດຍນັກວິເຄາະ. ດັ່ງນັ້ນ, ເມື່ອທ່ານສ້າງທາງເທິງ, ຜູ້ຈັດການຄັງເກັບຂອງເຈົ້າຂຽນບໍ່ພຽງແຕ່ "ປ່ອຍ 7.0.2", ແຕ່ "ປ່ອຍ 7.0.2 ທີ່ມີຄໍາເຕືອນ 100500 checkstyle." ຖ້າທ່ານໃຊ້ຕົວຈັດການບ່ອນເກັບມ້ຽນຂັ້ນສູງ (ເຊັ່ນ Artifactory), ການເກັບຮັກສາ metadata ດັ່ງກ່າວກ່ຽວກັບການປ່ອຍຂອງທ່ານແມ່ນງ່າຍ.
2. ໃນປັດຈຸບັນແຕ່ລະຄໍາຮ້ອງຂໍການດຶງ, ເມື່ອສ້າງ, ປຽບທຽບຈໍານວນຂອງການເຕືອນໄພຜົນໄດ້ຮັບກັບຈໍານວນຂອງຄໍາເຕືອນທີ່ມີຢູ່ໃນການປ່ອຍປະຈຸບັນ. ຖ້າ PR ນໍາໄປສູ່ການເພີ່ມຂຶ້ນຂອງຈໍານວນນີ້, ຫຼັງຈາກນັ້ນລະຫັດບໍ່ໄດ້ຜ່ານປະຕູທີ່ມີຄຸນນະພາບສໍາລັບການວິເຄາະ static. ຖ້າຈໍານວນຂອງການເຕືອນໄພຫຼຸດລົງຫຼືບໍ່ປ່ຽນແປງ, ຫຼັງຈາກນັ້ນມັນຜ່ານໄປ.
3. ໃນການປ່ອຍຕໍ່ໄປ, ຈໍານວນຄໍາເຕືອນທີ່ຖືກຄິດໄລ່ຄືນໃຫມ່ຈະຖືກບັນທຶກອີກເທື່ອຫນຶ່ງໃນ metadata ການປ່ອຍ.

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

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

ຂ້ອຍໃຊ້ສະບັບດັດແກ້ຂອງວິທີການນີ້, ການນັບຄໍາເຕືອນແຍກຕ່າງຫາກໂດຍໂມດູນໂຄງການແລະເຄື່ອງມືການວິເຄາະ, ສົ່ງຜົນໃຫ້ໄຟລ໌ YAML ທີ່ມີ metadata ກໍ່ສ້າງທີ່ມີລັກສະນະຄ້າຍຄືນີ້:

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

ໃນລະບົບ CI ຂັ້ນສູງໃດໆ, ratchet ສາມາດຖືກປະຕິບັດສໍາລັບເຄື່ອງມືການວິເຄາະແບບຄົງທີ່ໂດຍບໍ່ຕ້ອງອີງໃສ່ plugins ແລະເຄື່ອງມືພາກສ່ວນທີສາມ. ນັກວິເຄາະແຕ່ລະຄົນຜະລິດບົດລາຍງານຂອງຕົນເອງໃນຮູບແບບຂໍ້ຄວາມຫຼື XML ທີ່ງ່າຍຕໍ່ການວິເຄາະ. ສິ່ງທີ່ຍັງເຫຼືອແມ່ນການຂຽນເຫດຜົນທີ່ຈໍາເປັນໃນສະຄິບ CI. ທ່ານສາມາດເບິ່ງວິທີການນີ້ຖືກປະຕິບັດໃນໂຄງການແຫຼ່ງເປີດຂອງພວກເຮົາໂດຍອີງໃສ່ Jenkins ແລະ Artifactory ທີ່ນີ້ ຫຼື ທີ່ນີ້. ຕົວຢ່າງທັງສອງແມ່ນຂຶ້ນກັບຫ້ອງສະຫມຸດ ratchetlib: ວິທີການ countWarnings() ນັບແທັກ xml ໃນໄຟລ໌ທີ່ສ້າງຂຶ້ນໂດຍ Checkstyle ແລະ Spotbugs ໃນແບບປົກກະຕິ, ແລະ compareWarningMaps() ປະຕິບັດ ratchet ດຽວກັນ, ຖິ້ມຄວາມຜິດພາດໃນເວລາທີ່ຈໍານວນຂອງການເຕືອນໄພໃນປະເພດໃດຫນຶ່ງເພີ່ມຂຶ້ນ.

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

ກ່ຽວກັບຄວາມສໍາຄັນຂອງການແກ້ໄຂສະບັບການວິເຄາະ

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

ການຄົ້ນພົບ

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

ເອກະສານ

1. ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ
2. A. Kudryavtsev: ການວິເຄາະໂຄງການ: ວິທີການເຂົ້າໃຈວ່າທ່ານເປັນນັກຂຽນໂປລແກລມທີ່ດີ ລາຍງານວິທີການທີ່ແຕກຕ່າງກັນຂອງການວິເຄາະລະຫັດ (ບໍ່ພຽງແຕ່ static!)

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