在過去的七年半中，我在Ronimo遊戲公司指導過十幾個程式設計師實習生，審閱了數百份簡歷。我發現他們中的大多數都需要學習一件事情。你可能以為這是某一技術、演算法、數學，或其它形式的某方面知識。當然，他們的確需要彌補這些知識，但是在我看來，這些都不是最重要的。他們要去學習的最重要的一件事是：自律。這種自律體現在：編寫儘可能清晰的程式碼；重構程式碼以消除因後續開發中的變化所造成的混亂；移除從未用過的程式碼並且新增註釋。
我指導實習生的大部分時間不是在高階技術或引擎細節的解釋上，而是讓他們寫出更好的程式碼。我總是會問實習申請者：要成為一名優秀的程式設計師，你們認為哪些是重要的？他們的回答通常是：程式碼要清晰，易懂，便於維護。這當然是我想聽到的，但是很少有年輕的程式設計師能從一而終地去實踐。
做到這些需要自律，因為這意味著程式碼不能停留於“實現了功能”。假設所有的變數都被隨意地命名，程式碼依然能夠完美執行，但是閱讀性很差。從短期看，從“功能型程式碼”到“清晰型程式碼”帶來的回報很少：程式碼原本就可以執行，對其清理之後程式碼仍然可以執行。這就是為什麼需要自律來完成這一步，這也是為什麼參加實習會很有幫助：一個好的導師會非常注重程式碼的質量（儘管不同的人對“好的程式碼”有不同的定義），從而要求實習生進一步改進完善，走到下一個階段。
下面給出幾個例子，這些是我在新手程式設計師所寫的程式碼裡經常看到的問題：
名不副實的函式/變數/類
這些函式、變數、類所做的事情並不是他們名字所暗示的那樣，這些名字具有欺騙性。顯然名字應該反映真實的內容，但讓我吃驚的是，名不副實這種情況常常出現。
舉個例子，我最近偶然看到以前一個實習生寫的兩個類：EditorGUI 和 EditorObjectCreatorGUI，這程式碼本是用來處理編輯器裡的介面。令我吃驚的是，建立新物件的按鈕的程式碼放在了 EditorGUI 裡面，而EditorObjectCreatorGUI則是處理不同物件間的操作，這都跟名字所暗示的完全相反！儘管程式碼比較簡單，但我花了好大一會兒才弄明白，因為我基於類名稱作出了完全錯誤的假設。這個案例的解決辦法很簡單：重新命名為 EditorObjectCreatorGUI和 EditorObjectNavigationGUI，僅僅做一小步就可以大大提高閱讀性。
命名不準確這種情況我見到很多。之所以頻繁發生，是由於程式碼在不斷地演變。最初選擇那個命名時可能是正確的，但一到程式碼完成之後，命名可能就變得不準確甚至錯誤的了。這個陷阱提醒我們應該始終把命名記在心上，在你新增一段程式碼的時候就要弄清楚，這與函式或類的名稱是否相稱。
推薦閱讀：《程式設計師最頭疼的事：命名》
混淆不清的類
另一個問題是混淆不清的類，即一個類做了很多不相關的事情。當你長時間專注於同一塊程式碼時，就可能這個問題。新功能用最簡單的方法實現，到了某種程度，類就會變得臃腫，做了很多不相關的事情。有時候類變得臃腫不在於程式碼規模的大小：一個類可能只有幾百行，但它卻包含了不屬於本類功能的程式碼。
舉個例子，如果一個GUI類需要“分析哪些紋理可供使用”（設想有個按鈕用於選擇紋理），如果GUI類是唯一一個需要這種分析結果的類，那麼在GUI類裡實現它是很合理的。但是，這時一個完全不相關的gameplay類也需要這種分析結果的資訊，因此你將GUI類傳遞給gameplay類來查詢紋理資訊。這個時候GUI類就多出一種東西了：它是GUI類，同時也是TextureAnalyser類。這個案例的解決方案很簡單：從TextureAnalyser類分割出一個獨立的類，這個類可同時被GUI類和gameplay類使用。
避免這種問題的最好方法是在每次寫程式碼前三思：我在這裡新增的功能跟類的名稱符合嗎？如果不符合，那麼就要對類重新命名，或者將其分割成獨立的類，或者把這段程式碼放到其他的類中。
如果想不出來一個跟類非常匹配的名字，這通常是程式碼異味（Bad Smell）。如果找不到合適的名字描述這個類，可能因為它所做的事情太混雜了。這時可以將它分割成幾個部分，並且每個部分用一個恰當的名字來描述。
體積龐大的類
這問題跟上面所說混淆不清的類很相似：隨著時間的推移，越來越多的程式碼被新增到一個類裡，使得其變得臃腫。在這種情況下儘管放在一個類是很合理的，但是類的體積變得很大。超大的類處理起來是很麻煩的，當很多程式碼對同一個私有成員變數進行操作時，bug就很容易出現，並且人也很容易忽略很多細節。
分割一個超大的類是件相當無聊的工作。當程式碼高度交錯時，這也具有很大的挑戰性。分隔程式碼需要高度的自律，因為這只是對已有的程式碼進行增加或修改而保持原有的功能不變。
Ronimo公司有一個規定，保持類的程式碼在500行以下，函式的程式碼在50行以下。有時候這是不可行也不合理的，但是通常來說，不管哪一個類或函式超出了這個規定，我們都會尋找辦法將其重構或者分割成更小的，更易於管理的片段。（這讓我很好奇：你覺得這個限制應該是多少行？可以在評論中留言。）
程式碼註釋
實習申請人給我們發過來的樣本程式碼幾乎都有一些被註釋的程式碼塊，但並沒有說明為什麼會做這個註釋。是程式碼存在錯誤需要修改嗎？還是程式碼過舊需要更新？註釋掉的程式碼為什麼會在這裡？當我們問起申請人時，他們對這些被註釋的程式碼也顯得很疑惑，但是奇怪的是，總會有一些原因不明的被註釋的程式碼。
程式碼重複
另一個我經常看到的問題是有相似功能的程式碼重複出現。
舉個例子，從紋理名字也許可以看出這東西的用途，如TreeBackground.dds。為了知道這個紋理是否可以用於一棵樹，我們檢查以Tree開頭的檔名。也許當使用SDK後我們能很快找到，使用beginsWith(”Tree”)就行了。這個程式碼很短，如果需要用到它，直接貼上到那兒就可以了。這就是程式碼重複，並且人人都知道程式碼重複是應該避免的，如果重複的程式碼很短，那麼最吸引人的做法是直接複製貼上。在這兒的問題很明顯：以後如果要檢查這個紋理是否適用於別的東西，我們就要進行散彈式修正，一個地方一個地方修正了。
通常比較好的做法是，如果程式碼功能特殊，不要去複製，而是把它放到一個函式裡。儘管程式碼很短很短，並且呼叫一個函式比貼上需要寫更多的程式碼，但是你要學會這麼做，這也需要高度的自律。
本文所討論的主題很淺顯，大多數人在上大學一年級的時候已經學過了。難就難在從知道這些東西到實際花時間遵循它們，再到把它們記在心裡。這就是為什麼所有在Ronimo實習過的人學到的最重要的東西不是知識，而是自律。