10步讓你成爲更優秀的程序員

轉自：http://www.aqee.net/10-steps-to-becoming-a-better-programmer/

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

 

1. 永遠不要複製代碼

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

/// <summary>
/// 一些函數含有部分重複代碼
/// </summary>
void OriginalA()
{
    DoThingsA();

    // unique code

    DoThingsB();
}

/// <summary>
/// 另外一個含有部分重複代碼的函數
/// </summary>
void OriginalB()
{
    DoThingsA();

    // 沒有重複的代碼

    DoThingsB();
}

現在我們重構含有部分相同代碼的函數，用delegate模式重寫它們：

/// <summary>
/// Encapsulate shared functionality
/// </summary>
/// <param name="action">User defined action</param>
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. 爲優雅的代碼而努力

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

8. 編寫不言自明的代碼

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;
}

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

void DamagePlayer(Player player, int damageAmount)
{
    if (!player.m_IsInvincible && !player.m_IsDead)
    {
        player.InflictDamage( damageAmount );
    }
}

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

9. 不要使用純數字

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

10. 不要做手工勞動

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

11. 避免過早優化

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

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

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

下次再見！祝快樂！

Cheers, Paul.