Tại sao nó quá tệ để tối ưu hóa quá sớm?

Sau khi xem xét tối ưu hóa một chút, tôi đã phát hiện ra (nghĩa đen ở mọi nơi) rằng nó dường như là một tội lỗi được công nhận trên toàn cầu để tối ưu hóa một trò chơi quá sớm.

Tôi thực sự không hiểu điều này, sẽ không khó để thay đổi một số cấu trúc cốt lõi của trò chơi, thay vì phát triển chúng lần đầu tiên với hiệu suất trong tâm trí?

Tôi nhận được rằng việc chờ đợi cho đến khi trò chơi kết thúc sẽ cho bạn biết nếu bạn thậm chí cần tối ưu hóa, nhưng dù sao thì bạn cũng không nên làm điều đó, nó có thể mở rộng nhiều loại thiết bị mà trò chơi có thể chạy, điều này sẽ tăng số lượng tiềm năng người chơi.

Ai đó có thể giải thích cho tôi tại sao đó là một ý tưởng tồi để tối ưu hóa quá sớm?

Lời mở đầu:

Một vài ý kiến ​​phản đối đã được nêu ra trong các bình luận, và tôi nghĩ rằng chúng phần lớn xuất phát từ sự hiểu lầm về ý nghĩa của chúng ta khi chúng ta nói "tối ưu hóa sớm" - vì vậy tôi muốn thêm một chút làm rõ về điều đó.

"Đừng tối ưu hóa sớm" không có nghĩa là "viết mã bạn biết là xấu, bởi vì Knuth nói rằng bạn không được phép làm sạch nó cho đến khi kết thúc"

Điều này có nghĩa là "không hy sinh thời gian & mức độ dễ đọc để tối ưu hóa cho đến khi bạn biết phần nào trong chương trình của bạn thực sự cần trợ giúp nhanh hơn." Vì một chương trình thông thường dành phần lớn thời gian của nó trong một vài điểm nghẽn, đầu tư vào việc tối ưu hóa "mọi thứ" có thể không giúp bạn tăng tốc như khi tập trung đầu tư tương tự vào mã bị tắc nghẽn.

Điều này có nghĩa là, khi nghi ngờ , chúng ta nên:

• Thích mã đơn giản để viết, dễ hiểu và dễ sửa đổi cho người mới bắt đầu

• Kiểm tra xem có cần tối ưu hóa thêm không (thường bằng cách lập hồ sơ chương trình đang chạy, mặc dù một nhận xét bên dưới ghi chú khi thực hiện phân tích toán học - rủi ro duy nhất là bạn cũng cần kiểm tra xem toán học của mình có đúng không)

Tối ưu hóa sớm không phải là :

• Các quyết định kiến ​​trúc để cấu trúc mã của bạn theo cách sẽ mở rộng theo nhu cầu của bạn - chọn các mô-đun / trách nhiệm / giao diện / hệ thống truyền thông phù hợp theo cách được xem xét.

• Hiệu quả đơn giản mà không mất thêm thời gian hoặc làm cho mã của bạn khó đọc hơn. Những việc như sử dụng kiểu gõ mạnh có thể vừa hiệu quả vừa giúp ý định của bạn rõ ràng hơn. Lưu vào bộ đệm một tham chiếu thay vì tìm kiếm nó nhiều lần là một ví dụ khác (miễn là trường hợp của bạn không yêu cầu logic vô hiệu hóa bộ đệm phức tạp - có thể giữ việc viết đó cho đến khi bạn tìm hiểu cách đơn giản trước).

• Sử dụng đúng thuật toán cho công việc. A * là tối ưu và phức tạp hơn so với việc tìm kiếm toàn bộ biểu đồ tìm đường. Đó cũng là một tiêu chuẩn công nghiệp. Lặp đi lặp lại chủ đề, tuân theo các phương pháp thử và đúng như thế này thực sự có thể làm cho mã của bạn dễ hiểu hơn so với việc bạn làm một cái gì đó đơn giản nhưng chống lại các thực tiễn tốt nhất đã biết. Nếu bạn có kinh nghiệm gặp phải tình trạng tắc nghẽn khi thực hiện tính năng trò chơi X một cách trong dự án trước đó, bạn không cần phải gặp lại nút cổ chai đó trong dự án này để biết điều đó có thật - bạn có thể và nên sử dụng lại các giải pháp đã hoạt động trong quá khứ Trò chơi.

Tất cả các loại tối ưu hóa này đều được chứng minh rõ ràng và thường sẽ không được gắn nhãn "sớm" (trừ khi bạn đang đi xuống một lỗ thỏ thực hiện tìm đường dẫn tiên tiến cho bản đồ bàn cờ 8x8 của bạn ...)

