レガシーコード改善ガイド 1章 ソフトウェアの変更

前提

レガシーコード改善ガイドのoutputを章ごとにやってます。
自分のoutputとある程度の人に伝わったらラッキー程度の考えを前提にしているので、分かりやすい記事ではないです。
イラストもないので、完全に理解したい人は書籍を読みましょう。

概要

変更の種類と変更されるものの対応表が以下になる。リファクタリングをするときは基本的にinput/outputは変更されず、構造だけが変わる。これを行うためにはテストが必要である。

	要件追加	バグ修正	リファクタリング	最適化
構造	o	o	o
新機能	o
既存機能		o
リソース利用				o

しかし、テストがないコードがテストしやすいコードになっていることはまれであり、基本的にはテストコードを書くためにリファクタリングが必要になる。このテストコードを書くためにリファクタリングをする際にももちろんinput/outputを変更してはいけない。このinput/outputをかえずにうまくテストができる状態にする方法を本書籍では紹介している。
またPRを作成するときはこの4つの指針に則って、複数目的のPRを作成しないようにするのがベストである。