- コードを通勤の多くを行って過去には、コードの品質は、いくつかの比較的一般的な問題を発見した次は、トップ5の中で：
- ビッグクラス：肥大化したクラスの理由は、開発者はすなわち、「単一責任の原則」（SRP）のを理解し、最も基本的なコーディングの原則を欠いているため。これらのクラスは、異なる方法および相関関数の欠如のために、内部の同じクラスに配置されている非常に煩雑になる傾向があります。
- ロング方法：以下の理由により非常に長く、主なるメソッドの理由：
- 無関連の多くの複雑な機能コードモジュールも同様に入れました。これにより、開発者はSRPの概念が欠けている主な理由です。
- 種々の条件は、しばしば長いプロセスで行わ同じ方法内に配置されています。これは、SRPの欠如マッケイブコード比較概念と複雑さによるものです。
- 質量参加の大規模な数は：私は、多くの場合、状況にこれらのタイプの、他の方法と対話する方法をいくつか遭遇し、または多数のパラメータを渡す他のいくつかのメソッドを呼び出します。パラメータの変更の一つは、あなたが複数の方法で変更を加える必要がある場合に発生します。
- どこでも一定の値：多くの場合、開発者（特に初心者は）明確な意味（主にマジックナンバー）と、いくつかの定数を使用しますが、適切な定数変数に割り当てずになります見つけます。これは、コードの読みやすさとわかりやすさを削減します。
- ファジィメソッド名：多くの場合、以下のメソッド名を取り、コードの読みやすさとわかりやすさに影響します。
- ファジィメソッド名は意味を持ちません。
- 技術的な、しかし関連フィールドの名前を言及しませんでした
|
|
コードのにおい再構成法（アプローチ）上記6つの処置は
以下の6あなたは助けるために使用することができている
80％（80-20原則）コード品質の問題を解決する
再構成方法を、あなたがより良い開発者になることができます人。
- 抽出クラス / メソッド解放上述したように、「肥大化クラス」このコードのにおいは、元のクラスのメソッドおよびプロパティが移動するべきである（このタイプは提供されるいくつかの機能を有する提供クラス）のように：新しいクラスに適した数。新しいクラスとメソッドの旧対応するクラス属性を削除する必要があります。また、時には過度に肥大化したクラスの一部はこの方法を使用して、他のクラスが含まれているため、クラスのメソッドの他のメンバーの一員であるべきです。また、これらの方法は、適切なクラスに移動する必要があります。
- 抽出方法：「長い道のり」として上記コードのにおいは、新規なプロセスの1つ以上に、古いプロセスからコードを抽出することによって除去することができます。
- 分離条件：それはいくつかの分岐文（IF-ELSE）が含まれているため、多くの場合、この方法は長いです。分岐条件が抽出され、いくつかの別の方法に移動させることができます。これは確かに大幅にコードの読みやすさと分かりやすさを向上させることができます。
- パラメータオブジェクトの導入 / 維持グローバルオブジェクトを：私はコードレビューをしていたとき、別の非常に一般的な状況を見つける-いくつかのパラメータがメソッドに渡されます。既存の方法に関連したメソッドからのパラメータを追加または削除する必要の主な問題。これらの通過がメソッドではなく、各個別のパラメータオブジェクトように、このシナリオでは、提案手法のパラメータは、（組み込まれたパラメータオブジェクト）からなるオブジェクトに関連します。
- シンボリック定数とマジックナンバーを交換してください：どこでも使用することが有意義とリテラル定数のためにそれらのための一定の命名割り当てられるべきです。これは、大幅にコードの読みやすさとわかりやすさを向上させることができます。
- リネーム：上述のように、メソッド名の曖昧さは、コードの使用可否に影響を与えます。これらのあいまいな名前は、開発者がより良いコードをビジネスの文脈を理解するために、ビジネス用語に関連付けすることができる意味のある名前に名前を変更する必要があります。これはトリッキーなことと、開発者とビジネスの専門家がビジネスニーズを満たすために必要なコードを整理するために一緒に協力する必要がすることができます。興味深いことに、この再構成方法は、この1つは、多くの場合のEclipse IDEに表示されますが、このメニュー項目をリファクタリング、理解することは非常に簡単ですが、多くの場合、多くの開発者が見落としているようです。
|
