วิธีอ่านโค้ดหลายพันบรรทัดโดยไม่มีเอกสารประกอบ? [ปิด]

ก่อนหน้านี้ฉันค้นหาการควบคุม TimeLine ที่ดีสำหรับโครงการ WPF ฉันพบคำตอบในที่นี่ซึ่งนำฉันไปยังโครงการ CodePlexนี้

ตอนนี้ฉันต้องการเปลี่ยนรหัสเพื่อเลี้ยงความต้องการทางวัฒนธรรมของฉัน แต่มีบางอย่างไม่ตรงกัน!

คำถามของฉันคือ:

คุณโต้ตอบกับโค้ดหลายพันบรรทัดได้อย่างไร

แก้ไข:

ทางลัดใด ๆ จะดีมาก!

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

1. ผ่านรหัส
2. เปลี่ยนชื่อตามต้องการ
3. Refactor ตามต้องการ
4. ทำซ้ำจนกว่าคุณจะเข้าใจอย่างสมบูรณ์

... และรหัสจะขอบคุณสำหรับมัน ;-)

ดำเนินการเดี่ยวแก้ไขข้อบกพร่อง (อีกครั้งและอีกครั้ง) รหัสเพื่อค้นหาว่าการกระทำนั้นสำเร็จได้อย่างไร เขียนเหมือนกันในภาษาง่าย ๆ เพื่อทำความเข้าใจให้ดีขึ้น!

สิ่งที่ Joel Spolsky เขียนกลับมาเมื่อในบล็อกของเขา (ไม่สามารถหาบทความตอนนี้) ติดกับฉันเกี่ยวกับเรื่องนี้:

เขาบอกว่ารหัสไม่ใช่ภาษามนุษย์ธรรมดา แต่ในฐานะโปรแกรมเมอร์เรารู้สึกว่ามันเป็นเรื่องง่ายและเราควรจะสามารถอ่านได้ ดังนั้นเราหลายคนมองไปที่โค้ดใหม่และคาดว่าจะสามารถ "อ่าน" และเข้าใจได้ทันทีราวกับว่ามันเป็นบล็อกข้อความในภาษาอังกฤษ

ดังนั้นฉันคิดว่ากุญแจสำคัญคือต้องช้าช้าเป็นระเบียบและเป็นวิทยาศาสตร์ และอย่างที่คนอื่น ๆ พูด - แสดงความคิดเห็น (และแม้แต่ refactor) ตามที่คุณไป อย่าตกอยู่ในความคิดของ "ฉันควรดูและเข้าใจทันที"

โอ้และใช่ฉันยังตกหลุมพรางนี้บางครั้ง "ทำตามที่ฉันพูดไม่ใช่อย่างที่ฉันทำ" และทั้งหมดนั้น :)

SE-Radio สัมภาษณ์ Dave Thomas เกี่ยวกับเรื่องนี้

ตอนพอดคาสต์นี้มีเคล็ดลับและเทคนิคมากมายในการเข้าสู่ 'วัฒนธรรม' ของโครงการและเข้าใจว่าผู้คนดั้งเดิมอาศัยอย่างไร

ฉันต้องทำสิ่งนี้เมื่อเร็ว ๆ นี้ด้วยโครงการกว่า 100,000 LOC แนวคิดแรกของฉันคือการดูรูปแบบจากกราฟของ 100 หรือ 1,000 โหนดได้ง่ายกว่าจากข้อความ 100,000 บรรทัด

