ເນື້ອຫາ
- 01. ລະຫັດບໍ່ຕັດມັນອີກຕໍ່ໄປ
- ຄວາມກວ້າງແລະຄວາມເລິກ
- 02. ການອະນາໄມໃຫຍ່
- 03. ສິ່ງທີ່ອິນເຕີເນັດເວົ້າ
- ເຂົ້າໃຈສື່ກາງ
- 04. ສິ່ງທີ່ເຮົາສ້າງດ້ວຍ
- 05. ຜີສາດ
- ເຂົ້າໃຈຂັ້ນໄດ
- ວຽກທີ່ລຶກລັບ
- ເຄື່ອງມືທີ່ມີປະໂຫຍດ
- 06. ຈະແກ້ໄຂມັນ ... ບາງທີ
- ການແກ້ໄຂ
- 07. ສິ່ງທີ່ຜູ້ໃຊ້ຕ້ອງການ
- ຕະຫຼາດແຂ່ງຂັນ
- 08. ການແຕ້ມແລະການຂຽນ
- 09. ເພີດເພີນກັບຕົວທ່ານເອງ
- 10. ມີຄວາມຄົມຊັດ
- ມັກນີ້ບໍ? ອ່ານເຫຼົ່ານີ້!
ນັກພັດທະນາ ຈຳ ເປັນຕ້ອງມີຫຼາຍກວ່າພະນັກງານທີ່ສ້າງລະຫັດ. ພວກເຮົາຄາດຫວັງວ່າຊີວິດດິຈິຕອນຂອງພວກເຮົາຈະມີຫຼາຍຂື້ນແລະມັນແມ່ນຄົນພວກນີ້ທີ່ສ້າງມັນ, ດັ່ງນັ້ນສິ່ງທີ່ດີທີ່ສຸດຕ້ອງຮູ້ຫຍັງແດ່? ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍເຫັນວ່າຂາດຈາກນັກພັດທະນາຫລາຍເກີນໄປ. ນີ້ບໍ່ແມ່ນສິ່ງທີ່ເກີນໄປແຕ່ມັນແມ່ນຄຸນລັກສະນະເຫຼົ່ານີ້ທີ່ເຮັດໃຫ້ນັກໂຄສະນາທີ່ສົມເຫດສົມຜົນກາຍເປັນນັກພັດທະນາທີ່ ໜ້າ ປະຫຼາດໃຈ.
ແຕ່ມັນບໍ່ແມ່ນສິ່ງ ໜຶ່ງ, ແລະໂດຍສະເພາະແມ່ນບໍ່ມີຄວາມສາມາດໃນການແຍກລະຫັດ XML ຫຼືເພີ່ມປະສິດທິພາບລະຫັດ, ມັນແມ່ນຄວາມສາມາດໃນການລວບລວມທີ່ ໜ້າ ປະຫລາດໃຈທີ່ບໍ່ໄດ້ສອນໃນປື້ມກ່ຽວກັບລະຫັດຂຽນ. ພວກເຂົາມີສິ່ງເລັກນ້ອຍພິເສດ.
ເປັນຫຍັງລະບາຍອາກາດແບບນີ້? ເພາະວ່າເລື່ອງການພັດທະນາແຕ່ນັກພັດທະນາມັກຈະຖືກຈັດສັນໃຫ້ໂລກແຕກຕ່າງກັນ, ບໍ່ແມ່ນການເຮັດຂອງພວກເຂົາສະ ເໝີ ໄປ. ນີ້ບໍ່ເຄີຍເຮັດວຽກ. ການພັດທະນາ - ເຕັກນິກຫຍັງກໍ່ຕາມ - ຈະເລີນງອກງາມສະເຫມີເມື່ອຜູ້ທີ່ມີຄວາມຮູ້ຄວາມເຂົ້າໃຈຫຼາຍກ່ວາພຽງແຕ່ລະຫັດ.
01. ລະຫັດບໍ່ຕັດມັນອີກຕໍ່ໄປ
ພວກເຮົາຢູ່ໃນໂລກທີ່ການໃສ່ລະຫັດກາຍເປັນສິ່ງທີ່ ໜ້າ ປະທັບໃຈບໍ່ ໜ້ອຍ. ທຸກໆຄົນກໍ່ສ້າງເວັບໄຊ, ບາງລະຫັດຂອງພວກເຂົາແຕ່ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງເຮັດ. ມັນບໍ່ແມ່ນພຽງແຕ່ເກັ່ງກວ່າຜູ້ທີ່ສາມາດສ້າງເວັບໄຊ, ແອັບແລະຄຸນລັກສະນະຕ່າງໆອີກຕໍ່ໄປ.
ນັບຕັ້ງແຕ່ເວບໄຊທ໌ໄດ້ເຂົ້າມາແລະຜູ້ຄົນສາມາດສອນຕົວເອງໄດ້ມີນັກພັດທະນາທີ່ສອນຕົນເອງ. ແຕ່ເຖິງແມ່ນວ່ານັກຮຽນຈົບແມ່ນຢູ່ພາຍໃຕ້ໄພຂົ່ມຂູ່. ຂ້ອຍໄດ້ຮັບຊີວະປະຫວັດກັບຜູ້ທີ່ມີລະດັບວິທະຍາສາດຄອມພິວເຕີ, ຫຼັກສູດ AI, ສື່ຕ່າງໆແລະລະຫັດຕ່າງໆພາຍໃຕ້ສາຍແອວຂອງພວກເຂົາແຕ່ມັນຍັງມີບາງສິ່ງບາງຢ່າງທີ່ຍັງຂາດຢູ່. ບາງຄັ້ງກໍ່ຫາຍໄປຫຼາຍ.
ຂ້ອຍບໍ່ແມ່ນຜູ້ ທຳ ອິດທີ່ເວົ້າແນວນີ້. 'ລະຫັດບໍ່ຕັດມັນອີກຕໍ່ໄປ' ແມ່ນຫົວຂໍ້ຂອງບົດທີ 3 ຈາກ ນັກຂຽນໂປແກຼມ Passionate, ເຊິ່ງຄຽງຄູ່ກັບປື້ມຕ່າງໆເຊັ່ນ Pragmatic Thinking ແລະການຮຽນຮູ້ ຮຽກຮ້ອງໃຫ້ນັກຂຽນໂປແກຼມປັບປຸງຕົວເອງເກີນລະຫັດ; ກາຍເປັນສະມາຊິກຄົນທີ່ມີຄວາມອົດທົນແລະເປັນມະນຸດຂອງທີມ.
ຄວາມກວ້າງແລະຄວາມເລິກ
ນັກພັດທະນາຕ້ອງດີກວ່າໃນສອງທາງ: ຄວາມກວ້າງແລະຄວາມເລິກ. ພວກເຂົາຕ້ອງເຂົ້າໃຈຄວາມກວ້າງຂອງການພົວພັນຂອງມະນຸດໃນທີມຂອງພວກເຂົາແລະກັບສິ່ງທີ່ພວກເຂົາສ້າງ. ພວກເຂົາ ຈຳ ເປັນຕ້ອງເຂົ້າໃຈເລິກເຊິ່ງຂອງລະບົບທີ່ພວກເຂົາ ກຳ ລັງເຮັດວຽກກັບ, ລົງ O / S.
ແລະມັນບໍ່ແມ່ນພຽງແຕ່ນັກພັດທະນາເທົ່ານັ້ນທີ່ຄວນອ່ານສິ່ງນີ້. ຖ້າທ່ານ ກຳ ລັງເຮັດວຽກກັບ devs, ຂ້ອຍຄິດວ່າເຈົ້າຄວນຄາດຫວັງຈາກພວກມັນຫຼາຍຂື້ນ. ເຮັດໃຫ້ພວກເຂົາແຕ້ມຮູບກ່ຽວກັບສິ່ງທີ່ພວກເຂົາ ກຳ ລັງເວົ້າ. ເຮັດໃຫ້ພວກເຂົາອະທິບາຍດ້ວຍຮູບພາບ, ວັດຖຸແລະ (ມັນໃຊ້ໄດ້) ຕັດອອກຈາກຄົນຢ່າງແນ່ນອນວ່າລະບົບນີ້ຈະເປັນແນວໃດ ສຳ ລັບມະນຸດທີ່ໃຊ້ມັນ.
02. ການອະນາໄມໃຫຍ່
ຂ້ອຍຈະເວົ້າກ່ຽວກັບນັກພັດທະນາໃນທາງລົບ, ແຕ່ຂ້ອຍຄິດວ່າຂ້ອຍໄດ້ຮັບອະນຸຍາດເພາະຂ້ອຍເປັນຜູ້ ໜຶ່ງ. ເຊັ່ນດຽວກັນເພາະວ່າຢ່າງ ໜ້ອຍ ສິ່ງ ໜຶ່ງ ທີ່ຂ້ອຍເວົ້າກ່ຽວກັບນີ້ແມ່ນຄວາມຈິງຂອງນັກພັດທະນາຫຼາຍໆຄົນທີ່ຂ້ອຍພົບ. ເຖິງແມ່ນວ່າວຽກງານຂອງພວກເຂົາດີເລີດແລະພວກເຂົາຮູ້ລະຫັດຂອງພວກເຂົາ, ເວລາກໍ່ຈະແຂ່ງຂັນກັນ. ທ່ານ ຈຳ ເປັນຕ້ອງມີຂອບ, ແລະນີ້ແມ່ນ:
- ຈະ techy ຫຼາຍ
ແລະ
- ເປັນ ຫຼາຍ ມະນຸດຫຼາຍ
03. ສິ່ງທີ່ອິນເຕີເນັດເວົ້າ
Googling ສຳ ລັບ 'ທັກສະການພັດທະນາເວັບທີ່ ຈຳ ເປັນ' ນຳ ເອົາສິ່ງທີ່ທ່ານຄາດຫວັງໄວ້. ຄວາມຮູ້ກ່ຽວກັບກອບ, ຕົວທ່ອງເວັບ x, CSS ແລະ JS. ພວກເຂົາເຈົ້າບອກບັນດາກອບທີ່ທ່ານຄວນຮູ້, ເວທີທີ່ທ່ານຕ້ອງຂຽນແລະແນວໂນ້ມ ໃໝ່ໆ ທີ່ທ່ານຄວນຕິດຕາມເບິ່ງ.
ນີ້ແມ່ນສື່ຂອງພວກເຮົາ. ມັນແມ່ນສິ່ງທີ່ພວກເຮົາສ້າງຂື້ນແຕ່ມັນບໍ່ແມ່ນສິ່ງທີ່ເຮັດໃຫ້ໂຄງການປະສົບຜົນ ສຳ ເລັດ. ນັກພັດທະນາສາມາດເຂົ້າໃຈທຸກລາຍລະອຽດຂອງລະບົບ, ບອກທ່ານທຸກຄຸນສົມບັດຂອງ API ແລະເຕັກໂນໂລຢີ CSS ໃໝ່ ແຕ່ຍັງຜະລິດສິ່ງທີ່ໃຊ້ບໍ່ໄດ້.
ເຂົ້າໃຈສື່ກາງ
ນັກພັດທະນາ, ຄືກັບທຸກຄົນ, ຕ້ອງເຂົ້າໃຈສື່ກາງຂອງພວກເຂົາ - ແຕ່ພວກເຂົາຍັງຕ້ອງເຂົ້າໃຈຜູ້ຊົມ, ຄືຜູ້ໃຊ້, ທີມງານຫລືຜູ້ພັດທະນາຄົນອື່ນ. ພວກເຂົາຕ້ອງເຂົ້າໃຈວ່າສື່ກາງຂອງພວກມັນ ເໝາະ ສົມກັບໂລກແນວໃດ (ເວົ້າອີກຢ່າງ ໜຶ່ງ, ສະພາບແວດລ້ອມການຜະລິດ) ແລະມັນມີຜົນກະທົບແນວໃດ (ຄົນໃຊ້ມັນແນວໃດ).
ຂ້າພະເຈົ້າໄດ້ເຫັນ ຄຳ ອະທິບາຍນີ້ວ່າເປັນບຸກຄົນທີ່ 'ກວ້າງແລະເລິກ'. ກວ້າງ, ເພາະວ່າທ່ານ ຈຳ ເປັນຕ້ອງເຂົ້າໃຈໂລກຄືກັບມະນຸດເຮັດວຽກກັບມະນຸດຄົນອື່ນ. ເລິກເພາະວ່າທ່ານຕ້ອງການຄວາມຮູ້ດ້ານເຕັກນິກຢ່າງລະອຽດຕໍ່າກວ່າລະດັບຂອງໂຄງການຂອງທ່ານ. ນັກພັດທະນາເຫລົ່ານີ້ໃຫ້ໂຄງການຂອງທ່ານມີ ກຳ ລັງໃຈແລະປ່ຽນແປງຈັງຫວະຂອງໂຄງການ, ໂດຍທີ່ທ່ານຈະບໍ່ເຫັນວ່າພະນັກງານວິຊາການທີ່ບໍ່ແມ່ນເຕັກນິກຖືກຂັດຂວາງໃນລາຍລະອຽດທີ່ ໜ້າ ເບື່ອ ໜ່າຍ ທີ່ມາຈາກທີມງານເຕັກໂນໂລຢີ.
04. ສິ່ງທີ່ເຮົາສ້າງດ້ວຍ
ຂ້າພະເຈົ້າບໍ່ດົນມານີ້ໄດ້ຂຽນບັນຊີລາຍຊື່ຂອງທຸກສິ່ງທີ່ພວກເຮົາໃຊ້ໃນການກໍ່ສ້າງສະຖານທີ່, ຈັດການໂຮດຕິ້ງແລະເຮັດສິ່ງຕ່າງໆເພື່ອໃຫ້ຄົນເຂົ້າຮ່ວມສາມາດມີເຕັກໂນໂລຢີຫຼອກລວງເພື່ອຮຽນຮູ້ໃນສອງສາມອາທິດ ທຳ ອິດຂອງພວກເຂົາ. ພວກເຮົາ ກຳ ລັງອ່ານມັນທີ່ອ່ານວ່າປະຊາຊົນຮູ້ສິ່ງເຫຼົ່ານີ້, ສະນັ້ນເພື່ອໃຫ້ການທົດແທນທີ່ເກີດຂື້ນ ໃໝ່ ພວກເຮົາຈະມີລາຍຊື່ທຸກຢ່າງທີ່ພວກເຮົາໃຊ້ໃນແຕ່ລະມື້.
ຂ້າພະເຈົ້າຄາດຫວັງວ່າເຕັກໂນໂລຍີເຄິ່ງ ໜຶ່ງ ແຕ່ສິ້ນສຸດລົງດ້ວຍຫຼາຍຢ່າງ. ບັນຊີລາຍຊື່ນີ້ - 'ສິ່ງທີ່ພວກເຮົາໃຊ້' - ປະກອບມີ CMSes ປົກກະຕິ, ພາສາການຂຽນໂປແກຼມແລະເຕັກໂນໂລຢີ browser, ແຕ່ຍັງມີເຄື່ອງມືຫຼາຍຢ່າງທີ່ທີມງານບໍ່ຈື່ ຈຳ ຕົວເອງໂດຍໃຊ້. ມັນແມ່ນຄວາມຊົງ ຈຳ ຂອງກ້າມເນື້ອທັງ ໝົດ. ການພິມ 'git', 'phing', 'thor' ຢູ່ໃນເສັ້ນ ຄຳ ສັ່ງ, ພວກເຮົາຍັງບໍ່ຄິດວ່າບາງຄົນອາດຈະບໍ່ເຂົ້າໃຈ.
ສ້າງເຄື່ອງມື; CI; git ສຳ ລັບການຄວບຄຸມເວີຊັນແມ່ນຖືກປະຕິບັດ, ແຕ່ຖ້າເບິ່ງຄືນຫລັງກ່ຽວກັບຊີວະປະຫວັດຫຍໍ້ເຫລົ່ານີ້ບໍ່ຄ່ອຍປາກົດ. ຄົນທີ່ມີທ່າອ່ຽງຈະປາກົດຂື້ນ (ແລະມັນເປັນເລື່ອງ ໜ້າ ກຽດຊັງທີ່ຂ້ອຍຄິດວ່າມີອົງການບາງຢ່າງເພີ່ມເຂົາເຈົ້າເຂົ້າໃນ?!) ແຕ່ມັກຈະບໍ່ມີປະສົບການທີ່ແນ່ນອນ.
ເຄື່ອງມືເຫຼົ່ານີ້ແມ່ນມີຄວາມ ສຳ ຄັນ ສຳ ລັບການເລັ່ງການພັດທະນາໂຄງການ, ສະນັ້ນໃຫ້ແນ່ໃຈວ່າທ່ານມີເຄື່ອງມືທີ່ອຸດົມສົມບູນຫຼາຍກວ່າພາສາຂອງທ່ານ, CMS ແລະກອບສອງສາມຢ່າງ. ທ່ານຕ້ອງການການ ນຳ ໃຊ້, ການທົດສອບ, CI, ການຄວບຄຸມເວີຊັນທີ່ເຂັ້ມແຂງ (ເປັນທີມ - ບໍ່ແມ່ນຕົວທ່ານເອງ), ແລະທ່ານຕ້ອງເຂົ້າໃຈແນວຄວາມຄິດຫຼັກຂອງສິ່ງເຫຼົ່ານີ້ແທນທີ່ຈະເປັນພຽງແຕ່ການສອນສອງສາມຢ່າງເທົ່ານັ້ນ.
05. ຜີສາດ
ເຄື່ອງມືແລະເຄັດລັບພິເສດເຫລົ່ານີ້ແມ່ນ ເໝາະ ສົມກັບສິ່ງທີ່ຄົນເອີ້ນວ່າ 'devops'. Devops ບິນໃນໃບຫນ້າຂອງສອງ silos ແບບດັ້ງເດີມ: ການຜະລິດ, ເຊິ່ງເຮັດໃຫ້ສິ່ງທີ່ເຮັດວຽກແລະການພັດທະນາ, ເຊິ່ງເຮັດໃຫ້ສິ່ງໃຫມ່ໆ (ແລະມັກຈະຢຸດສິ່ງທີ່ເຮັດວຽກ). silos ຜົນອອກມາໃນສອງຄ່າຍທີ່ມີຄວາມເຫັນອົກເຫັນໃຈຫນ້ອຍຕໍ່ກັນແລະກັນ.
ນັກພັດທະນາທີ່ບໍ່ມີຄວາມຮູ້ກ່ຽວກັບການຜະລິດສ່ວນຫຼາຍມັກຈະຜະລິດລະຫັດທີ່ບໍ່ ເໝາະ ສົມກັບການຜະລິດ, ໂດຍການ ນຳ ໃຊ້ການຕັ້ງຄ່າຫຼືຄຸນລັກສະນະທີ່ຍັງບໍ່ໄດ້ຢູ່ໃນຊັ້ນຜະລິດ. ຍ້ອນວ່າພວກເຂົາບໍ່ຮູ້ເຖິງບັນຫາຂອງສະພາບແວດລ້ອມການຜະລິດ, ພວກເຂົາລະຫັດເພື່ອເຮັດໃຫ້ຄຸນລັກສະນະສົມບູນຫຼາຍກວ່າທີ່ຈະ ນຳ ໄປຜະລິດ.
ລາຍລະອຽດນ້ອຍໆເຫຼົ່ານີ້ສາມາດສ້າງຄວາມລ່າຊ້າທີ່ເຈັບປວດ, ຍິ່ງເຮັດໃຫ້ມີທ່າອ່ຽງໃນການສົ່ງຕໍ່ການຄຸ້ມຄອງເຊີບເວີໄປຕ່າງປະເທດ.
ເຂົ້າໃຈຂັ້ນໄດ
Devops ແມ່ນພາກສະຫນາມທີ່ກວ້າງຂວາງຢູ່ໃນຕົວຂອງມັນເອງ, ລວມທັງການປະຕິບັດຢ່າງຕໍ່ເນື່ອງແລະອັດຕະໂນມັດຫຼາຍ. ນີ້ແມ່ນບົດສະຫລຸບຄັ້ງໃຫຍ່, ແຕ່ສິ່ງ ສຳ ຄັນທີ່ນັກພັດທະນາຕ້ອງເຂົ້າໃຈແມ່ນຂັ້ນຕອນທີ່ພວກເຂົາ ກຳ ລັງ ດຳ ເນີນຢູ່. ມັນບໍ່ພຽງພໍທີ່ຈະມອບໂອນໃຫ້ຜູ້ເບິ່ງແຍງລະບົບເຊີຟເວີ, ທ່ານຕ້ອງເຂົ້າໃຈຜົນສະທ້ອນຂອງເວທີທີ່ມີໃນລະຫັດຂອງທ່ານ.
ຖ້າທ່ານເຮັດວຽກກ່ຽວກັບ Rails, ອ່ານລະຫັດ Rails ແລະຮູ້ວ່າ Ruby ຖືກປະຕິບັດໂດຍ Apache. ຖ້າທ່ານເຮັດວຽກຢູ່ Java, ຮູ້ກ່ຽວກັບຕົວເລືອກການຕັ້ງຄ່າ. ຖ້າມັນເປັນ Perl ທີ່ທ່ານໃຊ້, ເຂົ້າໃຈວິທີການຕິດຕັ້ງໂມດູນ Perl ແລະ ກຳ ຫນົດຄ່າເຫລົ່ານັ້ນ.
ວຽກທີ່ລຶກລັບ
ບັນຊີລາຍຊື່ ‘ສິ່ງທີ່ພວກເຮົາ ນຳ ໃຊ້’ ມີຫລາຍສິ່ງຫລາຍຢ່າງນີ້, ແລະນັກພັດທະນາທີ່ດີໄດ້ກ້າວກະໂດດເພື່ອເຂົ້າໃຈວິທີການເຮັດວຽກທີ່ລຶກລັບນີ້. ແລະເມື່ອພວກເຂົາໄດ້ຮັບມັນແລ້ວ, ການປະຕິບັດວຽກຕ່າງໆກໍ່ຈະໄວຂຶ້ນ, ວຽກງານຈະຖືກ ນຳ ໃຊ້ຢ່າງຄ່ອງແຄ້ວແລະທຸກຄົນກໍ່ມີຄວາມສຸກກວ່າເກົ່າ.
ການປະຕິບັດຢ່າງຕໍ່ເນື່ອງແລະການປະຕິບັດທີ່ກ່ຽວຂ້ອງຂອງ devops ແມ່ນກາຍເປັນມາດຕະຖານດັ່ງນັ້ນນັກພັດທະນາຫລືບໍລິສັດໃດທີ່ບໍ່ປະຕິບັດສິ່ງນີ້ແມ່ນ ກຳ ນົດຕົນເອງທີ່ຈະຖືກເອົາຊະນະ. ຄົນອື່ນຈະເລີ່ມເຮັດແລະຫຼັງຈາກນັ້ນມັນຈະໄວກວ່າທ່ານ.
ເຄື່ອງມືທີ່ມີປະໂຫຍດ
Googling for 'devops' ຊ່ວຍໃຫ້ທ່ານມີຄວາມຄິດກ່ຽວກັບເຄື່ອງມືທີ່ຄົນພວກນີ້ໃຊ້. ມັນບໍ່ແມ່ນກ່ຽວກັບ PHP ແລະ MySQL, ຫຼື Rails. ມັນແມ່ນກ່ຽວກັບຊອບແວການຈັດສົ່ງແລະການຮັກສາສ່ວນນ້ອຍໆຂອງໂຄງການທີ່ມີຄວາມສ່ຽງ. ພວກເຂົາສຸມໃສ່ການປະຕິບັດ ໜ້າ ທີ່, ການອັດຕະໂນມັດແລະການຮັກສາທໍ່ຈາກຜູ້ພັດທະນາໄປສູ່ສະພາບແວດລ້ອມການຜະລິດທີ່ແລ່ນໄວທີ່ສຸດ.
ທ່ານຈະເຫັນວ່າການພັດທະນາແບບນີ້ເຮັດໃຫ້ທ່ານມີນັກພັດທະນາທີ່ເຮັດວຽກຮ່ວມກັນໄດ້ດີຂື້ນກັບພະແນກແລະບໍລິສັດອື່ນໆ. ຖ້າພວກເຂົາເຮັດວຽກກັບ API ຈາກພາກສ່ວນທີສາມ, ພວກເຂົາຈະເຂົ້າໃຈບັນຫາທີ່ອາດຈະເກີດຂື້ນໃນອີກດ້ານ ໜຶ່ງ. ໃນເວລາທີ່ເຮັດວຽກກັບເຊີຟເວີຍອມຮັບວ່າພວກເຂົາຈະເຂົ້າໃຈສິ່ງທີ່ພວກເຂົາຕ້ອງການຕິດຕັ້ງແລະຮູ້ວິທີທີ່ເວັບໄຊທ໌ຊອບແວຂອງພວກເຂົາຢູ່ໃນເຄື່ອງແມ່ຂ່າຍການຜະລິດ. ປີ້ນກັບກັນຂອງສິ່ງນີ້ສາມາດເຮັດໃຫ້ເຈັບປວດ ...
06. ຈະແກ້ໄຂມັນ ... ບາງທີ
ການຄົ້ນຫາ ສຳ ລັບ 'ທັກສະການພັດທະນາເວັບທີ່ ສຳ ຄັນ' ນຳ ເອົາ ຄຳ ຕອບທີ່ດີຈາກ Michael Greer (The Onion's CTO) ໃນ Quora:
- ຄວາມຫິວໂຫຍ: ປະຕິເສດທີ່ຈະເຮັດຫຍັງສອງຄັ້ງ: ຂຽນຄິບຫລືງັດແງະ.
- ຄວາມຂີ້ຕົວະ: ຄິດທີ່ຈະທົດສອບ, ກັງວົນກ່ຽວກັບຜົນກະທົບຂອງການໂຫຼດແລະລະຫັດ
- Recklessness: ທົນກັບສິ່ງ ໃໝ່ໆ ຢູ່ສະ ເໝີ, ເປີດຕົວແນວຄິດໃນມື້ດຽວກັນ
Cowardice ແມ່ນວິທີທີ່ດີຂອງການ phrasing 'ເອົາໃຈໃສ່ກັບລາຍລະອຽດ'. ການແກ້ໄຂບັນຫາແລະການທົດສອບແມ່ນ 99 ເປີເຊັນຂອງຊີວິດຂອງນັກພັດທະນາທີ່ບໍ່ມີໃຜກ່າວເຖິງໃນເວລາທີ່ພວກເຂົາຕີໂຮງຮຽນ W3Schools ຫຼືເລີ່ມຕົ້ນການສອນຄອມພິວເຕີ້ 101.
ຄວາມສາມາດໃນການແກ້ໄຂແອັບ requires ຮຽກຮ້ອງໃຫ້ມີທັກສະໃນການແກ້ໄຂບັນຫາທີ່ດີເລີດ, ແຕ່ບໍ່ພຽງແຕ່ລະຫັດ debugging ເທົ່ານັ້ນ. ບາງຄັ້ງການແກ້ໄຂບັນຫາໃຫ້ຜູ້ໃຊ້ທີ່ບໍ່ສາມາດດາວໂຫລດໃບແຈ້ງ ໜີ້ ຂອງພວກເຂົາແມ່ນເພື່ອເຮັດໃຫ້ ໜ້າ ເວັບສາມາດພິມອອກໄດ້, ແທນທີ່ຈະໃຊ້ເວລາໃນການສ້າງເອກະສານ PDF. ບາງຄັ້ງການເຊື່ອມຕໍ່ສາມາດທົດແທນການພັດທະນາໃນອາທິດ ໜຶ່ງ, ແຕ່ວ່າການແກ້ໄຂທີ່ສະຫງ່າງາມຈະບໍ່ເກີດຂື້ນຖ້າ devs ກຳ ລັງແກ້ໄຂບັນຫາຢ່າງດຽວໂດຍການຂຽນລະຫັດຫຼາຍໆເສັ້ນ.
ການທົດສອບແມ່ນ blindspot ທີ່ປະເສີດ ສຳ ລັບຫລາຍໆ devs, ເຖິງວ່າຈະມີເຄື່ອງມືຫລາຍຢ່າງຢູ່ທີ່ນັ້ນ. ໃຊ້ຫົວ ໜ່ວຍ ທົດສອບ, ເຊເລນຽມ, ທົດສອບການໂຫຼດແລະເຄື່ອງມື profiling ເຊັ່ນ xhprof. ການວິເຄາະຈາກສິ່ງຕ່າງໆເຊັ່ນ New Relic ເພື່ອເຮັດໃຫ້ຮອຍຂອງແອັບ app ຂອງທ່ານນ້ອຍ. ແລະພິຈາລະນາທຸກພາກສ່ວນຂອງວຽກງານ: ມັນແມ່ນລະຫັດຂອງທ່ານ, ໃຫ້ແນ່ໃຈວ່າທ່ານຮູ້ວ່າມັນເຮັດວຽກໄດ້ຕາມຈຸດປະສົງຫຼາຍກວ່າຄວາມຫວັງ.
ການແກ້ໄຂ
Debugging ແມ່ນຈຸດເຈັບປວດເຊັ່ນດຽວກັນ. ບໍ່ແມ່ນວິທີການໃຊ້ໂປແກມ debugger, ແຕ່ວິທີການແກ້ໄຂບັນຫາ - ດັ່ງນັ້ນຂ້ອຍຈະເພີ່ມເຂົ້າໃນລາຍຊື່ຂອງ Michael Greer:
- ຄວາມບໍ່ອົດທົນ: ການລະເລີຍຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງເພື່ອຊອກຫາແລະແກ້ໄຂບັນຫາທີ່ແທ້ຈິງ
ນີ້ແມ່ນພື້ນຖານຂອງເຕັກນິກການແກ້ໄຂບັນຫາທັງ ໝົດ. ການບໍ່ສົນໃຈເລື່ອງທີ່ບໍ່ກ່ຽວຂ້ອງແລະຊອກຫາຄວາມ ໝາຍ ທີ່ກ່ຽວຂ້ອງ. ແຕ່ໂຊກບໍ່ດີ, ຫຼາຍໆຄົນມັກຈະຄ່ອຍໆຕີຄ້ອນທີ່ບໍ່ກ່ຽວຂ້ອງເປັນເວລາຫລາຍຊົ່ວໂມງຫລືມື້, ແກ້ໄຂບັນຫາໂດຍການທົດລອງໃຊ້ດຽວກັນ 10 ຄັ້ງ.
ມີປື້ມຫລາຍຫົວ (ທີ່ ໜ້າ ເສົ້າ, ບໍ່ແມ່ນປື້ມທີ່ຂ້ອຍສົນໃຈກັບຜູ້ເຜີຍແຜ່ທີ່ຂ້ອຍບໍ່ມີຊື່) ກ່ຽວກັບການແກ້ໄຂແລະຜູ້ພັດທະນາທຸກໆຄົນຄວນອ່ານທັງ ໝົດ. A dev ທີ່ຍິ່ງໃຫຍ່ແທ້ໆສາມາດແກ້ໄຂບັນຫາຕ່າງໆໃນລະບົບໄດ້ໂດຍບໍ່ຕ້ອງເບິ່ງສາຍຂອງລະຫັດ.
07. ສິ່ງທີ່ຜູ້ໃຊ້ຕ້ອງການ
ເຂົ້າໃຈສິ່ງທີ່ຄົນອ້ອມຂ້າງທ່ານພະຍາຍາມເຮັດ. ເພີດເພີນໄປກັບລະຫັດ - ຮັກສິລະປະຂອງການເຂົ້າເຖິງເອກະສານ CSS ຢ່າງສົມບູນ, ຫຼືການເພີ່ມປະສິດທິພາບຂອງແອັບ ra ລາງລົດໄຟ - ແຕ່ຈື່ໄວ້ວ່າມັນທັງ ໝົດ ແມ່ນເພື່ອຈຸດປະສົງ.
ນັກພັດທະນາຕ້ອງເຂົ້າໃຈທຸລະກິດ, ການ ດຳ ເນີນງານແລະຂະບວນການ ດຳ ເນີນທຸລະກິດເພາະວ່າສິ່ງຂອງຂອງມັນຊ່ວຍໃຫ້ມັນ ດຳ ເນີນງານໄດ້. Devs ທີ່ມີຄວາມຮູ້ນີ້ສາມາດສ້າງໂປແກຼມໂປຼແກຼມແລະໂປແກຼມທີ່ຊ່ວຍໃຫ້ຜູ້ໃຊ້ໄດ້, ແຕ່ມັນມັກຈະເບິ່ງຄືວ່າມີຜົນຜະລິດທີ່ຜິດປົກກະຕິ. ນີ້ອາດແມ່ນຍ້ອນວ່າການພິມແບບໄວໆຂອງພວກເຂົາຫລືຄວາມຮູ້ທີ່ ໜ້າ ຕື່ນຕາຕື່ນໃຈຂອງພວກເຂົາແຕ່ມັນອາດຈະເປັນຍ້ອນຄວາມຮູ້ຂອງພວກເຂົາກ່ຽວກັບສິ່ງທີ່ຜູ້ໃຊ້ຕ້ອງການ.
ຕະຫຼາດແຂ່ງຂັນ
ກັບໄປຫາຈຸດເລີ່ມຕົ້ນຂອງຂ້ອຍ, ການພັດທະນາໄດ້ງ່າຍຂຶ້ນແລະຕະຫຼາດ ສຳ ລັບນັກພັດທະນາທີ່ຍິ່ງໃຫຍ່ແມ່ນມີຄວາມສາມາດແຂ່ງຂັນໄດ້ຫຼາຍກວ່ານັກພັດທະນາຜູ້ທີ່ສາມາດເຂົ້າໃຈຄວາມຮຽກຮ້ອງຕ້ອງການຂອງທຸລະກິດແລະ ນຳ ເອົາສິ່ງທີ່ດີເລີດມາຕອບສະ ໜອງ ໃຫ້ພວກເຂົາແມ່ນຈະມີຜົນດີ. ເຂົ້າໃຈຕະຫຼາດ, ລູກຄ້າແລະເຫດຜົນທີ່ພວກເຂົາຮ່ວມກັບເງິນຊ່ວຍເຫຼືອທຸກຄົນ.
ເຂົ້າໃຈຂໍ້ມູນແລະວິທີທີ່ມັນຈະປ່ຽນແປງຕາມເວລາ. ໃນໃຈຂອງນັກພັດທະນາພວກເຂົາຄວນຈະວາງສາຍເຕັກໂນໂລຢີ ໃໝ່ໆ ກັບສິ່ງທ້າທາຍຕ່າງໆທີ່ທ່ານມີໃນມື້ນີ້ຫລືຈະມາເຖິງ. ວິທີນີ້, ເມື່ອທ່ານແນະ ນຳ ແນວຄວາມຄິດ ໃໝ່ໆ ທີ່ ໜ້າ ຮັກກັບ MD ຫຼືລູກຄ້າ, ມັນຈະອີງໃສ່ສິ່ງທີ່ລູກຄ້າຕ້ອງການແທ້ໆແລະທ່ານຈະໄດ້ຮັບງົບປະມານ / ເວລາ. (ໃນທາງກົງກັນຂ້າມ, ສິ່ງທີ່ບໍ່ດີທີ່ສຸດໃນການເປັນພະຍານແມ່ນນັກພັດທະນາເອົາເຕັກໂນໂລຍີທີ່ມັກ ໃໝ່ ຂອງພວກເຂົາເປັນການແກ້ໄຂບັນຫາຂອງພວກເຮົາ.)
ນັກພັດທະນາມີການຄວບຄຸມຫຼາຍ - ພວກເຂົາ ຈຳ ເປັນຕ້ອງຮູ້ວ່າແຕ່ລະຂົງເຂດໃນຖານຂໍ້ມູນມີຄວາມ ໝາຍ ແນວໃດ ສຳ ລັບຜູ້ ນຳ ໃຊ້ທີ່ສຸດ? ຖ້າພວກເຮົາປ່ຽນຂໍ້ມູນ, ຜູ້ໃຊ້ຈະເຫັນຫຍັງ? ມີວິທີການທີ່ດີກວ່າໃນການຊ່ວຍເຫຼືອຜູ້ໃຊ້ບໍ? ຄວາມຄິດເຫັນຂອງ DB ກໍ່ຄືວ່າໂລກແມ່ນການສະທ້ອນທີ່ບໍ່ດີຂອງຖານຂໍ້ມູນຂອງພວກເຂົາຫຼາຍກ່ວາຖານຂໍ້ມູນຂອງພວກເຂົາເປັນຕົວແທນທີ່ບໍ່ດີຂອງໂລກແທ້. ໂລກມີຄວາມວຸ້ນວາຍແລະເປັນເລື່ອງແປກທີ່ເຕັມໄປດ້ວຍບັນດາຄະດີ. ຈັດການກັບມັນ, DB ຍອມຮັບ.
08. ການແຕ້ມແລະການຂຽນ
ການແຕ້ມຮູບແມ່ນວິທີການສື່ສານໂດຍກົງທີ່ສຸດວ່າສິ່ງໃດຈະເປັນຄືກັນ. ນັກພັດທະນາຕ້ອງສາມາດແຕ້ມແນວຄວາມຄິດຂອງພວກເຂົາໃນກະດານຂາວ, ເຈ້ຍແລະກະດານເບຍ.
ນັກພັດທະນາຕ້ອງສາມາດເປັນຕົວແບບໃນເຈ້ຍ, ພິມພາບ ໜ້າ ຈໍແລະຂຽນໃສ່ພວກມັນພຽງເພື່ອສື່ສານຄວາມຕັ້ງໃຈຂອງພວກເຂົາ. ຢ່າເຊື່ອໃຈນັກພັດທະນາຜູ້ທີ່ຕື່ນຕົວ, ບອກວ່າພວກເຂົາເຂົ້າໃຈແລະເປີດບັນນາທິການຂອງພວກເຂົາ.
ບໍ່ມີລາຄາຖືກ: ລະຫັດທີ່ດີທີ່ສຸດເລີ່ມຕົ້ນດ້ວຍການແຕ້ມເປັນຕົວຢ່າງທີ່ວ່ອງໄວ. ລົ້ມເຫລວເລື້ອຍໆແລະຮັບປະກັນວ່າທຸກໆສິ່ງທີ່ຢູ່ອ້ອມຮອບທ່ານເຮັດເຊັ່ນດຽວກັນກັບທີ່ທ່ານມັກຈະປະສົບຜົນ ສຳ ເລັດໃນແບບນັ້ນ.
09. ເພີດເພີນກັບຕົວທ່ານເອງ
ແລະຈະເປັນແນວໃດຖ້າທ່ານຕ້ອງໃຊ້ເວລາ 10 ຊົ່ວໂມງໃນການແກ້ໄຂບັນຫາໂດຍການຍ້າຍລິ້ງໄປມາ? ເພີດເພີນກັບມັນ - ເຖິງແມ່ນວ່າມັນເປັນພຽງແຕ່ສິ່ງທ້າທາຍຂອງການໄດ້ຮັບການເຮັດວຽກ.
ທັດສະນະຄະຕິທີ່ຮ້າຍແຮງທີ່ສຸດຈາກນັກພັດທະນາ (ຫຼືຜູ້ໃດກໍ່ຕາມ) ແມ່ນຄວາມບໍ່ມີໃຈທີ່ເຮັດໃຫ້ທີມງານພະຍາຍາມບັນລຸ. ແຕ່ໂຊກບໍ່ດີນີ້ແມ່ນເລື່ອງ ທຳ ມະດາ, ເພາະວ່ານັກພັດທະນາເຫັນວ່າຕົນເອງຢູ່ນອກສິ່ງທີ່ທີມງານປະສົບຜົນ ສຳ ເລັດ. (ນັກຂຽນໂປແກຼມ Passionate ມີ ຄຳ ຖາມທີ່ວ່າ, "ເຈົ້າສາມາດເຮັດວຽກຂອງເຈົ້າໄດ້ມ່ວນເທົ່າໃດ? '- ລອງເບິ່ງ.)
ແລະກຽມພ້ອມທີ່ຈະສະແດງຜົນງານຂອງທ່ານໃນຖານະທີ່ປີ້ນກັບກັນຄື: ຢ່າຂະຫຍາຍການທົດລອງສອນກ່ຽວກັບ Ruby ເຖິງ 'ປະສົບການຂອງ Ruby'!
ການພັດທະນາເວບໄຊທ໌ແລະແອັບ is ຍັງເປັນອາຊີບທີ່ ໜຸ່ມ ນ້ອຍ, ແຕ່ທັກສະທີ່ ກຳ ລັງຕ້ອງການກໍ່ຍິ່ງຂະຫຍາຍອອກໄປ. ທຸກໆຄົນຄວນຄາດຫວັງໃຫ້ນັກພັດທະນາຫລາຍຂື້ນເພາະວ່າໄວໆນີ້ພວກເຮົາທຸກຄົນຈະອອກຈາກຫ້ອງຫລັງຮ້າຍແລະມີສ່ວນຮ່ວມກັບຂະບວນການສ້າງສັນຜົນໄດ້ຮັບຈະດີຂື້ນ.
10. ມີຄວາມຄົມຊັດ
ເພື່ອໃຫ້ຮອບນີ້ງາມຂື້ນຮອບ 10 ຂ້ອຍຈະຕື່ມສິ່ງສຸດທ້າຍ. ຢູ່ທີ່ຄົມຊັດ. ຊອກຫາການແຂ່ງຂັນ. ປະເພດທີ່ບໍ່ດີທີ່ສຸດແມ່ນສິ່ງ ໜຶ່ງ ທີ່ໂດດດ່ຽວ.
"ຈົ່ງເປັນຄົນທີ່ບໍ່ດີທີ່ສຸດໃນທຸກໆວົງການທີ່ທ່ານຢູ່."
ສິ່ງທີ່ບໍ່ດີທີ່ສຸດ - ຮ້າຍແຮງທີ່ສຸດ, ຮ້າຍແຮງທີ່ສຸດ - ນັກຂຽນໂປແກຼມ, ນັກຂຽນລະຫັດ, ນັກອອກແບບຮຽນຮູ້ສິ່ງຂອງແລະພັກຜ່ອນຂອງພວກເຂົາ. ຖ້າບໍ່ມີເຄື່ອງຈັງຫວະ, ມັນກໍ່ງ່າຍເກີນໄປທີ່ຈະຊ້າລົງແລະໂດຍບໍ່ເຫັນການແຂ່ງຂັນມັນຈະກາຍເປັນນິໄສທີ່ຈະເຫັນຕົວເອງສູງກວ່າສະເລ່ຍ.
ສະນັ້ນ, ເປັນສິ່ງທີ່ບໍ່ດີທີ່ສຸດທີ່ທ່ານສາມາດເຮັດໄດ້ໂດຍການຊອກຫາທີ່ດີກວ່າ. ເຂົ້າຮ່ວມບັນດາໂຄງການທີ່ຢູ່ນອກບ່ອນເຮັດວຽກ, ປະກອບສ່ວນແລະສະແຫວງຫາ ຄຳ ຄິດເຫັນແລະ ຄຳ ວິຈານເພາະວ່າທ່ານຈະໄດ້ຮັບການວິພາກວິຈານຫຼາຍ, ປະຊາຊົນກໍ່ຈະໃຫ້ທ່ານໃນອະນາຄົດ ໜ້ອຍ. ເມື່ອທ່ານຄາດເດົາວ່າມັນຕ້ອງການຫຍັງດີກ່ວາພວກເຂົາ, ທ່ານກໍ່ແມ່ນນັກພັດທະນາ Ninja ທີ່ທຸກຄົນຕ້ອງການ.
Dan Frost ເປັນຜູ້ ອຳ ນວຍການດ້ານເຕັກນິກຂອງບໍລິສັດເວບໄຊທ໌ 3EV, ເຊິ່ງເປັນຄູ່ຮ່ວມງານຂອງ AWS ຢ່າງເປັນທາງການ. ລາວໄດ້ເຮັດວຽກໃນ CMS ແລະພັດທະນາ web app ເປັນເວລາເຈັດປີ.
ມັກນີ້ບໍ? ອ່ານເຫຼົ່ານີ້!
- ວິທີການສ້າງແອັບ.
- ຕົວອັກສອນເວັບຟຣີທີ່ດີທີ່ສຸດ ສຳ ລັບນັກອອກແບບ
- ຄົ້ນພົບສິ່ງທີ່ເປັນຕໍ່ໄປ ສຳ ລັບ Augmented Reality
