โปรแกรมของคุณทำสิ่งที่คุณต้องการในครั้งแรกบ่อยแค่ไหน
หลายครั้งที่โปรแกรมของเราใช้งานไม่ได้อย่างที่เราคาดไว้ เราจึงต้องใช้ศิลปะของการดีบักทับทิม เพื่อช่วยให้เราค้นหาสาเหตุ
คุณอาจคุ้นเคยกับข้อความแสดงข้อผิดพลาดต่อไปนี้:
undefined method 'some_method' for nil:NilClass
ซึ่งหมายความว่าค่าศูนย์สามารถหาทางเข้าโค้ดของเราได้
การใช้เทคนิคต่างๆ ที่กล่าวถึงในบทความนี้ คุณจะได้เรียนรู้วิธีจัดการกับปัญหานี้และปัญหาที่คล้ายคลึงกัน!
ทำความเข้าใจข้อผิดพลาดและการติดตามสแต็ค
เมื่อคุณได้รับข้อผิดพลาดจากล่าม Ruby หรือโปรแกรมของคุณไม่ได้ทำในสิ่งที่ควรทำ ก็ถึงเวลาที่จะต้องสวมหมวกสำหรับการดีบักของคุณ
หากปัญหาคือโปรแกรมของคุณขัดข้อง สิ่งสำคัญคือต้องให้ความสนใจกับข้อความแสดงข้อผิดพลาด ซึ่งมักจะประกอบด้วยเงื่อนงำของสิ่งที่ผิดพลาด
นี่คือตัวอย่าง :
def method1 method2 end def method2 puts invalid_variable end method1
การเรียกใช้รหัสนี้จะทำให้คุณมีข้อผิดพลาดดังต่อไปนี้:
/tmp/stack.rb:6:in 'method2': undefined local variable or method 'invalid_variable' for main:Object (NameError) from /tmp/stack.rb:2:in 'method1' from /tmp/stack.rb:9:in ''
นี่คือสิ่งที่เรียกว่าการติดตามสแต็ก
มาวิเคราะห์กัน!
เราเริ่มต้นด้วยเส้นด้านบน
นี่คือที่ที่เกิดข้อผิดพลาดจริง แต่ไม่ได้หมายความว่าเงื่อนไขข้อผิดพลาดเกิดขึ้นที่นี่
อย่างไรก็ตาม การเริ่มต้นการตรวจสอบของเราถือเป็นจุดที่ดี
นี่คือข้อตกลง :
ข้อความ | คำอธิบาย |
---|---|
/tmp/stack.rb :6 | ไฟล์และหมายเลขบรรทัด |
ใน `method2 ' | ชื่อวิธีการ |
ตัวแปรท้องถิ่นหรือเมธอดที่ไม่ได้กำหนด ‘invalid_variable ' | ข้อความแสดงข้อผิดพลาด |
main:วัตถุ | ชื่อคลาส |
(NameError) | ชื่อข้อยกเว้น |
จะเห็นได้ว่าข้อผิดพลาดไม่ได้น่ากลัวอย่างที่คิดเมื่อถูกพังทลายด้วยวิธีนี้
อย่างไรก็ตาม คุณสามารถดูรายการข้อยกเว้นได้ที่นี่
ตอนนี้ :
ทุกบรรทัดในการติดตามสแต็กด้านล่างบรรทัดแรกจะบอกคุณว่าโค้ดมาอยู่ที่นี่ได้อย่างไร
โดยพื้นฐานแล้วมันเป็นห่วงโซ่วิธีการ หากคุณยังคงดำเนินต่อไป คุณควรพบวิธีการหลักของแอปในที่สุด
นี่คืออัลกอริทึมทั่วไปสำหรับจัดการกับ การติดตามสแต็ก :
- อ่านบรรทัดบนสุดของการติดตามสแต็ก
- หากไฟล์เป็นส่วนหนึ่งของโครงการของคุณ:เปิดไฟล์ที่มีข้อบกพร่องตามหมายเลขบรรทัดที่ระบุ หากไม่เป็นเช่นนั้น ให้ไปที่สแต็กเทรซต่อไปจนกว่าคุณจะพบการอ้างอิงแรกไปยังไฟล์ที่คุณรู้จัก
- ดูว่ามีอะไรชัดเจนถึงคุณและแก้ไขหรือไม่ (มองหาสิ่งที่กล่าวถึงในข้อความแสดงข้อผิดพลาด)
- หากไม่ได้ผล คุณจะต้องค้นหาข้อมูลเพิ่มเติม เช่น ค่าของตัวแปรที่ได้รับผลกระทบ
การดีบักทับทิม
เทคนิคการดีบักพื้นฐานที่สุด (ซึ่งไม่ได้หมายความว่าแย่) ที่คุณอาจคุ้นเคยคือการทิ้งค่าของตัวแปรที่น่าสงสัย
ใน Ruby คุณสามารถทำได้โดยใช้ puts หรือ p .
ใช้ p เท่ากับว่า ใส่ variable.inspect และมีประโยชน์สำหรับการดูวัตถุ
ตัวอย่าง :
Book = Struct.new(:title) def find_book(title) books = [] books << Book.new('Eloquent Ruby') books.find { |b| b.title == title } end book = find_book('Eloquent Ruby') p book # This will print our book object book = find_book('POODR') p book # This will print nil book.name # Guess what happens next!
เจาะลึกกับ Pry
เมื่อคุณมีตัวแปรมากมายที่ต้องตรวจสอบ ให้เพิ่ม puts
ทุกที่อาจไม่เป็นประโยชน์มากนัก
ในกรณีนี้คุณควรลองแงะ
ใช้ แงะ คุณสามารถทำให้โค้ดของคุณหยุดที่บรรทัดโค้ดเฉพาะ (หรือเรียกอีกอย่างว่าเบรกพอยต์) และจะนำคุณเข้าสู่สภาพแวดล้อมที่คล้ายกับ irb ซึ่งคุณสามารถประเมินโค้ด ruby ในบริบทของโปรเจ็กต์ของคุณ หรือดำเนินการอย่างใดอย่างหนึ่ง มีประโยชน์ แงะ คำสั่ง
การใช้แงะเป็นเรื่องง่ายมาก :
สิ่งที่คุณต้องทำคือวาง binding.pry
ที่คุณต้องการติดตั้ง pry เบรกพอยต์
คุณจะต้องกำหนดให้ pry เข้าไปในโปรเจ็กต์ของคุณด้วย (ต้องการ 'pry')
หากคุณต้องการทำเพียงชั่วคราว คุณสามารถเรียกสคริปต์ทับทิมของคุณดังนี้:
ruby -rpry app.rb
ซึ่งจะไม่เป็นประโยชน์สำหรับแอป rails มากนัก ดังนั้นคุณอาจต้องการเพิ่ม pry ลงใน Gemfile ของคุณ
สิ่งที่ฉันชอบทำคือการมีมาโคร/ข้อมูลโค้ดในโปรแกรมแก้ไขของฉันที่มี require อยู่ในบรรทัดเดียวกันมากกว่าเบรกพอยต์ ดังนั้นเมื่อฉันลบมัน ฉันจะลบทั้งสองสิ่ง
นี่คือสิ่งที่คุณจะเห็นเมื่อคุณถูกทิ้งในเซสชั่นการสอดรู้สอดเห็น:
หากคุณต้องการออกจากเซสชัน pry โดยสมบูรณ์ คุณสามารถพิมพ์ ออก! หากคุณทำ ออก regular เป็นประจำ มันรันโปรแกรมของคุณจนถึงเบรกพอยต์ถัดไป
พลังของการงัดไม่ได้จบที่นี่ ตัวอย่างเช่น คุณสามารถใช้ ls
คำสั่งเพื่อดูว่าอ็อบเจ็กต์สามารถเข้าถึงเมธอดและตัวแปรอินสแตนซ์ใดได้
อย่าลืมเรียกใช้ ความช่วยเหลือ คำสั่งเพื่อรับรายการสารพัดทั้งหมด!
โปรแกรมแก้ไขข้อบกพร่อง Ruby อื่น:บายบัก
Byebug สามารถทำหน้าที่เป็นตัวแทนที่ pry หรือเป็นตัวดีบั๊กที่เหมือน gdb สำหรับ Ruby
หากคุณต้องการใช้สำหรับอดีต คุณก็แค่ปล่อย ลาก่อน แทน binding.pry
ที่คุณต้องการให้รหัสของคุณหยุด ข้อเสียอย่างหนึ่งของการใช้ Byebug กับ pry คือไม่มีการเน้นไวยากรณ์
มาดูกันว่าคุณจะตั้งค่าเบรกพอยต์และดีบักโค้ดภายใน บายบักได้อย่างไร!
โดยปกติคุณจะเรียกคำสั่ง help แต่ในกรณีนี้ขาดข้อมูลเล็กน้อย:
ดังนั้นคุณจะต้องศึกษาเอกสารประกอบ
คุณสามารถดูวิธีการใช้คำสั่ง break และหมายเลขบรรทัดที่คุณสามารถกำหนดเบรกพอยต์ได้
ในการรับรายการเบรกพอยต์ คุณสามารถใช้ข้อมูลเบรกพอยต์ .
เมื่อตั้งค่าเบรกพอยต์แล้ว คุณสามารถเลื่อนการทำงานของโปรแกรมโดยใช้คำสั่งต่อไปนี้:
- ขั้นตอน (ล่วงหน้าหนึ่งคำสั่ง ก้าวเข้าสู่การเรียกใช้เมธอด)
- ต่อไป (ล่วงหน้าหนึ่งคำสั่ง ไม่ได้รับวิธีการภายใน)
- ไปต่อ (วิ่งจนถึงจุดสิ้นสุดหรือจุดพักถัดไป)
หากคุณพิมพ์ enter โดยไม่มีคำสั่งใด ๆ โดยเพียงแค่ทำซ้ำอันสุดท้าย สิ่งนี้มีประโยชน์มากเมื่ออ่านโค้ดของคุณ
เมื่อทุกอย่างล้มเหลว
อย่าลืมหยุดพักเมื่อคุณใช้เวลาพอสมควรและมองไม่เห็นวิธีแก้ปัญหา เมื่อคุณกลับมาพร้อมดวงตาที่สดใส คุณจะรู้ว่าทางออกอยู่ตรงหน้าคุณแล้ว คุณสามารถลองอธิบายปัญหาให้คนอื่นฟังได้
บางครั้งคุณไม่แน่ใจว่าปัญหาอยู่ที่ไหน เมื่อสิ่งนี้เกิดขึ้น คุณยังมีตัวเลือกมากมาย
ตัวอย่างเช่น คุณอาจต้องการแสดงความคิดเห็นในช่วงของโค้ดเพื่อพยายามแยกปัญหาออก
หากปัญหาหายไป คุณสามารถยกเลิกความคิดเห็นบางส่วนของรหัสที่คุณเพิ่งแสดงความคิดเห็นได้
นี่เป็นโซลูชันที่ใช้เทคโนโลยีต่ำมาก แต่อาจเป็นสิ่งที่คุณต้องการจริงๆ
ถ้าคุณมาไกลขนาดนี้และดูเหมือนว่าจะไม่มีอะไรช่วย :
ได้เวลาดึงปืนใหญ่ออกมาแล้ว
นี่คือเครื่องมือระบบบางส่วนที่คุณมักจะพบว่ามีประโยชน์
หนึ่งในเครื่องมือเหล่านี้คือ Wireshark ซึ่งจะช่วยให้คุณตรวจสอบการรับส่งข้อมูลในเครือข่ายได้
หากคุณกำลังจัดการกับทราฟฟิกที่เข้ารหัส SSL พร็อกซี mitm (คนตรงกลาง) เช่น mitmproxy อาจช่วยคุณได้
คุณยังสามารถลอง ดัดผม เพื่อเริ่มต้นการเชื่อมต่อ HTTP จากเทอร์มินัลของคุณ ซึ่งอาจช่วยให้คุณดีบักการตอบสนองของเซิร์ฟเวอร์ที่ไม่ถูกต้อง
เครื่องมือที่มีประโยชน์อีกอย่างหนึ่งคือ strace (เฉพาะลินุกซ์เท่านั้น)
Strace จะแสดงการเรียกของระบบทั้งหมดที่แอปของคุณทำ
คุณสามารถกรองการเรียกระบบเฉพาะได้โดยใช้ตัวเลือก -e ทางเลือกที่ทันสมัยกว่าสำหรับ strace คือ sysdig
คำเตือน! คุณอาจต้องการหลีกเลี่ยงการใช้ strace ในการผลิต เนื่องจากจะทำให้ประสิทธิภาพของระบบที่อยู่ระหว่างการทดสอบลดลงอย่างมาก
สุดท้าย หากคุณกำลังจัดการกับปัญหาที่ดูเหมือนว่ามาจากอัญมณีภายนอก ขั้นตอนที่ชัดเจนคือการตรวจสอบซอร์สโค้ดของอัญมณี
คุณสามารถใช้ อัญมณีเปิด
บทสรุป
แม้ว่าการดีบักจะไม่ใช่กิจกรรมที่สนุกที่สุด แต่ก็มีเครื่องมือและเทคนิคมากมายที่จะช่วยให้คุณใช้งานได้ง่ายขึ้น ลองใช้สิ่งเหล่านี้เพื่อช่วยคุณ
โปรดแบ่งปันโพสต์นี้หากคุณสนุกกับมันเพื่อให้ ppl สามารถเรียนรู้ได้มากขึ้น! 🙂
ขอบคุณค่ะ