ກ່ຽວກັບລູກຄ້າເວັບ 1C

ຫນຶ່ງໃນລັກສະນະທີ່ດີຂອງ 1C: ເທກໂນໂລຍີວິສາຫະກິດແມ່ນວ່າການແກ້ໄຂຄໍາຮ້ອງສະຫມັກ, ພັດທະນາໂດຍໃຊ້ເທກໂນໂລຍີແບບຟອມທີ່ຖືກຄຸ້ມຄອງ, ສາມາດເປີດຕົວໄດ້ທັງໃນລູກຄ້າບາງໆ (ປະຕິບັດໄດ້) ສໍາລັບ Windows, Linux, MacOS X, ແລະເປັນລູກຄ້າເວັບສໍາລັບ 5 ຕົວທ່ອງເວັບ - Chrome, Internet Explorer, Firefox, Safari, Edge, ແລະທັງຫມົດນີ້ໂດຍບໍ່ມີການປ່ຽນລະຫັດແຫຼ່ງຄໍາຮ້ອງສະຫມັກ. ຍິ່ງໄປກວ່ານັ້ນ, ພາຍນອກຄໍາຮ້ອງສະຫມັກໃນລູກຄ້າບາງໆແລະໃນຫນ້າຂອງຕົວທ່ອງເວັບແລະເບິ່ງຄືວ່າເກືອບຄືກັນ.
ຊອກຫາ 10 ຄວາມແຕກຕ່າງ (2 ຮູບພາຍໃຕ້ການຕັດ):

ປ່ອງຢ້ຽມລູກຄ້າບາງໆໃນ Linux:

ປ່ອງຢ້ຽມດຽວກັນຢູ່ໃນເວັບລູກຄ້າ (ໃນຕົວທ່ອງເວັບ Chrome):

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

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

ການສ້າງບັນຫາ

ດັ່ງນັ້ນ, ຄວາມຕ້ອງການຂອງໂຄງການ: ລູກຄ້າເວັບຕ້ອງເຮັດເຊັ່ນດຽວກັນກັບລູກຄ້າບາງໆ, ຄື:

1. ສະແດງສ່ວນຕິດຕໍ່ຜູ້ໃຊ້
2. ປະຕິບັດລະຫັດລູກຄ້າທີ່ຂຽນເປັນພາສາ 1C

ການໂຕ້ຕອບຜູ້ໃຊ້ໃນ 1C ໄດ້ຖືກອະທິບາຍໄວ້ໃນຕົວແກ້ໄຂສາຍຕາ, ແຕ່ຢ່າງຈະແຈ້ງ, ໂດຍບໍ່ມີການຈັດລຽງ pixel-by-pixel ຂອງອົງປະກອບ; ປະ​ມານ​ສາມ​ອາຍ​ແກ​ັ​ສ​ຂອງ​ອົງ​ປະ​ກອບ​ການ​ໂຕ້​ຕອບ​ແມ່ນ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້ - ປຸ່ມ​, ຊ່ອງ​ໃສ່​ຂໍ້​ຄວາມ (ຂໍ້​ຄວາມ​, ຕົວ​ເລກ​, ວັນ​ທີ / ເວ​ລາ​)​, ລາຍ​ການ​, ຕາ​ຕະ​ລາງ​, ກ​ຣາ​ຟ​, ແລະ​ອື່ນໆ​.

ລະຫັດລູກຄ້າໃນພາສາ 1C ສາມາດປະກອບມີການໂທຫາເຄື່ອງແມ່ຂ່າຍ, ເຮັດວຽກກັບຊັບພະຍາກອນທ້ອງຖິ່ນ (ໄຟລ໌, ແລະອື່ນໆ), ການພິມ, ແລະອື່ນໆອີກ.

ທັງລູກຄ້າບາງໆ (ເມື່ອເຮັດວຽກຜ່ານເວັບ) ແລະລູກຄ້າເວັບໃຊ້ຊຸດດຽວກັນຂອງບໍລິການເວັບເພື່ອຕິດຕໍ່ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ 1C. ການປະຕິບັດລູກຄ້າ, ແນ່ນອນ, ແມ່ນແຕກຕ່າງກັນ - ລູກຄ້າບາງໆຖືກຂຽນໃນ C ++, ລູກຄ້າເວັບແມ່ນຂຽນໃນ JavaScript.

ບາງປະຫວັດສາດ

