コードの品質と全体的な生産性を向上させるための 11 のステップ

この記事では、私がプロのプログラマーとして長年にわたって学んだ、コードの品質と全体的な作業効率を実際に向上させる 11 のことを紹介します。

1. コードをコピーしないでください

コードの重複は絶対に避けてください。よく使用されるコード部分がプログラム内の複数の異なる場所に出現する場合は、それをリファクタリングして独自の関数に組み込みます。コードが重複すると、同僚がコードを読んだときに混乱が生じます。ある箇所を修正し、別の箇所を修正し忘れるという繰り返しのコードを繰り返すと、あちこちでバグが発生し、コードサイズも肥大化します。最新のプログラミング言語は、これらの問題を解決するための優れた方法を提供しています。たとえば、次の問題は以前は解決するのが困難でしたが、現在ではラムダを使用して簡単に実装できます。

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;"> 
</span></span>

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">/// <summary>
/// 一些函数含有部分重复代码
/// </summary>
void OriginalA()
{
        DoThingsA();

        // unique code

        DoThingsB();
}

/// <summary>
/// 另外一个含有部分重复代码的函数
/// </summary>
void OriginalB()
{
        DoThingsA();

        // 没有重复的代码

        DoThingsB();
}</span></span>

次に、同じコードの一部を含む関数をリファクタリングし、デリゲート モードを使用して書き換えます。

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;"> 
</span></span>

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">/// <summary>
/// Encapsulate shared functionality
/// </summary>
/// <param name="action">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
        });
}</span></span>

2. 気が散り始めたときに注意してください

問題を解決する代わりに Facebook や Twitter をスクロールしていることに気づいた場合、それは通常、短い休憩が必要であることを示しています。デスクから離れて、コーヒーを飲んだり、同僚と 5 分間おしゃべりしたりしてください。これは直感に反するように思えるかもしれませんが、長期的には生産性が向上します。

3. 急いで自分の原則を放棄しないでください

問題を解決したり、バグを修正しなければならないというプレッシャーにさらされると、自制心を失い、急いでいることに気づき、遵守してきた重要なテスト プロセスを完全に忘れてしまうことさえあります。これは多くの場合、さらなる問題を引き起こし、上司や同僚の目にあなたがプロフェッショナルではないと映ることになります。

4. 完成したコードをテストします

コードが何をするのかはわかっていて、それを試してみるとうまくいきましたが、実際にはコードを完全に検証する必要があります。考えられるすべてのエッジケースを分析し、考えられるすべての条件下で期待どおりに動作することをテストします。パラメータがある場合は、予想される範囲外の値を渡します。 null 値を渡します。可能であれば、同僚にコードを見てもらい、解読できるかどうか尋ねてください。単体テストは、この目標を達成するための一般的な方法です。

5. コードレビュー

コードを送信する前に、同僚と座って、どのような変更を加えたかを説明してください。多くの場合、これを行うことで、同僚が何も言わなくてもコード内のエラーを見つけることができます。これは、独自のコードをレビューするよりもはるかに効果的です。

6. コードを減らす

単純な問題を解決するために大量のコードを書いていることに気づいたら、おそらくやり方が間違っています。次のブール値の使用法は良い例です:

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">if (numMines > 0) { enabled=true; } else { enabled=false; }</span></span>

このとき、次のように書く必要があります:

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">enabled = numMines > 0;</span></span>

コードは少ないほど良いです。これにより、バグが減り、リファクタリングの可能性が減り、エラーが発生する可能性が減ります。ほどほどにしましょう。読みやすさも同様に重要であり、これを行うことでコードの読みやすさが低下することはありません。

7. 为优雅的代码而努力

优雅的代码非常的易读，只用手边很少的代码、让机器做很少的运算就能解决问题。在各种环境中都做到代码优雅是很难的，但经过一段时间的编程，你会对 优雅的代码是个什么样子有个初步的感觉。优雅的代码不会通过重构来获得。当你看到优雅的代码是会很高兴。你会为它自豪。例如，下面就是一个我认为是优雅的 方式来计算多边形面积的方法：

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;"> 
</span></span>

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">static public double GetConvexPolygonArea(Vector2[] vertices)
{
        double area = 0;
        for (int i = 0; i </span></span>

8. 编写不言自明的代码

勿庸置疑，注释是编程中很重要的一部分，但能够不言自明的代码跟胜一筹，因为它能让你在看代码时就能理解它。函数名变量名要慎重选择，好的变量/方法名字放到语言语义环境中时，不懂编程的人都能看懂。例如：

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;"> 
</span></span>

<span style="font-family: " comic sans ms cursive><span style="font-size: 14px;">void DamagePlayer(Player player, int damageAmount)
{
        if (!player.m_IsInvincible && !player.m_IsDead)
        {
                player.InflictDamage( damageAmount );
        }
}</span></span>

能自我说明的代码不能代替注释。注释是用来解释“为什么”的，而自我说明的代码是来描述“是什么”的。

9. 不要使用纯数字

直接把数字嵌入代码中是一种恶习，因为无法说明它们是代表什么的。当有重复时更糟糕——相同的数字在代码的多个地方出现。如果只修改了一个，而忘记了其它的。这就导致bug。一定要用一个命名常量来代表你要表达的数字，即使它在代码里只出现一次。

10. 不要做手工劳动

当做一系列动作时，人类总是喜欢犯错误。如果你在做部署工作，并且不是一步能完成的，那你就是在做错事。尽量的让工作能自动化的完成，减少人为错误。当做工作量很大的任务时，这尤其重要。

11. 避免过早优化

当你要去优化一个已经好用的功能代码时，你很有可能会改坏它。优化只能发生在有性能分析报告指示需要优化的时候，通常是在一个项目开发的最后阶段。性能分析之前的优化活动纯属浪费时间，并且会导致bug出现。