Working Effectively with Legacy Code 読書会＃３

勉強会 レガシーコード

8/2 に Working Effectively with Legacy Code の第３回読書会が行われました。幹事のせとさん、参加者の皆さんお疲れ様でした。

今回は 9 章から 12 章の途中まで。

Chapter 9. I Can't Get This Class into a Test Harness

xUnit とかでテストを書こうとしたら、コンストラクタの引数が複雑だったり、前提条件が必要だったりして、独立したテストコードの中では容易にはインスタンス化できないというシチュエーションで取り得る対策についてあれこれ紹介。担当は せとさん、id:htada さん、川澄さん。


個人的には９章で紹介されている手法は、他にやりようがないにしても、ちょっと採用するのに二の足を踏んでしまいそうなものばかりでなかなかしんどい。new と delete が空中アクロバットしているとか、生理的に拒絶してしまうんですけど(苦笑)。
まあ、こんな泥縄を編まなくてもいいように最初から考えてコード書かないといけないよ！　という教訓だと思おう。

Chapter 10. I Can't Run This Method in a Test Harness

同じくテストを書こうとしたら、テストしたいメソッドが private だったり、(場合によっては危険な)副作用が発生してしまう可能性があるなどで、テストコードの中から気軽に呼んでみるわけにいかないというシチュエーションについて。川西さん担当。
川西さんは前回も推理小説メソッドということでとても味のあるプレゼンだったのだけど、今回もナレーションと「まとめ」のついたツボを押さえたおもしろい内容。川西メソッドが確立されてきたというもっぱらの噂。前日の夜中３時４時に資料を作っていると自然とそうなるとのことなので、忙しい時期に担当を押しつけるのが川西メソッド発動の十分条件ということでＦＡ？


private メソッドのテストは前回も議論の対象になった。そのときは「 private ということはインターフェースじゃないんでしょ？　それのテストって変じゃね？」という方向の話だった。１０章では「それでもどうしてもテストしたい場合にどうするか」を扱っていて、結論から言うと「 protected に変更しましょ」。
この著者はテスト原理主義者らしいので、テストのためならカプセル化を崩すことも厭わない。まあカプセル化も手段の一つに過ぎず、一方コードにテストが付いていることは直接間接に様々なメリットを生むので、一理はあると思う。が、private にする理由があって private にしている(かもしれない)のをほいほい変えてしまっていいんだろうかという違和感はどうしても残る。
また、前回 id:t-wada さんから授かった「 TDD はそれがないとコードが書けない(実装をコードに落とせない)人のためのもの」という神託からすると、private はやはり private のままテストしたい需要も多いのではないかとも思う。
「 Java だと package scope (偽 private) を使うという手があるよ」的な場当たりな手法はバッドノウハウ以外の何者でもないので、やはり言語がテスト用のスコープ(コンパイラオプションや起動オプションで有効無効を指定できる)をサポートするべきなのではないかと強く感じた。

Chapter 11. I Need to Make a Change. What Methods Should I Test?

テストコードは書かなきゃいけないとは思っている。変更するメソッドについてテストを書いただけじゃ足りないこともわかっている。でも全てのメソッドを網羅するテストを書いている時間はない。どこにテストを書いたらいいんだろう……というシチュエーション。自分で担当。
前回、「仕様を見たら実装が思い浮かぶ人に TDD は無理」ということは「自分の書くコードは常に必ず Legacy Code 」という結論が出てしまった。そんな自分は「 Legacy Code のどこにテストを書けばいいか」という話題を扱っている１１章・１２章をどこより読むべきでしょうということで手を挙げてみたわけだ。


Effect Sketch という影響の伝播を分析するためのツールが紹介されている。インスタンス変数やメソッドになどついて、あるものが別のものに影響を及ぼす場合に矢印を引き、そのグラフによって最も影響を受けるものを特定したり、依存性を解消したほうが良い箇所の特定に用いる……のであれば良かったのだが。
サンプルプログラムを使って実際に Effect Sketch をいくつか書いてみるのはいいが、第１弾「書いただけ」第２弾「コードのここにテストを書けばいいよ！　effect sketch 書いただけで使ってないけどね」第３弾「コードの重複解消するよ！　effect sketch 書いただけ(ry　しかも図間違ってるし！」という、ちょとここ来て座りなさい正座だよ正座。
読書会ではもっとまじめにフォロー( effect sketch をこう書けば自然にその結論が導けるのでは、とか)しているのでご安心を。WEwLC Wiki の資料にまとめてあるので、もし興味があればそちらを。
開発するときの設計ツールはあれこれあるけれど、すでに存在しているコードを、どこにテストを書けばよいかという観点で分析するツールは(寡聞なだけかもしれないが)他に知らないので、こういうツールはとても有用だろうという期待はあるのだけど、この程度の紹介ではさすがに厳しすぎる。こだわりの強い厳密な人がこの Effect Sketch を育てて(やり過ぎない範囲で)大きく伸ばしてくれれば芽が出る可能性はなかなかあるんじゃないかという気はするのだけど。


この章はツッコミどころの多いサンプルプログラムも見所の一つだろう。
１つ目のプログラムは「 Java で C++ のコードを生成する」という、サンプルにそれを選ぶというのは本当にどうなの？　と思わずにいられないし、２つ目は「このプログラム、メンテしてね」ともしも渡された日にはコンピュータ業界を選んだ自分を呪いたくなるだろう（あのわずか 20 行ちょいであれほどの破壊力があるということは、全体はいったい……！）。しかもどちらについても、そんなにひどいサンプルを採用した理由をくどくどと言い訳しているのが素敵。
まあこの章に限らず、この本のサンプルプログラムはおそらく著者がコンサルタントとして火消しの現場に数多く駆り出される中で、見て聞いて苦しんだ実際の Legacy Code が元になっているのだろうと推測され(テストコードがカメラ壊しちゃった！　とか)、必要以上に人間くさくてなにかとおもしろい。

Chapter 12. I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?

１０章までは改変の必要が生じたときにコードをどのように改変したりテストを書いたりするかを紹介していたのだが、１２章は改変の量が多すぎてとても追いつかない、コードは影響の連鎖で複雑に絡み合いすぎている、どうしたらいいんだ!?　的シチュエーション。ようちゃん担当。


さっきの Effect Sketch を依存性の解消のために用いるという内容なのだが……いろいろ納得しにくい部分が多かった。１１章があんな調子だったわけだから、その続きがそうなってしまうのは無理もないのかもしれないけど。
この章は本来とても重要な良いテーマを持っていると思うので、もうちょっとしっかり理屈を書いて欲しいなあと思わされてしまった。


id:t-wada さん担当の 13 章を楽しみにしていたのだけれど、残念ながら１２章の途中でタイムアップ。まあ都度都度の議論がそれだけ盛り上がっての結果なので仕方ないところ。
他の人も、しかも毎回書いていると思うが、この本の内容もさることながら読書会の議論がとにかく興味深い。定員に大きく届かなかったのはちょっぴり残念。
この読書会に参加している人はみんなシャイなのでブログエントリ少なめ、宣伝少なめなのが原因？　見つけた奴貼っておこう。


懇親会では一部の人が……あ、今回は自重したからネタがないや。周りに悪いお友達が座ってなかったのが功を奏したのかも。