คุณจะดีบักโดยไม่มี IDE ได้อย่างไร [ปิด]

61

ทุกครั้งที่ฉันมองหา IDE (ปัจจุบันฉันกำลังใช้งาน Go) ฉันจะพบกระทู้ที่เต็มไปด้วยผู้คนที่แนะนำ Vi, Emacs, Notepad ++ เป็นต้น

ฉันไม่เคยทำการพัฒนาใด ๆ นอกเหนือจาก IDE; ฉันคิดว่าฉันใจแตก คุณจะดีบักโดยไม่มี IDE ได้อย่างไร คุณ จำกัด การเข้าสู่ระบบหรือไม่?

ide debugging

— ConditionRacer
แหล่งที่มา

53

แก้จุดบกพร่องสไตล์ Oldschool printf เท่าที่ผมรู้ :-)

— แอนดรูวอลเตอร์ส

25

ในวันก่อน IDEs เราใช้ debuggers ที่แนบมากับกระบวนการทำงานหรือห่อกระบวนการเพื่อให้ก้าวหรือวิปัสสนาของสถานะโปรแกรม (gdb, perl -d, etc ... ) การรวมตัวดีบั๊กเข้ากับ IDE ทำให้สะดวก แต่ก็มีอยู่ต่างหาก การดีบักล้มเหลวกำลังบันทึก ... เพียงตรวจสอบให้แน่ใจว่าการบันทึกไม่เปลี่ยนสถานะของโปรแกรมเมื่อถูกนำออกจากระบบและนำข้อผิดพลาดที่คุณพยายามค้นหากลับมาใช้ใหม่

7

คำสั่งดีบักบรรทัด (แก้จุดบกพร่องหลาย IDE จะขึ้นอยู่กับพวกเขา)

— วงล้อประหลาด

14

ช้าและอย่างระมัดระวัง

— FrustratedWithFormsDesigner

3

ในขณะที่การพิมพ์เป็นเรื่องธรรมดาการใช้งานสามารถซ่อนข้อบกพร่องบางอย่างที่ละเอียดกว่าเช่นสภาพการแข่งขัน

— James

86

โดยใช้ตัวดีบัก ส่วนใหญ่แล้วนี่คือสิ่งที่ IDE ทำเบื้องหลัง - มันแค่ห่อประสบการณ์ใน GUI

บน Unix ซึ่งเป็นหนึ่งในจุดบกพร่องที่ใช้กันมากที่สุดคือ GNU gdbซึ่งได้แทนที่ส่วนใหญ่ก่อนหน้านี้ debuggers dbxยูนิกซ์เช่น

ที่จะได้รับความคิดของสิ่งที่ดูเหมือนว่าการแก้จุดบกพร่อง / รู้สึกเหมือนจากบรรทัดคำสั่งคุณสามารถดูคู่มือ gdb

ในขณะที่พื้นที่อื่น ๆ โดยใช้โปรแกรมดีบักจากบรรทัดคำสั่งต้องมีการเรียนรู้ไวยากรณ์และชุดของคำสั่ง แต่นำมาด้วยจำนวนมากของความยืดหยุ่นและ scriptability ในทางกลับกันถ้าคุณมีความสะดวกสบายในการทำงานในเอดิเตอร์เช่น vim หรือ emacs คุณอาจพบว่าเอดิเตอร์ที่คุณโปรดปรานมีปลั๊กอินสำหรับดีบักเกอร์ที่คุณชื่นชอบ

— jimwise
แหล่งที่มา

18

+1 สำหรับ "โดยใช้โปรแกรมดีบั๊ก" I in IDE ย่อมาจาก "Integrated" :)

— joshin4colours

1

ถ้าคุณเขียนใน Python pdbดีกว่าดีบักเกอร์ IDE ที่ฉันพบ

— asthasr

1

@syrion และipdbดีกว่านั้น;)

— Izkata

ยอดเยี่ยม - ฉันไม่รู้ว่ามีอยู่จริง Izkata ขอบคุณ

— asthasr

@ joshin4colours รวมเข้าด้วยกัน! = ไม่รวม?

— โคลจอห์นสัน

35

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

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

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

คนที่แตกต่างกันมีสไตล์ที่แตกต่างกันและสไตล์ที่แตกต่างจะดีกว่าสำหรับงานที่แตกต่างกัน พิมพ์คำสั่งไม่จำเป็นต้องเป็นขั้นตอนลงจากดีบักเกอร์ ขึ้นอยู่กับสิ่งที่คุณกำลังทำ โดยเฉพาะอย่างยิ่งในภาษาที่ไม่มีการดีบักเกอร์แบบดั้งเดิม

