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