やったこと

リファクタリング 第二版 1章 読了

学んだこと

リファクタリングは、人間のために行う。
優れたプログラマは、人間にとってわかりやすいコードを書く。

リファクタリングでやること

• 小さな単位に分割する
• フェーズを分割する
• ポリモーフィズムを駆使して処理を動的に変化させる

（順不同だけど、上からやる方がやりやすそう。また、対応済みだったり対応不要だったりする場合はスキップする）

小さな単位に分割する

長い処理を、意味のある小さな単位に分割する。

関数化を駆使するとやりやすい。

...
let thisAmount = ...; // 長い長い処理
...

const amountFor = () => {...}; /// 長い長い処理を関数化
...
let thisAmount = amountFor();
...

ローカル変数は、「小さな単位に分割する」際の障害になりやすい。
ローカル変数の排除を心掛けてリファクタリングしていくと、小さな単位に分割しやすい。 （=> 変数のインライン化）

フェーズを分割する

小さな単位に分割したコンポーネントを、取り回しの効くような意味のある単位にまとめていく。

この時、最も大雑把なまとめ方として、「入力処理」「計算」「出力処理」がある。

ポリモーフィズムを駆使して処理を動的に変化させる

成し遂げたいこと（例: 料金を計算する）は同じだけど、分類によって計算ロジックを変化させたい（例: 通常価格、特売価格、会員価格など）ような状況。
計算ロジックをサブコンポーネントに委譲し、メインロジックを親コンポーネントでまとめ上げる... といった設計を行う。
これを実現するキーワードの一つが ' ポリモーフィズム ' 。

リファクタリングの第一歩

• テストを作成する
• リファクタリングの度にコミットする
• 変数、関数などに、適切な名前を付ける

テストを作成する

リファクタリングによるコードの変更よって、新たにバグ（≒振る舞いが変化してしまうこと）が混入する事は十分考えられる。
このバグを早期に発見するためには、「振る舞いが変化していないこと」を検証する手段が必要。
テストは、この検証手段に相当する。

テストを作成することで、「振る舞いが変化していないこと」を常に確認できる。
振る舞いが変化していたとしても、それは「テスト失敗」という形である程度検知できる。

リファクタリングの度にコミットする

リファクタリングに成功（≒コードを修正して、テストもパス）したタイミングでコミットする。
小さな単位でコミットしておくことで、万が一リファクタリングに失敗した場合でも、動いていた状態に戻すことが出来る。
コミット単位が小さいと、コードのロールバック量が少なくなり、開発効率が上がる。

意味のある単位としてまとまったてから、共有のリポジトリに変更をプッシュすると良い。

変数、関数などに、適切な名前を付ける

適切な名前を付けられた変数は、中身の値が容易に特定できる。
適切な名前を付けられた関数は、中身の処理が容易に想像できる。

名前が適切であれば、「コードを読んで中身を理解する」手間を省く。
開発効率の向上に寄与すると同時に、バグの発生を防ぐことにもつながる。

良いコードとは

好みによる部分も大きいが、「どれだけ変更が容易か」（≒どれだけソフトか）という視点は、共通してそう。