ทำไมการเพิ่มประสิทธิภาพเร็วเกินไปจึงไม่ดี


168

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

ฉันไม่เข้าใจสิ่งนี้จริง ๆ มันจะไม่ยากอย่างไม่น่าเชื่อที่จะเปลี่ยนโครงสร้างหลักของเกมในตอนท้ายแทนที่จะพัฒนาพวกมันเป็นครั้งแรกด้วยประสิทธิภาพในใจ

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

มีคนอธิบายให้ฉันฟังบ้างไหมว่าทำไมจึงเป็นความคิดที่ไม่ดีที่จะเพิ่มประสิทธิภาพเร็วเกินไป


ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท
Josh

3
ตอบง่ายกว่านี้: "มันเสียเวลา" คุณอาจถามว่า "ทำไมต้องพยายามประหยัดเงินเมื่อซื้อของ"
Fattie

27
ตรงกันข้ามทราบว่าวิศวกรหลายคนมากเพียงบอกว่าประโยคที่ว่า "ไม่เพิ่มประสิทธิภาพเร็วเกินไป" เป็นเพียงที่ไม่ถูกต้อง ประโยคควรเป็นเพียง "อย่าเพิ่มประสิทธิภาพจนกว่าคุณจะรู้ว่าสิ่งที่จะเพิ่มประสิทธิภาพ" ดังนั้นค่อนข้างง่ายหากมีสามระบบ A, B และ C มันเป็นสิ่งที่ไร้ประโยชน์ที่สุดในการปรับ A ถ้ามันกลายเป็นว่า A ไม่ได้อยู่ในลักษณะใด ๆ ของคอขวดและ C ก็คือคอขวดจริง ๆ ในตัวอย่างนั้นเห็นได้ชัดว่าการปรับให้เหมาะสม A จะเป็นการเสียเวลาที่สุด ดังนั้น - ค่อนข้างง่าย - ไม่เพิ่มประสิทธิภาพจนกว่าคุณจะรู้ซึ่งของ, BC เพื่อเพิ่มประสิทธิภาพ: นั่นคือทั้งหมดที่มันหมายถึงมันเป็นเรื่องที่ง่าย
Fattie

2
การปรับระดับเวลาของแอปพลิเคชันของคุณให้เหมาะสมในระหว่างการพัฒนานั้นแตกต่างจากการพยายามโกนคำแนะนำบางอย่างออกจากลูปซึ่งโดยปกติจะเป็นเวลาคงที่ มุ่งเน้นที่ O (n) vs O (n log n) แทน "การเขียน a สำหรับลูปด้วยวิธีนี้จะช่วยประหยัดคำสั่ง CPU หนึ่งคำสั่ง"

1
@phyrfox ที่จริงแล้วการลดความเร็วในการโหลดดูเหมือนจะน่าประทับใจสำหรับฉัน เวลาในการโหลดสามวินาทีนั้นสังเกตได้ง่าย ฉันไม่แน่ใจว่าถ้าเห็นว่า 55fps ถึง 60fps
immibis

คำตอบ:


237

บทนำ:

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

"อย่าเพิ่มประสิทธิภาพก่อนเวลาอันควร" ไม่ได้หมายความว่า "เขียนโค้ดที่คุณรู้ว่าไม่ดีเพราะ Knuth บอกว่าคุณไม่ได้รับอนุญาตให้ล้างข้อมูลจนกว่าจะสิ้นสุด"

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

ซึ่งหมายความว่าเมื่อมีข้อสงสัยเราควร:

  • ชอบรหัสที่เขียนง่ายเข้าใจง่ายและปรับเปลี่ยนได้ง่ายสำหรับผู้เริ่ม

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

การปรับให้เหมาะสมก่อนวัยอันควรไม่ใช่ :

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

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

  • การใช้อัลกอริทึมที่เหมาะสมสำหรับงาน A * นั้นเหมาะสมที่สุดและซับซ้อนกว่าการค้นหากราฟเส้นทางอย่างละเอียด นอกจากนี้ยังเป็นมาตรฐานอุตสาหกรรม การทำซ้ำชุดรูปแบบการใช้วิธีที่พยายามแล้วจริงเช่นนี้จะทำให้โค้ดของคุณง่ายต่อการเข้าใจมากกว่าถ้าคุณทำอะไรง่ายๆ แต่ตอบโต้กับวิธีปฏิบัติที่ดีที่สุดที่รู้จัก หากคุณมีประสบการณ์การทำงานในคอขวดที่ใช้ฟีเจอร์เกม X ทางเดียวในโปรเจ็กต์ก่อนหน้านี้คุณไม่จำเป็นต้องไปที่คอขวดเดิมอีกครั้งในโปรเจ็กต์นี้เพื่อให้รู้ว่าเป็นเรื่องจริง - คุณสามารถและควร เกม.

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

