คุณดำดิ่งลงสู่ฐานรหัสขนาดใหญ่ได้อย่างไร

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

ฉันกำลังคิดถึงเครื่องมือเช่นgrep, ctagsการทดสอบหน่วย, การทดสอบการใช้งาน, เครื่องสร้างแผนภาพคลาส, กราฟการโทร, การวัดโค้ดเช่นsloccountและอื่น ๆ ฉันจะสนใจประสบการณ์ของคุณผู้ช่วยที่คุณใช้หรือเขียนเองและขนาดของรหัสฐานที่คุณทำงาน

ฉันรู้ว่าการทำความคุ้นเคยกับฐานรหัสเป็นกระบวนการที่เกิดขึ้นเมื่อเวลาผ่านไปและความคุ้นเคยอาจหมายถึงอะไรก็ได้ตั้งแต่ "ฉันสามารถสรุปรหัส" เป็น "ฉันสามารถปรับโครงสร้างและย่อขนาดเป็น 30% ของขนาด" แต่จะเริ่มได้อย่างไร

สิ่งที่ฉันทำมาตลอดคือ:

เปิดตัวแก้ไขของฉันหลายชุด (Visual Studio / Eclipse / Anything) จากนั้นตรวจแก้จุดบกพร่องและแบ่งบรรทัดตามขั้นตอนต่างๆ ค้นหาการไหลของรหัสติดตามสแต็คเพื่อดูว่าจุดสำคัญอยู่ที่ไหนและไปจากที่นั่น

ฉันสามารถดูวิธีหลังจากวิธี - แต่มันดีถ้าฉันสามารถคลิกที่บางสิ่งบางอย่างแล้วดูว่าในรหัสจะถูกดำเนินการและทำตาม ให้ฉันได้รู้ว่านักพัฒนาต้องการทำงานอย่างไร

คุณกินช้างอย่างไร

ครั้งละคำกัด :)

ฉันพยายามพูดคุยกับผู้เขียนรหัสอย่างจริงจังก่อน

ฉันต้องแฮ็คจนกว่าฉันจะทำงานเสร็จ

ในระดับใหญ่ใช่ (ขออภัย)

แนวทางที่คุณอาจพิจารณา:

1. ลองค้นหาว่าควรใช้รหัสใดในแง่ธุรกิจ
2. อ่านเอกสารทั้งหมดที่มีอยู่ไม่ว่ามันจะแย่แค่ไหน
3. พูดคุยกับทุกคนที่อาจรู้บางอย่างเกี่ยวกับรหัส
4. ดูรหัสในโปรแกรมดีบั๊ก
5. แนะนำการเปลี่ยนแปลงเล็กน้อยและดูว่ามีอะไรแตก
6. ทำการเปลี่ยนแปลงรหัสเล็กน้อยเพื่อให้ชัดเจนยิ่งขึ้น

บางสิ่งที่ฉันทำเพื่อชี้แจงรหัสคือ:

1. เรียกใช้ตัวเลือกรหัสล่วงหน้าเพื่อจัดรูปแบบโค้ดอย่างสวยงาม
2. เพิ่มความคิดเห็นเพื่ออธิบายสิ่งที่ฉันคิดว่าอาจทำ
3. เปลี่ยนชื่อตัวแปรเพื่อให้ชัดเจนยิ่งขึ้น (ใช้เครื่องมือการเปลี่ยนโครงสร้างใหม่)
4. การใช้เครื่องมือที่เน้นการใช้สัญลักษณ์ทั้งหมดอย่างเฉพาะเจาะจง
5. การลดความยุ่งเหยิงในรหัส - ใส่ความคิดเห็นรหัสความคิดเห็นที่ไม่มีความหมายการกำหนดค่าเริ่มต้นของตัวแปรที่ไม่มีจุดหมายและอื่น ๆ
6. เปลี่ยนรหัสเพื่อใช้ข้อกำหนดรหัสปัจจุบัน (อีกครั้งโดยใช้เครื่องมือการปรับโครงสร้างใหม่)
7. เริ่มที่จะแยกการทำงานเป็นกิจวัตรที่มีความหมาย
8. เริ่มเพิ่มการทดสอบหากทำได้ (ไม่บ่อย)
9. กำจัดตัวเลขเวทย์มนตร์
10. ลดการทำซ้ำหากทำได้

