在過去的7年半時間裡,我帶過的軟體實習生超過一打,也看到數以百計的學生和畢業生的檔案。我發現很多事情他們都需要學習。或許你會說,我說的不就是某種特定的技術、演算法、數學,或是其他特定形式的知識嗎?沒錯,這的確是需要學習的,但卻不是最重要的事。他們需要學習的最重要的東西是「自我規範」。這些規範就是:盡可能寫出最簡潔的程式碼;如果程式碼後期會因為改動而變得凌亂不堪就得重構;盡量刪除沒用的程式碼,並添加註解。
我花了很多時間來敦促這些實習生去學習這些內容。我常常問他們,怎麼樣才能成為優秀的php程式設計師,他們也通常會回答說,程式碼應該要清晰易懂易於維護。這的確是我想聽到的聲音,但是很少有年輕的程式設計師真的能夠始終如一地貫徹這一點。
請謹記這一點,要懂得“自我規範”,也不能一旦代碼“起效了”就立刻置之腦後。如果所有的變數都命名錯誤,但是程式碼依然可以完美地運行,那麼這些程式碼絕對亂糟糟得讓人不忍直視。將功能代碼改進為簡潔代碼可能在短期內是看不到回報的:代碼原本就可以工作,在清潔之後依然可以工作。這就是為什麼你需要「自我規範」這一步驟了。這也是為什麼實習工作是如此必要:一個好的上司是相當注重程式碼品質的(即使所謂「好程式碼」的定義對於每個程式設計師都不一樣),從而迫使實習生和初級程式設計師不得不反覆修改。
下面我舉的一些例子都是新手程式設計師寫程式碼的時候常出現的:
名不副實的函數/變數/類別
這些函數、類別和變數所做的名字表達的含義並不一致。片面看名字是正確的,但是聯繫實際的話,有的甚至是毫不相關的。
舉個例子,我上一期的實習生寫了兩個類別:EditorGUI和EditorObjectCreatorGUI。用於處理編輯介面的程式碼。讓我哭笑不得的是,用來建立新物件的是EditorGUI,而EditorObjectCreatorGUI只能透過處理不同的物件來導覽。兩者的意義居然是截然相反的!即使程式碼還算相對簡單,但我還是花了相當長的一段時間用來理解它,因為一開始我是在一個完全相反的假設基礎上來理解的。這種情況的解決方案非常簡單:重新命名EditorObjectCreatorGUI為EditorObjectNavigationGUI即可,這樣就易於理解多了。
這種情況我看到很多。之所以會發生這種情況是因為程式碼在工作過程中發生了演變。在選擇名字的時候可能還是正確的,但到了寫完程式碼的那一刻,就名不副實了。關鍵是要時時銘記命名法則。你得明白你添加的東西是否依然符合函數和類別的名稱。
混亂的類別
另一個問題是類很亂:類做了很多不相關的事情。新功能的添加很簡單,但是慢慢的,你會發現你的程式碼變得臃腫不堪,各種不相關的功能隨處可見。有時候,臃腫與否也不指的是類別的大小:某個類別可能只有幾百行,但依然囊括了不屬於它的程式碼。
為什麼會發生這種情況呢?舉個例子:假設因為某些原因,某個GUI類別需要分析什麼樣的紋理可行(可能是有按鈕要用來選擇紋理)。如果這個GUI類別是唯一需要這個分析結果的類別,那麼在GUI類別中這樣做是有意義的。然而,由於某種原因,一個完全無關的gameplay類別也需要這些資訊。所以你需要將這些紋理查詢的資訊從GUI類別傳給gameplay類別。這時候,其實這個GUI類別已經變大了:因為它裡面其實還包含了TextureAnalyser類別。解決方法也簡單:將TextureAnalyser類別分割為一個單獨的類,GUI類別和gameplay類別都可以使用它。
關於這一條經驗法則很多人提出質疑:要是我添加的功能仍然適合原來這個類的名字呢?如果的確不適合,那麼我就必須重命名,或者將其分割成單獨的類,抑或用代碼寫成一個不同的類嗎?
如果你不能為你的類別想出一個合適的名字,給人的感覺就會不舒服。如果你不能在類別的名字中描述它的目的,那麼就會顯得亂七八糟。有時候我們還需要將某個臃腫的類別分割成幾個部分,並各自取一個恰當的名字。
過於龐大的類
分割一個已經長得很大的類其實是相當枯燥的。這也會成為一個挑戰,如果類別中的程式碼高度交織在一起的話。再加上它已經在工作,修復時不能添加新功能,這樣一來,我不得說,分割一個過於龐大的類,不能嚴格地自我規範是不行的。
根據在Ronimo的普遍經驗,類別保持在500行程式碼以下、函數保持在50行程式碼以下是最適合的。不過有時候,這樣做反而不可行,也不明智。但是一般說來,一旦類別或函數超出了那個界限我們就可以想辦法重構,並將之分割為更小更易於管理的片段了。
關於程式碼註解
幾乎的程式碼都會包含註解好了的程式碼片段,而不說明為什麼。這段程式碼需要修復嗎?舊的程式碼是否已經被取代了?為什麼那兒要寫這些程式碼?大家都知道沒有註解的程式碼常常不知所言,但不知何故,很多人都會忘記在自己的程式碼上註解。
平行邏輯和程式碼重複
例如,我們可以從紋理這個名稱知道它大概的目標對象,比如說是「TreeBackground.dds」。為了知道紋理是否可以用於tree,我們檢查了檔案名稱以便知道它是不是以「tree」開的頭。可能使用SDK的話我們用filename.beginsWith(「tree」)可以很快地偵測出來。只是這句程式碼這麼短,我們往往會選擇哪個地方需要,就直接複製貼上。當然這樣就是程式碼重複了,而正如每個人都知道的,我們應該避免重複程式碼,但如果複製的程式碼是如此之短,我們往往會忘記這一點,很自然地就直接copy了。這裡我們面對的問題也是顯而易見的:也許後面我們檢查某個紋理是否適合tree的方法就得變了,然後我們就不得不實行「霰彈槍式修改」(即到處修改)策略,一處一處地修復。 此處的一般規律是,如果是非常具體的程式碼,那就不要複製,即使原本的程式碼超級之短,呼叫函數甚至比直接寫入需要更多的程式碼,也應該封裝成函數。 上面討論的這些內容已經講得非常透徹了。很多內容甚至你在大學就學過。但是現在要面臨的挑戰是你需要一步一步地從被動遵守到主動銘記於心養成一種習慣。這也是為什麼Ronimo中的實習生最重要的不是學習知識,而是學會自我規範。
免費領取兄弟連IT教育原創php教學光碟/《細說PHP》精要版,詳情諮詢官網客服:http://www.lampbrother.net
學PHP、Linux、HTML5、UI、Android等影片教學(課件筆記影片)!聯絡Q2430675018
參加活動領取兄弟連原創視訊教學光碟合集:http://www.lampbrother.net/newcd.html
|