ดังนั้นตอนนี้เมื่อล้างข้อมูลไปแล้วทำไมเราอาจพบว่านโยบายนี้มีประโยชน์ในเกมโดยเฉพาะ:


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

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

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

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

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

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

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

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


38
มีการอภิปรายเพิ่มเติมเกี่ยวกับ StackOverflow ที่นี่โดยเน้นความสำคัญของความสามารถในการอ่านและความชัดเจนในโค้ดและอันตรายของการทำให้โค้ดยากต่อการเข้าใจ
DMGregory

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

1
@Baldrickk ฉันว่ามันคุ้มค่าที่จะแบ่งปันเป็นคำตอบเพิ่มเติม (ฉันโหวตขึ้น!) คำตอบของฉันข้ามความสำคัญของสถาปัตยกรรมและการวางแผนเพื่อหลีกเลี่ยงการสร้างปัญหาใหญ่ตั้งแต่แรก สำหรับการอ้างอิงของ Gizmo เกี่ยวกับ "การพัฒนาโปรแกรมโดยทั่วไป" นั้นเป็นสิ่งที่แนวคิดการเพิ่มประสิทธิภาพก่อนวัยอันควรมาจากนี้ ดังที่อธิบายไว้ข้างต้นการเพิ่มประสิทธิภาพที่ไม่ถูกต้องอาจกลายเป็นหนี้ทางเทคนิคเช่นเดียวกับการเพิ่มประสิทธิภาพที่ขาดหายไป แต่เราควรเน้นว่าเราไม่เคยทำสิ่งต่าง ๆ อย่างช้าๆโดยจงใจเลือกความเรียบง่ายและความชัดเจนอ่านได้จนกว่าเราจะสามารถค้นหาและค้นหาปัญหาที่แท้จริง
DMGregory

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

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

42

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

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

สำหรับฉันแล้วนี่คือจุดเริ่มต้นของคำถาม

เมื่อสร้างการออกแบบดั้งเดิมของคุณคุณควรพยายามออกแบบให้มีประสิทธิภาพ - ในระดับสูงสุด นี่เป็นการปรับให้เหมาะสมน้อยลงและมีโครงสร้างมากขึ้น

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

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

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

ตัวเลือก:

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

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

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

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

TL; DR:

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

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


16
ในตอนแรกคุณยังสามารถใช้เรือข้ามฟากของคุณได้เช่นIRiverCrossingกันและเมื่อปริมาณการจราจรมากเกินไปสำหรับการติดตั้งเรือข้ามฟากให้ใช้สะพานเป็นIRiverCrossingและปล่อยมันเคล็ดลับที่แน่นอนคือการลด API ภายนอกของ Ferry และ Bridge เพื่อการใช้งานทั่วไปเพื่อให้สามารถแสดงโดยอินเทอร์เฟซเดียวกัน
Mr.Mindor

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

2
ตัวอย่างที่ดีมากว่าทำไมวันนี้ OOP จึงสำคัญมาก
Jaime Gallego

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

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

24

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

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

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

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

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

เป็นตัวอย่างของเกมล่าสุดที่มีการเพิ่มประสิทธิภาพมากมายฉันชี้ไปที่ Factorio ส่วนที่สำคัญอย่างหนึ่งของเกมคือสายเข็มขัด - มีหลายพันชิ้นและพวกเขามีวัสดุหลายชิ้นรอบโรงงานของคุณ เกมเริ่มต้นด้วยเอ็นจิ้นที่มีประสิทธิภาพสูงสุดหรือไม่? No! ในความเป็นจริงการออกแบบสายพานแบบดั้งเดิมนั้นแทบจะเป็นไปไม่ได้ที่จะปรับให้เหมาะสม - มันเป็นการจำลองทางกายภาพของไอเท็มบนสายพานซึ่งสร้างสิ่งที่น่าสนใจที่คุณสามารถทำได้ (นี่คือวิธีที่คุณจะได้เพลย์ "ฉุกเฉิน" ผู้ออกแบบ) แต่หมายความว่าคุณต้องจำลองทุกรายการบนสายพาน ด้วยสายพานนับพันคุณจะได้รับไอเท็มจำลองทางกายภาพนับหมื่น - แม้เพียงแค่ถอดสายพานและปล่อยให้สายพานทำงานช่วยให้คุณสามารถลดเวลา CPU ที่เชื่อมโยงได้ถึง 95-99% แม้ไม่คำนึงถึงสิ่งต่าง ๆ เช่นหน่วยความจำท้องถิ่น แต่มันมีประโยชน์ที่จะทำอย่างนั้นเมื่อคุณไปถึงขีด จำกัด เหล่านั้นจริงๆ

