在過去的7年半時(shí)間里，我?guī)н^的軟件實(shí)習(xí)生超過一打，也看到過數(shù)以百計(jì)的學(xué)生和畢業(yè)生的檔案。我發(fā)現(xiàn)很多事情他們都需要學(xué)習(xí)。或許你會(huì)說，我說的不 就是某種特定的技術(shù)、算法、數(shù)學(xué)，或者其他特定形式的知識(shí)嗎？沒錯(cuò)，這的確是需要學(xué)習(xí)的，但卻并不是最重要的事情。他們需要學(xué)習(xí)的最重要的東西是“自我規(guī) 范”。這些規(guī)范就是：盡可能地寫出最簡(jiǎn)潔的代碼；如果代碼后期會(huì)因?yàn)楦膭?dòng)而變得凌亂不堪就得重構(gòu)；盡量刪除沒用的代碼，并添加注釋。

我花了很多時(shí)間來敦促這些實(shí)習(xí)生去學(xué)習(xí)這些內(nèi)容。我經(jīng)常會(huì)問他們，怎么樣才能成為一名優(yōu)秀的程序員，他們也通常會(huì)回答說，代碼應(yīng)該清晰易懂易于維護(hù)。這的確是我想聽到的聲音，但是很少有年輕的程序員真的能夠始終如一地貫徹這一點(diǎn)。

請(qǐng)謹(jǐn)記這一點(diǎn)，要懂得“自我規(guī)范”，也不能一旦代碼“起效了”就立馬置之腦后。如果所有的變量都命名錯(cuò)誤，但是代碼依然可以***地運(yùn)行，那么這些代 碼絕對(duì)亂糟糟得讓人不忍直視。將功能代碼改進(jìn)為簡(jiǎn)潔代碼可能在短期內(nèi)是看不到回報(bào)的：代碼原本就可以工作，在清潔之后依然可以工作。這就是為什么你需要 “自我規(guī)范”這一步驟了。這也是為什么實(shí)習(xí)工作是如此必要：一個(gè)好的上司是相當(dāng)注重代碼質(zhì)量的（即使所謂“好代碼”的定義對(duì)于每個(gè)程序員都不一樣），從而 迫使實(shí)習(xí)生和初級(jí)程序員不得不反復(fù)修改。

[[139587]]

下面我舉的一些例子都是新手程序員寫代碼的時(shí)候經(jīng)常出現(xiàn)的：

名不副實(shí)的函數(shù)/變量/類

這些函數(shù)、類和變量實(shí)際所做的事與其名字所表達(dá)的含義并不一致。片面看名字是正確的，但是聯(lián)系實(shí)際的話，有的甚至是毫不相關(guān)的。

舉個(gè)例子，我上一期的實(shí)習(xí)生寫了兩個(gè)類：EditorGUI和EditorObjectCreatorGUI。用于處理編輯界面的代碼。讓我哭笑不 得的是，用于創(chuàng)建新對(duì)象的是EditorGUI，而EditorObjectCreatorGUI只能通過處理不同的對(duì)象進(jìn)行導(dǎo)航。兩者的含義居然是截然 相反的！即使代碼還算相對(duì)簡(jiǎn)單，但我還是花了相當(dāng)長(zhǎng)的一段時(shí)間用來理解它，因?yàn)橐婚_始我是在一種完全相反的假設(shè)基礎(chǔ)上來理解的。這種情況的解決方案非常簡(jiǎn) 單：重命名EditorObjectCreatorGUI為EditorObjectNavigationGUI即可，這樣就易于理解多了。

這種情況我看到過很多。之所以會(huì)發(fā)生這種情況是因?yàn)榇a在工作過程中發(fā)生了演變。在選擇名字的時(shí)候可能還是正確的，但到了寫完代碼的那一刻，就名不副實(shí)了。關(guān)鍵是要時(shí)刻銘記命名法則。你得明白你添加的東西是否依然符合函數(shù)和類的名稱。

混亂的類

另一個(gè)問題是類很亂：類做了很多不相關(guān)的事情。新功能的添加很簡(jiǎn)單，但是慢慢的，你會(huì)發(fā)現(xiàn)你的代碼變得臃腫不堪，各種不相關(guān)的功能隨處可見。有時(shí)候，臃腫與否也并不指的是類的大小：某個(gè)類可能只有幾百行，但依然囊括了不屬于它的代碼。

為什么會(huì)發(fā)生這種情況呢？舉個(gè)例子：假設(shè)由于某種原因，某個(gè)GUI類需要分析什么樣的紋理可行（可能是有按鈕要用來選擇紋理）。如果這個(gè)GUI類是 唯一需要這個(gè)分析結(jié)果的類，那么在GUI類中這樣做是有意義的。然而，由于某種原因，一個(gè)完全無(wú)關(guān)的gameplay類也需要這些信息。所以你需要將這些 紋理查詢的信息從GUI類傳給gameplay類。這時(shí)候，其實(shí)這個(gè)GUI類已經(jīng)變大了：因?yàn)樗锩嫫鋵?shí)還包括了TextureAnalyser類。解決 方法也簡(jiǎn)單：將TextureAnalyser類分割為一個(gè)單獨(dú)的類，GUI類和gameplay類都可以使用它。

