レガシーコード改善ガイド １〜３章まとめ
とりあえずレガシーコード改善ガイドの１〜３章を読んでみた。
書いてあった部分で印象的な箇所がいくつかあったのでまとめていきたいと思う。
はじめに
レガシーコードの定義について書かれていた。
テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。
なかなか印象的な言葉だ。
レガシーコードとは複雑で絡まり合ったコード、構造がわかりにくくて理解することが難しいコード…
ではない！
テストコードがないならそれはレガシーコードだよ！！！
伝えたいことは要するに、安全に仕様の変更、リファクタリングをするためにはテストないと無理ゲーってことだと思う。
ソフトウェアの変更は困難
毎日のようにコードを変更し、仕様変更、追加機能を実装しているけど変更されない既存の機能に比べると変更量はごくわずかである。
一部の変更によって振る舞いが変わる箇所はあるが今まで通り振る舞いが保たれる部分の方が多い。
しかし、既存の振る舞いを保ちつついくつかの変更を加えることは困難！
理由としては以下を意識しなければならないからだ。
- 変更が正しく行われたかどうか？
- 既存の機能を何も壊していないか？
コードを書けば書くほどバグを埋め込む可能性が高くなるもんね。。。
振る舞いを確認するための単体テスト
単体テストはしないけど結合テストはやってるよーって現場は結構多いと思う。
でも結合テストにはいくつか問題点がある。
- エラー箇所の特定
- テスト実行時間
エラー箇所の特定
結合テストでは最終的なアウトプットは確認できても一つ一つの振る舞いはわからない。
例えば本来"hoge"と出力が期待されるところが"huga"となっていた場合、バグは確認できたけど出力に到るまでの一連の処理の中でどこが問題なのかを割り出すことができない。
テスト実行時間
テストがダル過ぎて積極的にやりたくないw
ブラウザからポチポチするのは時間がかかり過ぎる。。。
（最終的にはやらないといけないと思うけど）
よっていいテストの条件は
- フィードバックがすぐに得られる（実行時間が短い）
- すぐに問題の箇所が特定できる
