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

ອັນດັບສາມ - Microsoft C compiler

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

ຮອດເວລາທີ່ຂ້ອຍຈົບປີ 86 ຢູ່ທີ່ MIT, ຂ້ອຍຍັງໜຸ່ມ ແລະບໍ່ມີປະສົບການ, ທັງໃນຊີວິດ ແລະການຂຽນໂປຣແກຣມ. ໃນຊ່ວງລຶະເບິ່ງຮ້ອນ, ຂ້ອຍໄດ້ຝຶກງານຢູ່ Microsoft, ໃນທີມ C compiler, ໃນຕອນທໍາອິດຂ້ອຍເຮັດສິ່ງທີ່ປົກກະຕິເຊັ່ນການສະຫນັບສະຫນູນ profile, ແລະຫຼັງຈາກນັ້ນຂ້ອຍໄດ້ຮັບຄວາມໄວ້ວາງໃຈໃນການເຮັດວຽກໃນສ່ວນທີ່ມ່ວນທີ່ສຸດຂອງ compiler (ຕາມທີ່ຂ້ອຍຄິດ) - backend optimization . ໂດຍສະເພາະ, ຂ້ອຍຕ້ອງປັບປຸງລະຫັດ xXNUMX ສໍາລັບລາຍງານສາຂາ.

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

ມັນເປັນຝັນຮ້າຍ. ຫຼາຍປີຕໍ່ມາຂ້ອຍໄດ້ຖືກບອກວ່າຜູ້ຂຽນໂປລແກລມຜູ້ສືບທອດລະຫັດຂອງຂ້ອຍກຽດຊັງຂ້ອຍ.

ບົດຮຽນທີ່ຖອດຖອນໄດ້

ດັ່ງທີ່ David Patterson ແລະ John Hennessy ຂຽນໃນ Computer Architecture and Computer Systems Design, ຫນຶ່ງໃນຫຼັກການຕົ້ນຕໍຂອງສະຖາປັດຕະຍະກໍາແລະການອອກແບບແມ່ນເພື່ອເຮັດໃຫ້ສິ່ງຕ່າງໆເຮັດວຽກໄວເທົ່າທີ່ຈະໄວໄດ້.

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

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

ຂ້ອຍຈໍາເປັນຕ້ອງໂທຫານັກພັດທະນາທີ່ມີປະສົບການແລະພ້ອມກັບລາວ, ຄິດກ່ຽວກັບກໍລະນີທົ່ວໄປແລະຈັດການກັບພວກມັນໂດຍສະເພາະ. ຂ້ອຍຈະຂຽນລະຫັດຫນ້ອຍ, ແຕ່ນັ້ນແມ່ນສິ່ງທີ່ດີ. ດັ່ງທີ່ຜູ້ກໍ່ຕັ້ງ Stack Overflow Jeff Atwood ຂຽນ, ສັດຕູທີ່ຮ້າຍແຮງທີ່ສຸດຂອງຜູ້ຂຽນໂປລແກລມແມ່ນນັກຂຽນໂປລແກລມເອງ:

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

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

ສະຖານທີ່ທີສອງ: ການໂຄສະນາໃນເຄືອຂ່າຍສັງຄົມ

ເມື່ອຂ້ອຍເຮັດວຽກຢູ່ Google ໃນການໂຄສະນາສື່ມວນຊົນສັງຄົມ (ຈື່ Myspace?), ຂ້ອຍຂຽນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້ໃນ C ++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

ບົດຮຽນທີ່ຖອດຖອນໄດ້

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

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

ນັ້ນແມ່ນສິ່ງທີ່ ບອກ ກ່ຽວກັບ Thomas Watson, ຫົວຫນ້າ legendary ຂອງ IBM:

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

Watson ຖາມສິ່ງທີ່ຜິດພາດ.

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

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

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

ສະຖານທີ່ທໍາອິດ: App Inventor API

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

ຮ້າຍ​ແຮງ​ກວ່າ​ທີ່​ດີກ​ວ່າ

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

ມັນຄວນຈະເປັນແນວໃດ: ການອອກແບບຄວນຈະງ່າຍດາຍໃນການປະຕິບັດແລະການໂຕ້ຕອບ. ຄວາມງ່າຍດາຍຂອງການໂຕ້ຕອບແມ່ນມີຄວາມສໍາຄັນຫຼາຍກ່ວາຄວາມງ່າຍດາຍຂອງການປະຕິບັດ.

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

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

ຜູ້ປະດິດແອັບ

ໃນຂະນະທີ່ເຮັດວຽກຢູ່ Google, ຂ້ອຍເປັນສ່ວນຫນຶ່ງຂອງທີມງານ ຜູ້ປະດິດແອັບ, ສະພາບແວດລ້ອມການພັດທະນາອອນໄລນ໌ແບບລາກແລ້ວວາງໄວ້ສໍາລັບຜູ້ພັດທະນາ Android ທີ່ຕ້ອງການ. ມັນແມ່ນປີ 2009, ແລະພວກເຮົາຮີບຮ້ອນທີ່ຈະປ່ອຍເວີຊັນອັນຟາໃຫ້ທັນເວລາເພື່ອວ່າໃນລະດູຮ້ອນພວກເຮົາສາມາດຈັດຫ້ອງຮຽນແມ່ບົດສໍາລັບຄູສອນຜູ້ທີ່ສາມາດນໍາໃຊ້ສະພາບແວດລ້ອມໃນເວລາສອນໃນລະດູໃບໄມ້ປົ່ງ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ອາ​ສາ​ສະ​ຫມັກ​ເພື່ອ​ປະ​ຕິ​ບັດ sprites​, nostalgic ສໍາ​ລັບ​ວິ​ທີ​ການ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໃຊ້​ໃນ​ການ​ຂຽນ​ເກມ​ໃນ TI-99/4​. ສໍາລັບຜູ້ທີ່ບໍ່ຮູ້, sprite ແມ່ນວັດຖຸກາຟິກສອງມິຕິທີ່ສາມາດເຄື່ອນຍ້າຍແລະພົວພັນກັບອົງປະກອບຊອບແວອື່ນໆ. ຕົວຢ່າງຂອງ sprites ປະກອບມີຍານອະວະກາດ, ດາວເຄາະນ້ອຍ, marbles, ແລະ rackets.

