怎麼讓代碼的邏輯更清晰？

01-03

基於Unity開發遊戲的整體設計流程，是應該先去完成一些基礎功能再慢慢拼湊起來？感覺開發邏輯有點混亂，都是想到一小部分就去完成一小部分。然後到最後整合起來的時候就會有各種問題，以及不好做代碼優化。比較好的開發思路應該是什麼？

先把整個遊戲做完，然後再談優化。

等具備三五個完整遊戲的經驗後，你自然而然會整理出可以重用的代碼，下次編寫新遊戲時自然會注意架構。

這幾年來我見過市面上一些成功商業遊戲的Unity 項目源代碼，其實也是混亂不堪的，我挺佩服開發人員能將其做上線並持續維護。

所以說，不存在完美的項目，只存在完整功能的項目。先把功能做完整再去考慮優化吧。

樓上有很多朋友說先把遊戲做出來再說，也沒啥問題。但是。。。

就像收拾屋子一樣，有的人不愛收拾，但是總能找到想要的東西，有的人喜歡收拾乾淨，方便以後忘記什麼東西好去做尋找。其實編程一樣的，我個人覺得如果你是個人的項目，隨便吧，看你自己。但是若團隊項目你的代碼是否清晰就關係你的假期呀。

比如說你代碼寫的好，別人能看得懂修改，OK，你請假出去玩了，公司出了事情你就可以叫一下同事幫你修改，只用說「幫我看一下XXX模塊的XXX函數，這是做XXX功能用的，這裡幫我判斷一下XXX」，不然你就得想方設法遠程連接電腦，甚至趕回公司解決問題了。

還有就是代碼清晰可以提高查錯的效率，你代碼越清晰查錯的時候就越不會被其他代碼所混淆，個人覺得還是有所必要。

行，我個人來說乾巴巴的，還是舉例幾個吧。

1.模塊化代碼

以下是我從http://blog.csdn.net/u011344883/article/details/9989469 的調試和查錯方法裡面節選的，能很好的說明模塊化對尋找問題分離概念的好處。

缺少架構的代碼是難以修復bug的主要源頭。只要代碼易於理解，而且理論上行得通，那麼對於程序員來講，找到並快速修復bug並不是什麼棘手的事情。另一方面，越是重要的代碼出現錯誤的幾率就越大，找到這個錯誤相對也就比較困難。

設計軟體的組件經常需要考慮一點就是所謂的代碼模塊化，代碼模塊化可以幫助程序員更好的用兩種方法來理解軟體系統。第一，模塊化能夠創造出一定層次的抽象感，在沒有完全理解所有細節的情況下也能想像出系統的模型。比如，程序員正在構建一個商業系統，可能會考慮到信用卡處理模塊，然後觀察這個模塊和其餘代碼有什麼聯繫，根本不用考慮信用卡處理模塊的所有詳細內容。第二，模塊的詳細說明，這個詳細說明是不會和別的模塊內容混淆的，就像每個卡只有一個卡號是一樣的。

2.做一些單例來統一實現重複的代碼

我們經常寫代碼的時候會發現這個代碼在某個模塊寫過，這個時候就可以想想可以不可以把代碼封裝到一個單例中做調用。這樣的好處在下次再遇到重複的問題不用再寫一遍，同時如果代碼出了錯，也可以只修改一個函數就搞定，而不是每個模塊去改一遍。

然後你代碼會健步如飛

3.配置化資源

這個和美術資源、遊戲的表現相關了。遊戲中經常會用代碼去處理美術的表現，新手寫代碼的時候喜歡直接在代碼裡面寫具體的數據，比如做一個攻擊表現，播放具體動畫到具體3秒結束，然後一個具體名字特效在1秒後到達什麼地方，然後2秒後刪除，就直接寫代碼中了。其實可以做一個簡單的攻擊配置，代碼不去關心具體的值，只關心具體的流程。比如還是一個攻擊表現就改成，我們有一個攻擊的配置，將配置傳入攻擊函數中。播放XX動畫到X秒，播放XX特效再XX秒後刪除，如果有其他的攻擊表現，就只用修改攻擊配置就好了，不用去修改具體的邏輯代碼。

這也就是數據和邏輯分離。

代碼邏輯結構清晰的好處也在於二次利用，比如你做完一個項目，下個項目要開發相似的新遊戲，就可以修改修改這個項目的玩法模塊就搞定了~。

當然也可能經常變成這樣:

Update: 2017年12月27日

目前最推薦的架構書籍是《Clean Architecture》

