ໂຮງຮຽນພັດທະນາການໂຕ້ຕອບ: ການວິເຄາະວຽກງານສໍາລັບ Minsk ແລະຊຸດໃຫມ່ໃນ Moscow

ມື້ນີ້ເປີດການລົງທະບຽນໃໝ່ແລ້ວ ໂຮງຮຽນພັດທະນາການໂຕ້ຕອບ Yandex ໃນ Moscow. ການ​ຝຶກ​ອົບ​ຮົມ​ຂັ້ນ​ຕອນ​ທຳ​ອິດ​ຈະ​ດຳ​ເນີນ​ແຕ່​ວັນ​ທີ 7/25 ຫາ​ວັນ​ທີ 3/XNUMX. ນັກສຶກສາຈາກເມືອງອື່ນໆຈະສາມາດເຂົ້າຮ່ວມໃນມັນຫ່າງໄກສອກຫຼີກຫຼືດ້ວຍຕົນເອງ - ບໍລິສັດຈະຈ່າຍຄ່າເດີນທາງແລະທີ່ພັກໃນ hostel. ທີສອງ, ຍັງເປັນຂັ້ນຕອນສຸດທ້າຍ, ຈະແກ່ຍາວເຖິງວັນທີ XNUMX ທັນວາ, ມັນພຽງແຕ່ສາມາດສໍາເລັດໃນຄົນ.

ຂ້ອຍຊື່ Yulia Seredich, ພວກເຮົາຂຽນບົດນີ້ຮ່ວມກັນກັບ Sergei Kazakov. ພວກເຮົາທັງສອງເປັນຜູ້ພັດທະນາການໂຕ້ຕອບຢູ່ໃນຫ້ອງການ Minsk ຂອງ Yandex ແລະຜູ້ຮຽນຈົບ SRI ຈາກປີທີ່ຜ່ານມາ.

ໃນໂອກາດຂອງການເປີດການລົງທະບຽນໃນມອດໂກ, ພວກເຮົາກໍາລັງເຜີຍແຜ່ການວິເຄາະຂອງຫນ້າທີ່ແນະນໍາກັບໂຮງຮຽນທີ່ຜ່ານມາ - ຢູ່ທີ່ນີ້ໃນ Minsk.

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

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

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

ວຽກທີ່ 1: ຫຼັກຊັບ

ວຽກງານທໍາອິດແມ່ນເຮັດວຽກໂດຍຜູ້ອອກແບບ Yandex.Collections Alexey Cherenkevich, ຜູ້ທີ່ຮູ້ວິທີການຈັດວາງ, ແລະເພື່ອນຮ່ວມງານການບໍລິການຂອງລາວ, ຜູ້ພັດທະນາການໂຕ້ຕອບ Sergey Samsonov.

ເງື່ອນໄຂ

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

ເມື່ອກວດສອບພວກເຮົາຈະພິຈາລະນາ:

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

ປະໂຫຍດຈະເປັນ:

• ການນໍາໃຊ້ການແກ້ໄຂ CSS ທີ່ທັນສະໄຫມ: flexbox, grid, ແລະອື່ນໆ;
• ຮູບແບບການປັບຕົວ;
• ການນໍາໃຊ້ pre- ແລະ (ຫຼື) post-processors, ການປະກອບ, minification, optimization ຂອງລະຫັດຜົນຜະລິດ;
• ການກວດສອບແບບຟອມ HTML, ປຸ່ມອັບໂຫລດໄຟລ໌ແບບສະໄຕລ໌.

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

ການຈັດວາງທີ່ນໍາສະເຫນີໃນການມອບຫມາຍບໍ່ພຽງແຕ່ມີຫນ້າຈໍສໍາລັບອຸປະກອນມືຖື, ແທັບເລັດແລະ desktop, ແຕ່ຍັງມີລັກສະນະສະເພາະ.

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

ເງື່ອນໄຂ

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

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

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