ทุกอย่างที่เกี่ยวกับเข็มขัดนั้นจะต้องถูกจัดแจงใหม่เพื่อให้สายพานนั้นได้รับการปรับให้เหมาะสม และเข็มขัดจำเป็นต้องได้รับการปรับให้เหมาะสมเพราะคุณต้องการสายพานจำนวนมากสำหรับโรงงานขนาดใหญ่และโรงงานขนาดใหญ่เป็นแหล่งท่องเที่ยวหนึ่งของเกม ท้ายที่สุดถ้าคุณไม่มีโรงงานขนาดใหญ่ทำไมต้องมีโลกที่ไม่มีที่สิ้นสุด ตลกที่คุณควรถาม - เวอร์ชันก่อนหน้าไม่ได้ :) เกมนี้ได้รับการทำใหม่และปรับรูปแบบใหม่หลาย ๆ ครั้งเพื่อให้ได้มาซึ่งตอนนี้ - รวมทั้งรีเมคที่สมบูรณ์แบบ 100% เมื่อพวกเขารู้ว่า Java ไม่ใช่หนทาง เกมแบบนี้และเปลี่ยนเป็น C ++ และมันใช้งานได้ดีสำหรับ Factorio (แม้ว่ามันจะยังคงเป็นสิ่งที่ดีที่มันไม่ได้รับการปรับปรุงให้ดีขึ้นจากการไปโดยเฉพาะอย่างยิ่งเนื่องจากนี่เป็นโครงการงานอดิเรกซึ่งอาจจะล้มเหลวเพียงเพราะขาดความสนใจ)

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

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

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


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

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

@Fattie คุณเข้าใจคำถาม แต่ไม่ใช่คำตอบใช่ไหม คุณแค่พยายามจะบอกว่าคำตอบที่ง่ายกว่านั้นเป็นไปได้ (เช่น "เศรษฐศาสตร์")? ฉันไม่เห็นว่าความคิดเห็นของคุณควรจะสร้างสรรค์อย่างไร
Luaan

2
@Fattie หากคุณคิดว่าคำตอบคือ "เพิ่มประสิทธิภาพเฉพาะเมื่อคุณรู้ว่าคอขวดคืออะไร" ให้โพสต์เป็นคำตอบ คุณใช้คำไปมากกว่าคำตอบที่ดีมากแล้วดังนั้นไปข้างหน้า การเพิ่มประสิทธิภาพแบบใดที่ไม่ทำให้ดีขึ้นและแย่ลง? ฉันไม่เคยเห็นอย่างแน่นอน สิ่งพื้นฐานที่ฉันกล่าวย้ำอยู่เสมอคือมันเป็นการแลกเปลี่ยนเวลาที่สามารถใช้ในที่อื่นได้ดีกว่าความซับซ้อนที่จำกัดความยืดหยุ่นของคุณ ... ตัวอย่างชี้ให้เห็นว่า "เร็ว" ไม่ใช่คำที่สมบูรณ์ การเพิ่มประสิทธิภาพบางอย่างจำเป็นจากวันที่หนึ่ง
Luaan

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

10

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

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

สมมติว่าเรามีขอบเขตคงที่ที่กำหนดโดยกรอบงานหรือเอนจิ้นที่เรากำลังทำงานด้วย

ป้อนคำอธิบายรูปภาพที่นี่

จากนั้นเราจะสร้างเลเยอร์ / โมดูลแรกของเกมต่อไป

ป้อนคำอธิบายรูปภาพที่นี่

ก้าวต่อไปเราสร้างเลเยอร์ / โมดูลที่สอง

ป้อนคำอธิบายรูปภาพที่นี่

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

ป้อนคำอธิบายรูปภาพที่นี่

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

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

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

ดังนั้นเราจึงรวบรวมทั้งหมด ...

ป้อนคำอธิบายรูปภาพที่นี่

อืมคุณเห็นสิ่งที่เกิดขึ้นไหม

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

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

ป้อนคำอธิบายรูปภาพที่นี่

และการปรับระดับต่ำสุดของระบบของเรานั้นไม่เป็นไปได้อีกต่อไปเพราะมันถูกฝังอยู่ภายใต้เลเยอร์อื่นทั้งหมด