Vì vậy, bây giờ với điều đó đã được làm rõ, về lý do tại sao chúng ta có thể thấy chính sách này hữu ích trong các trò chơi cụ thể:

Trong gamedev đặc biệt, tốc độ lặp là điều quý giá nhất. Chúng tôi sẽ thường thực hiện và thực hiện lại nhiều ý tưởng hơn là cuối cùng sẽ xuất xưởng với trò chơi đã hoàn thành, cố gắng "tìm niềm vui".

Nếu bạn có thể tạo ra một thợ máy theo cách đơn giản và có thể hơi ngây thơ và chơi thử vào ngày hôm sau, bạn sẽ ở vị trí tốt hơn nhiều so với việc bạn dành một tuần để tạo ra phiên bản tối ưu nhất của nó trước tiên. Đặc biệt là nếu nó bật ra để hút và cuối cùng bạn ném ra tính năng đó. Làm theo cách đơn giản để bạn có thể kiểm tra sớm có thể tiết kiệm được một tấn công việc tối ưu hóa mã lãng phí mà bạn không giữ.

Mã không được tối ưu hóa nói chung cũng dễ dàng sửa đổi và thử các biến thể khác nhau hơn mã được tinh chỉnh để thực hiện một điều chính xác một cách tối ưu, có xu hướng dễ gãy và khó sửa đổi hơn mà không phá vỡ, đưa ra lỗi hoặc làm chậm nó. Vì vậy, việc giữ mã đơn giản và dễ thay đổi thường có giá trị không hiệu quả trong thời gian chạy trong hầu hết quá trình phát triển (chúng tôi thường phát triển trên các máy cao hơn thông số mục tiêu, vì vậy chúng tôi có thể tiếp thu chi phí và tập trung vào trải nghiệm mục tiêu trước) cho đến khi chúng tôi Chúng tôi đã khóa những gì chúng tôi cần từ tính năng này và có thể tối ưu hóa các phần mà chúng tôi biết hiện đang chậm.

Có, việc tái cấu trúc các phần của dự án trong giai đoạn phát triển muộn để tối ưu hóa các điểm chậm có thể khó khăn. Nhưng việc tái cấu trúc lặp đi lặp lại trong suốt quá trình phát triển vì các tối ưu hóa bạn thực hiện trong tháng trước không tương thích với hướng phát triển của trò chơi kể từ đó hoặc đã khắc phục điều gì đó hóa ra không phải là nút cổ chai thực sự khi bạn có thêm các tính năng & nội dung trong.

Các trò chơi thật kỳ lạ và mang tính thử nghiệm - thật khó để dự đoán một dự án trò chơi và nhu cầu công nghệ của nó sẽ phát triển như thế nào và hiệu suất sẽ chặt chẽ nhất. Trong thực tế, chúng ta thường lo lắng về những điều sai trái - tìm kiếm thông qua các câu hỏi về hiệu suất ở đây và bạn sẽ thấy một chủ đề phổ biến xuất hiện của các nhà phát triển bị phân tâm bởi những thứ trên giấy có vẻ không phải là vấn đề.

Lấy một ví dụ ấn tượng: nếu trò chơi của bạn bị ràng buộc GPU (không phổ biến) thì tất cả thời gian đó dành cho việc tối ưu hóa siêu tốc và xâu chuỗi công việc CPU có thể không mang lại lợi ích rõ ràng nào. Thay vào đó, tất cả những giờ dev có thể đã được dành để thực hiện & đánh bóng các tính năng chơi trò chơi, để có trải nghiệm người chơi tốt hơn.

Nhìn chung, hầu hết thời gian bạn dành cho trò chơi sẽ không được dành cho mã mà cuối cùng là nút cổ chai. Đặc biệt là khi bạn đang làm việc trên một công cụ hiện có, các công cụ vòng lặp bên trong siêu đắt trong hệ thống kết xuất và vật lý phần lớn nằm ngoài tầm tay của bạn. Vào thời điểm đó, công việc của bạn trong các kịch bản trò chơi là về cơ bản tránh xa động cơ - miễn là bạn không ném cờ lê vào đó thì có lẽ bạn sẽ xuất hiện khá tốt cho bản dựng đầu tiên.