— GlenPeterson
แหล่งที่มา

7

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

— ชื่อปลอม

2

+1 going backwardsทั้งหมดสำหรับ ฉันมักจะมีประสบการณ์: "เฮ้ - ไม่เป็นไรค่านี้ไม่ถูกต้อง! สิ่งนี้กลายเป็นสิ่งนี้ได้อย่างไร" และต้องย้อนกลับไปมาในขณะที่อ่านรหัส นักแก้จุดบกพร่องไม่ดีที่ด้านหลัง

— Izkata

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

— Brian

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

— Newtopian

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

— Nishant

11

บางคนใช้gdbที่บรรทัดคำสั่งหรือปลั๊กอิน นอกจากนี้ยังมีหน้าแบบสแตนด์อโลน GUI จบลงไป gdb เช่นDDD ขึ้นอยู่กับภาษาของคุณมี GUI ดีบักแบบสแตนด์อโลนเฉพาะภาษาเช่นWinpdbสำหรับ python หรือjswatสำหรับ java เพราะโครงการเหล่านี้มุ่งเน้นเพียงการแก้ไขข้อบกพร่องพวกเขามักจะดีกว่าแก้จุดบกพร่องแบบบูรณาการ

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

— Karl Bielefeldt
แหล่งที่มา

1

1 ตัวเลือกอื่น ๆ ของหลักสูตรคือการตั้งค่ารูปแบบสีและ keybinds ในการแก้ไข IDE และหลอก :)

— darvids0n

1

@ darvids0n ฉันใช้ IDEs มานานกว่ายี่สิบปีแล้วและฉันยังมีอีกหนึ่งคนที่มีเอดิเตอร์ที่เริ่มคิดที่จะนึกถึงสักวันหนึ่งว่าบางทีในศตวรรษหน้าอาจจะนึกถึงการพยายามเริ่มพยายาม ถือเทียนให้ GNU Emacs

— John R. Strohm

6

บางภาษาเสนอ REPL - นั่นคือคุณสามารถเขียนและดำเนินการบรรทัดรหัสตามบรรทัดที่คุณเขียนซึ่งอาจเป็นขั้นตอนแรกในการตรวจสอบชิ้นส่วนของรหัส หลายสิ่งเหล่านี้ยังมีสิ่งอำนวยความสะดวกในการแก้ไขข้อบกพร่อง GHC สำหรับ Haskell มาพร้อมกับ GHCi ซึ่งสามารถใช้ในการดีบักแบบโต้ตอบในโปรแกรมในบรรทัดคำสั่งคล้ายกับที่ IDE ทำ

— CodexArcanum
แหล่งที่มา

2

