在過去的七年半中，我在Ronimo游戲公司指導(dǎo)過十幾個(gè)程序員實(shí)習(xí)生，審閱了數(shù)百份簡(jiǎn)歷。我發(fā)現(xiàn)他們中的大多數(shù)都需要學(xué)習(xí)一件事情。你可能以為這是某一技術(shù)、算法、數(shù)學(xué)，或其它形式的某方面知識(shí)。當(dāng)然，他們的確需要彌補(bǔ)這些知識(shí)，但是在我看來，這些都不是最重要的。他們要去學(xué)習(xí)的最重要的一件事是：自律。這種自律體現(xiàn)在：編寫盡可能清晰的代碼；重構(gòu)代碼以消除因后續(xù)開發(fā)中的變化所造成的混亂；移除從未用過的代碼并且添加注釋。

我指導(dǎo)實(shí)習(xí)生的大部分時(shí)間不是在高級(jí)技術(shù)或引擎細(xì)節(jié)的解釋上，而是讓他們寫出更好的代碼。我總是會(huì)問實(shí)習(xí)申請(qǐng)者：要成為一名優(yōu)秀的程序員，你們認(rèn)為哪些是重要的？他們的回答通常是：代碼要清晰，易懂，便于維護(hù)。這當(dāng)然是我想聽到的，但是很少有年輕的程序員能從一而終地去實(shí)踐。

做到這些需要自律，因?yàn)檫@意味著代碼不能停留于“實(shí)現(xiàn)了功能”。假設(shè)所有的變量都被隨意地命名，代碼依然能夠完美運(yùn)行，但是閱讀性很差。從短期看，從“功能型代碼”到“清晰型代碼”帶來的回報(bào)很少：代碼原本就可以運(yùn)行，對(duì)其清理之后代碼仍然可以運(yùn)行。這就是為什么需要自律來完成這一步，這也是為什么參加實(shí)習(xí)會(huì)很有幫助：一個(gè)好的導(dǎo)師會(huì)非常注重代碼的質(zhì)量（盡管不同的人對(duì)“好的代碼”有不同的定義），從而要求實(shí)習(xí)生進(jìn)一步改進(jìn)完善，走到下一個(gè)階段。

下面給出幾個(gè)例子，這些是我在新手程序員所寫的代碼里經(jīng)?？吹降膯栴}：

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

這些函數(shù)、變量、類所做的事情并不是他們名字所暗示的那樣，這些名字具有欺騙性。顯然名字應(yīng)該反映真實(shí)的內(nèi)容，但讓我吃驚的是，名不副實(shí)這種情況常常出現(xiàn)。

舉個(gè)例子，我最近偶然看到以前一個(gè)實(shí)習(xí)生寫的兩個(gè)類：EditorGUI 和 EditorObjectCreatorGUI，這代碼本是用來處理編輯器里的界面。令我吃驚的是，創(chuàng)建新對(duì)象的按鈕的代碼放在了 EditorGUI 里面，而EditorObjectCreatorGUI則是處理不同對(duì)象間的操作，這都跟名字所暗示的完全相反！盡管代碼比較簡(jiǎn)單，但我花了好大一會(huì)兒才弄明白，因?yàn)槲一陬惷Q作出了完全錯(cuò)誤的假設(shè)。這個(gè)案例的解決辦法很簡(jiǎn)單：重命名為 EditorObjectCreatorGUI和 EditorObjectNavigationGUI，僅僅做一小步就可以大大提高閱讀性。

命名不準(zhǔn)確這種情況我見到很多。之所以頻繁發(fā)生，是由于代碼在不斷地演變。最初選擇那個(gè)命名時(shí)可能是正確的，但一到代碼完成之后，命名可能就變得不準(zhǔn)確甚至錯(cuò)誤的了。這個(gè)陷阱提醒我們應(yīng)該始終把命名記在心上，在你添加一段代碼的時(shí)候就要弄清楚，這與函數(shù)或類的名稱是否相稱。

推薦閱讀：《程序員最頭疼的事：命名》

混淆不清的類

另一個(gè)問題是混淆不清的類，即一個(gè)類做了很多不相關(guān)的事情。當(dāng)你長(zhǎng)時(shí)間專注于同一塊代碼時(shí)，就可能這個(gè)問題。新功能用最簡(jiǎn)單的方法實(shí)現(xiàn)，到了某種程度，類就會(huì)變得臃腫，做了很多不相關(guān)的事情。有時(shí)候類變得臃腫不在于代碼規(guī)模的大?。阂粋€(gè)類可能只有幾百行，但它卻包含了不屬于本類功能的代碼。

