內部培訓——規範原則與重構

前天給公司即將加入到Team Dev的同事們做了一次培訓，內容比較基礎，但也比較使用，寫出來和大家一起分享。

第一部分的內容是關於代碼規範的，由於是國內開發，所以公司的核心系統的代碼規範比較差，甚至於很多地方沒有什麼規範。這給系統的問題診斷、修改、維護以及後期的二次開發帶來了很多不便，我的目的就是要把最基本的規範告訴大家，從最基本的規範做起，一點一點地提高。

之前曾經做過一次關於規範的交流，但是效果不是很好，這一次做了一些總結和提煉，想以大家更容易接受的方式來交流。

在其中我提到了以下幾點：

1、距離產生美

在代碼中我會採用一些形式，使得實現不同功能的代碼彼此之間能夠產生一些距離，這樣代碼看起來會比較美觀，也就達到了“距離產生美”的效果。

我們可以藉助以下幾種方式來產生距離：

a）空格

比方說：bonus=money*rate;

可以通過空格分隔：bonus = money * rate;

b) 空行

比方說：

 

//完成第一件事的代碼<br />……<br />//完成第二件事的代碼<br />…… 

 

兩端代碼之間可以放一個空行，使其中間產生距離。但是這裡一個空行足矣，如果用了多個空行，那就是“距離有了，美沒了”，哈哈。

c）大括弧，近似於空行的效果，也就是將每個大括弧都放在單獨的一行上。

比方說：

try<br />{<br />//一些代碼<br />……<br />}<br />catch (Exception ex)<br />{<br />//捕獲異常的代碼<br />……<br />} 

d）Tab符號

這個很簡單，就是用來控制縮排，從而讓代碼顯出層次來。

2、適度

這個原則也很好理解，而且針對的問題主要是不合理的變數命名以及過長的方法。

變數的長度要適度；

方法的長度要適度，一般不要超過70行；

注釋的量也要適度，並非越多越好，所寫的注釋都應該是有用的，而不是把代碼再說一遍。

3、垃圾要扔掉，有病要治好

首先垃圾指的是檔案中的無用代碼，比方說打出來顯示的調試資訊，比方說注釋掉的代碼等等。

病指的是檔案編譯之後存在的警告和錯誤，這在某些系統中大量存在。記得我第一次引入整個系統，編譯了一次之後，竟然發現有800多個Error以及上萬條的warning，我還以為自己什麼地方的配置出了問題，後來發現這個系統就是在這樣的一種狀態下啟動並執行，很可怕，是吧，但實際的情況就是這樣。

 

掌握以上三條原則，就可以達到最基本的代碼規範。雖然現在的系統使用Java開發的，但是用這種物件導向的語言開發出來的完全是面向過程的系統，所以在鬼法中沒有提到與類、介面、屬性等相關的內容。

 

之後我又介紹了最基本的幾種壞味道以及相應的重構方法，很遺憾，大家對此不是很瞭解，竟然感到很稀奇，這也更讓我決定要繼續向大家介紹更多的常識，從而讓開發更有效率，品質也更高。

 

這個部分的內容包括：（前者是壞味道，後者是重構的方法）

不規範的命名 VS 重新命名

過長的方法 VS 抽取方法

重複的類方法 VS 提取父類

魔法數 VS 定義常量

 

內容很簡單，在此不做過多說明。

 

其實培訓這種形式為大家的交流提供了一個很好的平台，我想我們應該堅持下去，而且隨著大家分享的內容不斷增多，也會有越來越多的想法，這不僅僅對於團隊很好，對於個人也同樣是非常有益的。