ໂຄງການລູກຄ້າເວັບໄຊຕ໌ໄດ້ເລີ່ມຕົ້ນໃນປີ 2006, ໂດຍມີທີມງານ (ໂດຍສະເລ່ຍ) 5 ຄົນ. ໃນບາງຂັ້ນຕອນຂອງໂຄງການ, ນັກພັດທະນາໄດ້ມີສ່ວນຮ່ວມໃນການປະຕິບັດຫນ້າທີ່ສະເພາະ (ເອກະສານຕາຕະລາງ, ແຜນວາດ, ແລະອື່ນໆ); ຕາມກົດລະບຽບ, ເຫຼົ່ານີ້ແມ່ນຜູ້ພັດທະນາດຽວກັນທີ່ເຮັດຫນ້າທີ່ນີ້ຢູ່ໃນລູກຄ້າບາງໆ. ເຫຼົ່ານັ້ນ. ຜູ້ພັດທະນາຂຽນອົງປະກອບໃຫມ່ໃນ JavaScript ທີ່ພວກເຂົາເຄີຍສ້າງໃນ C ++ ກ່ອນຫນ້ານີ້.

ໃນຕອນເລີ່ມຕົ້ນ, ພວກເຮົາປະຕິເສດແນວຄວາມຄິດຂອງການປ່ຽນແປງອັດຕະໂນມັດ (ແມ້ກະທັ້ງບາງສ່ວນ) ຂອງລະຫັດລູກຄ້າບາງໆ C ++ ເຂົ້າໄປໃນລູກຄ້າເວັບ JavaScript ເນື່ອງຈາກຄວາມແຕກຕ່າງທາງດ້ານແນວຄິດທີ່ເຂັ້ມແຂງລະຫວ່າງສອງພາສາ; ລູກຄ້າເວັບໄດ້ຖືກຂຽນໄວ້ໃນ JavaScript ຈາກຈຸດເລີ່ມຕົ້ນ.

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

ຮຸ່ນທໍາອິດຂອງ 1C: ແພລະຕະຟອມວິສາຫະກິດທີ່ມີການສະຫນັບສະຫນູນລູກຄ້າເວັບໄດ້ຖືກປ່ອຍອອກມາໃນປີ 2009. ລູກຄ້າເວັບໃນເວລານັ້ນສະຫນັບສະຫນູນ 2 ຕົວທ່ອງເວັບ - Internet Explorer ແລະ Firefox. ແຜນການຕົ້ນສະບັບປະກອບມີການສະຫນັບສະຫນູນ Opera, ແຕ່ເນື່ອງຈາກບັນຫາທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ໃນເວລານັ້ນກັບຕົວຈັດການການປິດແອັບພລິເຄຊັນໃນ Opera (ມັນບໍ່ສາມາດທີ່ຈະຕິດຕາມດ້ວຍຄວາມແນ່ນອນ 100% ວ່າແອັບພລິເຄຊັນປິດ, ແລະໃນເວລານັ້ນດໍາເນີນຂັ້ນຕອນການຕັດການເຊື່ອມຕໍ່ຈາກ. ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ 1C) ຈາກແຜນການເຫຼົ່ານີ້ຕ້ອງຖືກປະຖິ້ມ.

ໂຄງ​ປະ​ກອບ​ການ​

ໃນຈໍານວນທັງຫມົດ, 1C: ເວທີວິສາຫະກິດມີ 4 ໂຄງການທີ່ຂຽນໃນ JavaScript:

1. WebTools – ຫ້ອງສະຫມຸດທີ່ໃຊ້ຮ່ວມກັນໂດຍໂຄງການອື່ນໆ (ພວກເຮົາຍັງປະກອບມີ Google Closure Library).
2. ອົງປະກອບຄວບຄຸມ FormattedDocument (ປະຕິບັດໃນ JavaScript ໃນທັງລູກຄ້າບາງແລະລູກຄ້າເວັບ)
3. ອົງປະກອບຄວບຄຸມ ຜູ້ຈັດຕາຕະລາງ (ປະຕິບັດໃນ JavaScript ໃນທັງລູກຄ້າບາງແລະລູກຄ້າເວັບ)
4. ລູກຄ້າເວັບ