... และการปรับปรุงอื่น ๆ ที่คุณสามารถทำได้

ความหมายที่อยู่เบื้องหลังมันทั้งหมดจะค่อยๆชัดเจนขึ้น

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

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

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

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

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

ทำงานกับที่ปรึกษาหรือคนในทีมอย่างแน่นอนหากคุณต้องรับคำตอบ

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

ฉันชอบทำสิ่งต่อไปนี้เมื่อฉันมีไฟล์ต้นฉบับขนาดใหญ่:

• คัดลอกระเบียบทั้งหมดลงในคลิปบอร์ด
• วางใน Word / textmate อะไรก็ได้
• ลดขนาดตัวอักษรให้น้อยที่สุด
• เลื่อนลงดูที่รูปแบบในรหัส

คุณจะประหลาดใจกับความแปลกของโค้ดที่ดูเมื่อคุณกลับไปที่เครื่องมือแก้ไขปกติของคุณ

มันต้องใช้เวลา

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

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

"ทำไมคุณถึงทำส่วนนี้แบบนี้"

"ฉันสังเกตว่าคนส่วนใหญ่ที่ออนไลน์กำลังทำเช่นนี้และคุณทุกคนก็ทำอย่างอื่นทำไมถึงเป็นเช่นนั้น?"

"อะไรที่ทำให้คุณทุกคนเลือกเทคโนโลยี X มากกว่าเทคโนโลยี Y"

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

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

cscope สามารถทำสิ่งใดก็ตามที่ ctags สามารถทำได้สำหรับ C บวกนอกจากนี้ยังสามารถแสดงรายการที่เรียกฟังก์ชันปัจจุบันทั้งหมด รวมทั้งเร็วมาก ปรับขนาดได้อย่างง่ายดายนับล้าน LOC บูรณาการอย่างเรียบร้อยเพื่อ emacs และเป็นกลุ่ม

ตัวนับรหัส C และ C ++ - cccc สามารถสร้างตัวชี้วัดโค้ดในรูปแบบ html ฉันใช้ wc เพื่อรับ LOC ด้วย

doxygen สามารถสร้างเน้นไวยากรณ์และรหัสอ้างอิงข้ามใน html มีประโยชน์ในการเรียกดูฐานรหัสขนาดใหญ่

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

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

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

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

จากนั้นกดเรียกใช้และเริ่มเดินรหัสสำหรับสิ่งที่ดูเหมือนจะเป็นฟังก์ชั่นที่สำคัญ

หารและพิชิต ฉันดูแต่ละฟังก์ชันการทำงานและรหัสที่เกี่ยวข้องขั้นตอนเหล่านั้นและไปต่อไปสร้างภาพทั้งหมด

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

1. เรียกใช้การทดสอบทั้งหมดหากคุณมีและดูว่ารหัสใดครอบคลุมและไม่
2. หากรหัสที่คุณต้องการเปลี่ยนไม่ครอบคลุมให้ลองเขียนการทดสอบเพื่อให้ครอบคลุม
3. เปลี่ยนรหัส อย่าทำลายการทดสอบ

ดูการทำงานของ Michael Feathers อย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม

นี่คือรายการสั้น ๆ ของฉัน:

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

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

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

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

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

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

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

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

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

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

ฉันจะบอกว่าเริ่มต้นด้วยเอกสารเป็นต้น แต่จากประสบการณ์ของฉันความลึกของเอกสารและความรู้ท้องถิ่นมักจะแปรผกผันกับอายุขนาดและความซับซ้อนของระบบ

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

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

ฉันทำไปมาก ...

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

