Coders at Work プログラミングの技をめぐる探求を読みました。文字が小さめでかつびっしりと文字ばかりの本なので、ページ数の割に読むのに時間がかかりました(ページ数の割にと言っても、600ページ弱なので薄い本ではありませんが)。
これは良い本です。名文ぞろいです。
心に残ったひとことの引用と、それに対する個人的な感想を書きます。引用は手動で書き写しているので書き間違いがあるかもしれません。何か変だったら前後から類推するか本を当たってください。
長いので何回かに分割します。
ジェイミー・ザウィンスキー
C++には嫌悪しか感じません。あらゆることがあらゆる仕方で間違っています。だからNetscapeでは可能な限りC++を避け、何でもCでやっていました。
XEmacsやMozilla(辞めた件)で有名なjwzの言葉です。本を読む前からjwzのC++嫌いは知っていましたが、相変わらずの過激な物言いが笑えるので引用します。
ちなみに本書にでてくる人たちのほとんどがC++をけなします。ストラウストラップ氏にもインタビューしないと不公平な気がするぐらいC++ダメのオンパレードです。
–過剰なエンジニアリングというのには我慢ならないようですね。
ええ。最後にはプログラムをリリースしろって言うんです! コードなら後で書き直してきれいにすりゃいいんです。3度目にはすっかりきれいになっているだろうから。
この本でインタビューされる人は基本的に現場主義で実践派です(偶然ではなく、そういう人を選んでインタビューした本なので)。
現場主義にも幅があります。ソフトウェア開発には動くコード以外にも重要な要素があると言うエンジニアリングな立場(たとえばコードの保守性やドキュメンテーションなど)の人もいれば、コード至上主義に近い立場の人もいます。jwzはコード至上主義のもっとも極にいる人です。
ある意味では潔いですが、残念ながらすべての人に当てはまるとは思えません。個人的な見解では、普通の人はjwzを真似しないほうがいいと思います。
–あなたの場合、コードをトップダウンに構成しますか、それともボトムアップに構成しますか?
私はふつう、葉のノードをファイルの上のほうに置きます。基本的にそのように構造化しようと努めます。そして一番上でAPIについての説明を書きます。
回答が少しわかりづらいですが、基本的にはボトムアップに書くようです。コードをどう書くかやどう読むかの質問は、他の人のインタビューでも繰り返されます。興味深い回答がそれぞれの人から返ってくるのでとてもおもしろく感じます。
同時期に書かれた本でみんなが最高だと言っていた本に「デザインパターン」があります。私はくだらないと思いましたけど。あれはいわばカッとアンドペーストによるプログラミングです。自分のタスクについてじっくり考えるのではなく、レシピ集を眺めて、何かそれっぽいものを見つけ、単に猿まねするんです。そんなのプログラミングじゃありません。塗り絵ですよ。
「デザインパターン」に関しては、本書でインタビューされる人の中でも、くだらないと切り捨てる人(jwzは代表)と高い評価を与える人と中庸な人(共通理解のためのツールとして評価)に3分されます。
–プログラマが持つべき鍵となるスキルは何でしょうか?
好奇心です。分解するということ。中では何が起こっているのか知りたいと思うこと。それがプログラミングの本当の基本だと思います。
個人的には共感する部分です。一方、必ずしもこのタイプでない優秀な開発者もいる気がします。
ブラッド・フィッツパトリック
–ソフトウェアはどのように設計しているんですか?
僕はものの間のインターフェースから取りかかります。共通のメソッドは何か、共通のRPCは何か、共通のクエリーは何かと考えます。(途中略)それからそれぞれの部分のモックを作り、だんだんと中身を埋めていきます。
オーソドックスなプログラミングスタイルです。比較的抽象度の高い大規模開発に適応した姿勢がうかがえます。
–プログラマにとって最も重要なスキルは何でしょうか?
科学者のように考えること。一度に1つのことだけ変え、我慢強く根本原因を理解しようと努めることです。
この回答も、マシン寄りというより、少しレイヤの高いシステム寄りの印象を感じます。
ダグラス・クロックフォード
–見た目はぐちゃぐちゃだけど、きれいにしてみたら下に良いコードが埋もれているのを見つけたというようなことはありますか?
そういうのは見たことがありません。良いコードをルーズなやり方で書くというのはすごく難しいのだと思います。良いコードというのは、読めるコードということです。
同じ現場主義でもjwzとは少しベクトルの違いを感じます。個人的には、ダグラス・クロックフォード氏に共感します。
私に言わせるなら、自ら職業プログラマを名乗る者は、クヌースの本を読んでいるか、せめて本棚に置くくらいのことはすべきです。
…だそうです。
–ソフトウェアを設計するとき、トップダウンとボトムアップとその中間とで、どれがお好みですか?
全部です。これは頭の中にシステムを入れておくということです。最終的には分割統治して手に負えるものにする必要があります。私は問題のあらゆる部分を一緒に考え、これらのテクニックを同時に使います。
たぶんこれがプログラミングの真実の姿です。一方、プログラマ初心者にとってみれば答えがこれだと答えをごまかされたように感じる部分かもしれません。
–形式的証明に関心を持ったことはありますか?
70年代を通して注意して見ていました。それが果たして何ものかになるのかどうか。そして割に合わないと分かりました。ソフトウェアはあまりに複雑で、失敗し得る方法があまりにたくさんあります。
ダグラス・クロックフォード氏の言葉には重みがあります。
ブレンダン・アイク
もっと衒学的な反対派もいます。「プリミティブを最小限にしてシュガーを取り除くべきだ。ラムダさえあれば何だってできる。人々はそういう書き方を学ぶべきなのだ。それが私の考え方なのだから」とか「それが最良の考え方なのだから」と主張しています。非常に還元主義的で、多くの人には合いません。すべて切り詰め、言語をサブセット化するというのは、思考上の証明システムを作る1つの方法です。サブセット化は強力です。しかしみんなそのような極小のサブセットでプログラムを書くべきだと言っても、そんなのは使い物になりません。
JavaScriptの父がLisp派を切り捨てた印象深いひと言です。
もう1つ影響を受けたものとして、これは少し恥ずかしいのです、awkがあります。(略)ファーストクラス関数をどう名づけることもできたのですが、それを”function”としたのは主にawkのためでした。
多くの人が長いと文句を言うJavaScriptのfunctionですが、awk由来とのことです。だったら仕方ありません。我慢しましょう。
Javaのような労働者階級の言語はいかれたジェネリックシステムなど持つべきではありません。労働者たちは共変、半変のような型制約の構文がいったい何を意味するのか理解できないでしょう。(略)JavaScriptをラムダの機械語みたいに使おうとする荒々しく毛深いフランス人のスーパーハッカーたちから守らなければなりません。
Javaプログラマをバカにして切り捨てた後、返す刀でLisp派も切り捨てます。
インタビューを読むと、ラムダラムダと言ってJavaScriptを難しい言語にしようと考える人たちにうんざりしている様子がうかがえます。ブレンダン・アイク氏は、正しく美しい言語にするよりも、現実に普通の人に受け入れられることに重きを置いているようです。
デバッグの技術の研究というのはがっかりするぐらい進んでいません。これも業界と学界の間に大きなギャップのある例です。学界の人たちは証明を手でやっていたりしますが、(略)現実の世界ではみんなデバッガに頼っており、使っているのはGDBのような70年代からの遺物なのです。
御意。GDBが遺物扱いされました。
–プログラムの設計はどのようにやっていますか?
プロトタイピングをたくさんやります。以前は高レベルの擬似コードを使い、ボトムアップで作っていました。(略)ほとんどの場合ボトムアップでやります。(略)ボトムアップとトップダウンで進めて真ん中で行き会うようにします。
トップダウンとボトムアップの両方、という典型的な回答です。個人的にも、こうとしか言いようがない気がしています。
私は象牙の塔の設計とデザインパターンにはアレルギーを持っています。ピーター・ノーヴィグはHarlequin社にいたとき、デザインパターンは実際のところプログラミング言語の欠陥を示すものであり、もっと良い言語を求めるべきだという論文を書きました。彼はまったく正しいと思います。パターンを聖典のようにありがたがり、ことあるごとに「そうだ、Xパターンを使おう」などと考えるのはどうかと思います。
jwzに続いてのデザインパターン切り捨て派です。デザインパターンが言語の欠陥を示している話は、かつてJavaOneで聞いてなるほどと思いましたが、原典があったようです。まだまだ業界で知らないことがたくさんあります。
–大きなコードの塊を読むときは、どのように取り組みますか?
以前はトップダウンでやっていました。ある程度大きくなると、関数ポインタなんかが出てきて制御の流れが分かりにくくなります。デバッガを使って追いかけたりいじり回すこともあります。それからボトムアップに識別できるパターンを探します。(略)しかし本当に理解するにはゲシュタルトなプロセスを経る必要があります。トップダウン、ボトムアップ、様々な異なる視点から見、デバッガでステップ実行し、…うんざりするぐらい手間がかかることもあります。
トップダウンとボトムアップの組み合わせという回答はお馴染みですが、ゲシュタルトなプロセスという表現はいいです。誰かに、どうやってコードを理解しますか、と聞かれたときには使おうと思います。
ジョシュア・ブロック
–プログラマすべてが読むべき本というのは何かあるでしょうか?
(略)「デザインパターン」はすべてのプログラマが読むべきだと思います。この本は共通のボキャブラリを与えてくれます。良いアイディアがたくさん詰まっています。
ここまで本書で散々こけにされたデザインパターンですが、ついに支持派がでてきました。本書で最後の最後までこけにされ続けるC++とは違います。
(略)単に動くようにするのではいけないということです。読めて、保守できて、効率的な作品を作る必要があります。
御意。
ある程度複雑なプログラミングにはAPIデザインが必要になります。大きな問題はモジュール化する必要があり、モジュール間インターフェースの設計が必要になるからです。
御意。
私がマーチンと考えが違っている点は、テストはドキュメンテーションの代替とは到底なり得ないということです。ほかの人が実装できる何かを書こうと思うなら、正確な仕様が必要であり、テストはそのコードが仕様を満たすか確認するものであるべきです。
マーチンというのはマーチン・ファウラーのことです。ジョシュア・ブロック氏は一貫して手堅いエンジニアリング主義の代表です。
–自分が書いたのではない大きなプログラムをどのように読みますか?
(略)良く書かれたコードを読む場合には、1万フィート上空からの視点を得ようとします。通常誰かがどこかにシステム全体の形を記述してくれているものです。それが見つかれば、どれが重要なモジュールか分かるので、それを最初に読みます。そして時折下のレベルのモジュールへの潜っていき、理解を深めます。
基本的にはトップダウンから、ということでしょうか。
特にケビン・ブリリオンの言うところの「共感の遺伝子を欠いた」人がいます。そういう人は良いAPI設計者や言語設計者にはならないでしょう。そのAPIを使おうとする、あるいはその言語で何かをしようとする普通のプログラマの気持ちになって考えることができないとしたら、良い仕事はできないからです。
御意。個人的に、ジョシュア・ブロック氏の発言には共感できる部分が多くあります。自分はJava派なんでしょうか。
正しいプログラムを書くのがどれほど難しいかを考えれば、私たちには得られる限りのあらゆる助けが必要です。だからバグを取り除いてくれる可能性があるものは何であれありがたいのです。それが私の静的型付けや静的解析を支持する理由です。ある種のバグが起きる可能性をあらかじめ取りのけるものは、何であれとても良いものなんです。
まったくそのとおり。
–難解なコードを書くことについて言うと、そういう人は、ある特定の次元において頭が良すぎるためにまずいコードを書くことに気がつきました。彼らはそれを全部頭の中に入れておけるため、そういう膨大なスパゲッティコードを書くことができるわけです。
そういう人たちは、膨大な複雑さと折り合えるくらいに頭が良いと同時に、ほかの人たちがその餌食になることへの共感を欠いているということには私も同意します。
ジョシュア・ブロック氏はぶれません。
APIを設計するときには共感の遺伝子を持ち続け、しかしそれを極限まで速くしようとするときには、パズルの宮殿へと自由に降りて行ってかまわないのです。
パズルの宮殿と言っているのは、マシン寄りのコードだったり、ハッカー気質の凝ったコードの世界を指した言葉です。ジョシュア・ブロック氏は一貫して手堅いエンジニアリングを支持していますが、ハッカー気質を否定しているわけではありません。ハッカー気質とエンジニアリング視点の明確な使い分けを主張しています。
最近のコメント