Vì vậy, ngoài một chút về vệ sinh mã và ngân sách (ví dụ: không liên tục tìm kiếm / xây dựng công cụ nếu bạn có thể dễ dàng sử dụng lại, hãy giữ các truy vấn vật lý / truy vấn vật lý hoặc đọc lại GPU, v.v.), tạo thói quen không kết thúc - tối ưu hóa trước khi chúng ta biết các vấn đề thực sự có ích gì cho năng suất - giúp chúng ta tránh lãng phí thời gian để tối ưu hóa những điều sai trái và giữ cho mã của chúng ta đơn giản hơn và dễ điều chỉnh tổng thể hơn.

lưu ý: câu trả lời này bắt đầu như một nhận xét về câu trả lời của DMGregory, và do đó không lặp lại những điểm rất tốt mà anh ấy đưa ra.

"Sẽ không quá khó để thay đổi một số cấu trúc cốt lõi của trò chơi vào cuối, thay vì phát triển chúng lần đầu tiên với hiệu suất trong tâm trí?"

Điều này, với tôi, là mấu chốt của câu hỏi.

Khi tạo thiết kế ban đầu của bạn, bạn nên cố gắng thiết kế cho hiệu quả - ở cấp cao nhất. Đây là ít tối ưu hóa, và là về cấu trúc.

Ví dụ:
Bạn cần tạo một hệ thống để qua sông. Các thiết kế rõ ràng là một cây cầu hoặc một chiếc phà, vậy bạn chọn cái nào?
Câu trả lời tất nhiên phụ thuộc vào kích thước của giao cắt và lưu lượng giao thông. Đây không phải là một tối ưu hóa, đây là, thay vì bắt đầu với một thiết kế phù hợp với vấn đề của bạn.

Khi được trình bày với các lựa chọn thiết kế, bạn chọn một trong những phù hợp nhất với những gì bạn muốn làm.

Vì vậy, giả sử rằng lưu lượng giao thông của chúng tôi khá thấp, vì vậy chúng tôi quyết định xây dựng hai bến và mua trong một chiếc phà để xử lý lưu lượng. Một triển khai đơn giản tốt đẹp
Thật không may, một khi chúng tôi có nó và chạy, chúng tôi thấy rằng nó đang thấy lưu lượng truy cập nhiều hơn mong đợi. Chúng ta cần tối ưu hóa phà! (bởi vì nó hoạt động và xây dựng một cây cầu bây giờ không phải là một kế hoạch tốt)

Tùy chọn:

• Mua phà thứ hai (xử lý song song)
• Thêm một sàn xe khác để phà (nén lưu lượng)
• Nâng cấp động cơ của phà để làm cho nó nhanh hơn (thuật toán xử lý được viết lại)

Đây là nơi bạn nên cố gắng làm cho thiết kế ban đầu của mình càng mô đun càng tốt.
Tất cả những điều trên là tối ưu hóa có thể, và bạn thậm chí có thể làm cả ba.
Nhưng làm thế nào để bạn thực hiện những thay đổi này mà không thay đổi cấu trúc lớn?

Nếu bạn có một thiết kế mô-đun với giao diện rõ ràng, sau đó nó nên được đơn giản để thực hiện những thay đổi này.
Nếu mã của bạn không được liên kết chặt chẽ, thì các thay đổi đối với các mô-đun sẽ không ảnh hưởng đến cấu trúc xung quanh.

Hãy xem thêm một chuyến phà.
Một chương trình 'xấu' có thể được xây dựng xung quanh ý tưởng về một chiếc phà, và có các trạng thái bến tàu và trạng thái phà và vị trí tất cả được bó lại với nhau và trạng thái chia sẻ. Điều này sẽ khó sửa đổi để cho phép thêm một chiếc phà vào hệ thống.
Một thiết kế tốt hơn sẽ có các bến cảng và phà như các thực thể riêng biệt. Không có bất kỳ sự kết hợp chặt chẽ nào giữa họ, nhưng họ có một giao diện, nơi một chiếc phà có thể đến, dỡ hành khách, tiếp nhận những người mới và rời đi. Bến tàu và phà chỉ chia sẻ giao diện này và điều này giúp dễ dàng thực hiện các thay đổi cho hệ thống, trong trường hợp này bằng cách thêm một chuyến phà thứ hai. Bến tàu không quan tâm đến những gì phà thực sự có, tất cả những gì nó quan tâm là một cái gì đó (bất cứ thứ gì) đang sử dụng giao diện của nó.

tl; dr:

• Cố gắng thiết kế cho hiệu quả ở nơi đầu tiên.
• Khi được trình bày với hai lựa chọn, bạn chọn một lựa chọn hiệu quả hơn.
• Viết mã của bạn theo mô-đun càng tốt với các giao diện được xác định rõ.

