次の開発者のためのコーディング5つのステップ

私たちの多くは、自分のコードを保守する開発者のことを考えていないでしょう。最近まで、私も彼のことを考慮していませんでした。意図的に分かりにくいコードを書いたことはありませんが、パンくずを残すこともありませんでした。

優秀なプログラマーについてのケント・ベックの言葉：

どんな愚か者でもコンピューターが理解できるコードを書くことができる。優秀なプログラマーは人間が理解できるコードを書く。

優秀なコンピュータープログラムについてのダグラス・クロックフォードの言葉：

すべてはコミュニケーションと、そのコミュニケーションを促進するために使用する構造に帰結する。人間の言語とコンピューター言語は多くの点で非常に異なる働きをするが、最終的に私は、そのプログラムを読む人間とコミュニケーションを取る能力によって優秀なコンピュータープログラムを判断する。そのレベルでは、それらはそれほど違わない。

最もよく書かれたコードでも、目的と意図を発見するのは困難です。作者が残したパンくず、コメント、冗長な命名、一貫性は、次の開発者にとって非常に役立ちます。

私はパターンを探すことから始めます。パターンは変数名、クラスレイアウト、プロジェクト構造など多くの場所で見つけることができます。一度特定されると、パターンは前の開発者の意図への洞察となり、コードの理解に役立ちます。

パターンとは何でしょうか？パターンは繰り返し発生する問題に対する再利用可能な解決策です。ドアを考えてみてください。空間が人々の出入りを可能にしながらも隔離を維持する必要がある場合、ドアパターンが実装されます。これは明らかに思えますが、ある時点ではそうではありませんでした。誰かがドアハンドル、ヒンジ、これらのコンポーネントの配置を含むドアパターンを作成しました。どの家に入っても、ドアとそのコンポーネントを識別できます。スタイルや色は異なるかもしれませんが、コンポーネントは同じです。ソフトウェアも同じです。

一般的なソフトウェア問題に対する既知のソフトウェアパターンがあります。1995年に、一般的なソフトウェアパターンを説明する「デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素」が出版されました。この本は、ほとんどのソフトウェアアプリケーションで遭遇する一般的な問題を説明し、これらの問題を解決するエレガントな方法を提供しました。開発者は、日常的に遭遇する問題を解決しながら独自のパターンも作成します。彼らは本を出版しませんが、十分に注意深く見れば、それらを識別できます。

時にはパターンを識別するのが困難な場合があります。これによりコードの理解が困難になります。このような状況に陥った場合は、コードを検査し、それがどのように使用されているかを確認してください。書き直しを始めてください。自分ならどのように同じ結果を達成するかを自問してください。多くの場合、アルゴリズムの思考プロセスを辿ることで、他の開発者の実装への洞察を得ることができます。私たちの多くは、理解できないものを書き直したい衝動を持っています。この衝動に抵抗してください！既存の実装は実戦でテストされており、あなたのものはそうではありません。

一部のコードは単に困惑させるものです。同僚に手を差し伸べてください — 第二の目は常に役立ちます。一緒にコードを歩いてください。二人で見つけるものに驚くでしょう。

次の開発者のためにパンくずを残す5つのヒント

1. パターン
既知のパターンを使用し、独自のパターンを作成してください。コード全体を通して一貫したパラダイムを維持してください。例えば、データアクセスに3つのアプローチを持たないでください。

2. 一貫性
これはコーディングの最も重要な側面です。一貫性のないコードを見つけることほど苛立たしいことはありません。一貫性は仮定を可能にします。特定のソフトウェアパターンに遭遇するたびに、そのパターンの他のインスタンスと同様に動作すると仮定されるべきです。

一貫性のないコードは悪夢です。異なる場所の同じ単語を含め、すべての単語が異なる意味を持つ本を読むことを想像してください。各単語を調べ、意図を発見するために大量の精神的エネルギーを費やす必要があるでしょう。それは苛立たしく、退屈で、痛みを伴います。あなたは狂ってしまうでしょう！次の開発者にこれをしないでください。

3. 冗長な命名
これはあなたの言語です。これらはあなたの物語の言葉です。それらをうまく織り込んでください。

これにはクラス名、メソッド名、変数名、プロジェクト名、プロパティ名が含まれます。

悪い例：

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

良い例：

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

最初の例では、if文に3がハードコードされています。このコードは構文的に正しいですが、数字3の意図は何も教えてくれません。評価されるプロパティを見ると、それが実際に3時間であることを推測できます。実際には分かりません。私たちは仮定をしています。

2番目の例では、3を’feedInterval’という変数に設定しています。意図は変数名で明確に述べられています。最後の食事から3時間経過した場合、猿に餌を与える時間です。変数を設定することの副作用として、ロジックを変更することなく給餌間隔を変更できるようになりました。

これは作為的な例ですが、大きなソフトウェアでは、このタイプのコードは自己文書化され、次の開発者がコードを理解するのに役立ちます。

4. コメント
コメントは両刃の剣です。コメントが多すぎると保守コストが増加し、少なすぎると開発者はコードの動作について確信が持てなくなります。一般的な経験則は、平均的な開発者がコードを理解できない場合にコメントすることです。これは仮定が明らかでない場合や、コードが通常とは異なる場合に発生します。

5. シンプルなコード
私の専門的な意見では、複雑なコードを書くことは開発者の最大の愚行です。

シンプルさについてのスティーブ・ジョブズの言葉：

シンプルは複雑よりも困難な場合がある：シンプルにするために思考をクリアにする努力をしなければならない。しかし、最終的にはそれだけの価値がある。なぜなら、そこに到達すれば、山を動かすことができるからだ。

複雑さは多くの形で現れます。その一部には、将来の証明、過度に複雑な実装、過度の抽象化、大きなクラス、大きなメソッドが含まれます。

クリーンでシンプルなコードの書き方について詳しくは、アンクル・ボブの本「Clean Code」とマックス・カナット・アレクサンダーの「Code Simplicity」をご覧ください。

終わりに

コードを読むのは困難です。いくつかの簡単なステップで、次の開発者があなたのコードを理解できることを確実にできます。