ホームページ >バックエンド開発 >PHPチュートリアル >プログラマーのためのプログラミングの十戒_PHP チュートリアル
プログラマーのためのプログラミングの十戒_PHP チュートリアル
- WBOYオリジナル
- 2016-07-21 15:45:41956ブラウズ
1.- DRY: 繰り返しはしないでください。
DRY は最も単純なルールであり、最も理解しやすいです。しかし、これは適用するのが最も難しいかもしれません (これを行うには、一般的な設計に多大な労力を費やす必要があり、これは簡単な作業ではないからです)。これは、2 つ以上の場所で類似したコードを見つけた場合、それらの共通点を抽象化して独自の新しいメソッドを形成し、既存の場所のコードを変更して、適切なパラメーターを使用してこの新しいメソッドを呼び出す必要があることを意味します。
DRY このルールは、プログラミングにおいて最も一般的なルールかもしれません。これまでのところ、このルールに異議を唱えるプログラマーはいないはずです。ただし、一部のプログラムは単体テストを作成するときにこの規則を忘れていることがわかります。DRY を使用しない場合、クラスのいくつかのインターフェイスを変更するとき、呼び出しを渡すインターフェイスの単体テスト プロシージャが変更されると想像してください。システム クラスは手動で変更する必要があります。例: 単体テストの多くのテスト ケースが、クラスを構築する標準の共通メソッドを使用していないが、各テスト ケースが独自にクラスのインスタンスを構築する場合、クラスのコンストラクターが変更されたときに、次のことを行う必要があります。テストケースはいくつありますか?これは、DRY ルールを使用しなかった場合の結果です。
2.- 短いメソッド
少なくとも、プログラマーが短いメソッドを書くのには次の 3 つの十分な理由があります。
コードが読みやすくなります。
コードの再利用が容易になります（短いメソッドによりコード間の結合度を減らすことができます）
コードのテストが容易になります。
3.- 適切な命名規則 クラス、関数、または変数の名前が「文字通り無意味」になる場合、適切な統一命名規則を使用すると、プログラムが読みやすく、保守しやすくなります。このレベルでは、文書もコミュニケーションも少なくなります。 「プログラミングにおけるデザインの名前付けに関するいくつかのこと」という記事で、いくつかのヒントが得られます。
4.- 各クラスに正しい責任を与えます 1 つのクラスに 1 つの責任 このようなルールについては、クラスの SOLID ルールを参照できます。しかし、私たちがここで強調するのは、単一の責任ではなく、正しい責任です。 Customer というクラスがある場合、このクラスには sales メソッドを持たせないでください。このクラスには、Customer に最も直接関係するメソッドのみを持たせることができます。
5.- コードを整理する コードの整理には 2 つのレベルがあります。
物理層の構成: どのようなディレクトリ、パッケージ、または名前空間構造を使用する場合でも、クラスを簡単に見つけられるように標準的な方法で編成する必要があります。これは物理的なコード構成です。
論理層の構成: いわゆる論理層とは、主に、機能の異なる 2 つのクラスまたはメソッドを特定の仕様に従って接続して構成することを意味します。ここでの主な関心事は、プログラム モジュール間のインターフェイスです。これは、私たちがよく目にするプログラム モジュールのアーキテクチャです。
6.- 単体テストを大量に作成する 単体テストはバグに最も近い場所であり、バグ修正のコストが最も低い場所であり、全体の品質の成否を決める場所でもあります。ソフトウェア。したがって、可能な限り、より多くのより優れた単体テスト ケースを作成して、将来対応するコード変更を行うときに、コードの変更が他のユニットに影響を与えるかどうかを簡単に知ることができるようにする必要があります。
7.- コードを頻繁にリファクタリングします ソフトウェア開発は、コードが実際の要件の最新の変更に対応できるように、継続的な発見のプロセスです。したがって、このような変更に対応するには、コードを頻繁にリファクタリングする必要があります。もちろん、リファクタリングにはリスクがあり、すべてのリファクタリングが成功するわけではありません。また、いつでもコードをリファクタリングできるわけではありません。以下は、さらなるバグの導入や、すでに悪いコードの悪化を避けるためにコードをリファクタリングするための 2 つの前提条件です。
テストすべき単体テストが山ほどあります。前述したように、リファクタリングには保証とテストのために多数の単体テストが必要です。
すべてのリファクタリングは大規模なものであってはなりません。大規模なリファクタリングの代わりに小さなリファクタリングを少しずつ使用してください。 2000 行のコードをリファクタリングする計画を立て始めて、3 時間後に計画を諦めてコードを元のバージョンに戻すことがよくあります。したがって、私たちが推奨しているのは、リファクタリングは少しずつ積み重ねることです。
8.- プログラムのコメントは邪悪です これについては、多くのプログラマが、プログラムのコメントは非常に優れていると考えているはずです。理論的には、プログラムのコメントは非常に優れています。しかし、実際のプログラミングでは、プログラマが書くコメントが非常に貧弱（プログラマの表現能力に非常に問題がある）なため、プログラムのコメントが諸悪の根源となり、プログラムを読むのが困難になることがほとんどでした。そのときは、コメントは読まずにコードを直接読みます。したがって、ここでは、コメントを書かないことをお勧めするわけではありませんが、コメントが十分ではない場合は、コードをより読みやすく、より明確に、コメントよりも優れたものにするために、コードのリファクタリングにより多くの時間を費やしたほうがよいでしょう。
9.- 実装ではなくインターフェイスに焦点を当てます
これは最も古典的なルールです。インターフェースは「何を」という抽象化に焦点を当て、実装は「どのように」という詳細に焦点を当てます。インターフェイスは契約に相当し、実際の内容はこの契約の運用と実装に相当します。運用は非常に柔軟ですが、契約は比較的安定していて変更されない必要があります。インターフェースが適切に設計されておらず、頻繁な変更が必要な場合、この世代では間違いなく非常にコストがかかる結果になることが想像できます。したがって、ソフトウェア開発とデバッグでは、実装ではなくインターフェイスが最優先されます。ただし、当社のプログラマーは常に実装の詳細に重点を置いているため、部分的なコードは非常に優れていますが、全体的なソフトウェア設計は比較的貧弱です。これには私たちがさらに注意を払う必要があります。
10.- コードレビューのメカニズム
誰でも間違いを犯すでしょう。1 人が間違いを犯す確率は非常に高く、2 人が間違いを犯す確率は低くなり、人数が増えるほど確率は高くなります。間違いはどんどん小さくなっていきます。人数が増えると、物事をさまざまな視点から見ることができるため、非効率な議論につながる可能性がありますが、ソフトウェア製品のリリース後に発生する問題のメンテナンスコストに比べれば、このコストは十分に価値があります。したがって、コード レビューのメカニズムは、問題を発見するための最も効果的なメカニズムであるだけでなく、知識を共有するためのメカニズムでもあります。もちろん、コード レビューには以下のいくつかの基本原則があります:
レビュー担当者の能力はコード作成者の能力以上でなければなりません。そうでないと、コード レビューは初心者のための一種のトレーニングになってしまいます。
また、レビュアーがおざなりなレビューを行うのではなく、真に責任を負うためには、レビュアーがコードの作成者ではなく、レビューしたコードに対して主に責任を負う必要があります。
さらに、優れたコード レビューは、コードが完成したときではなく、コード作成のプロセス中に反復的にコード レビューを行う必要があります。良い習慣として、コードが完成したかどうかに関係なく、コード レビューは数日ごとに継続的に実行する必要があります。