非IT人士都能看懂的工程代碼重構方法：三步走

先來解釋本文常出現的兩個名詞：

策劃：指遊戲策劃。這裡的策劃指的是人(planner)，而非策劃方案(plan)

程序員：不解釋，最牛逼的職業（不要臉哈哈）

版本一：專業版

最近遊戲工程代碼有點失控。一個類上千行的比比皆是，甚至高達3000多行。

究其原因，還是挺典型的。

當然直接對此負責的，應是工程師。工程師的能力當然是最關鍵的一點，能力直接決定了代碼的質量。

然後從策劃方面入手。第一是進度安排太趕。由於前期項目趕工，寫了很多功能， 沒時間仔細安排代碼。第二個原因，需求改動過於頻繁。為了防止遊戲策劃突然又說「還是弄回上一個版本吧」事實上這種事情還經常出現。 所以程序員一般都不會直接推到重做，而是先把舊代碼留著活著注釋著，以對應未來那未必有的需求。於是預留了很多舊的介面，久了，就難免造成很多凌亂的代碼。

因此產生了一些負作用。最明顯的是代碼失控。有bug時想去修，卻經常被零亂的代碼絆倒。很多團隊會發現，工程做了越久，代碼越亂，修bug的用時越來越長。

策劃方面對很多公司的工程師來說，是不可改變的因素。但工程師可以改變自己管理代碼的方法，來獲得更好的工程代碼質量。

解決方法：

工程代碼重構三步走：

1.刪。弄清某個功能模塊的現時需求。注意，是現時的，以往一些留著以防策劃突然改需求的代碼就可以刪了。不要擔心太多。留著不用代碼的初衷，就是怕未來用上，再深入理解點，就是為了維護方便，總結一個詞：可維護性 。但未來用上的幾率是多少呢？如果是100%，當我沒說，留著也好。但就算一段代碼未來有80%的可能性會被再次使用到，那學過數學的都知道，時間長了，工程代碼里會躺著20%的無用代碼。這對工程的可維護性來說已經是一個很大的損害。所以已經被下架了的需求，就直接刪代碼吧，反正有svn管理著，寫清楚log，就算未來再用到，也不難找出來。

2.改：第一：清理函數。變數或函數名字要寫得明晰，不要寫到聯繫上下文幾十遍才能理解的那種。第二：函數內的每段代碼抽象層級要同一層。舉個簡單例子，如下一個執行過程，你看看是否好懂。

bool checkOk = CheckUserName();nif (checkOk)n{n int result = serverID * 1000 + (int) checkOk;n NetManager.SendToServer(result );n}n

這是我仿照我們工程出現的一段典型難懂代碼來模仿的。主要問題是第一行的代碼看起來是自然的語言一樣，第二段代碼就好像數學的公司一樣。這種感覺就是有人給你講著一個扣人心弦的故事，突然間插播一個數學的推導過程，推導完了，那種興奮的心情都沒了。這多蛋疼啊。重構後是這樣的：

if ( CheckUserNameOK() )n{n int result = CalculateResult(serverID);n SendresultToServer(result );n}nint CalculateResult(int serverID)n{n int checkOk = 1;n return serverID * 1000 + checkOk;n}nvoid SendresultToServer()n{n NetManager.SendToServer(result );n}n

重構後的代碼感覺就是好像有人給你講扣人心弦的故事，你聽完了這個故事，過完癮了，再對故事中主角用來推導線索的某個數學原理進行研究。

3.拆：一個類多拆幾個類，功能細化。例如遊戲里，之前一個人物就是一個類文件，什麼控制過程都在裡面實現。現在把一些控制過程做成一個個控制器，每個控制器一個類。

版本二：通俗版

工作太趕，來不及好好安排，最後雖然能完成，但不夠完美，或許還留下了隱患。於是後面的工作可能會遇到這些隱患，導致後面的工作不好開展。

究其原因，當然是直接執行者首當其衝。

但工作的制定者如果不是執行者本人的話，制定者本身也有一定責任。（例如老闆交代xxx必須多少天內完成哪些是）制定者沒有留下足夠的時間來讓執行者開展工作，導致執行者執行時考慮時間不夠。就好像一篇作文，時間太趕，不好好構思，儘管能寫出符合題意的文章，但不容易寫出優美有內涵的文章。除非靈感大發，或是一個職業作家（其實職業作家要求寫稿時間更多好么）。而且制定者還經常改變執行者的工作內容，讓執行者某些工作沒做好。

作為執行者，你無法敢於工作的制定者，但你可以改變你執行策略來讓自己工作更好開展。

話說要把代碼管理過程映射成通用的管理過程的確有點難，畢竟工程管理有累積性，這不是任何工作都有的特點。不過我盡量描述，不過既然是通用的道理，我就不再舉例子了：

工作管理方法三步走：

1.刪。刪掉那些已經和主線工作無關的工作內容，即使這些內容完成了一般。也不用覺得可惜。當然這些內容短期內會再用到的可能性比較大的話，可以先騰出一個空間來管理這些內容，但不要讓這些內容出現在你視線里。

2.改。重新安排工作內容。重新安排工作的順序，例如利用「時間四象限」法來管理哪些工作重要哪些工作緊急以決定下一步要做啥，清晰化自己的計劃。

3.拆。細化工作內容，以更細的粒度來管理工作進度。

後記：

工程管理里的理念，其實可以升華到其他工作的方方面面，甚至用來指導生活。最近讀了一本叫《斷舍離》的書，裡面的指導方法和我代碼管理理念竟然有很多相似之處。也建議你讀下這本書，不僅對生活有指導作用，也許還能對你迷茫的工作進度起到一點啟發。