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

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

Kent Beck が優れたプログラマーについて述べたこと：

どんな馬鹿でもコンピュータが理解できるコードを書くことができます。優れたプログラマーは人間が理解できるコードを書きます。

Douglas Crockford が優れたコンピュータプログラムについて述べたこと：

すべてはコミュニケーションと、そのコミュニケーションを促進するために使用する構造に帰結します。人間の言語とコンピュータ言語は多くの点で非常に異なる方法で機能しますが、最終的には、そのプログラムを読む人間とのコミュニケーション能力によってコンピュータプログラムの良さを判断します。だからその点では、それほど違いはありません。

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

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

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

一般的なソフトウェアの問題に対する既知のソフトウェアパターンがあります。1995年に、「Design Patterns: Elements of Reusable Object-Oriented Software」が出版され、一般的なソフトウェアパターンについて説明しました。この本は、ほとんどのソフトウェアアプリケーションで遭遇する一般的な問題について説明し、これらの問題を解決するための優雅な方法を提供しました。開発者は、日常的に遭遇する問題を解決しながら、独自のパターンも作成します。本を出版しなくても、十分に注意深く見れば、それらを識別できます。

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

一部のコードは本当に厄介です。ピアに連絡してください。2番目の視点は常に役立ちます。一緒にコードを進めてください。2人で見つけるものに驚くでしょう。

次の開発者のためにパンくずを残すための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. シンプルなコードを書く
私の専門的な意見では、複雑なコードを書くことは開発者の間で最大の愚行です。

Steve Jobs がシンプルさについて述べたこと：

シンプルは複雑よりも難しいかもしれません。シンプルにするために、あなたの思考をクリーンにするために一生懸命働く必要があります。しかし、最終的にはそこに到達すれば、山を動かすことができるので、それだけの価値があります。

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

クリーンでシンプルなコードの作成の詳細については、Uncle Bobの本Clean CodeとMax Kanat-AlexanderのCode Simplicityを参照してください。

終わりに

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