リファクタリングとは？
単純に理解すると、理解しやすくし、修正コストを削減するために、観察可能な動作を変えずにソフトウェアの内部構造を改善することです。
これは、達成すべき目標とタスクのリストです。
- Consolidate Conditional Expression
- Consolidate Duplicate Conditional Fragments
- Convert Procedural Design to Objects
- Decompose Conditional
- Duplicate Observed Data
- Encapsulate Collection
- Encapsulate Downcast
- Encapsulate Field
- Extract Class
- Extract Hierarchy
- Extract Interface
- Extract Method
- Extract Subclass
- Extract Superclass
- Form Template Method
- Hide Delegate
- Hide Method
- Inline Class
- Inline Method
- Inline Temp
- Introduce Assertion
- Introduce Explaining Variable
- Introduce Foreign Method
- Introduce Local Extension
- Introduce Null Object
- Introduce Parameter Object
- Move Field
- Move Method
- Parameterize Method
- Preserve Whole Object
- Pull Up Constructor Body
- Pull Up Field
- Pull Up Method
- Push Down Field
- Push Down Method
- Remove Assignments to Parameters
- Remove Control Flag
- Remove Middle Man
- Remove Parameter
- Remove Setting Method
- Rename Method
- Replace Array with Object
- Replace Conditional with Polymorphism
- Replace Constructor with Factory Method
- Replace Data Value with Object
- 委任を継承に置き換える
- Replace Error Code with Exception
- Replace Exception with Test
- Replace Inheritance with Delegation
- Replace Magic Number with Symbolic Constant
- Replace Method with Method Object
- Replace Nested Conditional with Guard Clauses
- Replace Parameter with Explicit Methods
- Replace Parameter with Methods
- Replace Record with Data Class
- Replace Subclass with Fields
- Replace Temp with Query
- Replace Type Code with Class
- Replace Type Code with State/Strategy
- Replace Type Code with Subclasses
- Self Encapsulate Field
- Separate Domain from Presentation
- Separate Query from Modifier
- Split Temporary Variable
- Substitute Algorithm
- Tease Apart Inheritance
Consolidate Conditional Expression
説明 : 条件付きテストの列がいくつかあり、それらがすべて同じ結果を得る場合、それらのテストを1つの条件式にまとめ、その条件式を別の関数に抽出することができます。
動機 : 条件が異なることをチェックする場合、「論理or」と「論理with」を使って1つの条件式にまとめるのがこれまでの動作でした。
interface ConfigFn {
(): number;
}
const disabilityAmount: ConfigFn = (): number => {
if (_seniority < 2) return 0;
if (_monthsDisabled > 12) return 0;
if (_isPartTime) return 0;
};
このコードでは、すべて同じことを行う一連の条件チェックをご覧ください。上記の条件チェックは、論理 OR で結合されたステートメントに相当します：
const disabilityAmount: ConfigFn = (): number => {
(_seniority<2)
(_monthsDisabled>12)
(_isPartTime))return 0;
}
//変革の継続
const isNotEligible = ():boolean=>{
return (_seniority<2)
(_monthsDisabled>12)
(_isPartTime));
}
const onVacation = ():boolean=>{}
const disabilityAmount = (): number => {
// ロジックは、より複雑なアプリケーションの継続にも使用できる。
// if(isNotEligible){
if(isNotEligible && onVacation){
return 0;
}
}Consolidate Duplicate Conditional Fragments
説明 : 条件式の各分岐に同じコード片がある場合、このコード片を条件式の外に移動。
動機 ：同じ重複コードを削除することは、条件によって何が変わり、何が変わらないかをより明確に示す唯一の方法です。
if (flag) {
const a = ' ';
res.end(a);
} else {
const foo = { 'message': ' ' };
res.end(foo);
}
let c = 'デフォルト情報';
if (flag) {
c = ' ';
} else {
c = { 'message': ' ' };
}
res.end(c);複雑なバージョンの登場です：
// .jscpd.json
{
"mode": "strict",
"threshold": 0,
"reporters": ["html", "console", "badge"]
}yarn add jscpd -D
yarn add jscpd-badge-reporter -D
jscpd ./src
効果の写真を追加してください：
Convert Procedural Design to Objects
説明 : カプセル化されていない、伝統的な手続き型コードがあります。データレコードをオブジェクトに変換し、振る舞いの大きな塊を小さな塊に分割し、振る舞いを関連するオブジェクトに移動することができるようになりました。
動機 ：ある時、120行以上の純粋な関数を生成しているバンドの実装を見ました。長い関数は一般的に、このルールに手をつけるのに最適なタイミングです。
ここでは口うるさくは言いませんが、SOLIDの設計に基づくカプセル化、継承、ポリモーフィズムに加えて、実際には十分な、よく見て静かにする時間を持っていることを願っています。
関数型プログラミングとSOLIDは、実は相性がいいのです。