ໂຄງສ້າງຂອງແຕ່ລະໂຄງການຄ້າຍຄືກັບໂຄງສ້າງຂອງໂຄງການ Java (ຫຼືໂຄງການ .NET - ອັນໃດກໍ່ຕາມທີ່ໃກ້ຊິດ); ພວກເຮົາມີ namespaces, ແລະແຕ່ລະ namespace ແມ່ນຢູ່ໃນໂຟນເດີແຍກຕ່າງຫາກ. ພາຍໃນໂຟນເດີມີໄຟລ໌ ແລະຫ້ອງຮຽນ namespace. ມີປະມານ 1000 ໄຟລ໌ໃນໂຄງການລູກຄ້າເວັບ.

ຕາມໂຄງສ້າງ, ລູກຄ້າເວັບສ່ວນໃຫຍ່ແບ່ງອອກເປັນລະບົບຍ່ອຍຕໍ່ໄປນີ້:

• ການຈັດການແອັບພລິເຄຊັນລູກຄ້າ
  • ສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ທົ່ວໄປ (ເມນູລະບົບ, ແຜງ)
  • ການໂຕ້ຕອບຂອງຮູບແບບການຄຸ້ມຄອງ, ລວມທັງ, ໃນບັນດາສິ່ງອື່ນໆ, ປະມານ 30 ການຄວບຄຸມ (ປຸ່ມ, ປະເພດຕ່າງໆຂອງຊ່ອງໃສ່ຂໍ້ມູນ - ຂໍ້ຄວາມ, ຕົວເລກ, ວັນທີ / ເວລາ, ແລະອື່ນໆ, ຕາຕະລາງ, ລາຍການ, ເສັ້ນສະແດງ, ແລະອື່ນໆ)

• ຮູບແບບວັດຖຸມີໃຫ້ຜູ້ພັດທະນາໃນລູກຄ້າ (ລວມຫຼາຍກວ່າ 400 ປະເພດ: ຮູບແບບວັດຖຸສ່ວນຕິດຕໍ່ທີ່ຈັດການ, ການຕັ້ງຄ່າໂຄງຮ່າງຂໍ້ມູນ, ການຈັດຮູບແບບຕາມເງື່ອນໄຂ, ແລະອື່ນໆ)
• ນາຍແປພາສາຂອງພາສາ 1C ທີ່ສ້າງຂຶ້ນ
• ສ່ວນຂະຫຍາຍຂອງຕົວທ່ອງເວັບ (ໃຊ້ສໍາລັບການເຮັດວຽກທີ່ບໍ່ຮອງຮັບໃນ JavaScript)
  • ເຮັດວຽກກັບການເຂົ້າລະຫັດລັບ
  • ເຮັດວຽກກັບໄຟລ໌
  • ເທກໂນໂລຍີຂອງອົງປະກອບພາຍນອກ, ໃຫ້ພວກເຂົາສາມາດນໍາໃຊ້ໄດ້ທັງລູກຄ້າບາງແລະເວັບ

ຄຸນນະສົມບັດການພັດທະນາ

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

ເພື່ອຫຼຸດຜ່ອນຂະຫນາດຂອງລະຫັດລູກຄ້າ, ພວກເຮົາທໍາອິດໃຊ້ obfuscator ຂອງພວກເຮົາເອງ, ແລະເລີ່ມຕົ້ນດ້ວຍເວທີ 8.3.6 (ເດືອນຕຸລາ 2014) ພວກເຮົາເລີ່ມໃຊ້. Google Closure Compiler. ຜົນ​ກະ​ທົບ​ຂອງ​ການ​ນໍາ​ໃຊ້​ໃນ​ຕົວ​ເລກ – ຂະ​ຫນາດ​ຂອງ​ໂຄງ​ການ​ລູກ​ຄ້າ​ເວັບ​ໄຊ​ຕ​໌​ຫຼັງ​ຈາກ​ຄວາມ​ຂັດ​ສົນ​:

• obfuscator ຂອງຕົນເອງ – 1556 kb
• Google Closure Compiler – 1073 kb

ການນໍາໃຊ້ Google Closure Compiler ໄດ້ຊ່ວຍພວກເຮົາປັບປຸງປະສິດທິພາບຂອງລູກຄ້າເວັບ 30% ເມື່ອທຽບກັບ obfuscator ຂອງພວກເຮົາເອງ. ນອກຈາກນັ້ນ, ຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ບໍລິໂພກໂດຍແອັບພລິເຄຊັນໄດ້ຫຼຸດລົງ 15-25% (ຂຶ້ນກັບຕົວທ່ອງເວັບ).