ฉันไม่เข้าใจว่าทำไมมีความเกลียดชังในการดีบักด้วยการใช้คำสั่ง printf มีเวลาที่ต้องใช้เวลาในการคอมไพล์ใหม่และเชื่อมโยงโปรแกรมนานเกินไป แต่วันนี้มันใช้เวลาเพียงไม่กี่วินาที ฉันพบว่ามันง่ายมากที่จะทำการ debug โดยใช้ cout, printf, qDebug (), ฯลฯ ชนิดของเอาต์พุต คำสั่ง Printf ให้ประวัติการใช้งานทุกอย่างที่โปรแกรมทำซึ่งคุณสามารถวิเคราะห์ได้หลังจากข้อเท็จจริงในขณะที่การเรียกใช้ในโปรแกรมดีบั๊กทำให้คุณต้องจำการไหลของโปรแกรมด้วยตนเอง ด้วย printf's คุณสามารถแปลงค่าของตัวแปรเป็นหน่วยที่เฉพาะเจาะจงแสดงในรูปแบบเลขฐานสิบหกทศนิยมอะไรก็ได้ คำสั่ง printf สามารถแสดงรายการชื่อของรูทีนและตัวแปรและหมายเลขบรรทัดได้เช่นกัน คุณสามารถแสดงรายการองค์ประกอบอาเรย์บางอย่างเท่านั้นโดยขึ้นอยู่กับตัวแปรอื่น ๆ คุณสามารถติดตามทิศทาง คุณสามารถควบคุมเอาต์พุตได้อย่างง่ายดาย ใส่ตัวนับพิมพ์เฉพาะบางครั้งผ่านลูปเพิ่มและลบคำสั่งการพิมพ์ขณะที่คุณดีบั๊กมีระดับการดีบั๊กเอาต์พุตเขียนไฟล์ ฯลฯ มันง่ายกว่ามากในการดูประวัติของโปรแกรมที่เขียนลงไฟล์ พยายามจดจำสถานที่ทั้งหมดที่คุณก้าวผ่านด้วยตนเองและอาจต้องเขียนเนื้อหาของตัวแปรตามที่เปลี่ยนแปลงไปตามกาลเวลาเพื่อค้นหาสิ่งที่โปรแกรมทำ และสุดท้ายด้วยคำสั่ง printf คุณสามารถปล่อยไว้ในแบบถาวรเพื่อเปิดและปิดสำหรับการดีบักในอนาคต ดูประวัติโปรแกรมของคุณที่เขียนลงไฟล์ได้ง่ายกว่าที่จะจำสถานที่ทั้งหมดที่คุณก้าวผ่านด้วยตนเองและอาจต้องเขียนเนื้อหาของตัวแปรตามที่เปลี่ยนแปลงไปตามเวลาเพื่อค้นหาว่าโปรแกรมใดบ้าง ได้ทำ และสุดท้ายด้วยคำสั่ง printf คุณสามารถปล่อยไว้ในแบบถาวรเพื่อเปิดและปิดสำหรับการดีบักในอนาคต ดูประวัติโปรแกรมของคุณที่เขียนลงไฟล์ได้ง่ายกว่าที่จะจำสถานที่ทั้งหมดที่คุณก้าวผ่านด้วยตนเองและอาจต้องเขียนเนื้อหาของตัวแปรตามที่เปลี่ยนแปลงไปตามเวลาเพื่อค้นหาว่าโปรแกรมใดบ้าง ได้ทำ และสุดท้ายด้วยคำสั่ง printf คุณสามารถปล่อยไว้ในแบบถาวรเพื่อเปิดและปิดสำหรับการดีบักในอนาคต

— Robert Felten
แหล่งที่มา

3

"มีเวลาที่ต้องใช้เวลาในการคอมไพล์และเชื่อมโยงโปรแกรมนานเกินไป แต่วันนี้มันใช้เวลาเพียงไม่กี่วินาที" ขึ้นอยู่กับภาษาและขนาดของโครงการ ถ้าฉันเปลี่ยนไฟล์ส่วนหัวในโครงการปัจจุบันของฉันจะใช้เวลาประมาณ 65 นาทีในการสร้างใหม่บนเครื่อง 32-CPU ที่มี 256GB RAM (ฉันไม่ได้ล้อเล่น)

— Nemanja Trifunovic

ผู้คนไม่มี "aversions" เพื่อทำการดีบั๊กด้วยคำสั่งพิมพ์พวกเขาเพียงต้องการดีบักเกอร์ ฉันรู้จัก "คน printf" มากกว่าที่ไม่เคยใช้ debuggers มากกว่า "คนดีบั๊ก" ที่ไม่เคยดีบั๊กกับ printfs

— Karl Bielefeldt

1

เป็นการยากที่จะใช้ตัวดีบักสำหรับระบบที่มีการกระจายอย่างเพียงพอ แต่ก็เป็นไปได้ที่จะมีความสัมพันธ์กับบันทึก หากระบบซอฟต์แวร์ของคุณประกอบด้วยไบนารีที่รันบนเครื่องที่แตกต่างกัน 100 เครื่องบันทึก / "การแก้จุดบกพร่อง printf" อาจจะง่ายกว่าการใช้ตัวแก้จุดบกพร่องและพยายามทำให้ทุกอย่างอยู่ในขั้นตอนการล็อคที่เพียงพอซึ่งคุณไม่ได้แนะนำปัญหาอื่น ๆ

— Vatine

2

jimwise ตอบคำถามได้ดีทีเดียว แต่ฉันคิดว่าฉันควรเพิ่มว่าคุณควรเลือกที่จะทำงานได้โดยไม่ต้อง IDE เต็มไมโครซอฟท์มีให้คำสั่งดีบักบรรทัดสำหรับ Windows เรียกว่าCDB CDB มาพร้อมกับเครื่องมืออื่น ๆ รวมถึงWinDBGซึ่งเทียบเท่ากับ GUI เมื่อคุณดาวน์โหลด Windows SDK

— Drew Marsh
แหล่งที่มา

4

คุณช่วยอธิบายรายละเอียดเพิ่มเติมได้อย่างไรว่าคำถามนั้นถาม

— ริ้น

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

— Drew Marsh

2

