レガシーコード本読了！ - @ikikko のはてなブログ

久しぶりの読了宣言のような気がします。本を読んでなくはないのですが、今の職場に移った事にともなって通勤時間が短くなって読書の時間も短くなったんですよね。睡眠不足で、電車の中で立ったまま寝てることもよくありますし。

で、今回の本は通称「レガシーコード本」。邦訳が出てないころから話は聞いてて、邦訳が出たらぜひ読んでみたいと思ってて今に至ります。時間がかかりましたが、何とか12月19日 "TDD" Boot Camp　～ "ＴＤＤ" をつかめ！～(東京都)の前に読み終わってよかったです。来たる12/19のTDD Boot Campでは、この辺を意識しながら望みたいです。

あと、実はこれ会社の経費で買ってもらいました。経費で買ってもらった以上、ちゃんと恩返しをということで読書感想文を載せます。まぁ、自分で買っても、感想文は載せていますけどね。。。

レガシーコード改善ガイド (Object Oriented SELECTION)

作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
出版社/メーカー: 翔泳社
発売日: 2009/07/14
メディア: 大型本
購入: 40人クリック: 555回
この商品を含むブログ (125件) を見る

以下、いつも通りに気になったところを。

1.2 危険な変更

頻繁に変更しないと腕がなまってしまう

これはアジャイル開発の頻繁なリリースと同じ考えかな。リリース作業が1回もしくはほんんの数回だけだと、作業にとまどって迂闊なミスもよくありますからね*1。

2.1 単体テストとは

実行に0.1秒もかかる単体テストは、遅い単体テストである

極論に聞こえるけど、実績がある人が言うんで重みがあります。そういや、レガシーコードの定義（テストがないコード）も極論ですし。

3.1 強調クラスの偽装

偽装オブジェクトとモックオブジェクトの違い。「モックオブジェクトとは、内部的に表明を実行する偽装オブジェクト」とのこと。たいていは、単純な偽装オブジェクトで大丈夫らしい。

モックオブジェクトといえば、easymockはちょっと触ったことある（⇒ 新しいものに取り組んでみた - @ikikko のはてなダイアリー）けど、イマイチ使い方が分からんかった記憶が。

6.1 スプラウトメソッド

追加するロジックをまったく新しいメソッド（スプラウトメソッド）として切り分け、そのメソッドに対してテストコードを記述するやり方。これは理解しやすいこともあって、よくやりますよね。

ただ短所もやっぱりあります。古いコードの中に新しいコードがあると、コードの美しさとかも含めた整合性がとれんのですよね。実体験しました。

9.1 いらだたしいパラメータ

とりあえず、テストコードを作る際に必要なパラメータをnullにするってのは、現実的な解だと思いました。テストコード中でそのパラメータが使われないなら特に問題ないし、使われててもその場でNullPointerExceptionが発生しますからね。

13.1 仕様化テスト

今動いている振る舞い（仕様）を維持するために、仕様化テストを書く。そのための手順は↓。

テストハーネスの中で対象のコードを呼び出す
失敗すると分かっている表明を書く
失敗した結果から実際の振る舞いを確認する
コードが実現する振る舞いを期待するように、テストを変更する
以上の手順を繰り返す

偶然にも、ちょうどこれやっていました。既存のプロダクトを修正するというのをプライベートな時間を使って友人とやっているのですが、そこでテストコードを書くときに、この手順に沿って行っていました。

18.1 クラスの命名規約

下記は、本書で例示されている金融パッケージのクラス一覧です。

- CheckingAccount
- CheckingAccountTest
- FakeAccountOwner
- FakeTransaction
- SavingsAccount
- SavingsAccountTest
- TestingCheckingAccount
- TestingSavingsAccount

それぞれのprefix / suffixは以下の意味を持ちます。