Google Closure Compiler ເຮັດວຽກໄດ້ດີກັບລະຫັດທີ່ເນັ້ນໃສ່ວັດຖຸ, ດັ່ງນັ້ນປະສິດທິພາບຂອງມັນສໍາລັບລູກຄ້າເວັບແມ່ນສູງທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້. Closure Compiler ເຮັດບາງສິ່ງທີ່ດີສໍາລັບພວກເຮົາ:

• ການກວດສອບປະເພດຄົງທີ່ຢູ່ໃນຂັ້ນຕອນການສ້າງໂຄງການ (ໃຫ້ແນ່ໃຈວ່າພວກເຮົາກວມເອົາລະຫັດທີ່ມີ JSDoc annotations). ຜົນໄດ້ຮັບແມ່ນການພິມແບບຄົງທີ່, ໃກ້ກັບລະດັບການພິມໃນ C++. ນີ້ຊ່ວຍຈັບອັດຕາສ່ວນຫຼາຍພໍສົມຄວນຂອງຄວາມຜິດພາດໃນຂັ້ນຕອນການລວບລວມໂຄງການ.
• ການຫຼຸດຜ່ອນຂະຫນາດລະຫັດໂດຍຜ່ານການເຮັດໃຫ້ສັບສົນ
• ຈໍານວນຂອງການເພີ່ມປະສິດທິພາບຂອງລະຫັດປະຕິບັດ, ສໍາລັບການຍົກຕົວຢ່າງ, ເຊັ່ນ:
  • inline function ການທົດແທນ. ການເອີ້ນຟັງຊັນໃນ JavaScript ແມ່ນການດໍາເນີນງານທີ່ມີລາຄາແພງພໍສົມຄວນ, ແລະການທົດແທນໃນແຖວຂອງວິທີການຂະຫນາດນ້ອຍທີ່ໃຊ້ເລື້ອຍໆເຮັດໃຫ້ລະຫັດໄວຂຶ້ນ.
  • ການນັບຄ່າຄົງທີ່ໃນເວລາລວບລວມ. ຖ້າການສະແດງອອກຂຶ້ນກັບຄ່າຄົງທີ່, ຄ່າທີ່ແທ້ຈິງຂອງຄົງທີ່ຈະຖືກແທນທີ່ມັນ

ພວກເຮົາໃຊ້ WebStorm ເປັນສະພາບແວດລ້ອມການພັດທະນາລູກຄ້າເວັບຂອງພວກເຮົາ.

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

ພວກເຮົາແກ້ໄຂບັນຫາຫຍັງແດ່?

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

ແລກປ່ຽນຂໍ້ມູນກັບເຊີບເວີ ແລະລະຫວ່າງປ່ອງຢ້ຽມ

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

• ລະຫັດມາຈາກເຄື່ອງແມ່ຂ່າຍໃນຮູບແບບຂອງໂຄງສ້າງຂໍ້ມູນ
• ລະຫັດສໍາລັບປ່ອງຢ້ຽມແອັບພລິເຄຊັນອື່ນ

ເພື່ອຫຼີກເວັ້ນການສັບສົນໃນເວລາທີ່ພົວພັນກັບເຄື່ອງແມ່ຂ່າຍ, ພວກເຮົາໃຊ້ແທັກ @expose:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

ແລະເພື່ອຫຼີກເວັ້ນການ obfuscation ເມື່ອພົວພັນກັບປ່ອງຢ້ຽມອື່ນໆ, ພວກເຮົາໃຊ້ອັນທີ່ເອີ້ນວ່າການໂຕ້ຕອບການສົ່ງອອກ (ການໂຕ້ຕອບທີ່ວິທີການທັງຫມົດຖືກສົ່ງອອກ).

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

ພວກເຮົາໃຊ້ Virtual DOM ກ່ອນທີ່ມັນຈະກາຍເປັນກະແສຫຼັກ)

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

ການເພີ່ມປະສິດທິພາບລູກຄ້າເວັບ

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

ການທົດສອບ

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

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

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

ເຄື່ອງມືການທົດສອບແລະຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາພາຍໃຕ້ການທົດສອບ

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

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

