ຫຼັກການ SOLID ແມ່ນເປັນພື້ນຖານທີ່ສໍາຄັນຂອງການອອກແບບຊອບແວທີ່ມີຄວາມເຂັ້ມແຂງ ແລະ ວິສະວະກໍາ, ໂດຍສະເໜີເປັນຄໍາແນະນໍາທີ່ສາມາດນໍາໄປປະຕິບັດໄດ້ເພື່ອຫຼຸດຜ່ອນໜີ້ທາງດ້ານເຕັກນິກ ແລະ ປ້ອງກັນບັນຫາທີ່ເກີດຕໍ່ເນື່ອງ. ກົດລະບຽບຫ້າຂໍ້ທີ່ເຊື່ອມຕໍ່ກັນນີ້ຈະສ້າງລະບົບທີ່ການປ່ຽນແປງຢູ່ໃນຂອບເຂດທີ່ຈໍາກັດ, ເຮັດໃຫ້ຜົນກະທົບທີ່ບໍ່ຄາດຄິດຫຼຸດລົງໃນຂະນະທີ່ກໍາລັງຮັກສາລະບົບ.
ມັນມີເຫດຜົນທີ່ຈະອອກແບບຊັ້ນຮຽນ ແລະ ບັນດາໂມດູນຕ່າງໆ ອ້ອມຂ້າງໜ້າທີ່ດຽວຄືການຈັດການການຢັ້ງຢືນຕົວຕົນ ຫຼື ການຢັ້ງຢືນຂໍ້ມູນການປ້ອນ. ເມື່ອລະຫັດຍັງຄົງສຸມໃສ່ວຽກງານທີ່ຊັດເຈນ, ການປ່ຽນແປງຈະມີຜົນກະທົບຕໍ່ສ່ວນນ້ອຍໆຂອງລະບົບ. ຕົວຢ່າງ, ເມື່ອພວກເຮົາປັບປຸງຂໍ້ກຳນົດລະຫັດຜ່ານ, ມັນກໍຈະບໍ່ໄປລົບກວນວິທີການສະແດງໂປຣໄຟລ໌ຜູ້ໃຊ້ງານໃນໜ້າຈໍ. ທີມງານທີ່ເຮັດວຽກແບບນີ້ມັກຈະໃຊ້ເວລາໜ້ອຍລົງໃນການຕິດຕາມຂໍ້ຜິດພາດຫຼັງຈາກການປ່ຽນແປງ, ແລະ ອາດຈະຫຼຸດຄວາມພະຍາຍາມໃນການກວດສອບຂໍ້ຜິດພາດລົງໄດ້ປະມານ 30 ຫາ 50 ເປີເຊັນ. ພວກເຂົາຍັງພົບບັນຫາໜ້ອຍລົງປະມານ 40% ໃນການປັບປຸງຄຸນລັກສະນະ, ເນື່ອງຈາກການປັບປຸງຕ່າງໆຈະບໍ່ລາມໄປທົ່ວບັນດາສ່ວນຕ່າງໆຂອງຖານຂໍ້ມູນລະຫັດ. ບໍ່ເລວເລີຍສຳລັບສິ່ງໜຶ່ງທີ່ເບິ່ງຄືວ່າງ່າຍດາຍໃນແງ່ມຸມມອງຄັ້ງທຳອິດ.
ຕາມຫຼັກການເປີດ/ປິດ, ສ່ວນປະກອບຂອງຊອບແວຄວນຈະເປີດໃນການຂະຫຍາຍຄວາມສາມາດຂອງມັນ, ແຕ່ຄວນປິດເມື່ອຕ້ອງການດັດແປງ. ວິທີນີ້ຈະເຮັດໄດ້ດີທີ່ສຸດເມື່ອພວກເຮົານຳໃຊ້ການດຶງຄວາມດູດຊັບລະຫວ່າງສ່ວນຕ່າງໆຂອງລະບົບ. ເມື່ອຮ່ວມກັບຫຼັກການຍ້ອນຄວາມພິກຂອງການຂຶ້ນກັບ, ໂດຍທີ່ໂມດູນຂັ້ນສູງຂຶ້ນກັບອິນເຕີເຟດທີ່ເປັນດູດຊັບແທນທີ່ຈະເປັນລາຍລະອຽດການຈັດຕັ້ງປະຕິບັດ, ນັກພັດທະນາສາມາດເພີ່ມຄຸນສົມບັດໃຫມ່ໄດ້ໂດຍບໍ່ທຳລາຍສິ່ງທີ່ມີຢູ່ແລ້ວ. ໃຫ້ຖືການຈ່າຍເງິນເປັນຕົວຢ່າງ. ໂດຍການສ້າງອິນເຕີເຟດ IPaymentGateway, ທີມງານສາມາດເພີ່ມການສະຫນັບສະຫນູນສະກຸນເງິນຄິບໂທຣະດຽວໄດ້ງ່າຍໂດຍບໍ່ຕ້ອງໄປແຕະລະຫັດທີ່ມີຢູ່ສຳລັບການດຳເນີນການບັດເຄຣດິດ. ຂໍ້ມູນຈິງຈາກໂລກສະແດງໃຫ້ເຫັນວ່າວິທີການເຫຼົ່ານີ້ຊ່ວຍຫຼຸດເວລາການນຳໃຊ້ຄຸນສົມບັດລົງໄດ້ປະມານເຄິ່ງໜຶ່ງ ຖ້າທຽບກັບວິທີດັ້ງເດີມ. ນອກຈາກນັ້ນ, ມັນຍັງຊ່ວຍຮັກສາເວີຊັ່ນເກົ່າໃຫ້ເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງໃນຂະນະທີ່ອະນຸຍາດໃຫ້ທີມງານທົດສອບຄຸນສົມບັດໃໝ່ຢ່າງປອດໄພ. ຄວາມໝັ້ນຄົງຂອງຄວາມສາມາດພື້ນຖານກາຍເປັນຂໍ້ດີໃຫຍ່ໃນຂະນະທີ່ທົດລອງເຫຼົ່ານີ້ ເນື່ອງຈາກບໍ່ມີສິ່ງໃດທີ່ເປັນພື້ນຖານຖືກລົບລ້າງໃນຂະບວນການ.
ການແຍກລະບົບທີ່ສັບຊ້ອນອອກເປັນສ່ວນຕ່າງໆ ໂດຍມີຂອບເຂດທີ່ຊັດເຈນ ຊ່ວຍໃຫ້ສາມາດທົດສອບ ແລະ ຕິດຕັ້ງແຕ່ລະສ່ວນໄດ້ຢ່າງອິດສະຫຼະ. ຄວາມຈິງທີ່ວ່າ ແຕ່ລະໂມດູນເຫຼົ່ານີ້ເຮັດວຽກໄດ້ດ້ວຍຕົນເອງ ເຮັດໃຫ້ທີມພັດທະນາສາມາດດຳເນີນການທົດສອບເພື່ອສິ່ງທີ່ຕ້ອງການເທົ່ານັ້ນ, ສົ່ງການປັບປຸງອອກໄປໂດຍບໍ່ຈຳເປັນຕ້ອງສ້າງທຸກຢ່າງຂຶ້ນໃໝ່, ແລະ ຫຼຸດຜ່ອນບັນຫາເວລາມີການປ່ຽນແປງ. ຕາມຂໍ້ມູນອຸດສາຫະກຳລ່າສຸດຈາກປີ 2023, ວິທີການນີ້ຊ່ວຍຫຼຸດຜ່ອນບັນຫາການກັບຄືນໄປເກົ່າ (regression) ໄດ້ປະມານເຄິ່ງໜຶ່ງ. ກົດລະບຽບການສື່ສານມາດຕະຖານລະຫວ່າງໂມດູນຕ່າງໆ ຊ່ວຍເຮັດໃຫ້ການເຮັດວຽກຄູ່ຄົງກັນໄປໄວ. ນອກຈາກນັ້ນ, ເມື່ອມີບັນຫາເກີດຂຶ້ນໃນສ່ວນໜຶ່ງຂອງລະບົບ, ຂໍ້ຜິດພາດເຫຼົ່ານັ້ນກໍ່ຈະບໍ່ແຜ່ກະຈາຍໄປທົ່ວທຸກບ່ອນຄືກັບທີ່ເຄີຍເປັນມາໃນສະຖາປັດຕະຍະກຳເກົ່າ.
ການຫຸ້ມຫໍ່ເຮັດວຽກໂດຍການຮັກສາສະພາບການໃນຕົວໃຫ້ປອດໄພຈາກການລ່ວງລີ້ນຈາກພາຍນອກ, ໂດຍພື້ນຖານແລ້ວແມ່ນການປິດບັງສິ່ງທີ່ບໍ່ຄວນຖືກຍຸ້ງຍົກ, ໃນຂະນະທີ່ສະແດງໃຫ້ເຫັນພຽງແຕ່ສິ່ງທີ່ຈຳເປັນຕ້ອງເຂົ້າເຖິງ. ການດຶງຄວາມໝາຍທົ່ວໄປໄປນຳກັນກັບວິທີການນີ້, ເຮັດໃຫ້ນັກພັດທະນາສາມາດອະທິບາຍຂະບວນການທີ່ຊັບຊ້ອນໂດຍໃຊ້ກົດລະບຽບງ່າຍໆ ແລະ ສອດຄ່ອງທີ່ບໍ່ປ່ຽນແປງເມື່ອສິ່ງຕ່າງໆພາຍໃນຖືກປັບປຸງ. ການປະສົມປະສານນີ້ມີຜົນກະທົບຢ່າງໃຫຍ່ຫຼວງ, ເຊິ່ງຫຼຸດຜ່ອນການປ່ຽນແປງອິນເຕີເຟດທີ່ລົບກວນລົງໄດ້ປະມານ 40% ຕາມການສຶກສາໃໝ່ໆໃນດ້ານວິສະວະກຳລະບົບ (2024). ນີ້ໝາຍຄວາມວ່າຊອບແວສາມາດເຕີບໂຕ ແລະ ພັດທະນາໄປຕາມເວລາໂດຍບໍ່ຈຳເປັນຕ້ອງໃຫ້ຜູ້ໃຊ້ທັງໝົດຕ້ອງຂຽນລະຫັດຂອງເຂົາເຈົ້າໃໝ່ຢູ່ສະເໝີ, ເຊິ່ງເປັນສິ່ງສຳຄັນຫຼາຍສຳລັບໂຄງການທີ່ດຳເນີນໄປໃນໄລຍະຍາວ ເຊິ່ງຄວາມເຂົ້າກັນໄດ້ກັບລະບົບເກົ່າມີຄວາມໝາຍ.
ການອອກແບບແລະວິສະວະກໍາຊອບແວທີ່ດີຂຶ້ນຢູ່ກັບສາມສິ່ງຫຼັກໆ ທີ່ເຮັດວຽກຮ່ວມກັນ: ຄວາມໜ້າເຊື່ອຖືໄດ້, ປະສິດທິພາບ, ແລະ ການນຳໃຊ້ຊັບພະຍາກອນໃຫ້ມີປະສິດທິຜົນສູງສຸດ. ໃນເງື່ອນໄຂຄວາມໜ້າເຊື່ອຖືໄດ້, ລະບົບຈຳເປັນຕ້ອງສາມາດດຳເນີນການໄດ້ຢ່າງລຽບງ່າຍ ເຖິງແມ່ນວ່າຈະເກີດບັນຫາຂຶ້ນມາ. ນັ້ນໝາຍຄວາມວ່າຈຳເປັນຕ້ອງມີແຜນສຳຮອງ, ເຊັ່ນ: ສ່ວນປະກອບທີ່ຊ່ວຍສຳຮອງກັນ ຫຼື ການປ່ຽນເສັ້ນທາງໂດຍອັດຕະໂນມັດໄປສູ່ເສັ້ນທາງທາງເລືອກ. ປະສິດທິພາບກ່ຽວຂ້ອງກັບການຮັກສາໃຫ້ລະບົບຕອບສະໜອງໄດ້ດີໃນເວລາທີ່ມີຜູ້ໃຊ້ງານຫຼາຍຄົນໃນຂະນະດຽວກັນ. ການເລືອກຂະບວນການທີ່ມີປະສິດທິພາບ ແລະ ການດຳເນີນການແບບບໍ່ແຂ່ງຂັນ (async) ຊ່ວຍໃນເລື່ອງນີ້. ການນຳໃຊ້ຊັບພະຍາກອນຢ່າງມີປະສິດທິພາບກໍສຳຄັນເຊັ່ນດຽວກັນ ເພາະບໍ່ມີໃຜຢາກໃຫ້ມີການສູນເສຍພະລັງງານການຄຳນວນ. ການຈັດການໜ່ວຍຄວາມຈຳທີ່ດີ ແລະ ລະຫັດທີ່ບໍ່ໄດ້ກິນພະລັງງານໂດຍບໍ່ຈຳເປັນ ສາມາດເຮັດໃຫ້ເກີດຄວາມແຕກຕ່າງຢ່າງໃຫຍ່ຫຼວງ. ການນຳເອົາອົງປະກອບເຫຼົ່ານີ້ມາຮວມກັນສາມາດຊ່ວຍຫຼຸດຜ່ອນການລົງລະບົບໄດ້ປະມານ 70 ເປີເຊັນ ແລະ ປະຢັດຄ່າໃຊ້ຈ່າຍໃນເຄື່ອງແມ່ຂ່າຍ ແລະ ບໍລິການຄັງຄັ້ງ. ຜູ້ໃຊ້ຈະໄດ້ຮັບປະສົບການທີ່ດີຂຶ້ນໂດຍລວມ, ເຖິງແມ່ນວ່າຈະມີການເພີ່ມຂຶ້ນຢ່າງທັນທີຂອງການຈະລາຈອນ ຫຼື ສ່ວນໜຶ່ງຂອງລະບົບເລີ່ມມີບັນຫາ. ນັກພັດທະນາທີ່ຄິດໄລ່ລ່ວງໜ້າກ່ຽວກັບບັນຫາທີ່ອາດເກີດຂຶ້ນ ແລະ ວິທີການທີ່ລະຫັດຂອງເຂົາເຈົ້າມີການຕຳໜິຕໍ່ກັບສະພາບແວດລ້ອມຕ່າງໆ ມັກຈະສ້າງແອັບຯທີ່ສາມາດຢູ່ລອດໄດ້ຕໍ່ສິ່ງທີ່ໂລກຈິງຈະມາທຳລາຍໃນແຕ່ລະມື້.
DRY, ຫຼື Don't Repeat Yourself, ຊ່ວຍຫຼຸດຜ່ອນການຂຽນລະຫັດຊ້ໍາກັນໂດຍການສ້າງຈຸດສູນກາງສໍາລັບຟັງຊັ່ນທີ່ນິຍົມ. ການສຶກສາສະແດງໃຫ້ເຫັນວ່າສິ່ງນີ້ສາມາດຫຼຸດຜ່ອນວຽກງານຮັກສາລະບົບໄດ້ປະມານ 40% ໃນຂະນະທີ່ເບິ່ງໃນລະຫັດຂະໜາດໃຫຍ່. ຕໍ່ມາກໍ່ມີ KISS, Keep It Simple Stupid, ທີ່ຂັດຂວາງການເຮັດໃຫ້ສິ່ງຕ່າງໆຊັບຊ້ອນ. ມັນສົ່ງເສີມການແກ້ໄຂທີ່ງ່າຍດາຍ ແລະ ສາມາດເຂົ້າໃຈ ແລະ ແກ້ໄຂໄດ້ງ່າຍເວລາເກີດບັນຫາ. ສະມາຊິກທີມໃໝ່ກໍ່ສາມາດເຂົ້າໃຈໄດ້ໄວຂຶ້ນ. ເມື່ອຫຼັກການທັງສອງນີ້ເຮັດວຽກຮ່ວມກັນ, ພວກມັນຈະສ້າງເປັນດັ່ງກ່ານປ້ອງກັນທາງຈິດໃຫ້ແກ່ນັກພັດທະນາ. ແທນທີ່ຈະເສຍເວລາຫຼາຍຊົ່ວໂມງໃນການພະຍາຍາມເຂົ້າໃຈວ່າຄົນອື່ນຂຽນຫຍັງ, ນັກຂຽນລະຫັດສາມາດສຸມໃສ່ການສ້າງຄຸນສົມບັດທີ່ໜ້າເຊື່ອຖື ແລະ ສິ່ງທີ່ຄົນຕ້ອງການແທ້ໆ. ວິທີການນີ້ເຮັດໃຫ້ໂຄງການຊອບແວຢູ່ໄດ້ດົນຂຶ້ນ ແລະ ສາມາດຄວບຄຸມຄ່າໃຊ້ຈ່າຍໄດ້ຕະຫຼອດໄລຍະເວລາ.
EN