ສ້າງບັນຫາຊ້ຳແບບສັ້ນໆ
ໃຊ້ການທົດສອບສັ້ນແທນການສ້າງທັງເອກະສານໃໝ່. ຕົວຢ່າງທົດສອບທີ່ມີປະໂຫຍດຢູ່ນີ້ແມ່ນ: ສະຫຼຸບການປະຊຸມແບບ Markdown ທີ່ມີຂໍ້ຕົກລົງ, ຜູ້ຮັບຜິດຊອບ ແລະຂັ້ນຕອນຕໍ່ໄປ. ເກັບສຳເນົາຕົ້ນສະບັບໄວ້ ເພື່ອໃຫ້ຍ້ອນກັບທຸກການແກ້ໄຂໄດ້. ຈົດວ່າທ່ານຄາດວ່າຈະໄດ້ຍິນຫຍັງ ແລະໄດ້ຍິນຫຍັງແທ້.
ຈຸດເລີ່ມຕົ້ນMarkdown ມີປະໂຫຍດສຳລັບບັນທຶກທີ່ຍ້າຍຂ້າມລະບົບໄດ້ ແຕ່ຮູບແບບການຂຽນ ແລະການເວົ້າມີໜ້າທີ່ຕ່າງກັນ.
ກວດຕົ້ນສະບັບກ່ອນ
- 01
ກວດສິ່ງທີ່ປ້ອນເຂົ້າ
ກວດຫົວຂໍ້ ແລະເຄື່ອງໝາຍລາຍການໃນຂໍ້ຄວາມທີ່ສະກັດອອກ. ປຽບທຽບຂໍ້ຄວາມທີ່ມີບັນຫາກັບເອກະສານຕົ້ນສະບັບ.
- 02
ປ່ຽນເທື່ອລະຢ່າງ
ຂຽນບລັອກໂຄດເປັນຄຳອະທິບາຍສັ້ນ ເມື່ອຄວນອ່ານອອກສຽງ. ຮັກສາການຕັ້ງຄ່າອື່ນໃຫ້ຄືເດີມ ເພື່ອໃຫ້ການທົດສອບຍຸດຕິທຳ.
- 03
ຟັງອີກຄັ້ງ
ຟັງຕົວຢ່າງລິ້ງ ແລະເຄື່ອງໝາຍວັກຕອນກ່ອນບັນທຶກ. ໃຊ້ປະໂຫຍກດຽວກັນເພື່ອຕັດສິນວ່າການປ່ຽນເຮັດໃຫ້ຜົນດີຂຶ້ນຫຼືບໍ່.
ແຍກອາການຂອງບັນຫາ
ຕົວຢ່າງໂຄດບໍ່ແມ່ນຄູ່ມືການອອກສຽງ. ສັນຍາລັກທາງເຕັກນິກອາດຕ້ອງມີຄຳອະທິບາຍດ້ວຍສຽງ ແທນການອ່ານຕາມຕົວອັກສອນ.
| ຈຸດກວດ | ສິ່ງທີ່ຄວນສັງເກດ | ວຽກຕໍ່ໄປ |
|---|---|---|
| ຄຳ ຫຼືລຳດັບຜິດ | ປຽບທຽບຂໍ້ຄວາມທີ່ສະກັດກັບຕົ້ນສະບັບ | ແກ້ໄຂຂໍ້ຄວາມກ່ອນປ່ຽນສຽງ |
| ຄຳຊັດເຈນ ແຕ່ການອ່ານຟັງບໍ່ຖືກໃຈ | ຟັງຕົວຢ່າງຜູ້ເວົ້າອື່ນດ້ວຍຄວາມໄວດຽວກັນ | ເລືອກສຽງ ແລະຄວາມໄວແຍກກັນ |
| ຕົວຢ່າງໃຊ້ໄດ້ ແຕ່ບັນທຶກເຕັມໃຊ້ບໍ່ໄດ້ | ກວດຄວາມຍາວເອກະສານ ແລະພື້ນທີ່ເກັບໃນອຸປະກອນ | ແບ່ງຕາມຂອບພາກທີ່ມີຄວາມໝາຍ |
ທົດສອບໃໝ່ກ່ອນປ່ຽນແທນສຽງບັນທຶກ
ເມື່ອການທົດສອບສັ້ນໃຊ້ໄດ້ ໃຫ້ນຳສະເພາະການປ່ຽນທີ່ສຳເລັດໄປໃຊ້ກັບບັນທຶກຍາວ. ຖ້າຍັງບໍ່ສຳເລັດ ໃຫ້ຈົດປະເພດໄຟລ໌, ສຽງທີ່ເລືອກ ແລະຂັ້ນຕອນທີ່ເກີດບັນຫາຢ່າງແນ່ນອນ. ລາຍລະອຽດນີ້ເຮັດໃຫ້ຄຳຂໍຊ່ວຍເຫຼືອມີປະໂຫຍດຂຶ້ນ.
ສະຫຼຸບການປະຊຸມແບບ Markdown ທີ່ມີຂໍ້ຕົກລົງ, ຜູ້ຮັບຜິດຊອບ ແລະຂັ້ນຕອນຕໍ່ໄປ. ເກັບຕົວຢ່າງນັ້ນເປັນຂໍ້ອ້າງອີງດ່ວນສຳລັບຄັ້ງຕໍ່ໄປ ແລະກັບໄປຫາຕົ້ນສະບັບເມື່ອລາຍລະອຽດທີ່ແນ່ນອນສຳຄັນ.
ຂຽນຕາມຄຸນສົມບັດຈິງຂອງ Velloriff ແລະຂໍ້ຈຳກັດ. ນີ້ແມ່ນຄຳແນະນຳຜະລິດຕະພັນທີ່ໃຊ້ໄດ້ຈິງ ບໍ່ແມ່ນຄຳແນະນຳທາງການແພດ ຫຼືຂໍ້ອ້າງວ່າການຟັງເຮັດໃຫ້ຜົນການຮຽນດີຂຶ້ນ. ເກັບເອກະສານຕົ້ນສະບັບເພື່ອຢືນຢັນ.