ดังนั้นฉันใช้เวลา 45 นาทีและเขียนโปรแกรม Python (<100LOC) สั้น ๆ เพื่อแยกสิ่งที่ฉันต้องการจากนั้นและวาดความสัมพันธ์ของวัตถุ ฉันสร้างซอร์สGraphvizซึ่งเป็นภาษาที่ง่ายต่อการสร้าง (ไม่มีอะไรพิเศษเกี่ยวกับ Python ที่นี่: Ruby หรือ C # หรือ Lisp สามัญหรืออะไรก็ได้ที่ทำได้เช่นกัน)

ในโครงการอื่น ๆ ฉันเคยเห็นผู้คนใช้ Graphviz สำหรับการอ้างอิงโมดูลกราฟการโทรประวัติรุ่นทุกสิ่ง เครื่องมือสร้างภาพเครื่องมือที่ยอดเยี่ยมที่สุดที่เคยมีมา

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

ก้าวผ่านมันในตัวดีบั๊กขณะที่มันทำงานเกือบจะเป็นวิธีเดียวในการทำความเข้าใจกับโค้ดฐานใหม่ที่มีขนาดใหญ่

ทำความเข้าใจว่าไม่มีทางลัดใด ๆ ในการเดินอย่างสมบูรณ์ (และถ้าคุณมีปัญหากับวลีนั้นการศึกษาของคุณถูกละเลยอย่างมากมันมาจาก "คนแปลกหน้าในดินแดนแปลก" โดย Robert A. Heinlein)

อ่านทีละหน้าทีละหน้าทีละครั้ง เพิ่มความคิดเห็น วาดภาพของโครงสร้างข้อมูลที่สำคัญ รู้จักอัลกอริทึม วาดตามความรู้ก่อนหน้า

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

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

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

การอ่านโค้ดจาวา 14,000 บรรทัดนั้นไม่สมเหตุสมผล ฟังก์ชั่นการค้นหาคือเครื่องมือช่วยชีวิตคุณ

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

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

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

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

ฉันจะเริ่มต้นด้วยการใช้Leo Editorในโหมด @ shadowด้วยการใช้งานโหนดที่ลอกแบบมา สิ่งนี้ช่วยให้หนึ่งสามารถเพิ่มบันทึกย่อและข้อคิดเห็นสำหรับแต่ละส่วนของรหัสภายใต้การศึกษาโดยไม่ต้องเปลี่ยนรหัสและคำอธิบายประกอบจะอยู่ในบริบทเสมอถัดจากรหัสที่พูดถึง นี่คือตัวอย่างขั้นตอนการทำงานของเอกสาร:

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

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

วาดไดอะแกรมของซอร์ส: ความสัมพันธ์ของข้อมูล, ความสัมพันธ์ของฟังก์ชัน, ความสัมพันธ์ของวัตถุ พิจารณาการรวมการไหลของข้อมูลและการไหลของรหัส รูปภาพนั้นดีกว่าความคิดเห็นสำหรับสิ่งนี้และสามารถแยกออกจากโค้ดได้

ก่อนที่คุณจะทำการทดสอบการเขียนอีกครั้ง มีการทดสอบมากมาย การทดสอบที่เฉพาะเจาะจงมาก ๆ กับโค้ดขนาดเล็กที่อย่างน้อยสามารถเรียกใช้ได้เพราะมันจะขึ้นอยู่กับการเขียนระเบียบที่สืบทอดของคุณ

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

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

ฉันใช้เครื่องมือเช่น doxygen เพื่อสร้างแผนภาพคลาสโดยรวมมากกว่าเพิ่มความเข้าใจในสิ่งที่แต่ละชั้นเรียนทำ

จากนั้นฉันก็รับบั๊กง่าย ๆ จากคิวบั๊ก (ก่อนที่ผู้จัดการของฉันจะกำหนดฮาร์ดไดรฟ์ให้ฉัน: P) จากนั้นเรียกใช้ฟังก์ชันการทำงานนั้นให้เป็นดีบั๊กเกอร์และพยายามสร้างกระแสข้อมูลคร่าวหรือรูปแบบการไหลของรหัส

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

เข้าหาข้อบกพร่องเล็กน้อยเช่น NullPointerException หลีกเลี่ยงสิ่งใดที่เกี่ยวกับการเกิดพร้อมกันในตอนแรกสิ่งใดก็ตามที่ธรรมชาติของมันจะเกี่ยวข้องกับการทำความเข้าใจกับรหัสจำนวนมากในครั้งเดียว

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

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

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

และฉันก็อ่านกระดาษสีขาวhttp://queue.acm.org/detail.cfm?id=2063168 ซึ่งพูดถึงสไตล์การเขียนโค้ดหรือวิธีที่เราสามารถใช้พื้นที่การเยื้องการแปรผันของตัวอักษรเป็น IDEs ส่วนใหญ่ที่เราสามารถใช้เขียน MUCH ได้ รหัสทำความสะอาดที่มนุษย์เราสามารถเข้าใจได้มากเท่าที่เครื่องทำ มันเน้นเพิ่มเติมเกี่ยวกับการเขียนรหัสความคิดเห็นฟรีเพื่อให้รหัสของเราจะปรากฏเป็นย่อหน้าเอง