ນັກພັດທະນາໃຊ້ເຄື່ອງມືທີ່ແຕກຕ່າງກັນເພື່ອສືບສວນເຫດການຊ້າລົງ; ສ່ວນໃຫຍ່ແມ່ນໃຊ້ Dynatrace AJAX Edition ບໍລິສັດຜະລິດ DynaTrace. ບັນທຶກການປະຕິບັດຂອງການດໍາເນີນງານທີ່ມີບັນຫາໃນການກໍ່ສ້າງທີ່ຜ່ານມາແລະໃຫມ່ໄດ້ຖືກບັນທຶກໄວ້, ຫຼັງຈາກນັ້ນບັນທຶກໄດ້ຖືກວິເຄາະ. ໃນຂະນະດຽວກັນ, ເວລາປະຕິບັດການດໍາເນີນການດຽວ (ເປັນ milliseconds) ອາດຈະບໍ່ເປັນປັດໃຈຕັດສິນ - ຂະບວນການບໍລິການເຊັ່ນ: ການເກັບຂີ້ເຫຍື້ອຖືກເປີດຕົວເປັນແຕ່ລະໄລຍະໃນຕົວທ່ອງເວັບ, ພວກເຂົາສາມາດຊ້ອນກັນກັບເວລາປະຕິບັດຫນ້າທີ່ແລະການບິດເບືອນຮູບພາບ. ຕົວກໍານົດການທີ່ກ່ຽວຂ້ອງເພີ່ມເຕີມໃນກໍລະນີນີ້ຈະເປັນຈໍານວນຂອງຄໍາແນະນໍາ JavaScript ປະຕິບັດ, ຈໍານວນຂອງການປະຕິບັດປະລໍາມະນູໃນ DOM, ແລະອື່ນໆ. ຖ້າຈໍານວນຂອງຄໍາແນະນໍາ / ການດໍາເນີນງານໃນສະຄິບດຽວກັນໄດ້ເພີ່ມຂຶ້ນໃນສະບັບໃຫມ່, ນີ້ເກືອບສະເຫມີຫມາຍຄວາມວ່າການຫຼຸດລົງໃນການປະຕິບັດທີ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂ.

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

ສ່ວນຂະຫຍາຍຂອງຕົວທ່ອງເວັບ

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

• ສໍາລັບການເຮັດວຽກກັບໄຟລ໌
• ສໍາລັບການເຮັດວຽກກັບ cryptography
• ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ ອົງປະກອບພາຍນອກ

ສ່ວນຂະຫຍາຍຂອງພວກເຮົາປະກອບດ້ວຍສອງສ່ວນ. ສ່ວນທໍາອິດແມ່ນສິ່ງທີ່ເອີ້ນວ່າສ່ວນຂະຫຍາຍຂອງຕົວທ່ອງເວັບ (ປົກກະຕິແລ້ວການຂະຫຍາຍສໍາລັບ Chrome ແລະ Firefox ທີ່ຂຽນໃນ JavaScript), ເຊິ່ງພົວພັນກັບສ່ວນທີສອງ - ການຂະຫຍາຍ binary ທີ່ປະຕິບັດຫນ້າທີ່ທີ່ພວກເຮົາຕ້ອງການ. ມັນຄວນຈະກ່າວເຖິງວ່າພວກເຮົາຂຽນ 3 ຮຸ່ນຂອງນາມສະກຸນຄູ່ - ສໍາລັບ Windows, Linux ແລະ MacOS. ສ່ວນຂະຫຍາຍຖານສອງແມ່ນສະໜອງໃຫ້ເປັນສ່ວນຫນຶ່ງຂອງ 1C:ແພລດຟອມວິສາຫະກິດ ແລະຕັ້ງຢູ່ໃນເຊີບເວີແອັບພລິເຄຊັນ 1C. ເມື່ອຖືກເອີ້ນເປັນຄັ້ງທໍາອິດຈາກລູກຄ້າເວັບ, ມັນຖືກດາວໂຫຼດໃສ່ຄອມພິວເຕີຂອງລູກຄ້າແລະຕິດຕັ້ງຢູ່ໃນຕົວທ່ອງເວັບ.

ເມື່ອແລ່ນຢູ່ໃນ Safari, ສ່ວນຂະຫຍາຍຂອງພວກເຮົາໃຊ້ NPAPI; ເມື່ອແລ່ນໃນ Internet Explorer, ພວກມັນໃຊ້ເຕັກໂນໂລຢີ ActiveX. Microsoft Edge ຍັງບໍ່ທັນສະຫນັບສະຫນູນການຂະຫຍາຍ, ດັ່ງນັ້ນລູກຄ້າເວັບໃນມັນເຮັດວຽກກັບຂໍ້ຈໍາກັດ.

ການພັດທະນາຕໍ່ໄປ

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

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

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