作為一個飽經(jīng)風(fēng)霜的程序員，你一定早就習(xí)慣了游戲開發(fā)中的反復(fù)。記得剛來公司的時候就聽師兄講過一個故事：策劃在國慶節(jié)前突然想模仿微信做一個紅包系統(tǒng)，還沒等他實現(xiàn)完畢，紅包二期的案子就已經(jīng)寫好了。不巧，這個幸運的師兄碰巧要去同學(xué)聚會，就暫時沒有做。等他請假2天回到公司的時候，驚奇地發(fā)現(xiàn)紅包二期已經(jīng)被推翻了，變成了紅包三期，師兄長舒一口氣，我想此刻他的內(nèi)心是復(fù)雜的，甚至復(fù)雜到不能用代碼表達(dá)~~

那我們的代碼到底能不能經(jīng)得起折騰呢？大概有兩種類型的代碼讓我印象深刻：

1.復(fù)雜的繼承

計算機(jī)專業(yè)出身的同學(xué)對面向?qū)ο缶幊桃欢ú荒吧?，這基本上是所有學(xué)校的計算機(jī)必修課，其實它也對很多公司的游戲架構(gòu)產(chǎn)生了深遠(yuǎn)的影響，在我們公司的代碼庫里，也有它的身影。在長期的維護(hù)中，這些本身設(shè)計良好的繼承關(guān)系由于需求的變動不斷改變著繼承關(guān)系，最后的結(jié)果就是，出現(xiàn)了很深很深的繼承，這樣的代碼很難維護(hù)，就像一個人很難一下說出自己應(yīng)該如何稱呼自己的爸爸的爸爸的爸爸的爸爸的兒子，一個需求的改變可能要求你理清這些類之間的關(guān)系，是要先調(diào)用父類的函數(shù)呢，還是先調(diào)用父類的父類的函數(shù)呢，還是重寫它。你甚至?xí)萑胍环N旋渦，這樣的設(shè)計很難讓邏輯清晰。

2.單個文件包含多種功能以及特判

這個可以舉一個實際的例子，游戲中有多種不同類型的戰(zhàn)斗，在戰(zhàn)斗的過程中，我需要顯示血條、倒計時、連擊數(shù)、方向盤、技能面板、傷害排行榜、暫停按鈕、托管按鈕等等等等。但是不巧，每一種戰(zhàn)斗需要的內(nèi)容是不一樣的，比如排行榜只在組隊模式下需要，而暫停按鈕則不能在PK模式中顯示，血條在PK模式要換另一種表現(xiàn)方式。一開始這對我們來說很簡單，幾個ifelse就可以輕松搞定，但是看看維護(hù)了一年之后的UI代碼吧，3000行的代碼和充斥著整個文件的20多種戰(zhàn)斗的特判，沒有人敢維護(hù)這塊代碼，因為它基本一改就會在別的關(guān)卡中出現(xiàn)BUG。

之前的代碼大概是這個樣子的，是不是感覺似曾相識呢。