プログラマーのためのプログラミング十戒

1.- DRY: 繰り返しはしないでください。
DRY は最も単純なルールであり、最も理解しやすいです。しかし、これは適用するのが最も難しいかもしれません (これを行うには、一般的な設計に多大な労力を費やす必要があり、これは簡単な作業ではないからです)。これは、2 つ以上の場所で類似したコードを見つけた場合、それらの共通点を抽象化して独自の新しいメソッドを形成し、既存の場所のコードを変更して、適切なパラメーターを使用してこの新しいメソッドを呼び出す必要があることを意味します。

DRY このルールは、これまでのところ、プログラミングにおいて最も一般的なルールと言えます。このルールに異議を唱えるプログラマはいないはずです。ただし、一部のプログラムは単体テストを作成するときにこの規則を忘れていることがわかります。 DRY を使用しない場合、クラスのいくつかのインターフェイスを変更するとき、呼び出しを渡すインターフェイスの単体テスト プロシージャが変更されると想像してください。システム クラスは手動で変更する必要があります。例: 単体テストの多くのテスト ケースが、クラスを構築する標準の共通メソッドを使用していないが、各テスト ケースが独自にクラスのインスタンスを構築する場合、クラスのコンストラクターが変更されたときに、次のことを行う必要があります。テストケースはいくつありますか?これは、DRY ルールを使用しなかった場合の結果です。

2.- 短いメソッド。
少なくとも、プログラマーが短いメソッドを作成する十分な理由が次の 3 つあります。

コードが読みやすくなります。
コードの再利用が容易になります (短いメソッドによりコード間の結合度を減らすことができます)
コードのテストが容易になります。
3.- 適切な命名規則
クラス、関数、または変数に名前を付けるときに、適切な統一命名規則を使用すると、プログラムが読みやすく、保守しやすくなります。 「テキストを文字通りに読む」ことができれば、文書が減り、コミュニケーションも減ります。 「プログラミングにおけるデザインの名前付けに関するいくつかのこと」という記事で、いくつかのヒントが得られます。

4.- 各クラスに正しい責任を与える
そのようなルールについては、クラスの SOLID ルールを参照できます。しかし、私たちがここで強調するのは、単一の責任ではなく、正しい責任です。 Customer というクラスがある場合、このクラスには sales メソッドを持たせないでください。このクラスには、Customer に最も直接関係するメソッドのみを持たせることができます。

5.- コードを整理する
コードの整理には 2 つのレベルがあります。

物理層の構成: 使用するディレクトリ、パッケージ、または名前空間の構造の種類に関係なく、標準的な方法でクラスを編成する必要があります。これは検索に便利です。これは物理的なコード構成です。
論理層構成: いわゆる論理層とは、主に、機能の異なる 2 つのクラスまたはメソッドを特定の仕様に従って接続して構成することを意味します。ここでの主な関心事は、プログラム モジュール間のインターフェイスです。これは、私たちがよく目にするプログラム モジュールのアーキテクチャです。
6.- 単体テストを大量に作成する
単体テストはBUGに最も近い場所であり、BUGを修正するコストが最も低い場所でもあります。ソフトウェア全体の品質の成否を決める場所。したがって、可能な限り、より多くのより優れた単体テスト ケースを作成して、将来対応するコード変更を行うときに、コードの変更が他のユニットに影響を与えるかどうかを簡単に知ることができるようにする必要があります。

7.- コードを頻繁にリファクタリングします
ソフトウェア開発は、コードが実際の要件の最新の変更に対応できるようにするための継続的な発見のプロセスです。したがって、このような変更に対応するには、コードを頻繁にリファクタリングする必要があります。もちろん、リファクタリングにはリスクがあり、すべてのリファクタリングが成功するわけではありません。また、いつでもコードをリファクタリングできるわけではありません。以下は、さらなるバグの導入や、すでに悪いコードの悪化を避けるためにコードをリファクタリングするための 2 つの前提条件です。

テストすべき単体テストが山ほどあります。前述したように、リファクタリングには保証とテストのために多数の単体テストが必要です。
すべてのリファクタリングを大規模なものにせず、大規模なリファクタリングの代わりに小さなリファクタリングを少しずつ使用してください。最初に 2000 行のコードのリファクタリングを計画し、3 時間後に計画を放棄してコードを元のバージョンに戻すことがよくあります。したがって、私たちが推奨しているのは、リファクタリングは少しずつ積み重ねることです。
8.- プログラムのコメントは悪です
ほとんどのプログラマは、プログラムのコメントは非常に優れていると考えています。理論的には、プログラムのコメントは非常に優れています。良い。しかし、実際のプログラミングにおいては、プログラマが書くコメントは非常に貧弱であり（プログラマの表現力には非常に問題がある）、それがプログラムのコメントが諸悪の根源となり、またプログラムを読む能力の欠如にもつながっている。そのときは、コメントは読まずにコードを直接読みます。したがって、ここでは、コメントを書かないことをお勧めするわけではありませんが、コメントが十分でない場合は、コードをより読みやすく、より明確に、コメントよりも優れたものにするために、コードのリファクタリングにもっと重要な時間を費やしたほうがよいでしょう。

9.- 実装ではなくインターフェースに焦点を当てる
これは最も古典的なルールです。インターフェースは「何を」という抽象化に焦点を当て、実装は「どのように」という詳細に焦点を当てます。インターフェイスは契約に相当し、実際の内容はこの契約の運用と実装に相当します。運用は非常に柔軟ですが、契約は比較的安定していて変更されない必要があります。インターフェースが適切に設計されておらず、頻繁な変更が必要な場合、この世代では間違いなく非常にコストがかかる結果になることが想像できます。したがって、ソフトウェア開発とデバッグでは、実装ではなくインターフェイスが最優先されます。ただし、当社のプログラマーは常に実装の詳細に重点を置いているため、部分的なコードは非常に優れていますが、全体的なソフトウェア設計は比較的貧弱です。これには私たちがさらに注意を払う必要があります。

10.- コードレビューの仕組み
1 人が間違える確率は非常に高くなりますが、2 人が間違える確率は低くなります。人数が増えれば増えるほど、間違いを犯す確率はどんどん小さくなっていきます。人数が増えると、物事をさまざまな視点から見ることができるため、非効率な議論につながる可能性がありますが、ソフトウェア製品のリリース後の問題のメンテナンスコストに比べれば、このコストは十分に価値があります。したがって、コード レビューのメカニズムは、問題を発見するための最も効果的なメカニズムであるだけでなく、知識を共有するためのメカニズムでもあります。もちろん、コード レビューには以下のいくつかの基本原則があります。

レビュー担当者の能力はコード作成者の能力以上でなければなりません。そうでない場合、コード レビューは初心者のための一種のトレーニングになってしまいます。
また、レビュアーがおざなりなレビューを行うのではなく、真の責任を負うためには、レビュアーがコードの作成者ではなく、レビューしたコードに対して主に責任を負う必要があります。
さらに、優れたコード レビューは、コードが完成した時点で行うのではなく、コード作成のプロセス中に反復的にコード レビューを行う必要があります。良い習慣として、コードが完成しているかどうかに関係なく、コード レビューは数日ごとに継続的に実行する必要があります。