1. รับเป้าหมายระบบนั้นควรแก้ไข (หากไม่ได้เขียน) - เขียนไว้ ถามผู้จัดการพนักงานคนอื่นแม้ในอดีตจะว่าง ถามลูกค้าหรือค้นหาเอกสารใด ๆ
2. รับข้อมูลเฉพาะ หากไม่มีอยู่ - เขียน มันไม่คุ้มค่าที่จะถามใครสักคนเพื่อมันราวกับว่ามันไม่มีอยู่จริงคุณอยู่ในสถานการณ์ที่คนอื่นไม่สนใจอะไรมาก ดังนั้นวิธีเดียวในการเขียนของตัวเอง (ต่อมามันจะง่ายขึ้นอ้างถึงมัน)
3. รับออกแบบ ไม่มีอยู่ - เขียน พยายามอ้างอิงเอกสารและซอร์สโค้ดให้มากที่สุด
4. เขียนรายละเอียดการออกแบบเพื่อเป็นส่วนหนึ่งที่คุณต้องการเปลี่ยนแปลง
5. กำหนดวิธีการทดสอบ ดังนั้นคุณสามารถมั่นใจได้ว่ารหัสเก่าและใหม่ทำงานในลักษณะเดียวกัน
6. ทำให้ระบบสามารถสร้างได้ในขั้นตอนเดียว และทดสอบด้วยรหัสเก่า วางไว้ที่ SVC หากยังไม่ได้ดำเนินการ
7. ใช้การเปลี่ยนแปลง ไม่ก่อนหน้านี้
8. ตรวจสอบหลังจากหนึ่งเดือนไปแล้วว่าไม่มีอะไรเสียหาย

สิ่งที่ต้องทำอีกหนึ่งทางเลือกซึ่งอาจต้องใช้ระหว่างแต่ละขั้นตอน: f off manager (เจ้าของโครงการ) ที่บอกคุณว่า "การเปลี่ยนแปลงเหล่านี้ควรจะทำเมื่อวานนี้" หลังจากผ่านไปสองสามโครงการเขาอาจจะเริ่มช่วยหารายละเอียดและเอกสารล่วงหน้า

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

PS: ฉันจำรหัสหนึ่งที่ใช้สำหรับไคลเอนต์ 5 ที่มีการตั้งค่าที่แตกต่างกัน และการเปลี่ยนแปลงแต่ละครั้ง (คุณสมบัติใหม่) จำเป็นต้องมีการคิดว่า "ใช้ชิ้นส่วนใด" และ "สิ่งที่ไคลเอ็นต์การกำหนดค่ามี" จึงไม่ต้องเบรกอะไรและไม่ต้องคัดลอกรหัส การวางการตั้งค่าของพวกเขาลงในโครงการ cvs และการเขียนรายละเอียดช่วยลดเวลาคิดนี้เกือบเป็น 0

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

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

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

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

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

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

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

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

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

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

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

ถ้าเพียง 1 เมธอด / ฟังก์ชั่นเรียก C มันจะเป็นการเปลี่ยนแปลงที่ค่อนข้างปลอดภัย หากวิธีการ / ฟังก์ชั่น 100s เรียก C มันจะมีผลกระทบมากกว่า

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

หากเป็นโคลนก้อนใหญ่คุณอาจไม่เคยเข้าใจ (หรือต้องการเข้าใจ) ผลงานภายในของมัน

บางสิ่งที่ฉันทำ ...

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

2) เจาะลึกรหัสบนลงล่างในEclipse (ดีที่มีตัวแก้ไขที่สามารถเรียกดูข้อมูลอ้างอิง ฯลฯ ) ได้จนกว่าฉันจะได้รู้ว่าเกิดอะไรขึ้นและเกิดขึ้นที่ไหนในฐานรหัส

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

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

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

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

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

นี่คือขั้นตอนที่เราใช้สำหรับกำจัดรายการที่ซ้ำกัน

