ຫຼັກການໃນການພັດທະນາຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມຈາກ NGINX. ພາກທີ 1

ສະບາຍດີຫມູ່ເພື່ອນ. ໃນ​ການ​ຄາດ​ຄະ​ເນ​ການ​ເປີດ​ຫຼັກ​ສູດ​ "ນັກພັດທະນາ Backend ໃນ PHP"ຕາມປະເພນີ, ພວກເຮົາແບ່ງປັນການແປພາສາຂອງອຸປະກອນທີ່ເປັນປະໂຫຍດກັບທ່ານ.

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

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

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

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

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

ໂດຍ​ການ​ນໍາ​ໃຊ້​ຫຼັກ​ການ​ເຫຼົ່າ​ນີ້​, ທ່ານ​ຈະ​ພົບ​ເຫັນ​ຕົວ​ທ່ານ​ເອງ​ໄດ້​ຮັບ​ປະ​ໂຫຍດ​ຈາກ​ທ່າ​ອ່ຽງ​ຫລ້າ​ສຸດ​ໃນ​ການ​ພັດ​ທະ​ນາ​ຊອບ​ແວ​, ລວມ​ທັງ​ການ​ DevOps ການພັດທະນາຄໍາຮ້ອງສະຫມັກແລະການຈັດສົ່ງ, ການນໍາໃຊ້ບັນຈຸ (ຕົວຢ່າງ, Docker) ແລະໂຄງຮ່າງການ orchestration ບັນຈຸ (ຕົວຢ່າງ, Kubernetes), ການ​ນໍາ​ໃຊ້​ຂອງ microservices (ລວມ​ທັງ​ສະ​ຖາ​ປັດ​ຕະ Microservice​ NGINX и ສະຖາປັດຕະຍະກໍາການສື່ສານເຄືອຂ່າຍ ສໍາລັບຄໍາຮ້ອງສະຫມັກ microservice.

ແອັບທີ່ທັນສະໄຫມແມ່ນຫຍັງ?

ຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມ? stack ທັນສະໄຫມ? "ທັນສະໄຫມ" ຫມາຍຄວາມວ່າແນວໃດ?

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

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

ຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມສະຫນອງ API ເພື່ອເຂົ້າເຖິງຂໍ້ມູນແລະການບໍລິການທີ່ຮ້ອງຂໍ. API ຄວນຈະບໍ່ປ່ຽນແປງໄດ້ ແລະຄົງທີ່, ແລະບໍ່ໄດ້ຂຽນສະເພາະສໍາລັບການຮ້ອງຂໍສະເພາະຈາກລູກຄ້າສະເພາະ. API ສາມາດໃຊ້ໄດ້ຜ່ານ HTTP(S) ແລະໃຫ້ການເຂົ້າເຖິງທຸກຟັງຊັນທີ່ພົບໃນ GUI ຫຼື CLI.

ຂໍ້​ມູນ​ຕ້ອງ​ມີ​ຢູ່​ໃນ​ຮູບ​ແບບ​ທີ່​ສາ​ມາດ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັນ​ເຊັ່ນ JSON​. API ເປີດເຜີຍວັດຖຸ ແລະການບໍລິການໃນຮູບແບບທີ່ຈະແຈ້ງ, ເປັນລະບຽບ; ຕົວຢ່າງ, RESTful API ຫຼື GraphQL ສະໜອງການໂຕ້ຕອບທີ່ເໝາະສົມ.

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

ສະບັບທີ່ນິຍົມຂອງປະເພດຂອງ stack ນີ້ແມ່ນອີງໃສ່ Java, Python, node, Ruby, PHP и Go. ສະຖາປັດຕະຍະກຳ Microservice NGINX ເປັນຕົວແທນຂອງຕົວຢ່າງຂອງ stack ທີ່ທັນສະໄຫມປະຕິບັດໃນແຕ່ລະພາສາທີ່ໄດ້ກ່າວມາ.

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

ຫຼັກການ

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

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

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

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

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

ຂໍໃຫ້ເບິ່ງສາມຫຼັກການນີ້ໂດຍລະອຽດຕື່ມ.

ຫຼັກການຂອງຂະຫນາດນ້ອຍ

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

ຄໍາຮ້ອງສະຫມັກແມ່ນ decomposed ສໍາລັບເຫດຜົນດັ່ງຕໍ່ໄປນີ້:

• ການຫຼຸດຜ່ອນການໂຫຼດມັນສະຫມອງກ່ຽວກັບນັກພັດທະນາ;
• ການເລັ່ງແລະຄວາມງ່າຍດາຍຂອງການທົດສອບ;
• ການຈັດສົ່ງໄວຂອງການປ່ຽນແປງຄໍາຮ້ອງສະຫມັກ.

ມີຫຼາຍວິທີທີ່ຈະຫຼຸດຜ່ອນການໂຫຼດມັນສະຫມອງຂອງນັກພັດທະນາ, ແລະນີ້ແມ່ນບ່ອນທີ່ຫຼັກການຂອງຂະຫນາດນ້ອຍເຂົ້າມາ.

ດັ່ງນັ້ນ, ສາມວິທີທີ່ຈະຫຼຸດຜ່ອນການໂຫຼດມັນສະຫມອງ:

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

ຫຼຸດໄລຍະເວລາການພັດທະນາ

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

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

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

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

codebases ຂະຫນາດນ້ອຍ

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

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

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

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

ການປ່ຽນແປງເທື່ອລະກ້າວ

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

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

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

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

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

ສິ້ນສຸດພາກທໍາອິດ.

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

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