設計
良いコードの始まりは常にデザインです。 コードを書くことへの情熱を落ち着かせる方法を知らないプログラマーは、デザインを省略することで、通常は迅速に書けますが、質的には書けません。 私自身も同じ問題を抱えていたので、これを知っています。 設計により、まだ実質的に存在しないシステムを調べ、アプリケーションとデータの正しい構造を熟考し、複雑さ、リスクを確認し、パフォーマンスとセキュリティについて考える機会が与えられます。 同時に、デザインはプロジェクト開始の特権だけではありません。 設計は、あらゆる「機能」の開発において不可欠な部分です。
非常に簡単に設計を開始できます。 職場には常にノートブックと数色のペンを保管してください。 コードを記述する前に、ダイアグラムを作成します-アプリケーションが全体としてどのように機能するか、UMLクラスダイアグラム（最小数のクラスで最大の結果を達成する方法を考えてください）、データベース構造（作成する前にデータベースを最適化し、どのクエリを使用するかを考えますデータベースに対して実行され、インデックスを考慮し、もちろんデータモデルを正規化します）。
同じ目的で、 starUMLを設計するための簡単なプログラムが適しています。 そのマイナスは、関係の力（多重度）を適切に確立することができないことですが、インターフェイス自体は非常に便利です。
後で構造エラーをリファクタリングする必要がなく、さらに悪いことに、モジュール全体を書き直す必要がないように設計する必要があります。
フィーチャクラスを設計するときに必ず知っておく必要があるいくつかの原則：
1. ソリッド （単一責任、オープンクローズ、リスコフ置換、インターフェース分離、依存関係の反転）
これがクラス設計の基礎です。 SOLIDに慣れていない場合は、 こちらで見つけることができます 。
2. DRY （自分を繰り返さないでください）
反復機能により、アプリケーションは扱いにくくなり、そのサポートはより高価で不便です。 これは、モジュールと小さなコードの両方に適用されます。
例：
-複数の場所で3行のコードを使用する代わりに、それらを関数に入れて、1行のコード（関数呼び出し）のみを使用できます。
-progress50（）関数を使用する代わりに、より抽象的な進行状況（$パーセント）を使用することをお勧めします。
-モジュール間の外部依存関係、内部（DI）を優先します。これにより、モジュールがより柔軟になり、複数の場所で使用できるようになります。
3. KISS （シンプルにしてください、ばか...）
複雑なタスクのソリューションが単純であればあるほど、より完璧になり、このルールは逆の方向にも機能します。 簡単な決定方法を学ぶには、タスクを非常に小さなサブタスクに分割する方法を学ぶ必要があります。 小さいものから大きいものへの移行。 後で、難しいタスクの結果を取得します。
例：
データベースからExcelレポートを生成するには、クラスを作成する必要があります。 レポート全体をパーツに分割する必要があります。テーブルヘッダーの設定、ドキュメントへの統計データの出力、ドキュメントフッターの出力、チャートの作成。 機能の一部を別のクラスに移動すると、それらを再利用できるようになります。
コードスタイル
コードスタイルのリファクタリングは、アプリケーションのパフォーマンスにまったく影響しません。 ただし、読みやすさとサポートには利点があります。 別のプログラマーは、詳細の実装を詳しく調べることなく、コードを簡単に読むことができます。これにより、時間とお金を節約できます。
Code Style Standard（およびそれ以上）PSR（PHP Standards Recommendations）。 こちらから入手できます 。 内容は英語です。英語では、いずれかまたは他のルールが適用される範囲がより明確になるため（「必須」、「必須」、「必須」、「共有」、「共有しない」、「すべき」、「すべきではない」、 「推奨」、「5月」、「オプション」）。
著者が重要だと考えたコメント ：
1. PHPDOCをチェックして、コードにコメントを書きます。
2.最良のコメントは、適切な名前のクラス、メソッド、パラメーター、または変数です。
3. PHPMD、PHPCSユーティリティを使用します。それらのアプリケーションは、コードスタイルの不一致を検出するためだけのものではありません。 ドキュメントはPHPMD 、 PHPCSです。
4.拡張IDEを使用します。
純粋なリファクタリング
非常に単純な公理-リファクタリングされたコードのみが本番になります。 時には、開発後に自分でリファクタリングを行うこともありますが、これはまったく悪いことではありません（たとえば、テストによる開発では一般に必要な手順としてリファクタリングが必要です。「作業コード」が最初に記述されてから「クリーン」になるため）コードは本当に高品質で、別のプログラマーによるコードレビューに合格する必要があります。 プロジェクトでコード検証のための時間を割り当てることができる場合、そのようなプロジェクトでは、コードクリーナーを次々と作成することを学習します。これにより、高品質コードの自動記述が可能になります。
ある会社で働いたときのことを覚えています。コードは、感情を常に抑えることができない人によってチェックされました。 したがって、このような場合を避けるために、高品質のコードを非常に迅速に記述することを学ばなければなりませんでした。
トピックに戻ります。 記事のこの部分では、私が自分で使用するリファクタリングへの実用的なアプローチをいくつか紹介したいと思います。
1.長いメソッド（機能をいくつかのメソッドに分割することをお勧めします）。
2.かさばるクラス（クラスはシステムで1つの機能タスクを実行する必要があります）。
3.クラスの構造が不明確です（混orderとした順序のメソッド、定数の代わりにクラスの中間にあるコンストラクター-コード内のマジック値-クラスは、実行していることを正しい順序で簡単に表示する必要があります）。
4.メソッド内のパラメーターが多すぎます（内部定数、属性およびゲッターから取得した値を使用して、メソッド内で一部の計算を実行できます）。
5.同じ変数とメソッドを含むクラス。 この問題は、追加のクラスを作成することで解決できます）。
6. IFの読み取りが難しい（式を別の変数に取り出し、論理部分に分割することもできます。論理部分は変数に取り出すこともできます。nullのチェックが多数ある場合は、NullObjectを使用することをお勧めします-チェックの数が大幅に削減されます）。
7.かさばるSWITH（別の方法で取り出します）。
8.本質的に異なるエンティティ（猫と椅子には脚がありますが、「動物」のカテゴリにグループ化することはできません）での同じメソッドとプロパティによる継承の使用。
9. 1つのタスクを実行するには小さなクラスが多すぎるため、その後の保守がより難しくなります。
10. 1つのクラスの機能が複雑すぎて、いくつかのクラスに分けることができます。
11.クラスがシステムに残しておくには少なすぎる。
12. 「Dead Code」-削除する必要があります。
13.将来のために設計した未使用のクラス構造ですが、役に立たなかったため、削除するのが最適です。
14.クラスメソッドは別のクラスでより多く使用されますが、それ自体ではまったく使用されません（使用頻度の高いクラスにメソッドを転送する価値があります）。
15.呼び出しチェーンが長すぎます（$ a-> b（）-> c（）-> d（）-> e（））。この場合、追加のメソッドを作成する価値があります。
16.別のクラスを作成する1つのメソッドのみを含むクラス。 （このようなクラスは、たとえば「プロキシ」パターンなどに賢く使用する必要があります。そうでない場合、このクラスはプロジェクトをサポートするための時間とリソースを増やすだけです）。
17.コンストラクター内のアクションが多すぎます。 （コンストラクタはクラスのプロパティを設定するだけで済みますが、他のクラスがコンストラクタで作成されると、いくつかの計算が行われるため、理解が難しくなります。実装の本質を掘り下げる必要があります。オブジェクトを作成してアクションを実行するには、create staticメソッドを追加します（$ param1、...）、追加のアクションを含むクラスのインスタンスを作成します。このメソッドは、それが行うことにより適していると呼ぶことができます）。
参照資料
» ソース作成
» PSR
» UML