ວິທີການປະຕິບັດຕົວວິເຄາະລະຫັດຄົງທີ່ໃນໂຄງການມໍລະດົກໂດຍບໍ່ມີການ demotivating ທີມງານ

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

ການນໍາສະເຫນີ

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

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

ບັນຫາ

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

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

ບວກທີ່ບໍ່ຖືກຕ້ອງບໍ່ແມ່ນບັນຫາຖ້າຕົວວິເຄາະສະຖິດຖືກຕັ້ງຄ່າແລ້ວ:

• ຄົນພິການຊຸດກົດລະບຽບທີ່ບໍ່ກ່ຽວຂ້ອງ;
• ການວິນິດໄສທີ່ບໍ່ກ່ຽວຂ້ອງບາງຢ່າງຖືກປິດການໃຊ້ງານ;
• ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບ C ຫຼື C ++, macros ແມ່ນຫມາຍເຖິງທີ່ປະກອບດ້ວຍໂຄງສ້າງສະເພາະທີ່ເຮັດໃຫ້ເກີດການເຕືອນໄພທີ່ບໍ່ມີປະໂຫຍດທີ່ຈະປາກົດຢູ່ໃນທຸກບ່ອນທີ່ macros ດັ່ງກ່າວຖືກນໍາໃຊ້;
• ຟັງຊັນຂອງຕົນເອງຖືກຫມາຍວ່າປະຕິບັດຫນ້າທີ່ຄ້າຍຄືກັບຟັງຊັນຂອງລະບົບ (ການປຽບທຽບຂອງຕົນເອງ memcpy ຫຼື printf) [4];
• ບວກທີ່ບໍ່ຖືກຕ້ອງແມ່ນຖືກປິດການໃຊ້ງານໂດຍສະເພາະໂດຍໃຊ້ຄໍາເຫັນ;
• ແລະອື່ນໆ.

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ພວກ​ເຮົາ​ສາ​ມາດ​ຄາດ​ຫວັງ​ວ່າ​ອັດ​ຕາ​ການ​ທາງ​ບວກ​ທີ່​ບໍ່​ຖືກ​ຕ້ອງ​ຕ​່​ໍາ​ປະ​ມານ 10-15​% [.5]. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, 9 ໃນ 10 ຄໍາເຕືອນຂອງການວິເຄາະຈະຊີ້ບອກເຖິງບັນຫາທີ່ແທ້ຈິງຂອງລະຫັດ, ຫຼືຢ່າງຫນ້ອຍ "ລະຫັດມີກິ່ນຫອມ." ຕົກລົງ, ສະຖານະການນີ້ແມ່ນເປັນທີ່ຫນ້າພໍໃຈທີ່ສຸດ, ແລະນັກວິເຄາະແມ່ນເພື່ອນທີ່ແທ້ຈິງຂອງໂປລແກລມ.

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

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

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

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

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

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

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

ປະຕິບັດ ​ແລະ ລົບ​ລ້າງ​ໜີ້​ສິນ​ທາງ​ວິຊາ​ການ

ໃນຄວາມເປັນຈິງ, ບໍ່ມີຫຍັງຍາກຫຼືຫນ້າຢ້ານກ່ຽວກັບການແນະນໍາການວິເຄາະ static ເຖິງແມ່ນວ່າເຂົ້າໄປໃນໂຄງການເກົ່າຂະຫນາດໃຫຍ່.

CI / CD

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

• PVS-Studio ໄປສູ່ຄລາວ: Azure Devops
• PVS-Studio ໄປສູ່ຄລາວ: Travis CI
• PVS-Studio ໄປຫາຄລາວ: GitLab CI/CD
• PVS-Studio ໄປຫາຄລາວ: CircleCI

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

ການແກ້ໄຂຫນີ້ສິນທາງວິຊາການທີ່ມີຢູ່ແລ້ວແລະການຈັດການກັບຄໍາເຕືອນໃຫມ່

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

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

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

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

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

ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ແລະ​ການ​ປັບ​ປຸງ​

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