舉個(gè)例子，如果一個(gè)GUI類需要“分析哪些紋理可供使用”（設(shè)想有個(gè)按鈕用于選擇紋理），如果GUI類是唯一一個(gè)需要這種分析結(jié)果的類，那么在GUI類里實(shí)現(xiàn)它是很合理的。但是，這時(shí)一個(gè)完全不相關(guān)的gameplay類也需要這種分析結(jié)果的信息，因此你將GUI類傳遞給gameplay類來查詢紋理信息。這個(gè)時(shí)候GUI類就多出一種東西了：它是GUI類，同時(shí)也是TextureAnalyser類。這個(gè)案例的解決方案很簡(jiǎn)單：從TextureAnalyser類分割出一個(gè)獨(dú)立的類，這個(gè)類可同時(shí)被GUI類和gameplay類使用。

避免這種問題的最好方法是在每次寫代碼前三思：我在這里添加的功能跟類的名稱符合嗎？如果不符合，那么就要對(duì)類重命名，或者將其分割成獨(dú)立的類，或者把這段代碼放到其他的類中。

如果想不出來一個(gè)跟類非常匹配的名字，這通常是代碼異味（Bad Smell）。如果找不到合適的名字描述這個(gè)類，可能因?yàn)樗龅氖虑樘祀s了。這時(shí)可以將它分割成幾個(gè)部分，并且每個(gè)部分用一個(gè)恰當(dāng)?shù)拿謥砻枋觥?/p>

體積龐大的類

這問題跟上面所說混淆不清的類很相似：隨著時(shí)間的推移，越來越多的代碼被添加到一個(gè)類里，使得其變得臃腫。在這種情況下盡管放在一個(gè)類是很合理的，但是類的體積變得很大。超大的類處理起來是很麻煩的，當(dāng)很多代碼對(duì)同一個(gè)私有成員變量進(jìn)行操作時(shí)，bug就很容易出現(xiàn)，并且人也很容易忽略很多細(xì)節(jié)。

分割一個(gè)超大的類是件相當(dāng)無聊的工作。當(dāng)代碼高度交錯(cuò)時(shí)，這也具有很大的挑戰(zhàn)性。分隔代碼需要高度的自律，因?yàn)檫@只是對(duì)已有的代碼進(jìn)行增加或修改而保持原有的功能不變。

Ronimo公司有一個(gè)規(guī)定，保持類的代碼在500行以下，函數(shù)的代碼在50行以下。有時(shí)候這是不可行也不合理的，但是通常來說，不管哪一個(gè)類或函數(shù)超出了這個(gè)規(guī)定，我們都會(huì)尋找辦法將其重構(gòu)或者分割成更小的，更易于管理的片段。（這讓我很好奇：你覺得這個(gè)限制應(yīng)該是多少行？可以在評(píng)論中留言。）

代碼注釋

實(shí)習(xí)申請(qǐng)人給我們發(fā)過來的樣本代碼幾乎都有一些被注釋的代碼塊，但并沒有說明為什么會(huì)做這個(gè)注釋。是代碼存在錯(cuò)誤需要修改嗎？還是代碼過舊需要更新？注釋掉的代碼為什么會(huì)在這里？當(dāng)我們問起申請(qǐng)人時(shí)，他們對(duì)這些被注釋的代碼也顯得很疑惑，但是奇怪的是，總會(huì)有一些原因不明的被注釋的代碼。

代碼重復(fù)

另一個(gè)我經(jīng)?？吹降膯栴}是有相似功能的代碼重復(fù)出現(xiàn)。

舉個(gè)例子，從紋理名字也許可以看出這東西的用途，如TreeBackground.dds。為了知道這個(gè)紋理是否可以用于一棵樹，我們檢查以Tree開頭的文件名。也許當(dāng)使用SDK后我們能很快找到，使用beginsWith（”Tree”）就行了。這個(gè)代碼很短，如果需要用到它，直接粘貼到那兒就可以了。這就是代碼重復(fù)，并且人人都知道代碼重復(fù)是應(yīng)該避免的，如果重復(fù)的代碼很短，那么最吸引人的做法是直接復(fù)制粘貼。在這兒的問題很明顯：以后如果要檢查這個(gè)紋理是否適用于別的東西，我們就要進(jìn)行散彈式修正，一個(gè)地方一個(gè)地方修正了。

通常比較好的做法是，如果代碼功能特殊，不要去復(fù)制，而是把它放到一個(gè)函數(shù)里。盡管代碼很短很短，并且調(diào)用一個(gè)函數(shù)比粘貼需要寫更多的代碼，但是你要學(xué)會(huì)這么做，這也需要高度的自律。

本文所討論的主題很淺顯，大多數(shù)人在上大學(xué)一年級(jí)的時(shí)候已經(jīng)學(xué)過了。難就難在從知道這些東西到實(shí)際花時(shí)間遵循它們，再到把它們記在心里。這就是為什么所有在Ronimo實(shí)習(xí)過的人學(xué)到的最重要的東西不是知識(shí)，而是自律。