อย่างไรก็ตามหากเราเลือกที่จะรอด้วยการกระตุ้นเพื่อเพิ่มประสิทธิภาพทันทีที่เราจะได้สิ่งที่เป็นเช่นนี้:

ป้อนคำอธิบายรูปภาพที่นี่

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

ป้อนคำอธิบายรูปภาพที่นี่

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


3
ฉันกำลังลบโฆษณา เราไม่สนใจว่าคุณจะสร้างภาพได้อย่างไร ส่วนที่สำคัญเพียงอย่างเดียวคือการสันนิษฐานว่าคุณมีสิทธิ์โพสต์
Gnemlock

2
@ Genemlock ยุติธรรมเพียงพอในขณะที่ความตั้งใจของฉันไม่ได้มุ่งไปที่การโฆษณาฉันยังสามารถดูว่ามันตีความผิดได้ง่ายเช่นนี้อย่างไรและฉันจะยอมรับว่ามันไม่ได้เพิ่มคำตอบลงไปดังนั้นจึงไม่มีที่อยู่ในนั้น
เพดานตุ๊กแก

2
ฉันคิดว่าคำอุปมาสายตานี้มีประสิทธิภาพอย่างยิ่ง วิธีการตอบคำถามที่ยอดเยี่ยม! :)
DMGregory

8

เงิน

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

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

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

* คำตอบอื่น ๆ ให้ความสำคัญกับส่วน 'เวลา' เป็นอย่างดี


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

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


1
@JBentley เป็นจุดที่ถูกต้อง อย่างไรก็ตามมีคำตอบที่สืบเนื่องมาจาก "ทำไม" ในฐานะที่เป็นนัยของประสบการณ์ที่รวบรวมได้โดยตรง ดังนั้น 1) การเพิ่มประสิทธิภาพในช่วงต้นจะนำไปสู่การเสียเวลาในส่วนของรหัสที่ไม่ส่งผลกระทบต่อรันไทม์เฉลี่ย (ได้รับประสบการณ์ที่คุณควรรู้ซึ่งสร้างรหัสมีผู้สมัครสำหรับการเพิ่มประสิทธิภาพการปฏิบัติที่ดีที่สุด) 2) การเพิ่มประสิทธิภาพในช่วงต้นสามารถสร้างรหัสที่ยาก ในการบำรุงรักษาเนื่องจากข้อ จำกัด การออกแบบที่กำหนดในบางระบบ คุณอาจได้รับการแลกเปลี่ยนน้อยเกินไปสำหรับรอบการพัฒนาที่นานขึ้น / รหัสที่ยุ่งยากในการบำรุงรักษา
teodron

3
@JBentley พิจารณาสิ่งนี้เป็นส่วนเสริมของคำตอบของ DMGregory
Alexandre Vaillancourt

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

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

6

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

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

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

พื้นที่ที่แท้จริงของการแก้ปัญหานั้นใหญ่กว่าที่เราคาดไว้ตั้งแต่แรกเพราะเราไม่มีความรู้ที่สมบูรณ์แบบของระบบที่ซับซ้อนมาก

ทำให้มันทำงานก่อน แล้วขันให้แน่น


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

2
@doppelgreener หมายความว่าคุณสร้างโซลูชันที่มีประสิทธิภาพมากขึ้นจนกว่าจะหยุดการผลิตเอฟเฟกต์ที่คุณต้องการ ...
immibis

1
"ทำให้มันทำงานก่อนแล้วจึงรัดให้แน่น" - นั่นจะต้องคุ้มค่ามากเท่ากับคำตอบที่เหลือรวมกัน และไม่ต้องบอกว่าสิ่งอื่น ๆ ไม่ดี
ebyrob

1
@ebyrob: มีอีกคนพูดว่า: "ทำให้มันทำงานถูกต้องทำให้มันเร็ว" wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
ninjalj

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

2

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

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

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

ดังนั้นฉันจะบอกว่ามันดีในแง่ของประสบการณ์การเรียนรู้


2

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

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

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


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

คำตอบที่สมบูรณ์แบบสำหรับคำถามที่เน้นย้ำ
Fattie

2

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

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

สิ่งสุดท้ายที่ฉันต้องการเพิ่มคือภายหลังแม้ว่าคุณไม่ต้องการสร้างเกมอีกต่อไปคุณมีอัลกอริทึม A * ที่ปรับให้เหมาะสมซึ่งคุณสามารถใช้สำหรับเกมถัดไปของคุณ สามารถนำมาใช้ ตัวอย่างเช่นเกมหลายเกมมีรายการสินค้าการสร้างเส้นทางการสร้างขั้นตอนการโต้ตอบระหว่าง npc ระบบการต่อสู้ AI การโต้ตอบส่วนต่อประสานการจัดการอินพุต ตอนนี้คุณควรถามตัวเองว่า - "ฉันเขียนองค์ประกอบเหล่านั้นอีกครั้งกี่ครั้งตั้งแต่ต้น?" พวกเขาเป็น 70-80% ของเกม คุณต้องการเขียนใหม่ตลอดเวลาหรือไม่? และถ้าพวกเขาไม่ได้เพิ่มประสิทธิภาพล่ะ?


