要修改的bug 和 編碼習慣

 CustomerActivityplanController 

一、不能從session中取值。

二、註釋儘可能  @throws   儘可能詳細一點。

這篇文章要介紹的，是我做爲專業程序員這些年來學到的能真正提升個人代碼質量和總體工做效率的10件事情。

1. 永遠不要複製代碼

不惜任何代價避免重複的代碼。若是一個經常使用的代碼片斷出如今了程序中的幾個不一樣地方，重構它，把它放到一個本身的函數裏。重複的代碼會致使你的同事 在讀你的代碼時產生困惑。而重複的代碼若是在一個地方修改，在另一個地方忘記修改，就會產生處處是bug，它還會使你的代碼體積變得臃腫。現代的編程語 言提供了很好的方法來解決這些問題，例如，下面這個問題在之前很難解決，而現在使用lambdas卻很好實現：

///<summary>

/// 一些函數含有部分重複代碼

///</summary>

void OriginalA（）

{

DoThingsA（）;

// unique code

DoThingsB（）;

}

///<summary>

/// 另一個含有部分重複代碼的函數

///</summary>

void OriginalB（）

{

DoThingsA（）;

// 沒有重複的代碼

DoThingsB（）;

}

如今咱們重構含有部分相同代碼的函數，用delegate模式重寫它們：

///<summary>

/// Encapsulate shared functionality

///</summary>

///User defined action

void UniqueWrapper（Action action）

{

DoThingsA（）;

action（）;

DoThingsB（）;

}

///<summary>

/// New implmentation of A

///</summary>

void NewA（）

{

UniqueWrapper（（） =>

{

// unique code

}）;

}

///<summary>

/// New implementation of B

///</summary>

void NewB（）

{

UniqueWrapper（（） =>

{

// unique code

}）;

}

2. 留意你開始分心的時候

當你發現本身在瀏覽facebook或微博、而不是在解決問題，這一般是一種你須要短暫休息的信號。離開辦公桌，去喝一杯咖啡，或去跟同事聊5分鐘。儘管這樣作看起來有點反直覺，但長久去看，它會提升你的工做效率。

3. 不要匆忙趕任務而放棄原則

當帶着壓力去解決一個問題或修改一個bug，你很容易失去自制，發現本身匆匆忙忙，甚至徹底忘了一直堅持的重要的測試過程。這一般會致使更多的問題，會讓你在老闆或同事眼裏顯得很不專業。

4. 測試你完成的代碼

你知道你的代碼能作什麼，並且試了一下，它確實好用，但你實際上須要充分的驗證它。分析全部可能的邊界狀況，測試在全部可能的條件下它都能如期的工 做。若是有參數，傳遞一些預期範圍外的值。傳遞一個null值。若是可能，讓同事看看你的代碼，問他們可否弄壞它。單元測試是到達這種目的的常規方法。

5. 代碼審查

提交你的代碼以前，找個同事一塊兒坐下來，向他解釋你作了哪些修改。一般，這樣作的過程當中你就能發現代碼中的錯誤，而不須要同事說一句話。這比本身審查本身的代碼要有效的多得多。

6. 讓代碼更少

若是你發現寫了大量的代碼來解決一個簡單的問題，你極可能作錯了。下面的boolean用法是一個很好的例子：

if （numMines > 0）

{

enabled=true;

}

else

{

enabled=false;

}

這時你應該寫成這樣：

enabled = numMines > 0;

代碼越少越好。這會使bug更少，重構可能性更小，出錯的概率更小。要適度。可讀性同等重要，你可不能這樣作而使代碼喪失可讀性。

7. 爲優雅的代碼而努力

優雅的代碼很是的易讀，只用手邊不多的代碼、讓機器作不多的運算就能解決問題。在各類環境中都作到代碼優雅是很難的，但通過一段時間的編程，你會對 優雅的代碼是個什麼樣子有個初步的感受。優雅的代碼不會經過重構來得到。當你看到優雅的代碼是會很高興。你會爲它自豪。例如，下面就是一個我認爲是優雅的 方式來計算多邊形面積的方法：

static public double GetConvexPolygonArea（Vector2［］ vertices）

{

double area = 0;

for （int i = 0; i < vertices.Length; i++）

{

Vector2 P0 = vertices［i］;

Vector2 P1 = vertices［（i + 1） % vertices.Length］;

area += P0.Wedge（P1）;

}

return area / 2;

}

8. 編寫不言自明的代碼

勿庸置疑，註釋是編程中很重要的一部分，但可以不言自明的代碼跟勝一籌，由於它能讓你在看代碼時就能理解它。函數名變量名要慎重選擇，好的變量/方法名字放到語言語義環境中時，不懂編程的人都能看懂。例如：

void DamagePlayer（Player player， int damageAmount）

{

if （！player.m_IsInvincible && ！player.m_IsDead）

{

player.InflictDamage（ damageAmount ）;

}

}

能自我說明的代碼不能代替註釋。註釋是用來解釋「爲何」的，而自我說明的代碼是來描述「是什麼」的。

9. 不要使用純數字

直接把數字嵌入代碼中是一種惡習，由於沒法說明它們是表明什麼的。當有重複時更糟糕——相同的數字在代碼的多個地方出現。若是隻修改了一個，而忘記了其它的。這就致使bug。必定要用一個命名常量來表明你要表達的數字，即便它在代碼裏只出現一次。

10. 不要作手工勞動

當作一系列動做時，人類老是喜歡犯錯誤。若是你在作部署工做，而且不是一步能完成的，那你就是在作錯事。儘可能的讓工做能自動化的完成，減小人爲錯誤。當作工做量很大的任務時，這尤爲重要。

11. 避免過早優化

當你要去優化一個已經好用的功能代碼時，你頗有可能會改壞它。優化只能發生在有性能分析報告指示須要優化的時候，一般是在一個項目開發的最後階段。性能分析以前的優化活動純屬浪費時間，而且會致使bug出現。

好吧，我說是10個，但你卻獲得了額外贈送的一個！

這些就是我要說的，我但願它們能幫助你改進編程開發過程。