Debugging: Finding It Yourself

ผู้เริ่มต้นส่วนใหญ่มองว่าข้อผิดพลาดเป็นเหมือนกำแพง พวกเขาชนมัน หยุด และขอให้คนอื่นปีนขึ้นไปให้พวกเขา นิสัยที่สร้างทักษะจริงนั้นต่างออกไป: คุณเรียนรู้ที่จะมองว่าข้อผิดพลาดเป็นเหมือนคำถามที่มีคำตอบที่ค้นหาได้ และคุณไปหาคำตอบนั้นก่อนที่คุณจะไปถามคนอื่น

อ่านข้อความแสดงข้อผิดพลาดเหมือนมันคือหลักฐาน ไม่ใช่เสียงรบกวน

Stack traces ถูกข้ามไปอย่างต่อเนื่องเพราะมันดูน่ากลัว แต่โดยปกติมันบอกคุณตรงว่าที่ไหนและทำไมอะไรบางอย่างจึงหัก ถ้าคุณได้รับ TypeError: 'NoneType' object is not subscriptable ใน Python มันไม่ใช่เรื่องไร้สาระแบบสุ่ม — มันหมายความว่าตัวแปรที่คุณคาดว่าจะเก็บรายการหรือพจนานุกรมกำลังเป็น None เลขบรรทัดบอกคุณว่าที่ไหน งานของคุณคือการติดตามย้อนกลับจากบรรทัดนั้นและค้นหาว่าค่านั้นควรจะถูกตั้งไว้ที่ไหนแต่ไม่เป็น

ทำสิ่งนี้ก่อนค้นหาอะไรออนไลน์: อ่านบรรทัดสุดท้ายของ traceback ก่อน แล้วทำงานขึ้นไป บรรทัดสุดท้ายมักจะตั้งชื่อข้อยกเว้นจริง บรรทัดข้างบนมันแสดงลำดับการเรียกที่นำคุณมาที่นี่

ทำให้มันเกิดขึ้นตั้งแต่เจตนา

ถ้าข้อผิดพลาดปรากฏขึ้นเพียงบางครั้ง คุณยังไม่เข้าใจมัน ก่อนที่จะแก้ไขโค้ด พยายามทำให้มันเกิดขึ้นอย่างน่าเชื่อถือ เปลี่ยนอินพุตทีละตัว มันล้มเหลวกับรายการว่างแต่ไม่ใช่รายการเต็ม มันล้มเหลวเพียงในการเรียกครั้งที่สองของฟังก์ชัน ไม่ใช่ครั้งแรก ข้อผิดพลาดที่คุณสามารถทำให้เกิดขึ้นตามคำสั่งคือข้อผิดพลาดที่แก้ไขได้ 80% แล้ว เพราะตอนนี้คุณสามารถทดสอบได้ว่าการแก้ไขจริง ๆ ช่วยหรือไม่ แทนที่จะเดา

ตัดปัญหาเป็นครึ่งหนึ่ง แล้วครึ่งหนึ่งอีกครั้ง

การค้นหาแบบไบนารีไม่ใช่แค่สำหรับอาร์เรย์ที่เรียงลำดับ — มันเป็นวิธีที่เร็วที่สุดในการค้นหาโค้ดที่หักในฟังก์ชันยาวหรือ pipeline ใส่ความเห็นหรือปล่อยผ่านครึ่งหลังของตรรกะของคุณและตรวจสอบว่าครึ่งแรกยังคงสร้างข้อผิดพลาดหรือไม่ ถ้าใช่ ปัญหาอยู่ในครึ่งแรก ถ้าไม่ก็อยู่ในครึ่งที่สอง ทำซ้ำ วิธีนี้ใช้ได้สำหรับสคริปต์ 200 บรรทัดเช่นเดียวกับที่ใช้ได้กับ pipeline ข้อมูลหลายขั้นตอนที่คุณตรวจสอบผลลัพธ์ในแต่ละขั้นตอนด้วย print() หรือ df.head()

นี่ดีกว่าการเปลี่ยนบรรทัดแบบสุ่มและรันใหม่ ซึ่งเป็นสิ่งที่คนส่วนใหญ่ทำภายใต้ความกดดันและมันเสียเวลามากกว่าที่มันช่วย

ใช้ debugger แทน print() เมื่อ print() หยุดทำงาน

คำสั่ง print() ใช้ได้สำหรับกรณีง่าย ๆ แต่เมื่อคุณติดตามสถานะจากการเรียกฟังก์ชันหลาย ๆ ครั้ง debugger จริง ๆ จะช่วยประหยัดเวลา ใน Python ให้ import pdb; pdb.set_trace() ถัดจากบรรทัดที่น่าสงสัยมากที่สุด รันสคริปต์ และคุณได้รับ prompt สด ๆ ที่คุณสามารถตรวจสอบตัวแปร ทำให้ก้าวทีละบรรทัดด้วย n และเข้าไปในการเรียกฟังก์ชันด้วย s Debugger ในตัวของ VS Code ทำเช่นเดียวกันกับจุดแบ่งที่คุณคลิกแทนที่จะพิมพ์ ไม่ว่าหลังไหน เป้าหมายเดียวกัน: ดูสถานะจริงของโปรแกรมของคุณแทนที่จะเดาว่ามันน่าจะเป็นไง

แยกมันจากส่วนที่เหลือของโปรเจกต์ของคุณ

ถ้าข้อผิดพลาดเกิดขึ้นในฐานรหัสขนาดใหญ่ อย่าดีบักมันในฐานรหัสขนาดใหญ่ คัดลอกฟังก์ชันที่เกี่ยวข้องลงในไฟล์สด ๆ ใหม่ด้วยอินพุตที่ปลอม และน้อยที่สุดที่ทำให้เกิดความล้มเหลวแบบเดียวกัน ถ้าข้อผิดพลาดหายไป บางอย่างเกี่ยวกับบริบทที่อยู่รอบ ๆ — ตัวแปรทั่วโลก อิมพอร์ต สถานะเก่า — คือสาเหตุจริง และคุณเพิ่งเรียนรู้บางอย่างที่สำคัญ ถ้าข้อผิดพลาดยังคงอยู่ในการแยก ตอนนี้คุณมีกรณีเล็ก ๆ ที่ใช้ร่วมกันได้ ทดสอบได้ และคุณใกล้เคียงกับการแก้ไขจริง ๆ มากขึ้น

ตรวจสอบสมมติฐานของคุณกับความเป็นจริง ไม่ใช่ความทรงจำ

ส่วนที่ใหญ่โตของเวลาการดีบักไปกับสมมติฐานที่ไม่มีคำถาม: