『リーダブルコード』
Dustin Boswell・Trevor Foucher(著)
角 征典(訳)
2012年
オライリー・ジャパン
☆☆☆☆☆
「Theory In Practice」シリーズ中の1冊(なのかな?)。「読み易い=他人が読んで理解し易いプログラム」を書くための指針を示したプログラミング入門。サブタイトルは「より良いコードを書くためのシンプルで実践的なテクニック」。
やっと読んだ。この本のことを知ったときから読みたいと思っていたのに、これまでずっと後回しにしていた。やっぱり思った通り面白い。それに面白いだけでなく、良い本でもある。
Dustin Boswell and Trevor Foucher, 2011,
"The Art of Readable Code", O'Reilly Media, Inc.の全訳。この日本語版には、「訳者まえがき」の他に須藤功平氏による「解説」も付されている(内容的には「解説」ではないが(笑))。翻訳された日本語の文章は、どことな〜く山形浩生風(こないだ読んだ『
プログラマの考え方が面白いほど身につく本』(V. Anton Spraul(著) 角征典・高木正弘(訳) 2013年 アスキー・メディアワークス)なんかもそうだったんだけど、こういう風に訳すのが流行ってるのかね? と言うか、本当に山形浩生が訳したら、どんな感じになるんだろう?)。本を読むのがもの凄く遅い僕でも、頑張って2日で読破できた。
読み物としてのプログラミング入門。著者の2人はMicrosoftやGoogleでプログラムを書いていた人たちらしい。著者たちは「悪いコード」の実例を集めに集めて(そのため、本書で取り上げているコード例は、C++、Java、JavaScript、Pythonと多岐に渡る)、それが「何故悪いのか」を分析した結果、「他人が読んで理解しづらいコードは書くべきではない」=「読み易いコードを書くべきである」という結論に達したのだそうだ。そして、「どう書けば読み易くなるか」という観点から、日々のコーディングですぐに実践できそうなテクニックを次々と挙げてくれるのが本書。逆に言うと、プログラム設計のようなトピックは扱っていない(ただし、関数分割について述べているクダリで、クラス抽出についても触れている箇所はある)。
4部15章構成。ただし、内容的には第2〜3章、第5〜6章、第8〜9章、第10〜11章はそれぞれ1章にまとめてしまってもいいのではないかと思う。「部」に分かれている意味もあまりなくて、強いて言えば、最後の2章が「実践編」か。各章のテーマは、簡単に始められるものから、徐々に難易度が上がっていく。具体的には、命名規則、書式、コメント、制御構造、式、変数、関数分割・メソッド抽出、ロジック、ライブラリの活用、テストコード…。巻末に「付録」として参考図書が掲載されているのもいい(いずれも有名な本バカリで、隠れた名著が紹介されているワケではないが…)。正直、もっと小難しい話を順を追って述べていくような本かと思っていたが、実際は各章バラバラに読めるし、各章の分量も少なく、気楽に読める。ただ、何と言うか、バラバラに書かれたコラムをテーマごとに再構成したような雰囲気があり、全体としてのまとまりにやや欠けるようにも思う。
途中まで読んでフと「何だか『論理的にプレゼンする技術』(平林純(著) 2009年 ソフトバンク クリエイティブ)に似ているな」と思った。あんな本と一緒にするな!という声も聞こえてきそうだけど、「優秀な人が特に意識することなく『普通に』できてしまっているプラクティスを言語化・顕在化し、下々の者にも教えてくれる」という意味でとても似ているように思うのだ。
こういう本ってプロの人には必要ないのかもしれないけど(秀逸なソースコードを目にする機会も多いだろうし、先輩から直接教えて貰えたりすることもあるのだろうし)、むしろ素人プログラマにこそ絶対に必要。素人は、入門書を終えてしまうと自分自身をレベルアップさせることが本当に難しいのだ(これは、僕がVisual Basic育ちだということも関係している。書籍から中級者向けの情報を得ようと思ったら、VBではなくJavaやC++、最近ならC#等、他のプログラミング言語の本を読むしかない)。
本書の良いところは、豊富な「実例」が示されているところ。本書に掲載されている「読みづらいコード」の例は、説明のために著者らが(ワザとヘタクソに)書いたものではなく、実際にプロが書いたものなのだ。そのコードの何が悪いかを指摘し、ちょこっと書き換えるだけで…、明らかに読み易いコードに変わっている! 逆に言えば、各章末の「まとめ」だけ読んでもピン!とこない。
本書には「特に目新しいことや、『これだ!』という解決策が書いてあるワケではない」という批判もあるだろう。それは確かにそうだろうと思う。ただ、逆に言うと、読み易く理解し易いプログラムを書く「魔法」は存在しない、ということなのかもしれない。チマチマと正攻法でやっていくしかないのだろう。
僕自身がこの本から学んだことは、(コードを読む人が)「なるべく考えないで済むようにする」ということだろうか。そうすれば、認知的な負荷が減るワケだから、以前よりも楽にプログラミングができるようになるのである! これは100kmマラソン完走の秘訣と同じ(笑)。僕が100kmマラソンを数度完走して開眼した完走の秘訣は「なるべく疲れないように走る」なのだ! そうすれば、人間は100kmだって走り続けることができる。
そして、もう1つは、そうやってできた認知的な余裕を「本質的な問題」に集中させること。単に楽するんじゃなくて、楽してできた余裕を意味のあることに振り向けるのだ。例えば、本書の後半(第3〜4部)なんかを読んでいると、「コードを書き始める前に、抽象レベルで考えてみろ」ということを繰り返し述べているように思う。クラスやプログラム全体の設計を見直すことによっても、コードは「読み易く」なる。
ついでに、僕がドキッとした文言を挙げておくと…、
- 名前は短いコメントだと思えばいい。
- 直交する概念は無理に1つにまとめようとせずに、別々に使えるようにするといい。
- 簡潔な名前で式を説明することで、コードを文書化できる。
- 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。
- 本章はコードの「デフラグ」について説明している。
- あとでテストを書くつもりでコードを書くと、おもしろいことが起きる。テストしやすいようにコードを設計するようになるのだ!
- コードを設計していると、「うーん、これをテストするのは難しそう」と思うことがある。そういうときは、立ち止まって設計を考え直せばいい。
ちなみに、本書の挿絵の多くは僕にとって「これ、いったいどういうツモリのジョークなんだろう?」と首を傾げざるを得ないようなものだった(本当に、どこに笑いの要素があるのか理解できなかった)。それでピーン!きた。この感覚は、以前『
ライト、ついてますか?』(ドナルド C. ゴース・ジェラルド M. ワインバーグ(著) 木村泉(訳) 1987年 共立出版)を読んだ時に感じたのと全く同じ。『ライト、ついてますか?』はもの凄く評判の良い本なのに、僕にはその面白さが全くわからなかった(まさに狐に抓まれたようだった)。要するに、僕にはアメリカンジョークが理解できないのである。それだけ! それだけ!
本文220ページ程度(他に、「訳者まえがき」「はじめに」「解説」「索引」として20ページ程度)。

0