レガシーコード改善ガイド
https://gyazo.com/48e823b20fe3ed9ce0c24fc13b1e82b8
タイトル
原題：Working Effectively with Legacy Code
著者
年
2009
リソース
ISBN：9784798116839
概要
内容
序論
Kindle版を買ったらソースコードのインデントが破綻していて読みづらくて困った 本番とテストでソースコードは同じであるべき
1347
1章
ソフトウェアが変更される理由に関する議論
table:変更理由
要件追加 バグ修正 リファクタリング 最適化
構造 変わる 変わる 変わる -
新機能 増える - - -
機能 - 変わる - -
リソース利用 - - - 変わる
既存の大部分の振る舞いは変わらないので、大部分の振る舞いを変えないことを保証することが重要になる
良いシステムは、調べると行う変更の影響範囲に確信が持てる
2章
ふるまいから見て最もatmicな単位
手続き型ではたいてい関数のテスト。オブジェクト指向ではクラス
優れた単体テスト
1. 実行が早い
0.1sかかったら遅い
30000個のテストがあったら1hもかかる
2. 問題箇所の特定がしやすい
単体テストではないもの
DBとやりとりする
NWを介した通信をする
ファイルシステムへアクセスする
実行のために特殊な環境設定が必要
kadoyau.iconどういうこと？PHPUnitなどでは自動的に環境変数を設定したりするが、きっとのそことではないのだろう
テストハーネス：テスト用のコードのこと
コードを変えずにテストできるのが理想
レガシーコードでは依存関係を排除する必要がある
ジレンマ：コード変更のためにテストを整備する必要があるが、テストを整備するためにはコードを変更する必要がある
テストなしのリファクタリング
保守的に作業せよ
この際に、一時的にコードが汚くなるのは許容する
4章
プログラミング言語はテストをうまくサポートしていない
kadoyau.iconGoは最初から考慮している
Seam（接合部）
その場所を直接編集しなくても、プログラムの振る舞いを変える事のできる場所
no. 1231
オブジェクト接合部
サブクラスで振る舞いを書き換えて依存性を排除して説卒る