なんか参加したことしかわからんなぁ・・・

参加しました。たのしかったです。ありがとうございました。で終わってるなぁ、最近のこのブログ・・・

・・・と反省したので昨日のWEwLC読書会をちょっとふりかえってみる。

Chapter 12. I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?: 前回半分ぐらいで時間切れになったので、続きから。目の前に既にテストのないクラスがあって、機能追加をしないと行けなくなった。最低限どこをテストしておくのがいいだろうか？ということがかかれている章。各クラスが影響し合っている関係を図で書いてみて、そこから今回追加した部分をテストするにはここの部分をテストしておけば十分だよねということを導き出す。けど、たくさん変更があると、最低限といってもすごい数になってくるのでどうよ？という話になるわけだが、今度はその影響関係をながめて、グルーピングを行って、そのなかでファサードになっているもの(この本ではPinch Pointと呼んでる)を見つけ出して、そこに対してテストをつけちゃう。そうしてしまえばそのグループは自分の支配下にはいるので、そのファサードのテストさえ通ってればその中身はリファクタリングしほうだいになる。その場ではもやもやしてたけど、今まとめるといい考え方だと思うなぁ。
Chapter 14. Dependencies on Libraries Are Killing Me: Chapter 13は是非次回id:t-wadaにしてもらおうということで温存して、続いて第14章。ライブラリを利用することはいいことなんだけど、無計画にそれをいろんなところから呼んじゃうと痛い目に遭うよという章ですな。まぁ、ラッパーを書けってことなんだけどね。そうすればそのライブラリの仕様が変わったときにそのラッパーのところで吸収するという選択がとれる（場合がある）。あと、ライブラリ提供者も使う側の立場に立ってテストしやすくしとけよと。はい、耳が痛いです・・・
Chapter 15. My Application Is All API Calls: APIをコールだけしている部分もテストする必要あるの？という章。14章の流れをうけているわけだが、ラッパーを書いてそのラッパーのテストは？とか。後はどうラップするかとか。私は基本的に委譲で解決できるものは委譲で解決するのでそういう選択をとるなぁ。そしてそのラッパーが仕組みでテストの時にはモックに切り替わるとか。DIであれこれやってるのはそれができやすい仕組みになるからで、Maple3ではそこまでたどりつけなかったけど、Maple4ではそこまでちゃんと準備しろ＞自分
Chapter 16. I Don't Understand the Code Well Enough to Change It: まだ見たことも食べたことのないコードを渡されたときに君ならどうする？という章。ここは私が担当させてもらった。発表の時には少々ちゃかしちゃいましたが、この章私好きですよ。紹介されているのは「ソースを読んでみて、各機能に適当に名前をつけて、それらの関係を表す図を書きながら自分の考えを整理したり、周りの人とコミュニケーションとったら？」というのと、「コードを印刷して、ブロック後にマーカーとかで囲って、それらの関係をみてみろ」とか、「テストがなかったらリファクタリングとはいえないけど、そんなの気にせずにがんがんリファクタリングテクニックを使いながらソースをきれいにすることによってソースを理解しろ。その代わりそいつはほんとに動くかどうかテストしようがないからリポジトリにはコミットすんな」とか、「不必要なブロックはけせ」とか。ベタなローテクだが結構いいと思うな。
Chapter 17. My Application Has No Structure: なんか急に毛色がかわって、なんでコードって劣化していくの？という章。それは特定の人しかそのシステムのアーキテクチャを理解してなくて、それが共有できてないから、わかってない人がアーキテクチャにあってない拡張とかしちゃうんじゃね？という話がでてくる。じゃあどう共有するの？ということだけど、まぁ「話し合え」ってことですね。図とかスタンドアップミーティングとかWikiとか駆使して今どういうモノを作ろうとしているかということの共有は重要だと思います。Naked CRCのデモは中谷さんならではの味がでてて良かったですね。そして最後の節の説明も関西弁ばりばりでぐっと来るものがありましたよ。
Chapter 18. My Test Code Is in the Way: 私はこうやってテストをつくってますよという章。筆者のやり方を説明してもらって、はいそうですかと。ここでもっとみんなどういうディレクトリにテストファイルおいてるの？とかつっこんで話がしたかったけど今回はスルーでしたね。ちなみにこのあたりでt-wadaがコスプレして登場しました。
Chapter 19. My Project Is Not Object Oriented. How Do I Make Safe Changes?: オブジェクト指向が使えない言語なんですが、どうしたらいいでしょう？という章。言語がそれをサポートしてる方が楽だよねというのは同意。けど、みんなつっこんでいたけどこの章の例もかなりキモい。そんなことするかよ！とは思う。まぁ、要はテストの重要性というか駆動力がわかってしまった人はどんな環境でもテストしたいんだよ！ということです。
Closing: 懇親会まで少々時間があったのでいろいろとまったりと話をしつつ、幹事の大中さんからしばらく幹事一人ではつらいというお話をいただいたので、じゃ私も幹事としてお手伝いしますよと手を挙げておきました。この読書会はそのあたりはすごい協力的な方が多いのでなんとかなりますよ。あとこの本もたぶん後3回くらいで読み終わっちゃうので、次は何にする？という議論も入れておきました（この本を読むのが飽きてきたらという意味は断じてない。この本はまだまだ楽しい）。私としては「Clean Code」を提案してみましたが、他にもこれを読みたいというのがあればいろいろ議論したいですね。このコミュニティーは「技術書(洋書)を読む。ただしテストが気になる」という軸足になっていると思ってるのでそれで長く続けたいですね。
懇親会: 運良くt-wadaの前をゲットできたので、前日のRESTful本読書会の内容報告をしてみたり、RESTfulBuriの話をちょっと聞いてみたり、XP祭りの話をきいてみたりと大満足の懇親会。13名の懇親会だったので、大きく2つくらいのグループに分かれて話していた感じでしたが、後半は全体で話してましたね。あの雰囲気は楽しかったです。

・・・うーむ、そこそこ長くなったけど、その場にいないとやっぱり意味がわからんかもしれん。なかなかすごい意見交換＆議論が行われてますので、都合が合う方は是非是非来月お越しください。

ちなみにRESTful本読書会が毎月第2土曜日を明け渡したので、WEwLC読書会は基本毎月第2土曜日開催になるかと思われます。なにーそんなおもしろいことを話してるなら俺にもなにかいわせろ！という方はぜひぜひ。

追記: 昨日帰りの電車の中で話してたんですが、テストがないコード=Legacy Codeが目の前にあった場合に「なんでか動いてるんだから、できるだけさわらないでおこう・・・」という消極的にそのシステムが死に絶えていくことを考えるより積極的に改善するループに持って行くためにはどうしたらいいか？という前向きな本だと思うんですよね、この本。確かに例が少々突拍子もなかったり説明不足なところが多いですが、「そんなこといってる場合じゃないだろ。なにか糸口を見つけて少しでもいいコードにしていく努力をしろよ。おまえら開発者だろ！」という声が聞こえてきてこの本好きです。