読者です 読者をやめる 読者になる 読者になる

ひながたり。

writing practice as practice flight

「達人プログラマー」 再読した

経緯

いつものようにRebuildを聴いた。ゲストはHajime Morritaさん。

 

rebuild.fm

 

今となっては古典になりつつある書籍、達人プログラマーについて語る回。書籍にたいする批評の詳細については配信を聴いてもらうとして、エピソードの終わりごろで出てきたゲストの発言が印象に残ってた。以下に文字起こしで引用する。

 

本当に言いたいのは、この本の良し悪しではなくて、この本を読んだ人は、あなたが思ったことをどこかに書いてくださいってことなんですよ。

あなたは達人プログラマーを読んで感化されたあと、どういう人生を送ってきたんですかっていう、10年とか5年とか、それが知りたいんですよね。

 

今となってはだいぶ昔のことだけど、僕もかつてこの本を読んでたから、それで上の発言が印象に残ってた。ここで言われている話、「どういう人生を送ってきたか」までいくとちょっと大げさだけど、本書を読んだことで結果的に世界線を移動していたのかどうか、今の時点で少し振り返ってみたくなった。あと最近になって本棚の整理をしていたらちょうど本書が出てきて、ちょっと読み返したいなと思っていたこともあって、再読する時宜を得た。

 

 

 

本の歴史

さきに本書を古典と呼んだのは、これはポッドキャストでも語られているとおりなんだけど、この本はなかなかに長い歴史をもっているからです。

 

Amazonで少しだけ調べてみると、オリジナルの洋書版の発売日が1999/10/20となっているので、もう17年以上も前になる。一方の和訳版、当時はピアソンの日本法人から出版されていたものだけど、この発売日(発売月)は2000/11となっている。僕の手元にあるピアソン版の本書を見ると2000年11月30日に初版第1刷、2008年3月10日に初版第19刷となっているから、おそらくそのくらいの時期に買ってた。それからの2度の引っ越し、またスキャンしてPDFに変える機会が幾度となくあったにもかかわらず、本書はいまだに紙媒体で僕の手元に残っている。電子ファイルよりも紙媒体に重きを置いているのは以前に書いた記事*1の通り、当時から続く達人プログラマーになりたいというかすかな希望が、僕の中にまだ残っているのだろうと思われる。

 

その後ピアソンの日本法人が消滅して、そのあおりで本書も長らく絶版となっていたもよう。しかし最近になってオーム社から新装版が出版されたことを少し前に知った。

 

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

 

僕は古いほう、ピアソン版を読み返しながらこの記事を書いてて、新装版は読んでいない。なので新装版ではちょっと違った記述になっているかもしれないし、あるいは記述そのものがなくなっていたりという可能性もあるので、その辺りはご注意ください。

 

 

本の内容

本書の内容についてはポッドキャストで詳細に語られているから、ここに繰り返して書くことはしないけれど、達人プログラマーとしての心構え・精神論の話題が半分、そして残りの半分はテクニカルな話題となっている。読み進めていくとヒントの箴言がところどころに登場してきて、自分なりに考えるきっかけを与えてくれること、またこれらのヒントは巻末に箴言集として一覧できるようになっていて、読んだあとにチェックリストとして機能する仕組みになっている。少し紛らわしいんだけど、巻末にはヒントの集合とはまた別にチェックリストが存在していて、こちらもまた本の要点を拾い集めたものになっている。プログラマーとしての美徳に欠いた、実に怠惰でないつくりになっていて良さがある。

 

上でも書いたとおり本書の出版は1999年で、内容からは当時の技術の趨勢を知ることもできる。例えばチェックリストのひとつめ、学ぶべき言語のところでは

C、C++Javaに疲れたのですか? ではCLOS、Dylan、Eiffel、Objective C、PrologSmalltalk、TOMを試してみましょう。

とあって、この列挙された言語たちのベテラン感が半端ない。いわゆるドッグイヤーというやつで、この世界での17年前は現実世界の戦前に相当するようなもの、ポッドキャストでは学問のすゝめとかゲティスバーグ演説に例えられてた。なるほどなという感じです。

 

 

読んでから8年が経った

ということで、約8年前に読んだであろう本を今になって読み返しているわけだけど、振り返ってみると幾つかの発見がある。まず現実問題として未だ達人プログラマーになれてないというのはさておき。

 

バージョン管理システム

かつて本書を読んだ年寄りとしてひとつめに言いたいのは、バージョン管理システム*2の偉大さです。ポッドキャストでも触れられているとおり、1999年当時はバージョン管理はごく一握りの達人たちがやるもので、だからこそ本書でもシステムを使うよう推奨されているのだけど、これを覚えたことによる恩恵は計り知れなかった。

 

それまでのバージョン管理は全部手動でやっていて、これが最新版、そしてこれが1つ前の版で、両者の変更点は云々とかをいちいちやっていた。当たり前だけどこんなことでは変更の記録漏れは頻発するし、それにリグレッションからの復帰に多大な労力を費やしていた。これがバージョン管理システムのおかげでものすごく楽に作業できるようになって、システムそれ自体の使い方を覚えるのに少し時間を費やしたけど、その結果得られたリターンはとても大きいものだった。

 

