ນັກພັດທະນາຄວນໃຊ້ແນວຄິດທີ່ມີຊື່ວ່າ shame.css ເພື່ອເຮັດໃຫ້ CSS ຂອງ hack 'ແກ້ໄຂໄວຂື້ນໃນໂຄງການຕ່າງໆ, ຕາມ Harry Roberts, ນັກພັດທະນາ UI ຊັ້ນສູງຂອງ BSkyB.
Roberts ໄດ້ອະທິບາຍໃນບົດຂຽນ blog ວ່າສິ່ງນີ້ອາດຈະເຮັດໃຫ້ນັກພັດທະນາບໍ່ສາມາດເຫັນການລັກລອບໃຊ້ທົ່ວ CSS ແລະໂດຍການຄິດວ່າສິ່ງເຫຼົ່ານີ້ເປັນສິ່ງທີ່ຍອມຮັບໄດ້ໂດຍຄ່າເລີ່ມຕົ້ນ.
ນອກຈາກນັ້ນ, ບົດຂຽນໄດ້ຍົກໃຫ້ເຫັນວ່າວິທີການດັ່ງກ່າວ, ຖ້າມີເອກະສານຢ່າງຖືກຕ້ອງແລະປະກອບດ້ວຍວິທີການແກ້ໄຂມັນ, ສາມາດຊ່ວຍໃຫ້ມີຄວາມຄືບ ໜ້າ ໄວຂຶ້ນຕໍ່ CSS ທີ່ສະອາດໃນໂຄງການຕ່າງໆທີ່ມີການ ນຳ ໃຊ້ແຮັກເກີ້ (ດ້ວຍເຫດຜົນໃດກໍ່ຕາມ).
.net ເວົ້າກັບ Roberts (HB) ກ່ຽວກັບການ hack CSS ແລະຂໍ້ໄດ້ປຽບທີ່ອາດຈະເກີດຂື້ນ.
. ສຸດທິ: ທ່ານຄິດວ່າມີແນວໂນ້ມຈາກບາງຄົນໃນອຸດສະຫະກໍາທີ່ບໍ່ມີເຫດຜົນຫຍັງກ່ຽວກັບຄວາມຕ້ອງການ (ຫວັງວ່າ) ການ hack ໄລຍະສັ້ນເພື່ອໃຫ້ເວັບໄຊທ໌້ເຮັດວຽກ?
HR: ເວລາໃຫຍ່. ຖ້າທ່ານເຮັດວຽກຢູ່ໃນເວັບໄຊຫລືຜະລິດຕະພັນທີ່ມີລາຍໄດ້ຫລາຍລ້ານປອນຕໍ່ປີ, ຂໍ້ບົກພ່ອງ, ຄວາມແຕກຫັກຫລືການຫົດຫູ່ກໍ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂໄວເທົ່າທີ່ຈະໄວໄດ້. ເຈົ້າຂອງຜະລິດຕະພັນຂອງທ່ານບໍ່ສົນໃຈຖ້າ CSS ຂອງທ່ານສົມບູນແບບ - ພວກເຂົາສົນໃຈວ່າເວບໄຊທ໌ນີ້ມີການໃຊ້ງານແລະມີປະໂຫຍດແລະເລືອກລາຍໄດ້ດັ່ງກ່າວ. ລະຫັດດີ ແມ່ນ ສິ່ງ ສຳ ຄັນ, ແລະແຮັກເກີ້ແມ່ນໄກຈາກຄວາມ ເໝາະ ສົມ, ແຕ່ຄິດວ່າທ່ານສາມາດປ້ອງກັນບໍ່ໃຫ້ແຮັກເກີ້ຢູ່ສະ ເໝີ ແລະການແກ້ໄຂໄລຍະສັ້ນ / ໄວກໍ່ບໍ່ໄດ້ຜົນ.
. ສຸດທິ: ດັ່ງນັ້ນທ່ານເວົ້າວ່າພວກເຂົາເປັນພຽງຄວາມຊົ່ວທີ່ຈໍາເປັນພາຍໃນທຸລະກິດ?
HR: ໃນເວລາທີ່ລູກຄ້າຫາຍໃຈລົງຄໍຂອງທ່ານ - ຫຼືຄຸນລັກສະນະຖືກແຍກຢູ່ໃນເວັບໄຊທ໌ສົດ - ທ່ານຕ້ອງແນ່ໃຈວ່າທ່ານຮັກສາຜູ້ທີ່ກ່ຽວຂ້ອງທີ່ມີຄວາມສຸກ. ຖ້າທ່ານໃຊ້ເວລາ ໜຶ່ງ ຊົ່ວໂມງຂຽນການແກ້ໄຂທີ່ດີເລີດ ສຳ ລັບບາງສິ່ງບາງຢ່າງທີ່ທ່ານສາມາດແກ້ໄຂແບບພິເສດໃນສອງນາທີ, ຂ້າພະເຈົ້າຢາກເວົ້າວ່າທ່ານ ກຳ ລັງຮັກສາຄົນຜິດໃຫ້ມີຄວາມສຸກ - ຕົວທ່ານເອງ!
ໃນວຽກງານຂອງຂ້ອຍເອງ, ຂ້ອຍໄດ້ພົບກັບຄວາມຕ້ອງການ 'ແຮັກເກີ້' ເພີ່ມຂື້ນຢ່າງເທົ່າທຽມກັນກັບຂະ ໜາດ ຂອງໂຄງການ, ແຕ່ສິ່ງທີ່ດີກ່ຽວກັບນັ້ນກໍ່ຄືວ່າເຈົ້າຍັງຈະມີເວລາໃນໂຄງການຫຼາຍກວ່າເກົ່າເພື່ອແກ້ໄຂບັນດາແຮັກເກີ້ເຫຼົ່ານັ້ນ.
.net: ບ່ອນໃດທີ່ບ່ອນທີ່ມີຄວາມອັບອາຍເຂົ້າມາ. ໃນແນວຄິດນັ້ນ, ທ່ານພິຈາລະນາການເຈາະ CSS ແບບໃດ?
HR: ບາງສິ່ງບາງຢ່າງທີ່ສາມາດເຮັດໄດ້ດີກວ່າມີເວລາຫຼາຍ. ມັນຍາກທີ່ຈະຄິດເຖິງຕົວຢ່າງອອກຈາກສະພາບການ, ແຕ່ຂ້ອຍຄິດວ່າເຈົ້າຈະຮູ້ເລື້ອຍໆວ່າເວລາມີບາງສິ່ງບາງຢ່າງຖືກແຮັກ. ໄດ້ຂຽນບາງສິ່ງບາງຢ່າງທີ່ເຈົ້າ ໜ້າ ອາຍທີ່ຈະອະທິບາຍໃຫ້ເພື່ອນຮ່ວມງານບໍ? ວ່າອາດຈະເປັນການ hack!
ເພາະສະນັ້ນ, shame.css ແມ່ນກ່ຽວກັບການສ້າງເອກະສານຂອງສິ່ງຕ່າງໆທີ່ທ່ານສາມາດເຮັດໄດ້ດີກວ່າເກົ່າ, ແລະທ່ານສາມາດເຮັດໄດ້ດີກວ່າເກົ່າເມື່ອທ່ານໄດ້ໃຊ້ເວລາໃນການກວດເບິ່ງພວກມັນ. ມັນແມ່ນລາຍການທີ່ຕ້ອງຂຽນດ້ວຍຕົນເອງ, ແມ່ນແທ້ໆ - ເອກະສານຂອງແຮັກເກີ້ທີ່ທ່ານວາງຢູ່ຂ້າງ ໜຶ່ງ ເພື່ອຄິດຫາໃນເວລາທີ່ທ່ານມີເວລາຫຼາຍ.
. ສຸດທິ: ໃນບົດຂຽນຂອງທ່ານ, ທ່ານກ່າວເຖິງເອກະສານກ່ຽວກັບການ hack, ແຕ່ວ່າບໍ່ມີຜູ້ພັດທະນາໂຕ້ຖຽງໂດຍທົ່ວໄປຄວນຈະໄດ້ຮັບການບັນທຶກເອກະສານ CSS ຫຼາຍປານໃດ, ແທນທີ່ຈະເປັນພຽງແຕ່ ສຳ ລັບການ hack?
HR: ແມ່ນແລ້ວ! ຖ້າມີສິ່ງ ໜຶ່ງ ທີ່ນັກພັດທະນາຄວນເຮັດຫຼາຍກວ່ານັ້ນ, ມັນກໍ່ແມ່ນການຂຽນ ຄຳ ເຫັນ. ທ່ານຄວນຈະໃຫ້ ຄຳ ເຫັນຫຍັງທີ່ບໍ່ສາມາດເຫັນໄດ້ທັນທີຈາກລະຫັດຢ່າງດຽວ. ບັນທຶກລະຫັດຂອງທ່ານເພື່ອວ່າ, ຖ້າທ່ານຖືກລົດໂດຍສານທີ່ເດີນທາງກັບບ້ານ, ເພື່ອນຮ່ວມງານຂອງທ່ານສາມາດເຂົ້າຮັບ ໜ້າ ທີ່ໃນມື້ຕໍ່ມາ.
.net: ໃນແງ່ຂອງການປະສົມປະສານລະຫວ່າງ txaj txaj, ທ່ານແນະ ນຳ ຫຍັງ?
HR: ຖ້າໃຊ້ໂປແກຼມ preprocessor, @import ໄດ້ ໜ້າ ອາຍ. ຍື່ນສິດທິໃນຕອນທ້າຍ, ໂດຍສະເພາະ. (ນີ້ສາມາດ ນຳ ໄປສູ່ບັນຫາສະເພາະແລະບັນຫາການສັ່ງຊື້, ສະນັ້ນໄລຍະທາງຂອງທ່ານອາດຈະແຕກຕ່າງກັນ.)
ຖ້າທ່ານບໍ່ໄດ້ ນຳ ໃຊ້ໂປແກຼມ preprocessor, ແຕ່ມີຂັ້ນຕອນການກໍ່ສ້າງທີ່ ເໝາະ ສົມ, CSS ຂອງທ່ານທັງ ໝົດ ຄວນຖືກສະຫລຸບແລະຫຼຸດຜ່ອນກ່ອນການ ນຳ ໃຊ້, ສະນັ້ນ, ອີກເທື່ອ ໜຶ່ງ, shame.css ສາມາດຍືດເຍື້ອຈົນເຖິງທີ່ສຸດ.
ຖ້າທ່ານບໍ່ໃຊ້ໂປເຈັກເຕີກ່ອນ ແລະ ທ່ານບໍ່ມີຂັ້ນຕອນການກໍ່ສ້າງ, ຫຼັງຈາກນັ້ນ ໜຶ່ງ ທ່ານ, ທ່ານອາດຈະຕ້ອງແກ້ໄຂບັນຫານັ້ນ, ແລະສອງ, ສ່ວນແຮັກເກີ້ທີ່ຢູ່ເບື້ອງທ້າຍຂອງຕາຕະລາງຂອງທ່ານແມ່ນອາດຈະເປັນການເດີມພັນທີ່ດີທີ່ສຸດຂອງທ່ານ. Shame.css ບໍ່ໄດ້ມີຈຸດປະສົງ ສຳ ລັບການສະແດງສາທາລະນະ, ສະນັ້ນບໍ່ຄວນມີຮູບແບບແຍກຕ່າງຫາກທີ່ເອີ້ນໂດຍອົງປະກອບເຊື່ອມຕໍ່ໃນເຄື່ອງ ໝາຍ ຂອງທ່ານ. ທ່ານຄວນໃຫ້ບໍລິການສະເພາະຮູບແບບຕາຕະລາງແລະລະດັບ ໜຶ່ງ ເທົ່ານັ້ນ.
. ສຸດທິ: ຖ້າວ່າຄວາມອັບອາຍເປັນແນວຄວາມຄິດທີ່ເກີດຂື້ນຈິງ, ທ່ານຄິດວ່າມັນສາມາດປ່ຽນຂັ້ນຕອນການອອກແບບແລະເວບໄຊທ໌ໂດຍທົ່ວໄປໄດ້ແນວໃດ?
HR: Shame.css ມີປະໂຫຍດເທົ່າກັບນັກພັດທະນາທີ່ປະຕິບັດມັນ. ມັນເປັນການໂດດດ່ຽວແລະດີທີ່ສຸດໃນການໂດດດ່ຽວແລະເກັບ ກຳ ເອກະສານກ່ຽວກັບການແຮັກ, ແຕ່ຖ້າທ່ານບໍ່ເຄີຍແກ້ໄຂຫລືທົບທວນພວກມັນ, ທ່ານກໍ່ຢູ່ໃນເຮືອດຽວກັນກັບແຕ່ກ່ອນ.
ສຳ ລັບຂ້ອຍ, shame.css ແມ່ນສັນຍານໃຫ້ມີການປ່ຽນແປງຢ່າງກວ້າງຂວາງໃນການພັດທະນາ; ມັນບໍ່ ຈຳ ເປັນຕ້ອງ ຈຳ ກັດຕໍ່ CSS. ແນວຄວາມຄິດດັ່ງກ່າວແມ່ນພຽງແຕ່ ‘ການຮູ້, ການບັນທຶກແລະຈຸດ ສຳ ຄັນຂອງການ hack ຂອງທ່ານ. ທ່ານສາມາດ ນຳ ໃຊ້ຄວາມຄິດດັ່ງກ່າວກັບທຸກໆຢ່າງ.
ການເຮັດວຽກທີ່ແທ້ຈິງທີ່ກ່ຽວຂ້ອງກັບຄວາມອັບອາຍແມ່ນການເຮັດໃຫ້ທີມງານ (ນັກພັດທະນາ) ຂອງທ່ານທັນທີ, ແລະຈາກນັ້ນກໍ່ເຮັດໃຫ້ທຸລະກິດ / PMs / scrum masters / BAs / ເຈົ້າຂອງຜະລິດຕະພັນ (ແລະອື່ນໆ) ຮູ້ເຖິງຄວາມຈິງທີ່ວ່າສິນຄ້າບາງຄັ້ງຈະລວມເອົາ ໜ້ອຍ ລົງ - ລະຫັດທີ່ ເໝາະ ສົມ, ແຕ່ວ່າລະຫັດນີ້ມີຢູ່ເພື່ອຕອບສະ ໜອງ ຄວາມຕ້ອງການທາງທຸລະກິດ.
ບອກພວກເຂົາວ່າທ່ານ ກຳ ລັງໂດດດ່ຽວແລະເກັບ ກຳ ເອກະສານກ່ຽວກັບການແຮັກແລະໃຊ້ເວລາໃນການພັດທະນາເພື່ອຈັດສັນໃຫ້ມີຄວາມກະທັດຮັດ. ມັນເປັນເລື່ອງງ່າຍທີ່ຈະເຮັດກໍລະນີທຸລະກິດ ສຳ ລັບການເຮັດລະຫັດລະຫັດຖ້າທ່ານສາມາດປະລິມານໄດ້. ເວົ້າງ່າຍໆກັບຜູ້ຈັດການໂຄງການຂອງທ່ານ, "ຂ້ອຍມີບາງສິ່ງທີ່ຈະເຮັດໃຫ້ກະທັດຮັດກ່ອນທີ່ຂ້ອຍຈະກ້າວໄປສູ່ Feature X" ຈະບໍ່ຕັດມັນຢູ່ສະ ເໝີ! ເອົາບັນຊີລາຍຊື່ຂອງສິ່ງຕ່າງໆໄປຫາ PM ຂອງທ່ານແລະພະຍາຍາມແລະໃຊ້ເວລາເຄິ່ງມື້ຂອງການໃຊ້ຈ່າຍເພື່ອໃຊ້ເວລາໃນການເຮັດຄວາມສະອາດ.
ແນວຄວາມຄິດທີ່ຢູ່ເບື້ອງຫລັງຄວາມອັບອາຍແມ່ນພຽງແຕ່ເຮັດໃຫ້ແຮັກຂອງທ່ານມີຄວາມໂປ່ງໃສ, ມີຄຸນຄ່າແລະໂດດດ່ຽວ. ມັນຂື້ນກັບທ່ານສິ່ງທີ່ທ່ານເຮັດກັບຂໍ້ມູນນັ້ນ!