Sau đó, bạn có thể thay đổi các cơ chế trong mỗi mô-đun mà không cần cấu trúc lại toàn bộ cơ sở mã khi bạn cần tối ưu hóa.

"Không tối ưu hóa sớm" không có nghĩa là "chọn cách tồi tệ nhất có thể để làm mọi việc". Bạn vẫn cần xem xét ý nghĩa hiệu suất (trừ khi bạn chỉ tạo mẫu). Vấn đề là không làm tê liệt những thứ khác, những thứ quan trọng hơn vào thời điểm phát triển - như tính linh hoạt, độ tin cậy, v.v. Chọn những tối ưu đơn giản, an toàn - chọn những thứ bạn giới hạn và những thứ bạn giữ miễn phí; theo dõi các chi phí. Bạn có nên sử dụng gõ mạnh? Hầu hết các trò chơi đã làm và hoạt động tốt; Bạn sẽ phải trả bao nhiêu tiền để loại bỏ điều đó nếu bạn tìm thấy cách sử dụng thú vị của tính linh hoạt cho trò chơi?

Khó hơn nhiều để sửa đổi mã được tối ưu hóa, đặc biệt là mã "thông minh". Đó luôn là một lựa chọn làm cho một số thứ tốt hơn và những thứ khác tồi tệ hơn (ví dụ: bạn có thể đang giao dịch thời gian CPU để sử dụng bộ nhớ). Khi đưa ra lựa chọn đó, bạn cần nhận thức được tất cả các hàm ý - chúng có thể là thảm họa, nhưng chúng cũng có thể hữu ích.

Ví dụ, Commander Keen, Wolfenstein và Doom đều được xây dựng trên đỉnh của một công cụ kết xuất được tối ưu hóa. Mỗi người đều có "mánh khóe" cho phép trò chơi tồn tại ngay từ đầu (mỗi người cũng có những tối ưu hóa hơn nữa được phát triển theo thời gian, nhưng điều đó không quan trọng ở đây). Đó là tốt . Bạn có thể tối ưu hóa rất nhiều cốt lõi của trò chơi, suy nghĩ đó giúp trò chơi trở nên khả thi; đặc biệt nếu bạn đang khám phá lãnh thổ mới nơi tính năng tối ưu hóa đặc biệt này cho phép bạn xem xét các thiết kế trò chơi chưa được khám phá nhiều. Những hạn chế mà tối ưu hóa giới thiệu cũng có thể mang đến cho bạn lối chơi thú vị (ví dụ: giới hạn số đơn vị trong các trò chơi RTS có thể đã bắt đầu như một cách để cải thiện hiệu suất, nhưng chúng cũng có hiệu ứng chơi trò chơi).

Nhưng hãy lưu ý rằng trong mỗi ví dụ này, trò chơi không thể tồn tại mà không tối ưu hóa. Họ đã không bắt đầu với một công cụ "được tối ưu hóa hoàn toàn" - họ bắt đầu với sự cần thiết hoàn toàn và làm việc theo cách của họ. Họ đã phát triển các công nghệ mới và sử dụng chúng để tạo ra các trò chơi vui nhộn. Và các thủ thuật động cơ được giới hạn ở một phần nhỏ của cơ sở mã càng tốt - tối ưu hóa nặng hơn chỉ được giới thiệu khi trò chơi được thực hiện hầu hết, hoặc khi nó cho phép một tính năng mới thú vị xuất hiện.

Bây giờ hãy xem xét một trò chơi mà bạn có thể muốn thực hiện. Có thực sự có một phép màu công nghệ làm hoặc phá vỡ trò chơi đó? Có lẽ bạn đang mường tượng ra một trò chơi thế giới mở trên một thế giới vô tận. Đó thực sự là phần trung tâm của trò chơi? Trò chơi sẽ không hoạt động mà không có nó? Có thể bạn đang nghĩ về một trò chơi trong đó địa hình có thể biến dạng không giới hạn, với địa chất thực tế và như vậy; bạn có thể làm cho nó hoạt động với một phạm vi nhỏ hơn? Nó sẽ hoạt động ở dạng 2D thay vì 3D? Có được thứ gì đó thú vị càng sớm càng tốt - ngay cả khi việc tối ưu hóa có thể yêu cầu bạn làm lại một khối lượng lớn mã hiện có, nó có thể có giá trị; và bạn thậm chí có thể nhận ra rằng làm cho mọi thứ lớn hơn không thực sự làm cho trò chơi tốt hơn.