ພວກເຮົາໄດ້ປະຕິບັດ App Inventor ຮັດກຸມວັດຖຸໃນ Java, ສະນັ້ນມີພຽງແຕ່ຊໍ່ຂອງວັດຖຸຢູ່ໃນນັ້ນ. ນັບຕັ້ງແຕ່ບານແລະ sprites ປະຕິບັດຕົວຄ້າຍຄືກັນຫຼາຍ, ຂ້າພະເຈົ້າໄດ້ສ້າງຫ້ອງຮຽນ sprite abstract ທີ່ມີຄຸນສົມບັດ (ພາກສະຫນາມ) X, Y, ຄວາມໄວ (ຄວາມໄວ) ແລະຫົວ (ທິດທາງ). ພວກເຂົາເຈົ້າມີວິທີການດຽວກັນໃນການກວດສອບການ collision, bouncing ອອກຂອບຂອງຫນ້າຈໍ, ແລະອື່ນໆ.

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

ເມື່ອ sprites ໄດ້ເຮັດວຽກ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈວ່າຂ້າພະເຈົ້າສາມາດປະຕິບັດວັດຖຸບານທີ່ມີລະຫັດຫນ້ອຍຫຼາຍ. ບັນຫາພຽງແຕ່ວ່າຂ້ອຍເອົາເສັ້ນທາງທີ່ງ່າຍດາຍທີ່ສຸດ (ຈາກທັດສະນະຂອງຜູ້ປະຕິບັດ), ຊີ້ໃຫ້ເຫັນຈຸດປະສານງານ x- ແລະ y ຂອງມຸມຊ້າຍເທິງຂອງ contour framing ບານ.

ໃນຄວາມເປັນຈິງ, ມັນຈໍາເປັນຕ້ອງຊີ້ບອກ x- ແລະ y-coordinates ຂອງສູນກາງຂອງວົງມົນ, ຕາມທີ່ສອນໃນປື້ມຮຽນຄະນິດສາດແລະແຫຼ່ງອື່ນໆທີ່ກ່າວເຖິງວົງ.

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

ໃນ​ທີ່​ສຸດ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້ patched bug ນີ້​ພຽງ​ແຕ່​ບໍ່​ດົນ​ມາ​ນີ້, ສິບ​ປີ​ຕໍ່​ມາ. "Patched", ບໍ່ແມ່ນ "ແກ້ໄຂ", ເນື່ອງຈາກວ່າ Joshua Bloch ເວົ້າວ່າ, APIs ແມ່ນຕະຫຼອດໄປ. ບໍ່ສາມາດເຮັດການປ່ຽນແປງທີ່ຈະສົ່ງຜົນກະທົບຕໍ່ໂປຼແກຼມທີ່ມີຢູ່ແລ້ວ, ພວກເຮົາໄດ້ເພີ່ມຄຸນສົມບັດ OriginAtCenter ທີ່ມີຄ່າ false ໃນໂປຼແກຼມເກົ່າແລະເປັນຄວາມຈິງໃນອະນາຄົດທັງຫມົດ. ຜູ້​ໃຊ້​ອາດ​ຈະ​ຖາມ​ຄໍາ​ຖາມ​ທີ່​ມີ​ເຫດ​ຜົນ​: ຜູ້​ທີ່​ເຖິງ​ແມ່ນ​ວ່າ​ຄິດ​ຂອງ​ການ​ວາງ​ຈຸດ​ເລີ່ມ​ຕົ້ນ​ຢູ່​ບ່ອນ​ອື່ນ​ນອກ​ຈາກ​ສູນ​ກາງ​. ເຖິງ​ໃຜ? ສໍາລັບນັກຂຽນໂປລແກລມຄົນຫນຶ່ງທີ່ຂີ້ຄ້ານທີ່ຈະສ້າງ API ປົກກະຕິເມື່ອສິບປີກ່ອນ.

ຖອດ​ຖອນ​ບົດ​ຮຽນ

ໃນເວລາທີ່ເຮັດວຽກກ່ຽວກັບ APIs (ເຊິ່ງເກືອບທຸກນັກຂຽນໂປລແກລມຕ້ອງເຮັດບາງຄັ້ງ), ທ່ານຄວນປະຕິບັດຕາມຄໍາແນະນໍາທີ່ດີທີ່ສຸດທີ່ໄດ້ລະບຸໄວ້ໃນວິດີໂອຂອງ Joshua Bloch "ວິທີການສ້າງ API ທີ່ດີແລະເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ"ຫຼື ໃນບັນຊີລາຍຊື່ສັ້ນນີ້:

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

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

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

ສະຫລຸບ

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

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

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