ຊິຟທ໌ເລັຟທ໌ (Shift Left)

ເມື່ອສະແດງ workflow ການພັດທະນາຊອບແວເປັນເສັ້ນເວລາຈາກຊ້າຍໄປຂວາ, ແນວຄິດຂອງ shift-left ຄືການຍ້າຍວຽກງານການກວດສອບທີ່ເຄີຍເຮັດລວມກັນກ່ອນ release (ຝັ່ງຂວາ) ໄປໄວ້ໃນຂັ້ນຕອນການອອກແບບ ແລະ coding (ຝັ່ງຊ້າຍ).

ແນວຄິດນີ້ມາຈາກໃສ

ເດີມທີແນວຄິດນີ້ແຜ່ຫຼາຍໃນບໍລິບົດຂອງ DevOps ແລະ agile development. ໃນການພັດທະນາແບບ waterfall, ການທົດສອບຈະຖືກດຳເນີນການເປັນ phase ແຍກຕ່າງຫາກຫຼັງຈາກ coding ສຳເລັດ. ແຕ່ຍິ່ງການຄົ້ນພົບ bug ຊ້າລົງເທົ່າໃດ, ຄ່າໃຊ້ຈ່າຍໃນການແກ້ໄຂກໍຈະຂະຫຍາຍຕົວຢ່າງ exponential. ສິ່ງທີ່ຫາກຄົ້ນພົບໃນຂັ້ນຕອນການອອກແບບສາມາດແກ້ໄຂໄດ້ດ້ວຍການປັບ specification, ແຕ່ຫາກຄົ້ນພົບໃນ integration test ກໍຈະເກີດການ rework ຫຼາຍ module. Shift-left ຄືການນຳເອົາຫຼັກການທີ່ໄດ້ຮຽນຮູ້ຈາກປະສົບການນີ້ໄປຝັງໄວ້ໃນໂຄງສ້າງຂອງອົງກອນ.

ການປະຕິບັດຢ່າງລະອຽດ

Shift-left ບໍ່ແມ່ນເລື່ອງຂອງການທົດສອບເທົ່ານັ້ນ. ໃນບໍລິບົດຂອງ security, ມັນໄດ້ພັດທະນາໄປເປັນ DevSecOps ໃນຮູບແບບການປະຕິບັດ "ການທຳ threat modeling ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ", ແລະໃນບໍລິບົດຂອງການຮັບປະກັນຄຸນນະພາບ, ມັນຖືກ implement ເປັນ CI pipeline ທີ່ "ດຳເນີນການ static analysis ແລະ unit test ໂດຍອັດຕະໂນມັດໃນທຸກ PR". ການໃຊ້ pre-commit hook ເພື່ອລັນ formatter ແລະ linter ກໍຈັດຢູ່ໃນ shift-left ໃນຄວາມໝາຍທີ່ກວ້າງຂຶ້ນ.

ໃນການພັດທະນາ AI agent ກໍໃຊ້ຫຼັກການດຽວກັນ. ໃນ harness engineering, ແທນທີ່ຈະ review output ຂອງ agent ຫຼັງຈາກນັ້ນ, ຈະສ້າງສະພາວະທີ່ "ບໍ່ສາມາດ commit ການປ່ຽນແປງທີ່ຜິດພາດໄດ້ຕັ້ງແຕ່ຕົ້ນ" ດ້ວຍ linter ແລະ type check. ຍິ່ງຍ້າຍຈັງຫວະການກວດຈັບໄປທາງຊ້າຍຫຼາຍເທົ່າໃດ, ຄ່າໃຊ້ຈ່າຍໃນການແຊກແຊງຂອງມະນຸດກໍຍິ່ງຫຼຸດລົງ.