Là một ví dụ về một trò chơi gần đây với rất nhiều sự tối ưu, tôi đã chỉ đến Factorio. Một phần quan trọng của trò chơi là những chiếc thắt lưng - có rất nhiều trong số chúng, và chúng mang theo nhiều vật liệu riêng lẻ xung quanh nhà máy của bạn. Trò chơi đã bắt đầu với một động cơ vành đai được tối ưu hóa mạnh mẽ? Không! Trên thực tế, thiết kế vành đai ban đầu gần như không thể tối ưu hóa - nó đã mô phỏng vật lý các vật phẩm trên thắt lưng, tạo ra một số điều thú vị mà bạn có thể làm (đây là cách bạn có được lối chơi "mới nổi" - trò chơi gây ngạc nhiên nhà thiết kế), nhưng có nghĩa là bạn phải mô phỏng từng vật phẩm trên thắt lưng. Với hàng ngàn đai, bạn có được hàng chục nghìn vật phẩm mô phỏng vật lý - thậm chí chỉ cần tháo nó ra và để dây đai hoạt động cho phép bạn giảm thời gian CPU liên quan đến 95-99%, thậm chí không xem xét những thứ như địa phương bộ nhớ. Nhưng nó chỉ hữu ích để làm điều đó khi bạn thực sự đạt đến những giới hạn đó.

Gần như mọi thứ liên quan đến thắt lưng đều phải được làm lại để cho phép dây đai được tối ưu hóa. Và các vành đai cần phải được tối ưu hóa, bởi vì bạn cần rất nhiều dây đai cho một nhà máy lớn, và các nhà máy lớn là một điểm thu hút của trò chơi. Rốt cuộc, nếu bạn không thể có những nhà máy lớn, tại sao lại có một thế giới vô tận? Bạn nên hỏi vui - các phiên bản đầu không :) Trò chơi đã được làm lại và định hình lại nhiều lần để có được vị trí hiện tại - bao gồm cả bản làm lại 100% khi họ nhận ra Java không phải là cách để đi trò chơi như thế này và chuyển sang C ++. Và nó hoạt động rất tốt cho Factorio (mặc dù nó vẫn là một điều tốt nhưng nó không được tối ưu hóa từ việc di chuyển - đặc biệt vì đây là một dự án sở thích, có thể đơn giản là đã thất bại vì không quan tâm).

Nhưng vấn đề là, có rấtrất nhiều điều bạn có thể làm với một nhà máy phạm vi giới hạn - và nhiều trò chơi đã chỉ ra điều đó. Giới hạn có thể thậm chí còn trao quyền cho niềm vui hơn là tự do; Spacechem sẽ vui hơn nếu "bản đồ" là vô hạn? Nếu bạn bắt đầu với "thắt lưng" được tối ưu hóa mạnh mẽ, bạn sẽ bị buộc phải đi theo hướng đó; và bạn không thể khám phá các hướng thiết kế khác (như xem những điều thú vị bạn có thể làm với băng tải mô phỏng vật lý). Bạn đang giới hạn không gian thiết kế tiềm năng của bạn. Có vẻ như không phải vì bạn không thấy nhiều trò chơi còn dang dở, nhưng phần khó là điều thú vị - với mỗi trò chơi thú vị mà bạn thấy, có lẽ hàng trăm người không thể đến đó và bị loại bỏ (hoặc tệ hơn, phát hành như những mớ hỗn độn khủng khiếp). Nếu tối ưu hóa giúp bạn làm điều đó - hãy tiếp tục. Nếu nó không ... nó có khả năng sớm. Nếu bạn nghĩ rằng một số cơ chế chơi trò chơi hoạt động tuyệt vời, nhưng cần tối ưu hóa để thực sự tỏa sáng - hãy tiếp tục. Nếu bạn không có cơ chế thú vị,đừng tối ưu hóa chúng . Trước tiên hãy tìm niềm vui - bạn sẽ thấy hầu hết sự tối ưu không giúp ích gì cho điều đó và thường gây bất lợi.

Cuối cùng, bạn có một trò chơi thú vị, tuyệt vời. Liệu nó có ý nghĩa để tối ưu hóa bây giờ ? Hà! Nó vẫn chưa rõ ràng như bạn nghĩ. Có gì vui khôngbạn có thể làm gì thay thế? Đừng quên thời gian của bạn vẫn còn hạn chế. Mọi thứ đều cần một nỗ lực và bạn muốn tập trung nỗ lực đó vào nơi quan trọng nhất. Có, ngay cả khi bạn đang tạo một "trò chơi miễn phí" hoặc một trò chơi "nguồn mở". Xem cách trò chơi được chơi; chú ý nơi hiệu suất trở thành nút cổ chai. Có phải tối ưu hóa những nơi đó làm cho nhiều niềm vui hơn (như xây dựng các nhà máy lớn hơn, rối hơn bao giờ hết)? Nó có cho phép bạn thu hút nhiều người chơi hơn (ví dụ với các máy tính yếu hơn hoặc trên các nền tảng khác nhau) không? Bạn luôn cần phải ưu tiên - tìm kiếm nỗ lực để đạt tỷ lệ. Bạn có thể sẽ tìm thấy rất nhiều trái cây treo thấp chỉ từ việc chơi trò chơi của bạn và xem những người khác chơi trò chơi. Nhưng lưu ý phần quan trọng - để đạt được điều đó, bạn cần một trò chơi . Tập trung vào đó.

