วิธีปรับปรุงความสามารถในการดีบักโค้ดที่มีอยู่ [ปิด]

งานทั่วไปในโลกแห่งการทำงานนั้นเกี่ยวข้องกับโค้ดที่มีอยู่ แต่มีบั๊กกี้ อะไรคือเคล็ดลับในการพัฒนาทักษะของคุณในฐานะนักดีบัก?

อย่าคิดอะไร

มันมักจะล่อลวงเพียงแค่พูดว่า "โอ้ฉันรู้ว่ารหัสนี้กำลังทำอะไรอยู่มันโอเค" อย่าทำอย่างนั้น ทดสอบสมมติฐานและก้าวผ่านทุกสิ่งอย่างรอบคอบ

การทดสอบแบบค่อยเป็นค่อยไป

ไปที่ความลึกอันดับแรกในโค้ดของคุณและทดสอบจากโมดูลที่เล็กที่สุดซึ่งค่อย ๆ ขยับขึ้นมาด้วยวิธีนี้คุณจะไม่เครียดจนเกินไปที่จะคิดออกว่าปัญหานั้นอาจจะอยู่ตรงไหน

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

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

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

แทนที่จะเป็นบั๊กสับให้เขียนการทดสอบในแบบฟอร์ม

• ได้รับ ...
• เมื่อ...
• คาดหวังว่า ...

เพื่อตรวจสอบสิ่งที่คุณรู้ว่าจริงเกี่ยวกับการทำงานของแอปกับสิ่งที่คุณคิดว่าเป็นจริง

IDEs ส่วนใหญ่ทำให้ง่ายต่อการแยกวิธีการและสร้าง stubs การทดสอบ xUnit ใช้ประโยชน์จากสิ่งนั้น

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

ทำการดีบัก หากคุณดีบักมากคุณจะปรับปรุง

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

สำหรับกระบวนการดีบักจริง:

• เขียนการทดสอบหน่วยหากยังไม่มีอยู่
• เพิ่มการบันทึกที่เหมาะสมหากยังไม่มี
• จากนั้นใช้การดีบัก

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

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

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

หากคุณสามารถแก้ไขรหัสในขณะที่การดีบัก:

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

ชอบ:

bool isLessThan5 = a < 5;
bool isGreaterThan10 = a > 10;
if ( isLessThan5 || isGreaterThan10 )
{
   // more code here
}

แทน:

if ( a < 5 || a > 10 )
{
   // more code here
}

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

สองสิ่งขึ้นอยู่กับการใช้จ่ายส่วนใหญ่ในช่วง 22 ปีที่ผ่านมาซึ่งคงรหัสไว้ที่คนอื่นเขียน

ทำความเข้าใจกับประเภทของข้อบกพร่องที่คุณมักจะเขียน

ตัวอย่างเช่นฉันเป็น coder ที่พิถีพิถันมากดังนั้นเมื่อรหัสของฉันรวบรวมมันมักจะไม่มีข้อบกพร่องเล็กน้อย ดังนั้นข้อบกพร่องของฉันมักจะเป็นสิ่งที่ซับซ้อนแปลก ๆ เช่นการหยุดชะงักของเธรด ในทางกลับกันฉันมีเพื่อนที่ส่วนใหญ่เขียนข้อบกพร่องเล็ก ๆ น้อย ๆ - อัฒภาคที่ปลาย C ++ สำหรับลูปดังนั้นบรรทัดถัดไปจะถูกประหารเพียงครั้งเดียวสิ่งนั้น

อย่าคิดว่าคนอื่นจะเขียนบั๊กแบบเดียวกับที่คุณทำ

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

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

ขอแนะนำให้อ่านหนังสือหรือเรียนวิธีใช้ตัวดีบั๊กเกอร์ ฉันเรียนสองสามครั้งและอ่านหนังสือสองสามเล่มโดย John Robbins ที่สร้างความแตกต่างอย่างมากในประสิทธิภาพของฉันในฐานะนักดีบัก

ทำความเข้าใจเกี่ยวกับการทำงานของรหัสที่พยายามทำ หากคุณไม่ทราบภาพรวมทั้งหมด (กรณีทดสอบทั้งหมดรหัสนี้ต้องผ่าน) เป็นการยากที่จะดีบักอย่างถูกต้องโดยไม่แนะนำข้อบกพร่องใหม่

เขียนการทดสอบหน่วยอัตโนมัติและการทดสอบบูรณาการและการทำงานอื่น ๆ

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

นอกจากนี้การออกแบบที่ดี - หลักการที่มั่นคง หากคุณกำลังเขียนชั้นเรียนขนาดเล็กที่มุ่งเน้นและให้ความสำคัญกับองค์ประกอบมากกว่าการสืบทอดการขจัดความซ้ำซ้อน ฯลฯ รหัสของคุณจะง่ายต่อการตรวจแก้จุดบกพร่อง

ฉันพบว่ารหัสที่ออกแบบมาอย่างดีจะสร้างชุดข้อบกพร่องที่แตกต่างกันซึ่งรหัสนั้นไม่ได้ออกแบบมาอย่างดี โดยทั่วไปแล้วโค้ดที่ออกแบบมาอย่างดีจะสร้างข้อบกพร่องที่ง่ายต่อการค้นหาทำซ้ำและแก้ไข

ข้อยกเว้น (และมักจะมีอยู่เสมอ) คือรหัสมัลติเธรด :-)

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

ลองอ่านหนังสือที่มีค่ามากว่าทำไมโปรแกรมจึงล้มเหลว: คู่มือสำหรับการดีบั๊กอย่างเป็นระบบโดย Andreas Zeller มันจะแนะนำคุณเกี่ยวกับเทคนิคทฤษฎีและเครื่องมือต่าง ๆ ซึ่งบางอันอยู่ในการวิจัยขั้นสูง

ภาพนิ่งสำหรับหนังสือมีให้ออนไลน์ แต่ฉันพบว่าหนังสือเล่มนี้อ่านง่ายกว่า

หนังสือเล่มนี้จะช่วยให้คุณเริ่มต้นและทำให้คุณคิดเชิงวิทยาศาสตร์มากขึ้นเกี่ยวกับการดีบัก แต่มันไม่ได้ทดแทนการฝึกฝน คุณอาจต้องเขียนและแก้ไขจุดบกพร่องเป็นเวลา 10 ปีก่อนที่จะเห็นลำดับการปรับปรุงประสิทธิภาพในการทำงานของคุณ ฉันยังจำได้ว่าการกรามของฉันที่ Sun เห็นนักพัฒนาอาวุโสซึ่งเป็นผู้เขียนโปรแกรมสำหรับ Unix เป็นเวลา 30 ปีพบข้อผิดพลาดแบบมัลติเธรดหรือข้อบกพร่องแบบขนานที่ชัดเจนในเวลาไม่กี่นาที เรื่องประสบการณ์!