test-driven reading

『Head First Java』（asin:4873112796）をちょっと読む。オブジェクト指向などのテクニックがなぜ必要かスムーズに理解できてる。たとえば配列からArrayListへの謎解きのような導入が見事。
知識を整理するとストーリは省かれる。しかし知識の価値を知るには、実際に試すか、事例の考察が欠かせない。ユースケース記述のシナリオが顧客の理解に有効であるという話も聞く。ひとに説明するとき事例や実体験はなんだか大切らしい。

『Head First Java』p.101 えっ！テストコードを先に書くの？
そんなこと思いつきもしなかった。
どうして？
びっくりさせないでちょうだい。

擬似コードに対してプログラミング言語でテストコードを書くというのは違和感がある。プログラムの機能つまり目標が明確になることに加えて、プログラムを書いたあとにテストコードを書くのが面倒、という素朴な理由を思うと、テストファーストという手法の有効性にも納得できる。
満たすべき条件を明確にすることはプレッシャーでもある。とくに文章を読解するときには、なんとなくわかる、という気持ちもあって、あいまいに済ませたくなる。判断や発表に用いる文献くらいはちゃんと読みたいなあ。
読解においても、はじめに答えるべき問いを設定するとよい。いってみれば文章を通して思考をプログラミングするようなもの。でも、プログラミングほど臨機応変なテストケースはいらないはず。『本を読む本』（asin:4061592998）に書かれているのもそういう問いだと思う。
関連：「読めていない」と気づかされる10の質問 - 反言子