Là một anh đào trên đỉnh, xem xét rằng tối ưu hóa không bao giờ kết thúc. Đây không phải là một nhiệm vụ với một dấu kiểm nhỏ mà bạn hoàn thành và chuyển sang các nhiệm vụ khác. Luôn có "một tối ưu hóa nữa" mà bạn có thể làm và một phần lớn của bất kỳ sự phát triển nào là hiểu được các ưu tiên. Bạn không thực hiện tối ưu hóa để tối ưu hóa - bạn làm điều đó để đạt được một mục tiêu cụ thể (ví dụ: "200 đơn vị trên màn hình cùng một lúc trên Pentium 333 MHz" là một mục tiêu tuyệt vời). Đừng để mất mục tiêu của thiết bị đầu cuối chỉ vì bạn tập trung quá nhiều vào các mục tiêu trung gian thậm chí có thể không còn là điều kiện tiên quyết cho mục tiêu cuối cùng nữa.

Rất nhiều câu trả lời dường như tập trung rất nhiều vào khía cạnh hiệu suất của "tối ưu hóa" trong khi bản thân tôi thích xem xét tối ưu hóa và toàn bộ thử thách tối ưu hóa quá sớm ở mức độ trừu tượng hơn.

Hài hước cho tôi khi tôi cố gắng xây dựng trên quan điểm của tôi với sự giúp đỡ của đa giác.

Giả sử chúng ta có một số ranh giới cố định được thiết lập bởi khung hoặc công cụ mà chúng ta đang làm việc.

Sau đó chúng tôi tiến hành tạo lớp / mô-đun đầu tiên của trò chơi như vậy.

Di chuyển trở đi, chúng tôi xây dựng lớp / mô-đun thứ hai của chúng tôi.

Tại thời điểm này, chúng tôi có thể nhận thấy rằng có một số không gian có sẵn giữa hai mô-đun và chúng tôi có thể được khuyến khích tối ưu hóa nó để sử dụng đầy đủ các ranh giới được phân bổ cho chúng tôi.

Hoàn hảo, bây giờ ứng dụng đang sử dụng đầy đủ các tài nguyên có sẵn cho chúng tôi, ứng dụng tốt hơn, tốt phải không?

Chúng tôi tiến hành xây dựng lớp / mô-đun thứ ba trong ứng dụng của chúng tôi và đột nhiên chúng tôi nhận ra (có lẽ chúng tôi không thể lường trước được trong kế hoạch ban đầu) rằng lớp / mô-đun thứ 3 không hoạt động cho chúng tôi.

Chúng tôi tìm kiếm một giải pháp thay thế, chúng tôi tìm thấy một và cuối cùng, điều này cũng yêu cầu chúng tôi thay đổi mô-đun thứ 2 của ứng dụng vì nó không tương thích với mô-đun thứ 3 mới được chọn. (Rất may là phần nào tương thích với mô-đun đầu tiên của chúng tôi vì vậy chúng tôi không phải viết lại mọi thứ từ đầu.)

Vì vậy, chúng tôi kết hợp tất cả lại với nhau ...

Hmm, bạn có thể thấy những gì đã xảy ra?

Bằng cách tối ưu hóa quá sớm, giờ đây chúng tôi thực sự đã khiến mọi thứ trở nên kém hiệu quả hơn vì những gì chúng tôi tối ưu hóa không phải là những gì chúng tôi đã kết thúc.

Và nếu chúng ta muốn thêm một số mô-đun bổ sung hoặc các mẩu tin bổ sung sau đó, chúng ta có thể không còn khả năng thực hiện chúng vào thời điểm này.

Và việc điều chỉnh mức thấp nhất trong hệ thống của chúng tôi không còn khả thi nữa vì nó đã bị chôn vùi dưới tất cả các lớp khác.

Tuy nhiên, nếu chúng ta đã chọn chờ đợi với mong muốn tối ưu hóa nó ngay lập tức thì chúng ta đã kết thúc với một cái gì đó như thế này:

Và bây giờ nếu chúng ta thực hiện tối ưu hóa vào thời điểm này, chúng ta sẽ có một cái gì đó thỏa mãn để xem xét.

Hy vọng rằng ít nhất một số bạn đã có nhiều niềm vui khi đọc nó như tôi đã rất vui khi làm điều này :) và nếu bây giờ bạn cảm thấy như bạn nắm bắt tốt hơn về chủ đề này - tất cả đều tốt hơn.

Tiền bạc.

Nó đi xuống đó. Tiền bạc. Vì thời gian là tiền *, bạn càng dành nhiều thời gian cho các hoạt động không được đảm bảo để tạo ra nhiều tiền hơn (nghĩa là bạn không thể coi các hoạt động này là đầu tư ), bạn càng có nhiều tiền để lãng phí và càng kiếm được ít tiền tro choi.

Dưới đây là một số tác dụng phụ tiềm năng khác của việc tối ưu hóa quá sớm và lý do tại sao bạn nên tránh nó:

• Đồng nghiệp của bạn ghét bạn vì bạn chơi trong hộp cát với đồ chơi của bạn trong khi họ làm việc chăm chỉ để có được các tính năng.
• Sự chậm trễ làm mất đi sự quản lý cao hơn và khiến nhóm bỏ lỡ ngày giao hàng, điều này khiến trò chơi được phát hành vào mùa xuân thay vì trước kỳ nghỉ lễ, điều này khiến trò chơi không bán đủ. Và vì điều này, trụ sở chính quyết định đóng cửa studio, khiến bạn thất nghiệp một cách hiệu quả. Và không có việc làm có nghĩa là không có tiền. (Và vì không ai thích bạn vì bạn đã dành quá nhiều thời gian để tối ưu hóa sớm, nên không ai muốn viết đánh giá tích cực về công việc của bạn cho bạn trên LinkedIn, điều này sẽ giúp bạn hết tiền trong thời gian dài hơn.)

^{* Các câu trả lời khác đã làm nổi bật đủ phần 'thời gian'}

Như một lưu ý phụ, nói chung , kinh nghiệm giúp xác định cái gì là không và tối ưu hóa sớm và cái gì có giá trị cho doanh nghiệp và cái gì không.

Chẳng hạn, nếu bạn đã làm việc với trò chơi A và nhận ra vào cuối dự án rằng tính năng XYZ đặc biệt nặng về vòng lặp trò chơi của bạn và cuối cùng bạn bắt đầu làm việc với trò chơi B có tính năng chính xác tương tự, quyết định viết lại tính năng và tối ưu hóa nó từ đầu không thực sự tối ưu hóa sớm, vì bạn biết nó sẽ là một nút cổ chai nếu không có gì được thực hiện.

Tối ưu hóa, theo định nghĩa, quá trình tăng hiệu quả của một giải pháp cho đến khi nó mất hiệu quả. Quá trình này ngụ ý sau đó giảm không gian của giải pháp.

Ở giai đoạn đầu phát triển phần mềm vẫn có thể có "yêu cầu ẩn": nếu bạn giảm quá nhiều dung lượng của giải pháp, bạn có thể gặp phải tình huống không thể đáp ứng "yêu cầu ẩn" khi bật lên ở giai đoạn phát triển sau này, buộc bạn phải sửa đổi kiến ​​trúc thêm theo cách này không ổn định và một loạt các hành vi không được xem xét.

Ý tưởng là sau đó để làm cho toàn bộ giải pháp hoạt động và chỉ sau đó, khi tất cả các yêu cầu được cố định và thực hiện, thắt chặt mã. Sau đó, bạn sẽ thấy rằng rất nhiều tối ưu hóa mà bạn đã từng thực hiện một cách nhẹ nhàng trong khi mã hóa, giờ đây không còn khả thi do sự tương tác với các yêu cầu muộn.

Không gian thực của giải pháp luôn lớn hơn so với dự kiến ​​ban đầu vì chúng ta không thể có kiến ​​thức hoàn hảo về một hệ thống rất phức tạp.

Làm cho nó hoạt động đầu tiên. Sau đó thắt chặt các sợi dây.

Nói tóm lại, việc tối ưu hóa sớm thường trở nên lãng phí công sức nếu bạn muốn thay đổi mọi thứ sau đó, và sau đó hóa ra bạn đã tối ưu hóa các cấu trúc mã dễ thay đổi thành một mức độ thấp hơn nhiều và bây giờ bạn cần thay đổi nó trở lại mức cao mức độ tiếp cận, và tối ưu hóa kết quả một lần nữa.