ການຈັດວາງແບບ semantic. "ພວກເຂົາບອກໂລກຫຼາຍປານໃດ" ວ່າການເຊື່ອມຕໍ່ຄວນຈະຖືກອອກແບບເປັນ , ປຸ່ມ - ເປັນ . ໂຊກດີ, ຜູ້ສະຫມັກສ່ວນໃຫຍ່ໄດ້ປະຕິບັດຄວາມຕ້ອງການນີ້ເຊັ່ນກັນ. ບໍ່ແມ່ນທຸກຄົນຮັບຮູ້ລາຍຊື່ທີ່ເຊື່ອງໄວ້ໃນຄວາມຄາດຫວັງຂອງ SRI, ເຮັດໃຫ້ມັນໃຊ້ div tags, ແຕ່ມັນບໍ່ແມ່ນສິ່ງທີ່ບໍ່ດີ. ມີຜູ້ສະຫມັກທີ່ໃສ່ tags semantic ທັງຫມົດທີ່ລາວຮູ້ - ບ່ອນທີ່ມັນຈໍາເປັນແລະບ່ອນທີ່ມັນບໍ່ຈໍາເປັນ. ຕົວຢ່າງ, ແທນທີ່ຈະເປັນບັນຊີລາຍຊື່ - ແລະ . ຫຼັງຈາກທີ່ທັງຫມົດ, semantics - ມັນເປັນການເຂົ້າໃຈອົງປະກອບຂອງຫນ້າຂອງທ່ານແລະຈຸດປະສົງຂອງແຕ່ລະຕັນ (ສ່ວນໃຫຍ່ໄດ້ຈັດການມັນຢູ່ທີ່ນີ້), ເຊັ່ນດຽວກັນກັບການນໍາໃຊ້ pre- ແລະ / ຫຼື post-processors (ຈໍານວນຫນ້ອຍຈັດການມັນຢູ່ທີ່ນີ້, ເຖິງແມ່ນວ່ານີ້. ຍັງຢູ່ໃນຈຸດ - ສ່ວນຫຼາຍມັກຈະໃຊ້ຫນ້ອຍແລະ scss).

ຕົວເລື່ອນເຮັດວຽກ. ໃນວຽກທີ່ພວກເຮົາຂຽນວ່າ JS ບໍ່ສາມາດໃຊ້ໄດ້. ໃນທີ່ນີ້ຄວາມສາມາດໃນການແກ້ໄຂບັນຫາໄດ້ຖືກທົດສອບ - slider ສາມາດເຮັດໄດ້ໂດຍໃຊ້ຊໍ່ ແລະ . ມະຫັດສະຈັນທັງໝົດເກີດຂຶ້ນທີ່ລະດັບຕົວເລືອກ #button-N:checked ~ .slider-inner .slider-slides. ເມື່ອ​ເຮົາ​ຄລິກ​ໃສ່​ນຶ່ງ​ໃນ​ປ່ອງ​ກວດ​ສອບ​ການ​ປ້ອນ​ຂໍ້​ມູນ​, ມັນ​ຈະ​ເຂົ້າ​ໄປ​ໃນ​ສະ​ຖາ​ນະ​ການ​ກວດ​ສອບ​ໄດ້​. ພວກ​ເຮົາ​ສາ​ມາດ​ໃຊ້​ປະ​ໂຫຍດ​ຈາກ​ການ​ນີ້​ແລະ​ກໍາ​ນົດ​ການ​ແປ​ພາ​ສາ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ກັບ​ພາ​ຊະ​ນະ​ທີ່​ມີ slides ໄດ້​: transform​: translate(-33​%​)​. ທ່ານສາມາດເບິ່ງການປະຕິບັດຂອງ slider ໄດ້ ທີ່ນີ້.

ລາຍຊື່ແບບເລື່ອນລົງ. ໃນທີ່ນີ້ມັນທັງຫມົດຍັງລົງມາ ແລະຕົວເລືອກທີ່ຄ້າຍຄືກັນ: .accordion-item input:checked ~ .accordion-item__content. ທ່ານສາມາດເບິ່ງການປະຕິບັດໄດ້ ທີ່ນີ້.

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

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

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

ການກວດສອບແບບຟອມ. ທັງຫມົດທີ່ຕ້ອງການແມ່ນເພື່ອເພີ່ມຄຸນລັກສະນະທີ່ຈໍາເປັນໃຫ້ກັບແຕ່ລະວັດສະດຸປ້ອນຂອງແບບຟອມ. ພວກ​ເຮົາ​ໄດ້​ເພີ່ມ​ຈຸດ​ໃຫ້​ຜູ້​ທີ່​ກວດ​ສອບ​ພາກ​ສະ​ຫນາມ​ອີ​ເມວ​ເປັນ​ອີ​ເມລ​໌​.

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

ຄວາມເຂົ້າກັນໄດ້ຂອງຕົວທ່ອງເວັບ. ພວກເຮົາໄດ້ກວດເບິ່ງວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີຢູ່ໃນສອງສະບັບຫລ້າສຸດຂອງຕົວທ່ອງເວັບທີ່ທັນສະໄຫມ (ໂດຍບໍ່ມີ IE - ຜູ້ເຂົ້າຮ່ວມແມ່ນໂຊກດີ), ເຊັ່ນດຽວກັນກັບໃນ Safari ໃນ iPhones ແລະ Chrome ໃນ Androids.

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

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

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