ฉันมักจะไม่ใช้ดีบักเกอร์บางทีทุกๆสองสามสัปดาห์ แต่ไม่ใช่สิ่งแรกที่ฉันไป

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

ฉันเดาวิธีทั่วไปที่สองที่ฉันตรวจพบปัญหาง่ายๆคือมันอาจเป็นรหัสที่ฉันเพิ่งเปลี่ยน ฉันเรียกใช้การทดสอบหน่วยบ่อย ๆ ดังนั้นโดยทั่วไปฉันรู้ว่าสิ่งที่ฉันยากจน

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

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

หากคุณได้รับการเข้ารหัสตลอดการใช้ตรรกะและการบันทึกระดับ debug / ติดตามก็สามารถเป็นกรณีของการตรวจสอบงบบันทึกที่ยอดเยี่ยมของคุณ (อาจเพิ่มระดับการบันทึก) เพื่อหาปัญหาโดยไม่ต้องเข้าถึงฮาร์ดแวร์

แม้ว่าฉันคิดว่าเครื่องมือดีบั๊กเป็นเครื่องมือที่ทรงพลัง แต่อย่าให้มันเป็นเครื่องมือเดียวในกล่องเครื่องมือของคุณ!

— บิลเค
แหล่งที่มา

1

ไม่มีเหตุผลใดที่คุณไม่สามารถใช้ดีบักเกอร์ใน IDE ควบคู่ไปกับเครื่องมือแก้ไขข้อความแบบสแตนด์อโลน ฉันเคยใช้! Zap เพื่อแก้ไข JBuilder เพื่อแก้ไขข้อบกพร่องในเครื่องอื่นและไฟล์เซิร์ฟเวอร์ในห้องใต้ดิน โปรแกรม debuggers แบบดั้งเดิมนั้นเป็นโปรแกรมแบบสแตนด์อโลนโดยไม่ต้องลากไปตาม IDE และก็ใช้ได้เช่นกัน

เป็นที่น่าสังเกตว่าการทดสอบที่ครอบคลุมช่วยแก้จุดบกพร่องได้ การพิจารณาจุดบกพร่องที่รายงานจะเป็นข้อบกพร่องในการทดสอบของคุณแทนที่จะเป็นในโค้ดของคุณ

printfนอกจากนี้ยังมี มันจะมีประโยชน์ในการสร้าง "การบันทึก" จำนวนมากและค้นหาผ่านแทนที่จะหยุดทุกบรรทัด ฉันพบว่ามีประโยชน์อย่างยิ่งหากคุณสามารถปรับเปลี่ยนคลาสไลบรารีที่คุณจะไม่สามารถปรับเปลี่ยนในการผลิตเช่นใช้-Xbootclasspath/p:เพื่อแฮ็คคลาสไลบรารี Java

— Tom Hawtin - tackline
แหล่งที่มา

"เป็นเรื่องที่น่าสังเกตว่าการทดสอบที่ครอบคลุมจะช่วยแก้จุดบกพร่องได้" - ฉันจะบอกว่าลดน้อยลงแทนที่จะ "แทนที่" มีบางครั้งที่การรันโค้ดผ่านดีบักเกอร์นั้นมีประโยชน์แม้ในขณะที่ทำการทดสอบ TDD - เช่นเมื่อการทดสอบให้ผลลัพธ์ที่ไม่คาดคิดอย่างสมบูรณ์การค้นหาว่าสิ่งที่ผิดไปนั้นมีประโยชน์มาก - เป็นที่ยอมรับ รหัสคุณเพียงแค่เขียนนั่นหมายความว่าคุณได้พลาดกรณีขอบในการทดสอบก่อนหน้านี้ แต่ไม่เกิดขึ้น ...

— จูลส์

1

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

คุณสามารถใช้pudbซึ่งเป็นคอนโซลที่มีส่วนต่อประสานผู้ใช้อย่างง่าย คุณสามารถเลือกดีบักเกอร์ที่คุณต้องการเช่น pdb หรือ ipdb ถ้าคุณต้องการป้อน REPL และตรวจสอบรายละเอียดเพิ่มเติม

นอกจากนี้โปรดตรวจสอบPythonDebuggingTools Wiki เพื่อรับชุดเครื่องมือที่ครอบคลุมมากขึ้น

— Nishant
แหล่งที่มา

คำถามเดิมเกี่ยวกับ Go ไม่ใช่ Python

— TMN

ใช่ฉันพลาดไปอย่างใด มันเกิดขึ้นในการค้นหาของฉันเมื่อฉันกำลังตรวจสอบตัวดีบัก Python

— Nishant