————————

該怎麼架構，只有你完整完成了幾個項目之後，才會明白。

因為架構就是決策，而決策必須有經驗，沒有經驗就無法在不同架構的細枝末節間進行選擇。

先按照你自己的理解能力，儘可能用優雅的方式去實現需求，並在維護需求變更的時候進行重構。

你可以試著去讀《代碼大全2》，但是其中的結論也是需要項目經驗才能理解的，沒有捷徑。

——————

另外附上我非常喜歡的 Game Programming Patterns 中的一句話：

My experience, though, is that it』s easier to make a fun game fast than it is to make a fast game fun.

所以，不要過早考慮優化，放手去實現功能，享受做遊戲的樂趣吧！

先從個人、項目、團隊、公司的角度想想為什麼要追求代碼邏輯的清晰？

———————20170927更新—————————

代碼邏輯清晰，首先是要看起來邏輯清晰，就要提高代碼可讀性，提高可讀性就首先要著手的事情是各種命名，臨時變數，成員變數，方法，類，命名空間，文件夾，項目名。每樣都找到合適的命名就可以提升很大的可讀性。命名的時候要一直思考，這個東西職責是什麼。這是可以馬上著手做的，容易養成習慣的。

接下來可以做，就是考慮縱向分層，底層中間層應用層反正有很多種分法，然後橫向根據業務分模塊比如根據UI界面或者功能模塊。

遊戲當然應該經歷需求分析後一次成型。否則就會額外經歷幾次重構，浪費時間，甚至由於重構難度太高而放棄，導致代碼變得一團糟。

但沒經驗的人怎麼可能一次成型呢？

一個辦法就是試，經過幾個項目的磨鍊後自然會慢慢得出結論。但更有效的方法則是抄別人的架構，讓對方解釋每一處這樣做的理由，復訴遇到的坑，將對方的經驗轉化為自己的。

所以架構這個東西其實是可以教的。

但畢竟不同項目的架構都不同，複製容易，講清楚這麼做的理由就需要很多口水了，分開不同情況講就更麻煩，是不可能指望有人在這麼一條回答里讓你明白的。

1.寫代碼勤注釋，只要有一點以後難以看懂的可能性就解釋一通。

2.控制單個文件代碼長度，一般認為不要超過5000行，否則就要考慮進一步抽象新類。

3.減少耦合，類與類之間，模塊與模塊之間依賴越少越好。

4.插件化開發，時刻用即插即用的標準提醒自己，這是最好的。

一個是抽象。一個是解耦。

重複的，相似的代碼盡量放到一個函數裡面。相似功能，使用管理者進行管理。

解耦就是比如一個彈窗，直接複製出來盡量可以不用改就可以運行。盡量不要把邏輯放在視圖裡面。可以使用事件解耦。但也彆強求，有時候項目緊張首要還是造成任務。

主要的還是在功能完成時候對代碼進行整理，思考那些以後可能會重用的，用到下個項目中去。一般比較複雜的整理工作項目上線運行良好就不要亂動。

然後在接到需求時候不要一下就埋頭寫代碼，先整理下思路，想下哪些可以模塊化，那些可以配置化。一般也花不了多長時間

1，由頂往下設計（設計）

2，由底往上綜合（重構）

具體的設計方法，在遊戲行業肯定就是oo的套件，你感覺代碼邏輯不清晰，多半是設計工作沒做好。

﹌﹌﹌

補充一下，看到回答當中有很多說作圖的，什麼都有，腦圖，框圖，流程圖都出來了。可以說他們對設計的理解是一知半解，這樣有誤人子弟的嫌疑，什麼圖做什麼事情是有一整套方法學的。比如腦圖框圖是在概念階段用的，流程圖是在詳細設計階段用的，數據流圖是在概要設計階段分解系統用的，我們很多程序員需要系統的學習和提高軟體工程素養，這樣才能在專業的方向上更近一步。

做遊戲的一般就去整oo套件，其中最重要的還是靜態圖（類圖），建議初學者這個靜態圖要做到什麼程度呢，就是拿過來就能直接翻譯成代碼，你必然會很深入的去思考和理解類和類之間的關係，以及為什麼這樣劃分，只需要一次系統化的練習之後，你對系統和設計的理解馬上明顯能上一個檔次，這個效率比在代碼中摸爬滾打要強許多倍。

認為畫流程圖或者框圖是一個良好的習慣。

在寫代碼前，先講邏輯大概整理好，

