コンピュータサイエンスはこう学べ (2) - 人の心を動かすインタビュー

http://d.hatena.ne.jp/ryocotan/20090919/p1 の続きです。

---- 勉強をしている人は、「リファクタリング (ASIN:4894712288)」を読んでるイメージがあります

omo: 主にこの人でしょｗ

A: そうかなぁｗ

A: そういう所はあるかもね。リファクタリングは、2000年ぐらいですかね。ソフトウェアの開発スタイルを変えた一大事件で。2000年以前と2000年以降というのは、リファクタリングをベースに開発するというのと、そうじゃないというのが、大きな時代の区分としてあったんじゃないかな。

---- テクノロジーによって変わったんですか？元々思想的なものがあった？

A: 半々ぐらいだよね。やっぱりJavaとかが主体になるというのがあって、C++では厳しかったけどJavaなら、っていうのがあって使いやすくなったというのがある。あとはプロセスとかもリファクタリング向きなものになっていったっていうのがあるから、そういう外側の要因と、ただ純粋にリファクタリングに焦点を当てたという、マーティン・ファウラーの功績なんじゃないですかね。「その前からあった」とはみんな言うけど、少なくとも自分はそれを意識して開発してなかったんだけど、リファクタリングを読んで影響を受けて、意識するようになった部分はあるね。

A: 新人が来て、コーディングの文法は知っているという人間に、一番最初に読ませようと思うのはリファクタリング (ASIN:4894712288) かなぁ、と思うけどね。まず、本の出来が素晴らしい。

ひげぽん: うん。

omo: そうだね。薄い！ｗ

一同: (笑)

A: 薄い、ってほどでもないけどねｗでもまぁ薦められるよね、あの厚さだったら。特に、後半のケント・ベック (Kent Beck) なんて良い事を言ってるけど別に読まなくてもいいし。

omo: そうそうそうｗ構成がいいんですよね。

A: 別に最初の方だけちゃんと読んでおけばいいわけだし。

omo: 最初にモチベートする例を示して、こういう風にやんだぜ、って。

A: あれは素晴らしい本だね。後になって読むほど「あ、こんなこと書いてあるんだ」って気付く事が多いね。知らない時は知らないなりに学ぶことがあって、知ってくると知ってくるなりに学べるという、とても良く書かれた本だと思う。

omo: やっぱマーティン・ファウラーすげーって思う。

A: 思うね、あの本はｗマーティン・ファウラーはろくでもない、ってアナリシス・パターン (ASIN:4894716933) は読んでいて思うけど、リファクタリング (ASIN:4894712288) を読むと「あ、こいつ凄い奴なんだな」って、いつも思うよ。

---- 作者は何をやってる人なんですか？

A: Javaの受託じゃないですかね。

omo: アジャイル開発をプッシュする、受託＋コンサルみたいな会社のCTO。

A: Channel9とかにたまに出てくるんだけど、人の話を聴かないで自分の話を延々とするというｗあんまり華がある感じじゃないんだけど、

ひげぽん: そうなんだ。文章は素敵なのに。

A: そうなんだよねぇｗ　全然あんなタイプには見えないのに。「ギークとはこういうものか」って気もちょっとする。最近はDSLがお気に入りなんですかねぇ。

リファクタリングは良いんじゃないんですかね。「コードのクリンナップとリファクタリングは違う」って事を明らかにして、リファクタリングのやり方でコードを変更していくという事によって、それまで出来なかったスタイルの開発が出来るようになった、というのが「偉大だなぁ」って思いますね。「試してみて結果を見てから判断する」というのが、それまでには出来なかった事なんだよね。

---- なるほど

A: 設計とかで、Aって設計とBって設計があって「どっちが良いか？」って時に、「こっちが良いんだよ！」って勝手に進めていたところを、リファクタリングが出来るようになってからは、Aを試して、Bを試して、良かった方を選ぶように、実際に試して進められるようになったのが、それ以前とそれ以後の大きな違いなんじゃないんですか。

「プロトタイプをちゃんとやってた」って人にとっては、似たような部分があるかもしれないけど、そこを連続的に進められるようになったというのが大きい。現実の案件とかだと、プレッシャーとかもあるからさぁ。「実施するのに大きなジャンプが必要なテクノロジとか手法」ってあんまり使えないけど、リファクタリングは漸進的に導入できるからね。プロトタイプとかに比べて、大きく開発スタイルを変えたんじゃないんですかね。

omo: (図説中…)

