まだ１週間くらいしかやっていないが、なかなか良い感じで気に入っている。
以前にも書いたとおり、フォトリーディングでは「目的を持って読む」ということがとても大切で、これを上手くできているときは潜在能力(?)が活用されるらしい。実際、準備段階でより具体的な目的意識をもてた場合は、より多くのものを得られる実感があった。
さらに、マインドマップを使ってアウトプットまでした場合は、普通に読むより理解が深まり、多くが頭に残るのも嬉しい。しかも速いので、今までは勿体無いことをしてきたな、と思っている。ただ、フォトリーディングフェーズまでは、お気楽な感じなのだが、アクティベーションフェーズ以降は、結構気合が必要だと感じた。疲れている時は、ちょっとヤル気がしないのが難点と言えば難点。
Java言語には、クラス、メンバ、そしてローカル変数のスコープを制御するための素晴らしい仕組みがある。
僕がまだ研修中のプログラマだった頃*1は「全部publicにしておけば困る事は無い。だって、後でアクセスしたくなるかもしれないし？」と思っていた。誰にもその間違いを暴露されないまま3ヶ月の研修を修了した僕は、人生最初の受託開発プロジェクトに参加し、テストで出た不具合の山を中程まで登った時にようやく、このちょっとしたプラクティスの重要性に気がついた（そして気がついた時には遅かったんだけど）。
たとえば、全部publicにしておくと、確かに書くのは楽だと思うし、実際そのように書いている時は楽だった*2。問題は、それで楽をできるのは書くときだけだということだ。その後に待っている不具合修正とか、仕様変更対応とかは、楽どころかかなり苦しくなる。そして、不具合修正が全く無いなんてそんな素晴らしいプログラマは控えめ言ってもほとんどいないし、仕様変更対応は、必ず必要になる*3。もっと悪いことに、書いた後のこういう作業のほうが、書く作業よりも遙かに多いという事実。
ここから他の色々なプラクティスの基礎となる指針が導かれる。すなわち、
書くときのことよりも、書いた後のことを考えて書いたほうが良い
ということだ。
スコープに話をもどそう。
スコープは小さい方が良い、というのが僕の主張だ。主な理由は以下の通り。
どの理由もミスを減らすことに関係している。ミスを減らすことは、書いた後の作業を軽くするので、このプラクティスの効果の説明にもなる。
能書きの後に、あまり見かけないけど効果的なローカル変数のスコープ制限*4についてのありがちな例を書いておこう。
例として、Modelクラステストのフィクスチャなどで以下のようなコードを書く場合を考える。
final FooModel foo1 = new FooModel();
final BarModel bar11 = new BarModel();
final BarModel bar12 = new BarModel();
foo1.setBars(bar11, bar12);final FooModel foo2 = new FooModel();
final BarModel bar21 = new BarModel();
final BarModel bar22 = new BarModel();
foo1.setBars(bar11, bar22);
このコードには1箇所、間違いがあるが、すぐに気付くだろうか？
賢いIDEの警告機能を全開にしていれば、警告くらいはしてくれると思うけど、まぁ普通は、すぐには気がつかない。レッドバーが「何かが間違っている」ことを教えてくれるけれど、それがテストフィクスチャのタイプミスだなんて事までは教えてくれない。そこでテスタは無実のテスト対象のコードの方にあらぬ疑いをかけたりすることになるわけだ。
そこで、ブロックを使って変数のスコープを限定してみる。
final FooModel foo1 = new FooModel();
{
final BarModel bar11 = new BarModel();
final BarModel bar12 = new BarModel();
foo1.setBars(bar11, bar12);
}final FooModel foo2 = new FooModel();
{
final BarModel bar21 = new BarModel();
final BarModel bar22 = new BarModel();
foo1.setBars(bar11, bar22); //ここでコンパイルエラー bar11 cannot be resolved.
}
コメントの通り、エラーが出て、何が悪いのかすぐに分かって、テスト対象コードは無罪放免、テスタのあなたは残業なし、でめでたしめでたし、というわけだ。
理解の秘密―マジカル・インストラクション (BOOKS IN・FORM Special)
現時点では、あまり読みたいところが無かった。
操作説明書とか書く時に読むと良さそう。
インストラクションの構成要素：
「失敗」のところは、勉強になった。
最近、プロジェクトで、ポストモーテム/レトロスぺクティブ（振り返りプロセス）というのをやるようになった。
今のところは、まぁ前向きな話題が多くて、「失敗してしまった。何が悪かったのか？」なんて話題は出ていないけど、残念ながら、そういうのもすぐに必要になると思う。
そういう時って真剣に考えれば考えるほど、
→ひとつのミスに過剰反応
→それを防ぐ為にはどうすれば良いのか議論しよう！みたいな感じになったり。
→その結果、重すぎるプロセスが段々増えていって何かしんどい…
みたいなことにならないように要注意。
やっぱりリスク対応の”匙加減”というか、ポイントを押さえた対応というのが必要なんだと思う。言うのは簡単だけど、じゃぁ具体的に「ポイント」って何？という答のひとつが、この本の2ページ目に書かれていた。
しかし、事故はたった一つのきっかけだけで説明できるものではありません。事故は、複数の要素・要因がそろった結果生じるものです。これはちょうど、ポーカーや麻雀で薬がそろって上がることに似ています。「あのカードが手に入れば上がれた」とか「あの牌を捨てたことが敗因だ」という後悔は適切ではありません。麻雀の教科書を読んでみると、「両面待ちにしろ」とか「危険牌を振り込むな」と書いてあります。”最後のトドメ”である論された牌については、なんら原級していません。これに習えば、「事故は何面待ちになっていたか？」とか「危険牌を見極める方法は何か？」について書いたヒューマンエラーの本があってよいはずです。
「事故は何面待ちになっていたか？」 という「発生しやすさ(あるいは、発生しにくさ)の構造」という捉え方は、良いポイントかも。
以下はその他のメモ。
目次よりも前書よりも前に、この本を25分、プラス30分、プラス45～90分で読むためのガイダンスが付いているところが面白い。
でも、「準備」のステップで、いきなりつまづいた。
効果的なリーディングは、明確な「目的」を持つことから始まります。「これは、読むことで自分が何を得たいのか」を具体的にする、ということを意味します。
とても納得の行く話なんだけど、僕にはちょっと難しい。
積読キューからFIFOで本を読んで行くと、ちょっと情けないけど、「この本、何で買ったんだっけ…」という事を先ず考えないといけない。
最近、職場で「人生の目標を達成するために、人生をプロジェクトとみなしてマネジメントしてみてはどうか」というような話を聞いた。自分の個人的な目標を明確にして、ブレイクダウンできていたら、「自分はこの本から何を得たいのか」なんて自問自答する必要も無いと思う。読書よりもそっちが先ということか。