新手程序員在工做中須要注意的問題

 

須要學習的最重要的東西是「自我規範」。這些規範就是：儘量地寫出最簡潔的代碼;若是代碼後期會由於改動而變得凌亂不堪就得重構;儘可能刪除沒用的代碼，並添加註釋。

請謹記這一點，要懂得「自我規範」，也不能一旦代碼「起效了」就立馬置之腦後。若是全部的變量都命名錯誤，可是代碼依然能夠完美地運行，那麼這些代碼絕對亂糟糟得讓人不忍直視。將功能代碼改進爲簡潔代碼可能在短時間內是看不到回報的。這就是爲何你須要「自我規範」這一步驟了。這也是爲何實習工做是如此必要：一個好的上司是至關注重代碼質量的(即便所謂「好代碼」的定義對於每一個程序員都不同)，從而迫使實習生和初級程序員不得不反覆修改。

 

下面本文舉的例子都是新手程序員寫代碼的時候常常出現的：

 

名存實亡的函數/變量/類

這些函數、類和變量實際所作的事與其名字所表達的含義並不一致。片面看名字是正確的，可是聯繫實際的話，有的甚至是絕不相關的。

舉個例子，這兩個類：EditorGUI和EditorObjectCreatorGUI。用於處理編輯界面的代碼。用於建立新對象的是EditorGUI，而EditorObjectCreatorGUI只能經過處理不一樣的對象進行導航。二者的含義竟然是截然相反的!即便代碼還算相對簡單，但仍是花了至關長的一段時間用來理解它，由於在一開始是在一種徹底相反的假設基礎上來理解的。這種狀況的解決方案很是簡單：重命名EditorObjectCreatorGUI爲EditorObjectNavigationGUI便可，這樣就易於理解多了。

這種狀況有不少。之因此會發生這種狀況是由於代碼在工做過程當中發生了演變。在選擇名字的時候可能仍是正確的，但到了寫完代碼的那一刻，就名存實亡了。關鍵是要時刻銘記命名法則。你得明白你添加的東西是否依然符合函數和類的名稱。（西安尚學堂）軟件開發

 

混亂的類

另外一個問題是類很亂：類作了不少不相關的事情。新功能的添加很簡單，慢慢的你會發現你的代碼變得臃腫不堪，各類不相關的功能隨處可見。有時候臃腫與否也並不指的是類的大小：某個類可能只有幾百行，但依然囊括了不屬於它的代碼。

爲何會發生這種狀況呢?舉個例子：假設因爲某種緣由，某個GUI類須要分析什麼樣的紋理可行。若是這個GUI類是惟一須要這個分析結果的類，那麼在GUI類中這樣作是有意義的。然而，因爲某種緣由，一個徹底無關的gameplay類也須要這些信息。因此你須要將這些紋理查詢的信息從GUI類傳給gameplay類。這時候，其實這個GUI類已經變大了：由於它裏面其實還包括了TextureAnalyser類。解決方法也簡單：將TextureAnalyser類分割爲一個單獨的類，GUI類和gameplay類均可以使用它。

關於這一條經驗法則不少人提出質疑：要是我添加的功能仍然適合原來這個類的名字呢?若是的確不適合，那麼我就必須重命名。或者將其分割成單獨的類，抑或用代碼寫成一個不一樣的類嗎?

若是你不能爲你的類想出一個合適的名字，給人的感受就會不舒服。若是你不能在類的名字中描述它的目的，那麼就會顯得亂七八糟。有時候咱們還須要將某個臃腫的類分割成幾部分，並各自取一個恰當的名字。

　　

過於龐大的類

這和上一點——混亂的類有些相似：不少東西一點一點地都添加到類中，而後它不可避免地就臃腫了。在這種狀況下，這樣一個類仍然是有意義的，但就是長得太大個了點。這麼個龐然大物不但繁瑣，並且很容易出現bug，由於大量的代碼須要用於操做同一個私有成員變量，因此咱們很容易忽視一些細節。

分割一個已經長得很大的類實際上是至關枯燥的。這也會成爲一個挑戰，若是類中的代碼高度交織在一塊兒的話。再加上它已經在工做，修復時不能添加新功能，這樣一來，我不得說，分割一個過於龐大的類，不能嚴格地自我規範是不行的。

根據在Ronimo的廣泛經驗，類保持在500行代碼如下、函數保持在50行代碼如下是最合適的。不過有時候，這樣作反倒不可行，也不明智。可是通常說來，一旦類或函數超出了那個界限咱們就能夠想辦法重構，並將之分割爲更小更易於管理的片斷了。

　　

關於代碼註釋

幾乎全部的示例代碼都會包含註釋好了的代碼片斷，而不說明爲何。這段代碼須要修復嗎?舊的代碼是否已經被取代了?爲何那兒要寫這些代碼?你們都知道沒有註釋的代碼經常不知所言，但不知何故，不少人都會忘記在本身的代碼上註釋。

　　

並行邏輯和代碼重複

還有一個問題就是我常常能在若干個代碼段處看到類似的邏輯。

例如，咱們能夠從紋理這個名稱知道它大概的目標對象，好比說是「TreeBackground.dds」。

爲了知道紋理是否能夠用於tree，咱們檢查了文件名以便知道它是否是以「tree」開的頭。可能使用SDK的話咱們用filename.beginsWith(「tree」)能夠很快地檢測出來。只是這句代碼這麼短，咱們每每會選擇哪一個地方須要，就直接複製粘貼。固然這樣就是代碼重複了，而正如每一個人都知道的，咱們應該避免重複代碼，但若是複製的代碼是如此之短，咱們每每會忘記這一點，很天然地就直接copy了。此處咱們面對的問題也是顯而易見的：也許後面咱們檢查某個紋理是否適合tree的方法就得變了，而後咱們就不得不實行「霰彈式修改」(即處處修改)策略，一處一處地修復。

 

此處的通常規律是，若是是很是具體的代碼，那就不要複製，即便本來的代碼超級之短，調用函數甚至比直接寫須要更多的代碼，也應該封裝成函數。

上面討論的這些內容已經講得很是透徹了。不少內容甚至你在大學中就學過。可是如今要面臨的挑戰是你須要一步步地從被動遵照到主動銘記於心養成一種習慣。