ວຽກງານທີ 2: ເສັ້ນທາງການຂົນສົ່ງ

ຜູ້ຂຽນຂອງວຽກງານແມ່ນຫົວຫນ້າຂອງກຸ່ມຄົ້ນຫາການໂຕ້ຕອບ Denis Balyko.

ເງື່ອນໄຂ

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

ລາຍເຊັນຟັງຊັນ:

const solution = function(graph, start, finish)  {
    // Ваше решение
} 

ຕົວຢ່າງຂໍ້ມູນການປ້ອນຂໍ້ມູນ:

const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 

ຕົວຢ່າງຜົນຜະລິດ:

{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 

ຫມາຍ​ເຫດ​: ໂຄງ​ຮ່າງ​ການ​ແກ້​ໄຂ​ແມ່ນ​ຢູ່​ໃນ src/ folder, ເອົາ​ການ​ແກ້​ໄຂ​ຂອງ​ທ່ານ​ໃນ solution.js.

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

ເງື່ອນໄຂ

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

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

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

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

ການ​ແກ້​ໄຂ​ທີ່​ຖືກ​ຕ້ອງ​:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);

    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)

    const visited = [];
    let node;

    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];

            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)

    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };

    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }

    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }

            return lowest;
        }, null);
    };
};

ວຽກງານທີ 3: ປະຕິທິນເຫດການ

ມັນໄດ້ຖືກກະກຽມໂດຍນັກພັດທະນາການໂຕ້ຕອບ Sergey Kazakov ແລະ Alexander Podskrebkin.

ເງື່ອນໄຂ

ຂຽນປະຕິທິນນ້ອຍເພື່ອສະແດງຕາຕະລາງຂອງທ່ານ. ທ່ານສາມາດເອົາຕາຕະລາງທີ່ທ່ານຕ້ອງການ. ຕົວຢ່າງ, ຕາຕະລາງຂອງກອງປະຊຸມ frontend ໃນປີ 2019.

ປະຕິທິນຄວນມີລັກສະນະເປັນລາຍການ. ບໍ່ມີຂໍ້ກໍານົດການອອກແບບອື່ນໆ. ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຕັ້ງການແຈ້ງເຕືອນເຫດການ 3, 7 ແລະ 14 ມື້ລ່ວງຫນ້າ. ຫຼັງ​ຈາກ​ການ​ດາວ​ໂຫຼດ​ຄັ້ງ​ທໍາ​ອິດ​ຈາກ​ອິນ​ເຕີ​ເນັດ​, ປະ​ຕິ​ທິນ​ຄວນ​ຈະ​ເປີດ​ແລະ​ເຮັດ​ວຽກ offline​.

ຊັບພະຍາກອນທີ່ມີປະໂຫຍດ

ຕາຕະລາງກອງປະຊຸມ Frontend:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

ພະນັກງານບໍລິການ:
developer.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers

API ການແຈ້ງເຕືອນ:
developer.mozilla.org/ru/docs/Web/API/Notifications_API

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

ເງື່ອນໄຂ

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

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

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

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

ຄວາມສາມາດໃນການວາງ icon ໃນ desktop ໄດ້ (ປປສ). ພວກເຮົາໄດ້ກວດເບິ່ງການປະກົດຕົວຂອງໄຟລ໌ manifest.json ມີໄອຄອນທີ່ຖືກຕ້ອງ. ຜູ້ຊາຍບາງຄົນສ້າງໄຟລ໌ນີ້ (ຫຼືປະໄວ້ມັນສ້າງຢູ່ໃນ CreateReactApp) - ແຕ່ບໍ່ໄດ້ເພີ່ມໄອຄອນທີ່ຖືກຕ້ອງ. ຫຼັງຈາກນັ້ນ, ເມື່ອພະຍາຍາມຕິດຕັ້ງ, ຂໍ້ຜິດພາດເຊັ່ນ "ຕ້ອງການໄອຄອນທີ່ແຕກຕ່າງກັນ" ເກີດຂື້ນ.

Codestyle ແລະໂຄງສ້າງໂຄງການ. ເຊັ່ນດຽວກັນກັບວຽກງານທີສອງ, ພວກເຮົາເບິ່ງຢູ່ໃນ codestyle ດຽວ (ເຖິງແມ່ນວ່າມັນບໍ່ກົງກັນກັບຂອງພວກເຮົາ). ຜູ້ຊາຍບາງຄົນ screwed ສຸດ linters - ທີ່ຍິ່ງໃຫຍ່.

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

ຜົນໄດ້ຮັບ

