9/14 に、サイボウズ・ラボを会場に Working Effectively with Legacy Code 読書会 #4 が開かれました。主催者＆参加者の皆さん、お疲れ様でした＆ありがとうございました。
この本の前半は「せっぱ詰まった状況だけど新しく書くコードのテストだけはなんとかしたい」というシチュエーションで今日聞いて明日使える（かもしれない……？）メソッドをあれこれ紹介してくれるというものなんだけど、今回の範囲にはちょっと毛色の違う、「長くやっていくチームがせっぱ詰まらないためにどうしたらいいか」とか、「せっぱ詰まる以前に右も左もわからない」とかいう連中のための章がいくつか混じってたりする。
まあでも、懇親会でどなたか言っていたがやっぱり「崖っぷちで爆弾処理する人たちのための本」。もちろん「爆弾」は誰か（あなたかも）の書いたレガシーコード。
Chapter 12. １カ所でいろいろいっぱい変更しないといけないんですけど
id:Youchan さん担当。コードを分析して "Pinch Point" なるものを見いだし、テストの足がかりにする、という内容。
この章は 11 章の続きなので、このタイトルは実は「〜けど、どこにテストを書いたらいいんでしょうか？」と続く。
ちょっと著者が "Pinch Point" をどうしたいのか伝わってこないので、微妙にとまどってしまう。
せっぱ詰まってテストをたくさん網羅的に書く時間なんてどこにもない人は "Pinch Point" のところに１つ書いておけば、幅広い範囲をテスト配下に置けるし、ある程度の安全性を確保した状態でのリファクタリングが出来るようになるよね！ そうして "Pinch Point" でのテストが不要になったら消せばいいんだよ。
なるほど、それは一理ある。でもそれを "Pinch Point Traps" という節に書かれてしまったら、読者はいったいどうしたらいいんだろう。
Chapter 13 は次回順延。id:t-wada さんの暑い熱い語りが聞けるはず。
Chapter 14. ライブラリ依存関係殺人事件
hiro さん担当。ライブラリに依存しすぎて首が回らなくなってしまった男が次々と悲劇に巻き込ま(ry*1
ベンダー提供のライブラリをそのまま使っていろんな意味で痛い目にあったり、逆に１枚ラッパーをかぶせて置いたおかげでいろいろ助かったー、とかはある程度の開発経験がある人ならどちらも身に覚えがあるだろうから、この章に違和感を感じる人は少ないだろうと思う(短いし)。
あえてあるとすれば、次の章でライブラリをラップする具体的な手法が語られるのならば、わざわざ 14 章と 15 章を分けた理由は何？ くらいしか。しかも 14 章たった２ページしかないし。
おそらく「例えばある例として、ライブラリベンダがライブラリのロイヤリティ料を大きく吊り上げてしまったために、それを使っている製品が全く利益を出せなくなるなんてことがありました」という筆者の昔話を語りたかっただけちゃうんかーと踏んでるのだがどうだろう。
Chapter 15. うちのアプリは API 呼んでるだけだよ
kzys さん担当。API 呼んでるだけなのにどうしてテストしなくちゃいけないの？ という話。
この本で最長のサンプルコードが出てきて、確かに「 API 呼んでるだけ」なのだ。うーむ。しかも kzys さんの指摘があるまで気づかなかったが、全てのメソッドが static(苦笑)。
で、前半ではテストしやすい形にそのコードをごっそり設計し直すという話で、そりゃそうしたほうがいいだろうけど、それが出来る人なら「うちのアプリは API 呼んでるだけだよ」とかそもそも言わへんて、とは誰も突っ込まなかったな、そう言えば。
後半は一般論として、API をラップする方法として「皮一枚」と「ちゃんと責務を持たせてまじめに」の２つを上げている。
もちろん後者の方が望ましいのは議論を待つまでもないわけだが、この本が対象としている読者的には前者かな、と思うし、何も考えていない「皮一枚ラッパー」でも、困ったことになったときにどれほど助かるかとかいうあたりを（いつもの筆者の調子で）熱を込めて語ってくれてもよかったような気がしないでもない。
Chapter 16. 変更しようにもまだコードよくわかってないんですけど
id:kunit さん担当。コードをマーカーで色分け塗り塗りする話……いや、マジで本当に。
この章の白眉はやっぱり "Scratch Refactoring" だろう。自己矛盾したこの名称と、「テストを気にせずリファクタリングし*2、結果のコードは捨てろ」だなんてどんだけ無茶な兄貴っぷり。惚れる。
まじめな話、理解するために書き直してみるというのは最後の手段としてはありだと思う。まあ、そこまでしないとわからないコードはいっそ最初から捨(ry
ちなみにこの "Scratch Refactoring"、Chapter 20 でも「最後の手段」としてもう一度出てくるｗ
最後の節は "Delete Unused Code"。誰もメンテナンスしていない謎の巨大コードを解析してみたら、３分の１が使われてないコードで、３分の１が標準のライブラリににある機能を自分で実装してて、３分の１がコピペで、全部書き直したらなんと……的な話を思い出してしまうわけだが、そこまでいかなくともどこを削ってもいいかわかってるくらいならもう十分コードを理解していると思うのは気のせい。
Chapter 17. うちのアプリに構造なんてないよ
id:n_shuyo 担当。この本のノリとタイトルからすると、「構造化されていない legacy code に直面した時に ad hoc にどうすればいいか」という内容を期待してしまうところだが、実は「いつのまにか構造を失ってしまうのは the big picture(グランドデザイン) を見失ってしまうため。そうならないためには？」という話。
そしてその答えは「コミュニケーション」。というわけでこの章は語って語って語り尽くす。
実のところ、ただでさえこの本の英語はかなりくだけたものとなっており読みにくいことこの上ないのだが、通常の章なら題材となるサンプルコードが手がかりになってくれてずいぶん助かっている。
でも 17 章は題材が「物語」、筆者の昔話癖もリミッターが外れてしまったようで……。
というわけで途中からこっちも、ぷちっと切れてしまって、最終節はこんなことになってしまいました。「ネイティブ」にしかわからんと大評判。すいません、ごめんなさい、もうしません。
まあ、「『けったいな』ってなんですか？」とか、ついぞ読書会ではお目にかかったことのあるはずがない質問が飛び出したというあたりでよしとしよう。
Naked CRC という手法が紹介されていて、セッションとかトランザクションとかシステムの基本的な動作を、白紙のカードとかそこら辺にあるものを使って一種アニメーション的に説明するというもの。「このお菓子の箱をストレージに見立てると……」的に説明をしたことのある人はそこそこ多いだろう。あれだ。
名前に CRC って使わない方がいいんじゃないの？ というのはおいといて、なかなか面白い方法だと思う。ただ残念ながら残す方法がない。これを簡単に残し、共有する方法があれば結構いい感じだと思えるのだが。
Chapter 18. このテストコード、邪魔です＞＜
m-takagi さん担当。テストコードの名前の付け方と置き場所の話。
うーん、さすがにこの章の内容は特別可も不可もない……すいません。
やっぱりこういうのは IDE でサポートするだけじゃなく、言語でもサポートするといいと思いましたまる。
Chapter 19. うちのプロジェクトは OO じゃないんだ。安全に書き換えるにはどうしたらいい？
hiro さん＆ id:htada さん担当。タイトル通りの話。
個人的には OO だろうが OO じゃなかろうが別に気にしないんだが*3、この本で紹介されている手法の多くが OO を前提としているのでこういう話になるのだろう。
というわけで内容的には別段感心させられるところはなく、この章はとにかく最後の２節のぶっ飛び具合に尽きてしまう。
"Taking Advantage of Object Orientation" は C のソースでも C++ のコンパイラ使えばいいんじゃね？ "It's All Object Oriented" は C のコード全体を class program {} でくくっちゃえばもうそれは OO だよ、という話。ひどすぎるｗ
19 章の途中から、プライベートのご用事で欠席していた id:t-wada さんが用事が終わって駆けつけてくれた。内容的にもネタ的にも大変おいしかった。お疲れのところ本当にありがとうございました。
次回は 13 章と 20 章以降で、10/11(土) が開催候補日。
あと３回で読み終わる見込みだが、今回はこのタイミングながら新しいメンバーも参加してくださって、次回も増えるはずなので（予定空いてるって言ってましたよね？ ね？＞某同僚）、ひとまず楽しく読み切れそうだ。
懇親会では、幅広くいろんな話題に飛びまくってなんか細かく覚えていないのだが、とりあえず REST とステータスコードと Excel の話をしていた一団がいたような気がする。って、おまえら毎回やな。
あと、 id:t-wada さんが何か金言を見つけたらしく忘れないようにとメモっていたのだが、あれは今頃何のメモだか絶対わからなくなっている気もする。
席上にて、id:kunit さんに RESTful 勉強会で flowr の話を〜のとのお誘い。是非是非話させていただきますんで、よろしくです。
flowr はここまで３回ほど（ラボのテーマ発表会も入れたら４回）話させてもらってるが、REST との関わりについては全く触れないか、せいぜいごく控えめに……。
RESTful 勉強会でなら仮に確変突入とかしてももちろんドン引きとかされないんですよね？