A: リファクタリングの肝っぽいところは、「既に上手く行くと分かっている手順」だけを組み合わせて目的の場所に行く、ってところがクリンナップとの大きな違いだね。「変形できるパターン」というのは、限られた個数のパターンしかなくて、それだけを使って目的の場所に行くというのが肝なんだけど……まぁ、そうじゃない手順もちょっと混ぜたりするけどね。面倒くさいから。

---- 洗練された変形していく手法があると

A: そうだね。それが2005年になってIDEで自動化されて、凄い速度で出来るようになったんで、またそこで5年前とは大きく違ったギャップがあって。2005年以前と以後でね。人によっては2004年かもしれないけど。そこらへんの前後ってのは、プログラミングのスタイルも違うし、出来上がるコードも品質が全然違う。

omo: C++にはあまり関係ない話だよね。

一同: (笑)

A: これは一部のIDE信者的発言なんで（笑）。JavaとかC#が好きな人だけって感じ。「じゃあLLはどうなんだ？」って言われると、LLも劣るとは思わないけどね。そこは良く分からないんだよね。理屈で考えると、「型付きの方が良い」って思うんだけど。実際に書いてそうなのか、って言われるとそうでもなくて。この理論と現実の違いというのは埋めがたいけど。

omo: 抽象化能力は高いですよね、LLは。だから何とか補えるんじゃないんですかね。

A: 「小難しい本」というと、「役に立たない本」ってのがあるんだよね。例えば数学寄りな本？意味論とか。SICPとかそういうノリがあるけど、あれは半分ぐらい役に立つところもあるんだけど、そういうのもたまに読むけどね。ただ、そういうのはこういう場で話すものなのかなぁと思って。一方、「そんなに読んでるの？」と言われたら、そんなには読んでないので（笑）。「型付きラムダ計算は終了する」とか。おっ、終了するのか、だから何なんだよとか思うわけだけど（笑）。

ひげぽん: (笑)

A: 一部の人には大切らしい（笑）。「有限型のベータリダクションで」みたいな。「だから型付きラムダ計算以外はダメだ！」みたいな人も世の中には居るわけで。そういう本を読んで、だから何なんだと言われると別にね。

ひげぽん: 趣味の世界ですよね。

一同: (笑)

A: コンピュータサイエンスだと、コンパイルより後はそういう世界に入っちゃうけどね。LALR(1)の話とかは、数学っぽいけど現実的な世界なのにねぇ。それより一歩先に進むとろくでもない話になるよね。

omo: 本を読むってのもあるけど、現実の仕事からフィードバックを受けるというのもあると思うんですよ。そのバランスをどう取っていくのか、っていうのが。本を読んで、使ってみて、やってみて、勉強して、またやってみてみたいな。

A: 今やってる事に近い本を読んでる場合は、そういう感じになるよね。凄い良い本に、凄い良い時期に出会った時は、そういう風になるけれど。あんまり多くも無いけどね。

omo: 読む本のチョイスって、割と仕事で困った時に決めるよね。

A: そういう本が丁度あるってのは、良い時だよね。

omo: まぁね。

A: 「勉強が楽しい」と思えるパターンなんじゃないんですかね。例えば、見積もりとかを丁度やってる時に、見積もりの本が出たりして、「あぁ、良いタイミングで良い本が出たなぁ」とか思ったけど。そう多くある事じゃないよね。

omo: なかなか解決しない大きな問題とか……ほっといても進むんだけど気に食わない、ってことあるじゃないですか。そういうのを一年とかの単位でテーマを決めて読む、みたいな。

A: 私はそういう事はあまり無いかなぁ。でもそれは良い話って気がするけどね。

ひげぽん: 僕はもう仕事で役立つとかじゃなくて「貯金型」ですかね、今は。穴埋め型というか。ここが弱いから、あの時に困ったんだろうなぁ、と思いつつ読むみたいな。

omo: 一年ぐらい、性能関係を読んでるんだけど、あんまり読むペースは速くないんで。年に２，３冊なんだけど。

A: いい話じゃないですか。

omo: そういうのがあると仕事で「あぁ、あの時に性能を測っておけばよかった！」みたいなフィードバックがあるな。

A: 性能については言いたい事が沢山あるけど……性能の話は勉強とは全く関係ないね（笑）。

omo: (笑)

A: でもまぁ関係あるところもあるかもね。やっぱり、前は大きい会社に居たんで、大きい会社の良い所はそういう最新の研究成果とかが社内だけに出ている時に、それに触れられるというのがあって。性能というのは自分が居た時はホットな話題だったので、世の中では本にもなっていないような最先端のスタイルみたいなものを沢山読めて、それを実践できたというのは、性能に関して自信があると思える所だね。

