คุณติดตามโครงการขนาดใหญ่ได้อย่างไร

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

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

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

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

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

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

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

ไม่มีทางลัด คุณเพียงแค่ต้องทนทุกข์ผ่านมัน

เพื่อตอบคำถามของคุณเกี่ยวกับวิธีไดอะแกรมDoxygenคือสิ่งที่คุณต้องการ AFAIK ใช้งานได้กับ PHP

โดยทั่วไปแล้วฉันจะผ่านขั้นตอนต่อไปนี้เมื่อพบโค้ดเบสใหม่:

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

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

3. เรียนรู้เกี่ยวกับกรอบสิ่งที่คุณใช้ อย่างน้อยที่สุดคุณควรจะสามารถสร้าง "สวัสดีโลก" หรือแอปพลิเคชันแบบง่าย ๆ ที่มีกรอบดังกล่าวก่อนที่จะดำดิ่งลงสู่แอปพลิเคชันการผลิต

4. รับขั้นตอนการปรับใช้ทั้งหมด (ทำได้ดีที่สุดในขณะที่ผู้พัฒนาดั้งเดิมจับมือคุณไว้) หากคุณไม่สามารถใช้ codebase ปัจจุบันและสร้างและปรับใช้ผ่านสภาพแวดล้อมการทดสอบ / การตรวจสอบความถูกต้อง / ผลิตภัณฑ์ที่แสดงว่าคุณกำลังปิ้งขนมปัง แม้แต่การเปลี่ยนแปลงที่เล็กที่สุดก็ต้องผ่านการปรับใช้ทั้งหมดดังนั้นทำไมไม่ลงส่วนนี้ทันที ในการทำเช่นนี้คุณจะได้รับการแนะนำให้รู้จักกับเซิร์ฟเวอร์ฐานข้อมูลบริการและสคริปต์ที่น่าใช้ทั้งหมดที่แอพใช้ - คุณจะรู้ว่า "มันอยู่ที่ไหน"

5. รับการทดสอบการทำงาน (ถ้ามี) คุณจะรู้ได้อย่างไรว่าสิ่งที่ทำงานอย่างถูกต้อง? ผู้ปฏิบัติงานต้องทำอะไรเพื่อดูแลและให้อาหารแอปพลิเคชัน

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

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

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

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

9. บุ๊กมาร์ก IDE มีค่าสำหรับการแท็กฮอตสปอตใน codebase ความสามารถในการสลับผ่านพวกเขาอย่างรวดเร็วจะส่งเสริมความเข้าใจ

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

ตามที่ร้องขอนี่คือความคิดเห็นของฉันเป็นคำตอบ

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

หาก codebase มีการทดสอบ (การรวมหรือหน่วย) บางครั้งก็คุ้มค่าที่จะเช็คเอาท์เช่นกัน

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

a) ระบุกรอบการเขียนโปรแกรมที่ใช้ซึ่งช่วยในการรู้ว่าแอพพลิเคชั่นทำงานอย่างไร

b) ระบุบริการทั่วไป - การบันทึก, การจัดการข้อยกเว้น, MVC, การเชื่อมต่อฐานข้อมูล, การตรวจสอบ, มุมมอง (การสร้างหน้า) เนื่องจากส่วนนี้เป็นส่วนที่เราจะใช้มากที่สุด

c) เรียกใช้การไหลเวียนของผู้ใช้ทั่วไป (ในแอพพลิเคชั่น) จากนั้นลองจัดเรียงให้เข้ากับวิธีการวางรหัส

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

ฉันจะแจ้งให้คุณทราบว่าความคิดอื่น ๆ ที่ฉันได้รับในช่วงสองสัปดาห์ถัดไป

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

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

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

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

สิ่งที่ฉันได้รับคือแบบจำลองเดี่ยวขนาดใหญ่ที่ประกอบด้วยแบบจำลองย่อยหลายแบบแต่ละแบบประกอบด้วยแพ็คเกจซึ่งประกอบด้วยตัวแยกประเภท ฯลฯ การทำงานในระดับโปรเจ็กต์หลายระดับช่วยให้ฉันสามารถติดตามตัวแยกประเภทแต่ละตัวและการเรียกใช้เมธอด ฉันหมายความว่าวิธีการเดียวกันสามารถเรียกตัวแยกประเภทหนึ่งในโครงการ A และตัวแยกประเภทอื่นในโครงการ B วิธีเดียวที่จะเห็นโครงสร้างแบบเต็มของโครงการคือการกลับรายการทั้งสองในเวลาเดียวกัน ฉันไม่มีเวลาในการสร้างแผนภาพส่วนประกอบและข้อมูลไม่ถูกต้องจริงๆ ฉันต้องการให้คอมพิวเตอร์ย้อนกลับโครงการทั้งหมดสำหรับฉัน ฉันย้อนกลับในแต่ละรอบซ้ำกับทีมและไดอะแกรมทั้งหมดของฉันได้รับการปรับปรุงทันที วิศวกรรมย้อนกลับนั้นเพิ่มขึ้นและใช้การจับคู่ Java กับ UML Ids ฉันหมายความว่าแต่ละองค์ประกอบ java ถูกแมปกับองค์ประกอบ MOF เดี่ยวและไม่ซ้ำกันซึ่งยังคงเหมือนเดิมตลอดชีวิตของโครงการแม้ว่าจะมีการปรับโครงสร้างใหม่ก็ตาม การทำนั้นไม่ จำกัด จำนวนมากสำหรับการสร้างแบบจำลอง UML และอนุญาตให้สร้างแบบจำลองโครงการขนาดใหญ่และซับซ้อนมาก สำหรับข้อมูลของคุณฉันทำงานกับโครงการที่มีรหัส OOP มากกว่า 5,000,000 บรรทัด โครงการทั้งหมดของฉันกลับด้านอย่างถูกต้องและการนำทางแบบกราฟิกเป็นไปได้

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