概要
このチートシートでは、コードを直す前に確認したい判断項目をまとめます。
リファクタリングは、動作を変えずにコードの構造を改善する作業です。
最初に確認すること
| 確認 | 理由 |
|---|
| 今の動作を説明できるか | 仕様変更と混ざるのを防ぐ |
| テストや確認手順があるか | 壊したことに気づける |
| 何を改善したいか明確か | 目的のない修正を防ぐ |
| 変更範囲は小さいか | レビューしやすくする |
共通化する前
| 質問 | 判断 |
|---|
| 同じ変更理由を持つか | はいなら共通化候補 |
| 同じ業務ルールか | はいなら共通化候補 |
| 片方だけ変わりそうか | はいなら分けておく |
| 共通化で引数が増えるか | はいなら注意 |
| 名前を具体的に付けられるか | いいえなら待つ |
関数を分ける前
| サイン | 対応 |
|---|
| ネストが深い | ガード節を検討 |
| コメントで処理を区切っている | 関数切り出しを検討 |
| 関数名にandが入る | 責務分割を検討 |
| テストしたい部分がある | その単位を切り出す |
| 引数が多くなる | 分け方を見直す |
命名を直す前
| 悪いサイン | 改善方向 |
|---|
data | 何のデータか書く |
flag | is / has / can で始める |
handle | 何をするか動詞で書く |
tmp | 一時的でも意味を書く |
manager | 具体的な責務へ分ける |
副作用を分ける前
| 質問 | 判断 |
|---|
| DBやAPIを呼んでいるか | 計算処理と分ける |
| 引数を書き換えていないか | 新しい値を返す |
| 同じ入力で同じ結果になるか | ならテストしやすい |
| メールやログが混ざっているか | 外側へ寄せる |
やらない判断
| 状況 | 理由 |
|---|
| まだ仕様が固まっていない | 早すぎる抽象化になりやすい |
| 1回しか出ていない重複 | 共通化の根拠が弱い |
| 動いている範囲が広すぎる | 小さく分けてから触る |
| テストも確認手順もない | 先に現状を固定する |
レビュー前チェック
- 動作を変えていないか
- 名前は具体的か
- 不要な引数や分岐が増えていないか
- 変更理由が混ざっていないか
- 変更前より読みやすいか
- 参考にした原則を説明できるか
まとめ
リファクタリングでは、何を改善したいのかを先に決めます。共通化、関数分割、命名改善、副作用分離は、目的が明確なときに効果を発揮します。
参考リソース
← 一覧に戻る 