---- 性能って何ですか？

A: きゅっと立ち上がって、きゅっと早く見えるとかじゃないの？うちはウェブサイトだったんで、そのページに移ってから出るまでの時間と、いじった時にきゅきゅきゅっと動くという（笑）、そういうのが性能じゃないですかね。色々あるけどね。

omo: 落ちない、とか。

A: 性能っていうのは、今時っぽい開発スタイルを要求するもので、リファクタリングブラウザとかを使って凄い速度でリファクタリングが出来るという前提じゃないと、色々と達成できない方法が前提となっているので。

ひげぽん: へぇぇ。

A: 「IDEないとダメだよなぁ」というのを、そういうのを通して思って、「ダメだC#以外は」みたいな（笑）。

一同: (笑)

A: まぁ別にJavaでもいいけどね（笑）。「Emacsなんか使ってる奴はダメだ」って話になるわけですよ。

omo: OSをまたいだりネットワークをまたいだりすると、ボトルネックって何だかよくわからなかったな。

A: プロファイルはやっぱり色々あって、計測することにどれだけ時間を掛けるか…ってのは今時と一つ前の世代では違うと思うけどね。性能を測るのに凄いコストをかけて、プロファイラで取る以上の事を色々やるというのは、今時の速さのソフトを作る肝になっていると思うけど。まぁ、そういう話というのは表に出ているものでもないので。

omo: (笑)

ひげぽん: 気になる！

---- Emacsの話が出ましたが…

A: めちゃアンチですよ。

---- 使ってますよね？

ひげぽん: 使ってますね。Aさん、昔Emacs使ってた人ですよね？

A: まぁそうですねぇ。

ひげぽん: 「Emacs最高！」とは最近は言わなくて、道具の一つなんで、まぁいいよね、ってぐらいです。「リファクタリングブラウザ」とかの話は、反論のしようがない。

omo: (笑)。Emacsの所為でなくて、C++の所為だと。

A: Schemeとかもあるけどね。そこらへんはIDE信者も歯痒いところだよね。「IDE素晴らしいんだよ！」って言っても、でも「仕事でC++なんだけど」って言われると、そこで会話が終わってしまって。

omo: （笑）

A: 「何それ。仕事でPS3なんだけど」って言われたら「知らんがな」って話になってしまうので（笑）。そこから先は分かり合えないので、どうしようもないんだよね。

---- リファクタリングブラウザがあってからこそのIDEなんですね

A: それ以前とそれ以後では違うよね。ただ、ボタン置いて、ダブルクリックして、ハンドラ書いて、ってのも良いじゃん、って思うよ（笑）。

---- コード補完とかいいですよね

A: インテリセンスとか良いよね。IDEとかは、インテリセンス無しだとやってけないよね。長いメソッド名とか打てないから。頭文字が散らばってる方が良いよね（笑）。

一同: (笑）

---- メソッド名の付け方も変わってきますね

A: 長くはなるよね。まぁ、Emacsでも…メタMだっけ、スラッシュだっけ。viだとCtrl-Pとか。その頃も、それなりにあったけど。インテリセンスは別物ではあるけど。

---- 名著五冊みたいなのを挙げて欲しいんですけど……

A: それは難しいねぇ。「新人に読ませたい」とかもあるね。

---- 「自分から勉強しないプログラマ」とかもいるわけですよね

omo: コース別ってことね。

---- とりあえずプログラマとして食っていくための五冊とか（笑)

A: 難しいなぁ。何も読まなくてもいいんじゃね？とかｗ

ひげぽん: それでも構わないんじゃないですか。

omo: 一緒に働いてるか、って前提がどれくらいかだよね。

---- 一緒にコード書いてるぐらいかなぁ。不勉強な人に苛立ちませんか？

ひげぽん: 自分はないです。周りが優秀なので、何も文句ありません。

A: 私はありますね。やっぱり、前提として知っておいて貰わないとコミュニケーションが成立しない会話とかがあって、設計とかの話をする時とかに、対等に話をしたい場合に知っておいて欲しい事って膨大にあるけど。それは抑えておいて欲しいけど、抑えていてくれる事ってあまりない。自分が思う前提を抑えている同僚ってのは、あんまり多くない。

---- どこら辺を抑えておいて欲しい？

omo: 膨大なんでしょ（笑)

