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

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

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

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

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

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

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

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

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

混淆不清的類

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

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

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

如果想不出來一個跟類非常匹配的名字，這通常是代碼異味（Bad Smell）。如果找不到合適的名字描述這個類，可能因為它所做的事情太混雜了。這時可以將它分割成幾個部分，并且每個部分用一個恰當?shù)拿謥砻枋觥?/p>

體積龐大的類

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

分割一個超大的類是件相當無聊的工作。當代碼高度交錯時，這也具有很大的挑戰(zhàn)性。分隔代碼需要高度的自律，因為這只是對已有的代碼進行增加或修改而保持原有的功能不變。

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

代碼注釋

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

代碼重復

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

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

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

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