「リファクタリング」の完全読破。その4

今回は第4章と第5章。この次から、いよいよカタログに入る。

第4章 テストの構築

多分ここが、古いということで一番割を食ってる箇所。
JUnitの説明などは、今は他の本を読んだ良いと思う。
所々出てくる、今読んでも色褪せないなと思う部分だけ引用する。
（古い古いと書いているが、未だにJUnitすら使っていないシステム開発現場はあるし、むしろ経験上そっちの方が多い。）

P89　リファクタリングに限らず、よいテストを書くとプログラミングが加速するようです。
P90　テストを完全に自動化して、その結果もテストにチェックさせること。
P94　テストを頻繁に実行せよ。コンパイル時にはテストを局所化して、1日に最低1度はすべてのテストを実行せよ。
P97　バグレポートを受け取ったら、まずそのバグを明らかにするための単体テストを書け。
P98　不完全なテストでも、書いて実行するほうが、実行できない完全なテストよりもましだ。
P99　失敗の恐れのある境界条件を考えて、そこを集中的にテストせよ。
P100　失敗すると予測されるときに、例外が上がることをテストし忘れないこと。
P101　テストですべてのバグが見つからないからと入って、テストを書くのをやめてはならない。ほとんどのバグはテストで補足される。

テストのやめ時について、いくつか補足する。
カバレッジを100にする意味があるときと、あまり無いときがある。
まずはテストにおける収益低減点を考えること。
適当な時間で大部分のバグを補足するほうが良い。
継承とポリモーフィズムを踏まえるとテストの組み合わせはどんどん増えていくが、全部の組み合わせを試す必要はない。

ふと見ると、Kent Beckの「テスト駆動開発入門」も、相当に古い本だった。
私が持っているのは2008年の第3刷だけど、日本語の初版は2003年。
リファクタリングもTDDも、思想と技術は確実に身になってるんだけど、職場では強制されないし、逆に強制できないというのが少しもどかしい。

第5章 リファクタリング・カタログに向けて

こちらはタイトルのとおり、カタログ（第6章〜第12章）の記述方針等の説明。
注意点として、リファクタリングの説明に集中するために、金額をdoubleとしたり本来はまずしないような書き方もしているということ。
（それを踏まえると、Javaのバージョンが古いということも、ある程度は受け入れられるかな。）
また、GoFには「デザインパターンはリファクタリングの目標を提供する」と書かれており、リファクタリングを使うとき、デザインパターンはその出発点であることを心に留めるようにと書かれている。

・過去記事。
「リファクタリング」の完全読破。その1 - holyppの日記
「リファクタリング」の完全読破。その2 - holyppの日記
「リファクタリング」の完全読破。その3 - holyppの日記