バージョン管理の対象はソースコードに限ることはなくて、論文をはじめとした原稿執筆にも応用できる。僕がこれまでに手がけた最も大きい文章のまとまりは博士論文だけど、原稿の執筆に合わせて細々とコミットを続けていたら、いつごろに・何を・どれくらいのペースで書いていたかの事実が数年経った今でもちゃんと辿れた。辿れることそれ自体は単なる自己満足かもしれないけど、それでも当時は執筆のペースメーカー、コミットを重ねて一歩ずつ前に進んでいくことが、書き上げるモチベーションの維持に繋がっていたのかもしれないと思う。

 

今ではGitHubとかでバージョン管理するのが当たり前な世界観になっているけれど、それは先人たちが努力してその世界観を普及させてくれたおかげなのです。達人たちに感謝。

 

 

直交性

文章を書く、あるいは研究発表スライドを作るときに頭の中に浮かんでくる箴言があって、それが「ロジックとビューを分離する」というやつなんだけど、何かで読んだのか・あるいはどこかで聞いたのか、その出典がこれまで不明だった。でも本書の直交性の節でそれらしき文章が見つかって、この文章を読んでいたことはすっかり忘れていたのだけれど、もしかしたらここに由来するのかもしれないと思い至る。

 

さらに驚くべき事に、直交性はドキュメントにも適用できるのです。軸は記述内容とその表現です。本当に直交しているドキュメントでは、記述内容に変更を加えることなく、その見栄えを劇的に変化させることができるはずです。

 

冒頭の箴言、「ロジックとビューを分離する」の言わんとするところは上の引用文の通りで、"何が言いたいのか" という記述内容の部分と、それを "どうやって見せるか" の表現の部分は別物であるから、書き始める前には先ず "何が言いたいのか" の筋を一本通してやることが重要なのだと理解している。そしてその言いたい内容を踏まえたうえで、それを最も良く伝えるのに表現をどうするかを改めて考えるということ。これを意識してからは文章を書く、あるいはプレゼン資料を作るのが楽になったし、あるいは極まった研究プレーヤー同士の応酬、「落としどころが~」とか「それは見せ方の問題で~」とかいう感じの会話にも、ようやく理解が追いついていくようになった。

 

もともとの直交性というのは、本書中のヒントを引用するならば

ヒント13:関係ないもの同士の影響を排除すること

ということである。狭義にはコーディングにおける「グローバル・データを避ける」だとか、「類似機能のリファクタリングを行う」などを意味するけど、でももう少し広い意味で、設計やライブラリといった領域にまで拡大して解釈できるもよう。詳しくは本書を参照してほしい。

 

 

(手段|目的)としてのプログラミング

プログラミングそれ自体を研究の対象にするケースもままあるだろうけど、多くの場合はプログラミングを手段として何をやるのかの部分を求められているのだと思う。やりたいことがあって初めてプログラムは走るし、あるいは上で書いた直交性の話も同じで、言いたいことがあって初めて文章法とか書き方が機能するのである。何をやろうとしているのか、そのwhatの部分が大事だよということ。

 

けれど実際にはプログラミングそれ自体を学ぶこと、あるいはその周辺環境に触れることは純粋に楽しい。細かな言語仕様を調べる、超マイナーな組み込み関数を試してみる、あるいはコンパイルオプションを全部覚えてみたり、そういうhowの部分を追求するのは確かに面白いのだけれど、それは同時にwhatから少し遠ざかってしまうことでもある。最終的に何をなすのかのbig pictureに乏しいのは決して好ましい状況ではなく、でもプログラミングという手段そのものは相変わらず興味深くもある。一体どちらに重きを置けばいいんだろう?

 

とか悶々と考えながら再読してたら、まえがきから1ページめくったところにもう答えが書いてあって驚く。ここに8年前に気づいていれば、もう少し中庸の道を歩めたのかもしれないなと思う。

ヒント1:自らの技術に関心を持つこと。

ヒント2:あなたの仕事について考えること!

達人は、なしとげるために自らの技術に関心を持つこともするし、一方で自身の仕事、何をなしとげるのかについても考える。つまりは両輪で考えるべきだよということを、まず真っ先に説いているのである。この達人の功には思わずやられたし、今回再読して良かったなと感じたところでもあった。

 

 

まとめ

達人プログラマーを読んだことが(おそらくは)きっかけとなって得られたことをまとめた。世界線はおおむねポジティブな方向に動いていたようなので一安心した。

 

本書に限らず古典というものは、およそ長く生き残っているだけあって、何かしらの役立ちを持っているもの。その内容はすっかり忘れていても、僕にとって本書がそうであったように、こっそりと自分の血肉になっていることがあるから侮れない。最新の技術動向を追うのも大事だけど、たまには肩の力を抜いて、古典に触れて往時を振り返るのも良い。長く険しい達人への道、どうか最適の健闘を。

 

*1:

hina747.hatenablog.com

*2:本書中ではソースコード管理システムと記載されているが、現在ではバージョン管理システムの呼称がより汎用的かつ直感的(ウィキペディアでもバージョン管理システム - Wikipediaとあるように)だろうから、そのように記述する

お越しくださりありがとうございます。このブログについて