A: 膨大ですね。

---- それを概ねカバーできる名著、みたいなのは難しい？

A: 今まで出てきたような本は良いんじゃないんですかね。リファクタリング (ASIN:4894712288) から始まって、DDD (ASIN:0321125215) を読んで、Working Effectively With Legacy Code (ASIN:0131177052) を読んで、xUnit Test Patterns (ASIN:0131495054) を読めばいいのか？……って言われると全然足りないけれど（笑）。

omo: なんか偏ってるよねぇ。

A: 今仕事をしていて困るのは、そこらへんが多いような気がする。

omo: 最近思うのは、他人に迷惑を掛けないコードを書く、ってのと、自分の中の満足度を上げていくのは別の軸で。

ひげぽん: 他人に迷惑を掛けるコードって、どんなのですか？

omo: バグってるとか、保守しにくいとかですよ。

A: 他人に迷惑を掛けるコード、ってのは多いんじゃないですかねぇ。

---- 他人に迷惑を掛けないようにする、というのは難しいですか？

omo: それは簡単で、Code Complete (ASIN:489100455X) とか、そういう方向だよね。チームで仕事をする時に、同僚の邪魔をしない為のコード、ってのはあるんですよ。最低の品質を保証するためのコード。OSとかコンパイラの本ってのは、読んで無くても割と大丈夫で、そういう本を読んでないとローレベルなレイヤーのものは作れないけど、それはそれで大丈夫で、仕事だとそういう仕事は作れる人に回っていくので。それがただ回して貰えないだけで。誰もが普段書くコードの品質ってのは重要で、そいつにインパクトのある本と、そうじゃない奴ってのは別なんだよ。コンピュータサイエンス寄りなやつってのは、自分の満足度とかハイテク路線。チームとか仕事としてコードを書く時に、他人に迷惑を掛けない為の本というのは、主にデザインとかプロセスの話。

omo: Code Complete (ASIN:489100455X) は、他人に迷惑を掛けないラインの本だよね。

A: 最低限だったら、「Code Complete (ASIN:489100455X)」と「リファクタリング (ASIN:4894712288)」ぐらいかな。「Writing Solid Code (ASIN:4756103642)」を入れるかどうかは、ちょっと微妙。

omo: もうね。

ひげぽん: もういいんじゃないんですか。

omo: 絶版だしね（笑）

A: 俺はあの本好きだけどね（笑）。あれは良い本だよ。迷惑を掛けない、となるとその辺のラインになるのかな。でも足りないような気もするけどねぇ。今言った本を読んで、そこそこのコードを書けるようになるかと。

omo: デザインパターンはどうなのかと。

A: デザインパターン……GoF (ASIN:4797311126) ？

omo: デザインパターンって難しくてさ。デザインパターンは要るけど、「あれか？」って。

A: でも悪くないよ、読み直してみると。どう思います、GoF。

ひげぽん: 僕は読んでないです。結城さんの本 (ASIN:4797327030) しか読んでないです。

A: お、読んでないんだ。へぇぇー。GoFを読んでない人がいた。衝撃。ひげぽんはGoFを読んでいなかった。GoFは、結構早く翻訳された本として思い浮かぶ本だね。あの頃は、原書が出て一年か二年で小難しい系の本が翻訳されてたよね。ああいう本が翻訳されるのは素晴らしい。GoFは、今時の本があると良いんだけどね。「Visitorとかねぇよ！」って誰かが言えばいいのにね。

omo: （笑）

A: Visotorパターンってのがあるんだよね。「ダブルディスパッチはこうやるんだ！」とか。「やるなよ！」ってみんな思っていると思うんだけど、そういう事が書いてある本なんで。「そっか、これがオブジェクト指向か！」とか思われると、大変たちが悪い（笑）。

omo: 間違ってるのも混じってる、って話なんですよ。

A: まぁ、良い事もあるんじゃないんですかね。

omo: パターンとして紹介されてるんだけど、使える場面がとても限られている。よく使われるようなものとして紹介されると困る。

A: たまに使えるシーンもあるので、一概にダメかというとね。GoFぐらいまでは読んでいいと思うけどね。あれ、何だっけ。

omo: Pattern-Oriented Software Architecture (ASIN:4764902834) ？

A: そうそう。そこら辺まで行くと、読まなくてもいいかなって思うよ。

omo: 何度挑戦しても途中で眠くなっちゃうんだよね。

A: あれは読んだら読んだで「へぇ」ってぐらいだけどねｗ