• เลือกคำนำหน้าความคิดเห็นมาตรฐานสำหรับรายการที่ซ้ำกัน (เราใช้[dupe]ทันทีหลังจากเครื่องหมายความคิดเห็น
• เขียนรายละเอียดกับทีมงานของคุณเกี่ยวกับชื่อที่จะใช้สำหรับกระบวนการที่ซ้ำกัน;
• รอบแรก: ทุกคนใช้ไฟล์บางไฟล์และเพิ่ม[dupe][procedure_arbitrary_name]ก่อนทำซ้ำขั้นตอน;
• รอบที่สอง: ทุกคนใช้โพรซีเดอร์หรือเซตย่อยของโพรซีเดอร์และกำหนดค่าที่ระบุลำดับของความน่าพอใจของการใช้งานที่มีจุดประสงค์เดียวกันที่แตกต่างกัน (สตริงจะเป็น[dupe][procedure_arbitrary_name][n]:);
• รอบที่สาม: ผู้รับผิดชอบในแต่ละขั้นตอนเขียนใหม่ในคลาสที่เกี่ยวข้อง
• รอบที่สี่: grepมีความสุข!

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

1. อ่านรหัสเพื่อทำความเข้าใจองค์ประกอบที่คุณกำลังแก้ไข
2. เปลี่ยนรหัสและทำความเข้าใจวิธีการที่ส่งผลกระทบต่อระบบโดยรอบ
3. ทดสอบการเปลี่ยนแปลงและระบุว่าส่วนประกอบมีปฏิสัมพันธ์กันอย่างไร
4. เขียนกรณีทดสอบและหวังว่าจะแบ่งหนึ่งหรือสองกรณีทดสอบเพื่อให้คุณได้รับการแก้ไขและเข้าใจค่าคงที่ของระบบ
5. สร้างสิ่งหรือเห็น CI สร้างมันแล้วส่งมัน

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

สิ่งเล็ก ๆ น้อย ๆ ที่ฉันต้องการเพิ่ม:

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

ฉันขอแนะนำให้ใช้เครื่องบินฟรีท่ามกลางตัวเลือกการทำแผนที่มากมาย

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

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

สร้าง / อัพเดตเอกสารการสร้างสภาวะแวดล้อมซอฟต์แวร์ เครื่องมือทั้งหมดนิสัยใจคอตัวเลือกการติดตั้ง ฯลฯ ไปที่นี่

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

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

ผลข้างเคียงอย่างหนึ่งคือคุณจะต้องสร้างเครื่องมือด้วยตนเองคุณสามารถอ้างอิงเดือนนับจากนี้เมื่อคุณลืม

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

ฉันเขียนโพสต์ที่มีความยาวพอสมควรในหัวข้อนี้ นี่คือข้อความที่ตัดตอนมา

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

1. สร้างแผ่นคำศัพท์
2. เรียนรู้แอปพลิเคชัน
3. เรียกดูเอกสารที่มีอยู่
4. ทำให้สมมติฐาน
5. ค้นหาห้องสมุดบุคคลที่สาม
6. วิเคราะห์รหัส

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

นำมาจาก: กระบวนการสำหรับการเรียนรู้ Codebase ใหม่

มีเคล็ดลับเล็ก ๆ น้อย ๆ ที่ฉันสามารถแบ่งปันได้

สำหรับผลิตภัณฑ์ที่มีอยู่ฉันเริ่มทำการทดสอบอย่างเข้มข้น ถ้าเลือก / รับมอบหมายงานฉันจะมุ่งเน้นไปที่คุณสมบัติเฉพาะเพิ่มเติม

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

• ขั้นตอนต่อไปคือการสร้างคลาสไดอะแกรมอย่างง่ายพร้อมความรับผิดชอบ (เช่นการ์ด CRC)

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

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

เป็นเวลานานแล้วที่ฉันต้องดำดิ่งสู่ฐานรหัสขนาดใหญ่ของตัวเอง แต่ในช่วงสองสามปีที่ผ่านมาฉันพยายามหลายครั้งเพื่อให้นักพัฒนาใหม่เข้าสู่ทีมที่เรามีฐานรหัสที่มีอยู่ค่อนข้างใหญ่

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

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

กระบวนการนี้ได้พิสูจน์แล้วว่าค่อนข้างประสบความสำเร็จ