ສິ່ງທີ່ຕະຫລົກກ່ຽວກັບການຕັດສິນໃຈຂອງຜູ້ເຂົ້າຮ່ວມ:

• ແບບສອບຖາມຫນຶ່ງມີຂໍ້ຄວາມຕໍ່ໄປນີ້: “ເພື່ອນນັກຂຽນໂປລແກລມໄດ້ຊ່ວຍຂ້ອຍເອົາຄໍາຮ້ອງສະຫມັກ React ຮ່ວມກັນ. ຂ້າພະເຈົ້າໄດ້ຖິ້ມລະເບີດໃສ່ລາວດ້ວຍຄໍາຖາມກ່ຽວກັບວິທີການແລະເປັນຫຍັງ, ແລະລາວບອກຂ້ອຍ. ຂ້ອຍມັກມັນຫຼາຍ, ຂ້ອຍຢາກຮູ້ເພີ່ມເຕີມກ່ຽວກັບມັນ.” ພວກເຮົາໄດ້ປົ່ງຮາກອອກຕາມຄໍາຮ້ອງສະຫມັກນີ້ດ້ວຍຫົວໃຈຂອງພວກເຮົາທັງຫມົດ, ແຕ່ຫນ້າເສຍດາຍ, ຫມູ່ເພື່ອນຂອງຜູ້ສະຫມັກບໍ່ໄດ້ເປັນປະໂຫຍດຫຼາຍເພື່ອເຮັດໃຫ້ຄໍາຮ້ອງສະຫມັກເຮັດວຽກ.
• ຜູ້ສະຫມັກຄົນຫນຶ່ງໄດ້ສົ່ງລິ້ງໄປຫາ GitHub, ບ່ອນທີ່ບ່ອນເກັບມ້ຽນ RAR ຕັ້ງຢູ່ - ມັນຍາກທີ່ຈະສະແດງຄວາມຄິດເຫັນກ່ຽວກັບເລື່ອງນີ້. 🙂
• ຜູ້ສະຫມັກຄົນອື່ນ, ໃນຄໍາເຫັນກ່ຽວກັບແຖວທໍາອິດຂອງໄຟລ໌ solution.js, ຍອມຮັບຢ່າງຊື່ສັດວ່າລາວໄດ້ຄັດລອກ algorithm.

ພວກເຮົາໄດ້ຮັບໃບສະໝັກຈາກຜູ້ສະໝັກທັງໝົດ 76 ທ່ານ ແລະ ເລືອກເອົາ 23 ຄົນ. ພວກເຮົາໄດ້ຖືກສົ່ງແບບສອບຖາມບໍ່ພຽງແຕ່ຈາກ Minsk, ແຕ່ຍັງມາຈາກ Moscow, St. Petersburg ແລະແມ້ກະທັ້ງ Tatarstan. ຜູ້ຊາຍບາງຄົນເຮັດໃຫ້ພວກເຮົາປະຫລາດໃຈກັບອາຊີບໃນປະຈຸບັນຂອງພວກເຂົາ: ຫນຶ່ງໃນນັ້ນແມ່ນຜູ້ຊ່ຽວຊານດ້ານ forensic, ແລະອີກຄົນຫນຶ່ງແມ່ນນັກສຶກສາແພດ.

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

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

ຂ້ອຍຈື່ໄດ້ວ່າເຫັນວຽກເຂົ້າ SRI ຂອງຂ້ອຍເມື່ອສອງປີກ່ອນແລະຄິດວ່າຂ້ອຍບໍ່ເຄີຍແກ້ໄຂມັນ. ສິ່ງທີ່ສໍາຄັນໃນເວລານີ້ແມ່ນນັ່ງລົງ, ອ່ານເງື່ອນໄຂຢ່າງລະມັດລະວັງແລະເລີ່ມຕົ້ນເຮັດມັນ. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ເງື່ອນ​ໄຂ​ປະ​ກອບ​ດ້ວຍ​ເກືອບ 80​% ຂອງ​ການ​ແກ້​ໄຂ​ໄດ້​. ຕົວຢ່າງ, ໃນເງື່ອນໄຂຂອງວຽກງານທີສາມ (ຍາກທີ່ສຸດ), ພວກເຮົາໄດ້ເພີ່ມການເຊື່ອມຕໍ່ກັບພະນັກງານບໍລິການແລະ Notifications API ໃນ MDN. ນັກສຶກສາຜູ້ທີ່ໄດ້ສຶກສາເນື້ອໃນຂອງການເຊື່ອມຕໍ່ສໍາເລັດມັນໂດຍບໍ່ມີຄວາມຫຍຸ້ງຍາກ.

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

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