封裝、分層、分治。最重要的是先畫腦圖，腦圖畫明白了，邏輯自然就清晰了。

用自動機理論構建檢查自己的代碼，這樣可以保證你寫代碼前分析需求的時間。思考得清晰，代碼邏輯就清晰了，後續修改就是加個狀態的問題

先把主要功能做出來，做時適當寫一下comment,然後就是抽象化，refactor，解耦……再來就是擴展－＞還技術債的循環

先求有再求好是對的，但不可能把整個遊戲都做出來才還債，基本上是一邊寫代碼一邊還債的，技術債多的話還得特定排時間專門用來還債的

技術債還多了代碼就會變好

OO的思路還是可以借鑒的

先寫注釋(偽代碼)後寫代碼,當然文件夾命名/類名/方法名/類圖本身也是個注釋,前題是你有消滅//_TODO_的強烈意志.

盡量在開始就用少的代碼來完成相同的工作。

你會發現代碼少了自然就清晰了，多了也自然就複雜了。

先把遊戲做出來，遊戲掙錢了就可以請小弟來慢慢整理代碼維護遊戲開發新的小功能。遊戲不掙錢整理的再好也沒用。遊戲掙錢了小弟干這活你去搞新的遊戲。

編碼也是一個熟能生巧的工作，大量的練習和多思考可以提高編碼能力。當編碼能力提高後，你工作時自然會想要尋找讓代碼更清晰的方法，有了意識就不再困難了。

個人覺得這件事的源頭在需求，邊想邊做說明需求很碎片化，可能連基本的遊戲要包含哪些系統都沒設計出來。這種情況下基本等於有個人坐在你邊上隨時告訴你，我又有一個新想法，你很難去寫出一個能覆蓋所有這種不成體系的需求的框子。所以樓上說的需要經驗，意味著你能猜出來某種類型的遊戲可能會有哪些系統，比如屬性，技能，裝備，戰鬥單位，ai等等，有了大的邏輯塊的劃分，框子上就清楚多了，再繼續細化下去，代碼就不會亂。另外，跟具體業務性相關的代碼一般多多少少都不會很乾凈，總會有些膠，優化要有個明確的量化程度，適可而止。

做幾個項目就知道了。

單純的實現功能沒啥，維護起來就頭疼了，這個時候你就開始考慮如何避免在增加需求的時候改動原來的代碼。慢慢的就知道在一個遊戲中如何設計你的代碼。

歸根結底就是先懂業務，然後總結。

開發語言無法提供或者實現起來比較麻煩的可以用工具生成代碼減少重複性代碼複製粘帖的工作量和出錯紀錄。

很多時候還要考慮到debug，所以開始不要糾結，只要你用心慢慢來就好了。

看來樓主，還是個楞頭青，首先，你得有邏輯吧。

走一步，算一步，肯定是沒有邏輯的。

一個類型配一個生成器

參與一個事件全過程需要多種類型的對象。

多個事件，就需要多個事件生成器。

顯然，類型生成器，類型生成器的生成器。

事件生成器，事件生成器的生成器。

工廠，組織。

各種大器，都需要生成出來。

顯然，你沒有抽象工具，那是不行的。

不多說了，你需要名師指導。光去參加項目，

在如今高內聚，低耦合的年代，項目經理，或者領導會讓你碰架構？

呵呵，他飯碗不想要了。

居安思危。

你要用這個組件的時候，你要思考，如何把它除掉。

如果沒有辦法除掉。。你還敢用嗎？

當前階段已經進入到了贏者通吃的階段。

只有努力做到局部細分第一名，你才能夠養活自己。

如果你寫的每一行代碼的命名都沒有道理可言，我勸你，改行。

名不正則言不順。每一個函數，變數，常量的名稱，都需要有來頭，有考究。

你才可以服眾。

這個在dota裡面叫，大局觀比較差…

我教你怎麼治本，治標的方法樓上全是…

核心就是:哪裡不會點哪裡…

1.分析出問題，你都說了每次寫小模塊還可以，一旦湊一起就出問題了，那麼先分析出，出哪些問題…自己分析…

常見的有兩個模塊的事件數據通訊問題…就拿這個打比方…

2.根據你分析出的問題，一一找解決方案…

就醬紫………

什麼設計模式啥的，都是扯淡，偽科學，

不是授人以漁的書，看不看隨個人…

代碼隨便寫都好，最主要的是注釋！！！多用#region把代碼摺疊起來，這樣你代碼即便不重構也能使同事看的清楚！