Đây là một lỗi phổ biến đối với các nhà phát triển người mới, những người thích tập trung vào việc đạt được niềm vui từ "đã hoàn thành công việc hữu ích", như tối ưu hóa, không suy nghĩ liệu đó có phải là thời điểm thích hợp để làm việc đó không. Khi bạn có kinh nghiệm lập trình các dự án lớn như trò chơi, bạn sẽ học khi được bảo đảm tối ưu hóa cơ sở mã hiện tại và khi quá sớm. Đừng sợ phạm sai lầm này, bạn sẽ chỉ được hưởng lợi bằng cách học hỏi từ nó.

Nói chung, chỉ tối ưu hóa nếu bạn thực sự không thể làm việc với bản dựng phát triển ngay lúc này. Giống như nếu bạn đang tạo và xóa hàng triệu đối tượng 60 lần mỗi giây.

Vì vậy, tôi muốn nói rằng tốt về mặt kinh nghiệm học tập, để tối ưu hóa sớm một vài lần: p

Tối ưu hóa tập trung vào việc làm cho máy tính hoạt động tốt nhất trên mã trong khi phát triển đòi hỏi phải làm cho lập trình viên làm việc tốt nhất với mã.

Tối ưu hóa không mang lại hiểu biết sâu sắc. Nó làm cho máy tính làm việc ít hơn và lập trình viên nhiều hơn.

Tất nhiên, có nhiều loại khác nhau, như với việc thiết kế một chiếc xe hơi. Không có gì sai khi tối ưu hóa động cơ trước khi bạn xây dựng khung xe đầu tiên của mình, nhưng tối ưu hóa khung xe trước khi bạn không biết hình dạng của động cơ có thể sẽ lãng phí thời gian. Tính mô đun và thông số kỹ thuật có thể có được một số vị trí khả thi cho công việc tối ưu hóa ngay cả trước khi toàn bộ sản phẩm được lắp ráp.

Tôi hoàn toàn không đồng ý với tất cả các tuyên bố rằng mã không nên được tối ưu hóa ở giai đoạn đầu. Nó phụ thuộc vào giai đoạn bạn đang có. Nếu đây là MVP - nguyên mẫu và bạn chỉ đang cố gắng nhìn vào trò chơi mất từ ​​1 đến 2 tuần, rằng bạn đã sẵn sàng viết lại mọi thứ bạn đã viết. Vâng, tối ưu hóa không thành vấn đề. Nhưng nếu bạn đã làm việc với một trò chơi mà bạn biết sẽ được phát hành, thì nó nên có mã tối ưu hóa tất cả cùng. Những câu chuyện mà mọi người nói về các tính năng mới và những thứ có thể được thêm vào là sự hiểu lầm. Đó là kiến ​​trúc mã được thiết kế kém hơn là mã được tối ưu hóa. Bạn không cần phải viết lại bất cứ điều gì để thêm các yếu tố mới nếu bạn có thiết kế mã đẹp.

Ví dụ: nếu bạn có thuật toán tìm đường dẫn A *, sẽ tốt hơn nếu viết nó theo cách tối ưu nhất bạn có thể? Thay vì sau đó thay đổi một nửa mã bạn có vì bạn phải thực hiện một số thay đổi trong thuật toán vì bây giờ nó cần một cuộc gọi phương thức và cuộc gọi lại khác? Và nếu bạn đã có một mã được tối ưu hóa từ đầu, nó sẽ giúp bạn tiết kiệm rất nhiều thời gian. Bởi vì bạn có thể tự vẽ ra mối quan hệ giữa các đối tượng và cách chúng tương tác, thay vì mù quáng tạo ra hàng tấn tập lệnh mới và tạo ra tất cả các kết nối ngay lập tức - điều này dẫn đến mã sphagetti không rõ ràng.

Điều cuối cùng tôi muốn thêm là sau này, ngay cả khi bạn không muốn tạo trò chơi nữa, bạn có thuật toán A * được tối ưu hóa mà bạn có thể sử dụng cho các trò chơi tiếp theo của mình. Tái sử dụng. Ví dụ, nhiều trò chơi có hàng tồn kho, tìm đường, tạo thủ tục, tương tác giữa npc, hệ thống chiến đấu, AI, Tương tác giao diện, quản lý đầu vào. Bây giờ bạn nên tự hỏi - "Đã bao nhiêu lần tôi viết lại những yếu tố đó từ đầu?" Họ là 70-80% của trò chơi. Bạn có thực sự cần phải viết lại chúng mọi lúc? Và nếu chúng không được tối ưu hóa thì sao?