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

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

1.復(fù)雜的繼承

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

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

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

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