プロダクティブ・プログラマ読了！

多分6月終わりには読み終わっていたのですが、ちょっと読書感想文を書くのが延び延びになっていました。で、もう一度ざっと読み返していたら、何か1回目読んだときにはそこまで引っかからなかったところが思いのほか（いい意味で）引っかかる。色々インスピレーションをもらえて、2度お得な気分ｗ

I部は技法編ということで、TIPS的なものや有用なツールの紹介といった感じ。II部が実践編ということで、哲学とかもうちょっと踏み込んだ話。I部を詳しく紹介してもあまり意味がないと思ったので、II部で心に残ったことが中心です。

プロダクティブ・プログラマ -プログラマのための生産性向上術 (Ｔｈｅｏｒｙ　ｉｎ　ｐｒａｃｔｉｃｅ)

---

4.12 SQLファイルの分割ツールをRubyで作る

単純作業の繰り返しは、知力と集中力を奪う

とありますが、まさにその通りだと思います。自動化による作業時間短縮はあくまで一時的なものであって、かけがえのないものは自動化するに当たって振り絞って得られた知力（スキル・知識）だと。

4.13 自動化すべきか否かの検討

作業の自動化をするに当たってのプロジェクトマネージャの懸念事項として、自動化をするための時間が見積もれないというのが挙げられています。例えば、2時間で終わるはずが4日かかってしまうとか。まぁ、↑で述べたように、いくらスキルが得られて将来役に立つと言っても、現在のプロジェクトが破綻したら本末転倒ですもんね。

これに対する回避策として、「時間割を決める」という案が提示されています。自動化作業に実際に当たる前に、調査時間を設けておくというもの。調査の結果いけそうであれば自動化作業に着手すればいいし、現実的でないならば諦めればいい、もう少し追加調査が必要ならばその旨を伝えると。

大体やっていることでしょうが、スケジュールの責任者（プロジェクトマネージャ）に時間割をはっきりと明示しておくというのがポイントかな。以降の作業が楽になって作業時間が削減できる（かもしれない）自動化を喜ばないマネージャはいないと思うので、ちゃんと明示してさえおけば大丈夫…と思う。

断定できないのは、作業の自動化を喜ばない人もいるのも事実だと感じているから。例えば、時間でいくらという契約をしている人は、下手に自動化してしまうと短縮されば分のお金がもらえないというのもあるでしょう。そのことの良し悪しは、別問題として。直接的にそこまで言う人はなかなかいないけど、「機械に自動化作業をやらせるより、人間がやった方が確実」とか言って遠まわしに自動化に反対する人は、結構いますよね。。。

6.1.2 評価指標

「TDDだとメソッドの本体が短くなりやすい、なので処理が分かりやすい」という論理になっています。それはそれで正しいのですが、あまりに分割されていると、今度は全体で何をやっているかがぱっと分かりにくくなると感じています。この辺、バランス感覚が大事かなと。

本書例題のように、メソッドが細かく分かれていたら組み合わせて再利用しやすいってのはあるでしょうけどね。

10.3 デメテルの掟

かの「達人プログラマー」にも出てきた、デメテルの掟。言いたいことは分かるけど、そこまで有用なものかは（自分のレベル不足のため）ちょっと分かりません。結合度が疎になるってのは分かるんですが、ラッパークラスメソッドがものすごく増えそうなので…。

達人プログラマー―システム開発の職人から名匠への道

12.4 メタプログラミングの利点

本節で述べられている「言語に制限を加えても、ダメなプログラマが良いプログラマになることは決してなく、優れたプログラマの足かせになるだけだ」という文。「ダメなプログラマが良いプログラマになることはない」ってのはある意味そうなのかもしれないけど、だからといって「優れたプログラマが間違いを犯さない」とは言い切れないんじゃないかなと。ってか間違いを犯すからこそ、それを未然に防ぐというポリシーでJavaは設計されていると思っています。

ここも、バランスというものはあるんでしょうがね。

13.1 Composed Methodパターンの実例

ここでは、リファクタリングの実例が載っています。ここまできれいさっぱりコード全体をリファクタリングするってのは、抵抗が強いところはあると思うんですよね。ユニットテストを揃えることが、一つの解決案だとは考えていますが。この辺のやり方、この前発売されたレガシーコード本に書いてないかなぁ・・・

レガシーコード改善ガイド (Object Oriented SELECTION)

15.4 不適切なツールを拒否する

この中で提案されている方法の一つ、「時には相談する前に動くことも重要」。これはケースバイケースと言わざるを得ないです。動いたあげくに誤った方向に進んだときはもちろん、明らかに改善されたという状況でも勝手に動いたということで責められることは多々あります。いい方向に進んだからといって手放しで喜べるほど、人間って素直な生き物じゃないんです・・・＞＜

---

本書の中で、比較的多くGroovyの話が出てきたんですよね。見てたら、やりたくなりました！そういや、グリモンで作りたいものがあるんで、JavaScriptも覚えたいんですよね。

ま、まずはJavaを最低限マスターするか・・・。