จะเห็นภาพการออกแบบของเครื่องยนต์ฟิสิกส์ได้อย่างไร

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

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

ดังนั้นแผนภาพชนิดใดที่ฉันควรใช้เพื่อช่วยในการติดตามกระบวนการ อาชีพแผนภาพประเภทใดที่ใช้สร้างเอนจิ้นฟิสิกส์

รายการสิ่งที่ต้องทำเป็นสิ่งมหัศจรรย์

ฉันไม่ได้พูดถึง // #TODO: ความคิดเห็น blah blah ฉันหมายถึงจงซื่อสัตย์ต่อสมุดบันทึกของพระผู้เป็นเจ้า

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

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

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

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

อย่าปล่อยให้สิ่งที่ดำเนินการครึ่ง

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

หยุดคิดว่าคุณต้องการการออกแบบทั้งหมดบนกระดาษ

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

เขียนบันทึกย่อเมื่อคุณหยุดการเข้ารหัส

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

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

"ทุกอย่างควรถูกสร้างขึ้นจากบนลงล่างยกเว้นครั้งแรก" พวกเขาพูด

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

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

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

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

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

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

ทำไดอะแกรมของสถาปัตยกรรม! ท่อ OpenGL แผนภาพ FrustratedWithFormsDesigner โพสต์ในการแสดงความคิดเห็นเป็นตัวอย่างที่ดีสำหรับโปรแกรมการไหลแต่นั่นเป็นเพียงหนึ่งในประเภทของแผนภาพที่สามารถเป็นประโยชน์

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

หากเป็นอย่างดีเอกสารของคุณควรทำให้ผู้อื่นเข้าใจได้ง่าย สิ่งนี้สามารถทำให้สิ่งต่างๆเช่นบทวิจารณ์โค้ดหรือการทำงานร่วมกันแบบโอเพนซอร์สเป็นเรื่องง่าย ดูโครงการขนาดใหญ่เพื่อดูว่าพวกเขาทำสิ่งนี้ได้สำเร็จอย่างไร - เมื่อทำงานกับโค้ดหลายร้อยหรือหลายพันบรรทัดการทำความเข้าใจว่าโปรแกรมทำงานอย่างไรโดยไม่ต้องอ่านมันมีความสำคัญอย่างยิ่งสำหรับการติดตาม codebase หรือแนะนำให้คนอื่น ๆ . พื้นที่เก็บข้อมูลเป็นกลุ่มที่มี 1.3 ล้าน LOC มีเอกสารที่ดีสวยระดับสูง (IMO) สำหรับเรื่องนี้ใน/src/README.txt มันแนะนำ:

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

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

หนึ่งในคุณสมบัติที่ดีที่สุดเกี่ยวกับ Vim /src/README.txtคือความง่ายในการค้นหาและความครอบคลุม มันไม่ได้มีความละเอียดใด ๆ แต่ถ้าคุณคลิกที่srcโฟลเดอร์บน Github มันจะทำการโหลดโดยอัตโนมัติและมันจะบอกทิศทางสำหรับการค้นหารหัสหรือเอกสารอื่น ๆ ตรงกันข้ามกับ Powershell repo ซึ่งฉันมองหาตัวอย่าง แต่ไม่สามารถหาไฟล์หรือไฟล์ใด ๆ ที่เทียบเท่ากับ Vim /src/README.txtได้ (เครื่องหมายที่ไม่ดีสำหรับโครงการที่มี 988,000 LOC!)

บางสิ่งที่คุณอาจต้องการไดอะแกรมหรือเอกสารรวมถึง:

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

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

• Dot / Graphviz ชุดของโปรแกรมสำหรับสร้างกราฟจาก .dotไฟล์
• LaTeX / TikZ เป็นเครื่องมือที่ซับซ้อนและละเอียดมากสำหรับการสร้างกราฟหรือรูปภาพใด ๆ - มันอาจจะหนักเกินไปสำหรับความต้องการของคุณโดยเฉพาะอย่างยิ่งเมื่อการวางตำแหน่งโหนดทั้งหมดเป็นคู่มือ แต่ควรระลึกไว้โดยเฉพาะถ้าคุณวางแผนที่จะเขียน กระดาษหรืออะไรทำนองนั้นในภายหลัง
• สำหรับ C egyptตะขอของ gson เข้าgccและออก.dotกราฟการโทร สามารถเป็นแบบอัตโนมัติหรือฝังในmakeคำสั่งซึ่งเป็นสิ่งที่ดี!
• ที่เกี่ยวข้อง GNU cflowสามารถสร้างกราฟการโทรเฉพาะข้อความสำหรับ C. เครื่องมือเทียบเท่าอาจมีอยู่ในภาษาอื่นแม้ว่าคุณอาจต้องการที่จะหลงทางจากเครื่องมืออัตโนมัติโดยทั่วไป - การไม่สร้างกราฟด้วยตนเองอาจขัดขวางความเข้าใจของโค้ดหรือให้รหัสที่ไม่เหมาะสม ระดับรายละเอียดที่ซับซ้อน (การรู้ว่าการเรียกฟังก์ชั่นprintf()ใดมักจะไม่ช่วยสวย)

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

อ้างอิง

องค์ประกอบสุทธิและคำอธิบายประกอบ: ภาษาโปรแกรม Visual วัตถุประสงค์ทั่วไป (2016) มีให้ที่https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language

องค์ประกอบสุทธิและคำอธิบายประกอบสำหรับการเขียนโปรแกรมคอมพิวเตอร์: การคำนวณและการโต้ตอบใน PDF (2014) มีจำหน่ายที่https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF