2008-08-02

近況

また WEwLC 読書会に参加した. 参加者ほぼ全員が ノート PC を持っており, Lingr で番外編をしている. ノートなし派(派閥じゃなくて経済的事情ですが)としてはやや悲しい. の 新型 MacBook が出たら欲しいなあ. 宴会ではまたしても名刺を切らせていた. すみません... > 名刺を頂いた皆様

この読書会はいつも, 本の内容より読書会そのものが勉強になる. 今回は n_shuyo さんの発表がわかりやすかった. 立ち振舞いもなんとなく先生っぽい. このわかりやすさは真似できないと思いつつ, 何が良いのかを考えていた.

きちんと読む: まずきちんと本を読んで理解しないと始まらない. 私は字面だけ追って読み進めてしまう癖がある. (割と根本的にまずい...) 批判的に読まないといかん. 特に内容が主観的だったり, 未整理なアイデアである時は, 話の整合性が怪しくなりがち. ちゃんと読まないと不整合なままのアイデアが自分の中に残ってしまう. 今回は, コード内の影響範囲を図示する "effect sketch" というアイデアが示されるのだが, 著者の考えが整理されておらず記法が一貫性を欠いていた. 私は "影響を図で書けばいいのね" くらいの認識でぼんやりと読んでいたので気がつかなかったけれど, 本当はもっとディティールがあった. そしてそのディティールが少し間違っていた. ぼんやり読むだけだと実際に "effect sketch" を試そうとした時に困るか, それ以前に存在を忘れてしまう気がする.

別の言葉で短く説明しなおす: これは理解を促す上でよく言われることだけれど, 上手くできた例はけっこう珍しい気がする. 参考書のような文章の構造化に自覚的な本が相手だと, 目次や強調部分をピックアップしただけでなんとなくまとまった気がしてしまう. 同じ流儀を普通の本に持ち込むと構造や要点を掴みそこねる. n_shuyo さんのメモはそうした再構成がうまかった. 良い読書ノートってのはこういうんだろうと感心. どうやれば上手くいくのかはよくわからない. 語彙の多少は関係がありそう.

クロスカットな文脈を意識する: "ちゃんと読む" の一環として. 文章には "起承転結" のように大きな流れがある. 普通, この流れは目次に現れる. 一方で, その流れとは直交した文脈もある. たとえばここは著者の "経験談" だな, 次は "愚痴" でここは "思いつき", ようやく "主義主張" が出てきた...というかんじ. こういう文脈を検知できると, それに応じて読み方を変えることができる. 具体的には読み飛ばせる. 今回の例だと, ここは "設定の説明" です, というパターンがよく出てきた. これからテストをするレガシーコード(=設定)の中身を説明する部分. 基本的に酷いコードであるレガシーコードの設計は, 善し悪しを吟味しても仕方がない. だからささっと読めば良いとわかる. (受験英語のエキスパートによれば, こういう文脈を識別する技術があるという.)

周辺情報を補足する: 本の中身ではなく, そこから参照されている技術や用語の説明を調べて追記することができる. 今回はコード変更の影響範囲を絞りこむプログラミング言語の要素として C++ の const 機能 (と, それを台無しにする mutable 修飾子) の話が補足されていた. C++ に不案内な参加者には役に立つものだったと思う.

私は以前から本の読み方が下手だと思っていた. そのまま長いこと放置してきたけれど, だんだん非効率の負担が大きくなり困っている. 技術書の著者は本業の文筆家とは限らないから, 文章や構成が期待するほどわかりやすくないことがある. 扱う話題が本質的に複雑なこともある. けれど文章がわかりにくいからと言って, 主張や説明の中身が間違っているとは限らない. 逆に明快な文章で間違った主張をする本も多い. 少しくらい文章がわかりにくくても中身を読みとることができないと, 有意性ではなく読みやすさにバイアスされて自分の知識が形作られてしまう. そんな恐怖がある. (程度を越えてわかりづらい文章は無視していいと思うけれど. 書き手が問題を理解してないせいだろうから...)

読書会の準備であるという分を差し引いても, n_shuyo さんのノートは読む人がちゃんと読めば効率は高い実例. 精進したい. まずは 本を読む本 を読み直そうかしら.