5
หากรหัส A * ควรเริ่มปรับให้เหมาะสมวิธีที่เหมาะสมที่สุดคือ "ปรับให้เหมาะสม" คุณทำคู่มือในการประกอบก่อนที่จะทำการวัดประสิทธิภาพหรือไม่? ฉันคิดว่างานทั่วไปที่ไม่เกี่ยวกับการปรับขนาดเล็กควรจะเหลือไว้จนกว่าจะทำการวัดประสิทธิภาพ คอมไพเลอร์การปรับให้เหมาะสมอาจทำงานได้ดีกว่าคุณในการเพิ่มประสิทธิภาพขนาดเล็กและราคาถูกกว่ามาก
gmatht

@ gmatht Well A * อาจแตกต่างไปจากที่ฉันบอกว่ามันมีการออกแบบที่ไม่ดีและทำงานได้ไม่ดี แต่มันสามารถเป็นแบบมัลติเธรดตามกอง Fibonacci มีการคาดการณ์บางอย่างแบ่งออกเป็นชิ้น ๆ หากเรากำลังพูดถึงการหาเส้นทางเราสามารถเพิ่ม Flow Field เพื่อผสมกับ A * นอกจากนี้ยังมีวิธีการปรับให้เรียบความสูงหลาย บางที A * ไม่ใช่ตัวอย่างที่ดีที่สุด แต่อย่างที่ฉันบอกว่าการปรับให้เหมาะสมไม่เกี่ยวข้องกับการเปลี่ยนรหัสจริงนักพัฒนากำลังเปลี่ยนรหัสเพราะมันออกแบบมาไม่ดีเช่นเขาไม่ได้ติดตาม SOLID เป็น 1 เหตุผลถ้าคุณ ได้เขียน A * นี้แล้วคุณไม่จำเป็นต้องเขียนอีกต่อไป
Candid Moon _Max_

@gmatht การเพิ่มประสิทธิภาพขนาดเล็กไม่ใช่ปัญหาจริง ฉันคิดว่า OP หมายถึงวิธีที่ดีที่สุดและมีประสิทธิภาพมากที่สุดในการคำนวณพฤติกรรม AI หรือส่วนแบ่งหรือสิ่งอื่นใด
Candid Moon _Max_

หากคุณรู้วิธีการเขียนสิ่งนี้อย่างมีประสิทธิภาพฉันไม่เห็นปัญหาในการทำเช่นนั้น จะใช้เวลาเท่ากันหรือน้อยกว่านั้น ขึ้นอยู่กับประสบการณ์ของนักพัฒนา ในฐานะโปรแกรมเมอร์ถ้าฉันรู้วิธีแก้ปัญหาที่ดีกว่าฉันจะไม่เขียนเส็งเคร็ง ถ้าฉันรู้วิธีเขียน Fibonacci heap ฉันจะไม่ใช้ List และ sorting เพื่อรับค่า min หรือ max แน่นอนว่าจะใช้เวลาและความพยายามในการเขียนมากกว่าใช้ List.Sort (); แต่จะเกิดอะไรขึ้นถ้าฉันมีสิ่งที่นำกลับมาใช้ใหม่ได้แล้ว
Candid Moon _Max_

2
@CandidMoon ฉันไม่เห็นด้วยกับ "จะใช้เวลาเท่ากันหรือน้อยกว่านี้" เพื่อเขียนโค้ดที่มีประสิทธิภาพ อาจจะใช้เวลาเดียวกันในการเขียนโค้ดที่ไม่มีประสิทธิภาพอย่างเห็นได้ชัด แต่เมื่อความคิดของคุณของ "efficienct" หมายถึงการพิจารณาการช่วงชิงแคชเพิ่มมัลติเธรดโดยใช้ CPU เฉพาะที่มีอยู่ใน CPU บางตัวเท่านั้น (N log N) vs O (N) - สิ่งนั้นยากและผิดพลาดและใช้เวลามากกว่าการใช้งานง่าย คุณทำได้ก็ต่อเมื่อคุณรู้ว่ามันจะมีผลอย่างมากต่อผลลัพธ์สุดท้าย
Michael Anderson
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.