if (a = b)

ຜູ້ລວບລວມແລະນັກວິເຄາະ C ++ ສ່ວນໃຫຍ່ຈົ່ມກ່ຽວກັບລະຫັດດັ່ງກ່າວ, ເພາະວ່າມີຄວາມເປັນໄປໄດ້ສູງທີ່ພວກເຂົາຕ້ອງການຂຽນ. (a == b). ແຕ່ມີຂໍ້ຕົກລົງທີ່ບໍ່ໄດ້ເວົ້າ, ແລະນີ້ມັກຈະສັງເກດເຫັນຢູ່ໃນເອກະສານ, ວ່າຖ້າມີວົງເລັບເພີ່ມເຕີມ, ມັນຖືວ່ານັກຂຽນໂປລແກລມເຈດຕະນາຂຽນລະຫັດດັ່ງກ່າວ, ແລະບໍ່ຈໍາເປັນຕ້ອງສາບານ. ຕົວຢ່າງ, ໃນເອກະສານ PVS-Studio ສໍາລັບການວິນິດໄສ V559 (CWE-481) ມັນໄດ້ຖືກຂຽນຢ່າງຊັດເຈນວ່າເສັ້ນຕໍ່ໄປນີ້ຈະຖືກພິຈາລະນາທີ່ຖືກຕ້ອງແລະປອດໄພ:

if ((a = b))

ຕົວຢ່າງອື່ນ. ມັນລືມຢູ່ໃນລະຫັດ C ++ ນີ້ບໍ? ພັກຜ່ອນ ຫຼືບໍ່?

case A:
  foo();
case B:
  bar();
  break;

ເຄື່ອງວິເຄາະ PVS-Studio ຈະອອກຄໍາເຕືອນຢູ່ທີ່ນີ້ V796 (CWE-484). ອັນນີ້ອາດຈະບໍ່ເປັນຂໍ້ຜິດພາດ, ໃນກໍລະນີທີ່ທ່ານຄວນຈະໃຫ້ຄຳຊີ້ບອກຕົວວິເຄາະໂດຍການເພີ່ມຄຸນສົມບັດ. [[ຫຼຸດ​ລົງ]] ຫຼື, ສໍາລັບການຍົກຕົວຢ່າງ, __ຄຸນລັກສະນະ__((ຫຼຸດ)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

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

ນອກເຫນືອຈາກການແກ້ໄຂຂໍ້ບົກພ່ອງແລະ refactorings, ທ່ານສາມາດສະກັດກັ້ນການເຕືອນຂອງການວິເຄາະທີ່ບໍ່ຖືກຕ້ອງໂດຍສະເພາະ. ການວິນິດໄສທີ່ບໍ່ກ່ຽວຂ້ອງບາງຢ່າງສາມາດຖືກປິດການໃຊ້ງານໄດ້. ຕົວຢ່າງ, ບາງຄົນຄິດວ່າຄໍາເຕືອນບໍ່ມີຈຸດຫມາຍ V550 ກ່ຽວກັບການປຽບທຽບຄ່າ float/double. ແລະ​ບາງ​ຄົນ​ຈັດ​ປະ​ເພດ​ພວກ​ເຂົາ​ເປັນ​ສິ່ງ​ສໍາ​ຄັນ​ແລະ​ມີ​ຄ່າ​ຄວນ​ຂອງ​ການ​ສຶກ​ສາ [7]. ການເຕືອນໄພອັນໃດທີ່ຖືວ່າກ່ຽວຂ້ອງ ແລະອັນໃດບໍ່ແມ່ນຂຶ້ນກັບທີມງານພັດທະນາຈະຕັດສິນ.

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

ນອກຈາກນີ້, ພວກເຮົາສະເຫມີຊ່ວຍລູກຄ້າຂອງພວກເຮົາສ້າງຕັ້ງ PVS-Studio ຖ້າຄວາມຫຍຸ້ງຍາກໃດໆເກີດຂື້ນ. ຍິ່ງ​ໄປ​ກວ່າ​ນັ້ນ, ມີ​ບາງ​ກໍ​ລະ​ນີ​ທີ່​ພວກ​ເຮົາ​ເອງ​ໄດ້​ລົບ​ລ້າງ​ການ​ເຕືອນ​ໄພ​ທີ່​ບໍ່​ຖືກ​ຕ້ອງ​ແລະ​ການ​ແກ້​ໄຂ​ຄວາມ​ຜິດ​ພາດ [8]. ພຽງແຕ່ໃນກໍລະນີ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະກ່າວເຖິງວ່າທາງເລືອກນີ້ສໍາລັບການຮ່ວມມືແບບຂະຫຍາຍກໍ່ເປັນໄປໄດ້ :).

ວິທີການ Ratchet

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

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

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

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

ຜູ້ຂຽນບົດຄວາມຍັງມີບົດລາຍງານກ່ຽວກັບຫົວຂໍ້ນີ້: "ການວິເຄາະສະຖິດຢ່າງຕໍ່ເນື່ອງ".

ສະຫລຸບ

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

ມີຄວາມສົງໃສທົ່ວໄປອື່ນໆກ່ຽວກັບວ່າການວິເຄາະສະຖິດສາມາດສະດວກແລະເປັນປະໂຫຍດແທ້ໆ. ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມລົບລ້າງຄວາມສົງໃສເຫຼົ່ານີ້ສ່ວນໃຫຍ່ໃນສິ່ງພິມ "ເຫດຜົນທີ່ຈະນໍາສະເຫນີຕົວວິເຄາະລະຫັດສະຖິດຂອງ PVS-Studio ເຂົ້າໃນຂະບວນການພັດທະນາ" [9].

ຂອບໃຈສໍາລັບຄວາມສົນໃຈຂອງທ່ານແລະມາ скачать ແລະລອງໃຊ້ເຄື່ອງວິເຄາະ PVS-Studio.

ການເຊື່ອມຕໍ່ເພີ່ມເຕີມ

1. Andrey Karpov. ຂ້ອຍຈະເຫັນຄໍາເຕືອນທີ່ຫນ້າສົນໃຈຢ່າງໄວວາທີ່ເຄື່ອງວິເຄາະ PVS-Studio ຜະລິດສໍາລັບລະຫັດ C ແລະ C ++ ໄດ້ແນວໃດ?
2. Wikipedia ທິດສະດີບົດຂອງເຂົ້າ.
3. Andrey Karpov, Victoria Khanieva. ການນໍາໃຊ້ການຮຽນຮູ້ເຄື່ອງຈັກໃນການວິເຄາະສະຖິດຂອງລະຫັດແຫຼ່ງໂຄງການ.
4. PVS-Studio. ເອກະສານ. ການຕັ້ງຄ່າການວິນິດໄສເພີ່ມເຕີມ.
5. Andrey Karpov. ລັກສະນະຂອງເຄື່ອງວິເຄາະ PVS-Studio ໂດຍໃຊ້ຕົວຢ່າງຂອງ EFL Core Libraries, 10-15% false positives.
6. PVS-Studio. ເອກະສານ. ການສະກັດກັ້ນມະຫາຊົນຂອງຂໍ້ຄວາມການວິເຄາະ.
7. Ivan Andryashin. ກ່ຽວກັບວິທີການທີ່ພວກເຮົາທົດສອບການວິເຄາະ static ກ່ຽວກັບໂຄງການຂອງພວກເຮົາຂອງ simulator ການສຶກສາຂອງການຜ່າຕັດ endovascular X-ray.
8. Pavel Eremeev, Svyatoslav Razmyslov. ທີມງານ PVS-Studio ປັບປຸງລະຫັດ Unreal Engine ແນວໃດ.
9. Andrey Karpov. ເຫດຜົນທີ່ຈະແນະນໍາຕົວວິເຄາະລະຫັດສະຖິດ PVS-Studio ເຂົ້າໃນຂະບວນການພັດທະນາ.

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

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