關(guān)于這一條經(jīng)驗(yàn)法則很多人提出質(zhì)疑：要是我添加的功能仍然適合原來這個(gè)類的名字呢？如果的確不適合，那么我就必須重命名，或者將其分割成單獨(dú)的類，抑或用代碼寫成一個(gè)不同的類嗎？

如果你不能為你的類想出一個(gè)合適的名字，給人的感覺就會(huì)不舒服。如果你不能在類的名字中描述它的目的，那么就會(huì)顯得亂七八糟。有時(shí)候我們還需要將某個(gè)臃腫的類分割成幾部分，并各自取一個(gè)恰當(dāng)?shù)拿帧?/p>

過于龐大的類

這和上一點(diǎn)——混亂的類有些類似：很多東西一點(diǎn)一點(diǎn)地都添加到類中，然后它不可避免地就臃腫了。在這種情況下，這樣一個(gè)類仍然是有意義的，但就是長(zhǎng) 得太大個(gè)了點(diǎn)。這么個(gè)龐然大物不但繁瑣，而且很容易出現(xiàn)bug，因?yàn)榇罅康拇a需要用于操作同一個(gè)私有成員變量，所以我們很容易忽視一些細(xì)節(jié)。

分割一個(gè)已經(jīng)長(zhǎng)得很大的類其實(shí)是相當(dāng)枯燥的。這也會(huì)成為一個(gè)挑戰(zhàn)，如果類中的代碼高度交織在一起的話。再加上它已經(jīng)在工作，修復(fù)時(shí)不能添加新功能，這樣一來，我不得說，分割一個(gè)過于龐大的類，不能嚴(yán)格地自我規(guī)范是不行的。

根據(jù)在Ronimo的普遍經(jīng)驗(yàn)，類保持在500行代碼以下、函數(shù)保持在50行代碼以下是最合適的。不過有時(shí)候，這樣做反倒不可行，也不明智。但是一般說來，一旦類或函數(shù)超出了那個(gè)界限我們就可以想辦法重構(gòu)，并將之分割為更小更易于管理的片段了。

關(guān)于代碼注釋

幾乎所有的示例代碼都會(huì)包含注釋好了的代碼片段，而不說明為什么。這段代碼需要修復(fù)嗎？舊的代碼是否已經(jīng)被取代了？為什么那兒要寫這些代碼？大家都知道沒有注釋的代碼常常不知所言，但不知何故，很多人都會(huì)忘記在自己的代碼上注釋。

并行邏輯和代碼重復(fù)

還有一個(gè)問題就是我經(jīng)常能在若干個(gè)代碼段處看到相似的邏輯。

例如，我們可以從紋理這個(gè)名稱知道它大概的目標(biāo)對(duì)象，比如說是“TreeBackground.dds”。為了知道紋理是否可以用于tree，我們 檢查了文件名以便知道它是不是以“tree”開的頭。可能使用SDK的話我們用filename.beginsWith（“tree”）可以很快地檢測(cè)出 來。只是這句代碼這么短，我們往往會(huì)選擇哪個(gè)地方需要，就直接復(fù)制粘貼。當(dāng)然這樣就是代碼重復(fù)了，而正如每個(gè)人都知道的，我們應(yīng)該避免重復(fù)代碼，但如果復(fù) 制的代碼是如此之短，我們往往會(huì)忘記這一點(diǎn)，很自然地就直接copy了。此處我們面對(duì)的問題也是顯而易見的：也許后面我們檢查某個(gè)紋理是否適合tree的 方法就得變了，然后我們就不得不實(shí)行“霰彈式修改”（即到處修改）策略，一處一處地修復(fù)。

此處的一般規(guī)律是，如果是非常具體的代碼，那就不要復(fù)制，即使原本的代碼超級(jí)之短，調(diào)用函數(shù)甚至比直接寫需要更多的代碼，也應(yīng)該封裝成函數(shù)。

上面討論的這些內(nèi)容已經(jīng)講得非常透徹了。很多內(nèi)容甚至你在大學(xué)中就學(xué)過。但是現(xiàn)在要面臨的挑戰(zhàn)是你需要一步步地從被動(dòng)遵守到主動(dòng)銘記于心養(yǎng)成一種習(xí)慣。這也是為什么Ronimo中的實(shí)習(xí)生最重要的不是學(xué)習(xí)知識(shí)，而是學(xué)會(huì)自我規(guī)范。