ベストプラクティスパターンのいきおいで、読みかけてやめていたリファクタ リングをもう一度読む。 実際 2002年の本では読んだことにしてある一冊。まんなかへんまで読んでや めたのが実状。
2002年当時は読みにくかった。なにせ、UMLも知らなかった。 矢印の意味もよくわかんなかった。継承関係を逆だと思ったり。
今は、少しは読める。
当時の私の感想は、
「これはプログラマーに勇気を与える書だ。」
だった。
今、現在、やっぱりこの本読むと勇気とリファクタリングしたい熱が高まって 行く。test書いてOKが表示される快感。
しかし、400ページもあって、しかも6章から12章は、またも、カタログなので 読みにくい。
ただ、「Smalltalkベストプラクティスパターン」よりは、各リファクタリン グのタイトルは判り易い。日本語だし。
今回もまんなかへん(8章終了)で、くじけそうになる。とりあえず、前回読ん でない、13章から、15章を読んでおく。カタログはくじけてもゲスト寄稿を読 んでおけば、読んだことにできる(ような気がする)。
リファクタリングブラウザが使ってみたくなる。Rubyのリファクタリングブラ ウザは、お、emacs版があるのか。うーん使い方が難しそうだ。
あと100ページもあるのだ。
(じわじわ読む。途中、遥かなるケンブリッジを読んだりする)。
12章 大きなリファクタリング。 この読みにくさは、KentBeckだ。彼の比喩はわからないのだ。 『丘の頂上近くで車が停止してしまった2人のような状況になることは望まな いでしょう。彼らはめいめい車の一方を押すために車から降ります。実りのな い数10分のあと先頭にいた男が、「車を下りの方に押すことがこんなに大変だ とは思わなかった」と言います。それに対してもう1人が「下りとはどういう 意味だい」と答えるような事態は避けたいはずです。』
わからん。想像では、車から降りた二人は、互いに逆方向に車を押していた。 だから全然車が動かなかった。コンセンサスを得ることは重要だよ、という比 喩なんだと思う。だったらそう書いて欲しかった。
『大きなリファクタリングが、小さなリファクタリングに価値をもたらしてい る多くの品質(予測性、目に見える進歩、即座の満足)を欠いているのだとした ら、なぜ重要なものとしてここに記されるべきなのでしょうか。』
日本語として破綻寸前である。ちなみにこれらの2つの文は、間で段落が変わっ ているが繋っている。
この章は、どこがどちら(ベックかファウラー)の文書か、署名されてないのだ が、これら2文はKentBeckだと思う。 Smalltalkベストプラクティスパターンは比較的読み易かったが、やっぱり KentBeckはレトリックがひねくれているので、読みにくい。
最終章も、やっぱりKentBeckだ。大ネタを振っておいて、結論はちょっとしか 言わない。
すぐにもリファクタリングを始めたくなったかもしれないが、大きなリファク タリングは災害を保証するなうからそう簡単には許可すべきでない。
と、あれ、っと思わせておいて、普通はここで、。。。なときに、リファクタ リングはじっくりと進むべきなのだ、的にまとめると思うのだが、ベックは、 少しずつ進むのだと一言だけ言って、新たな機能を追加する場合、テストを追 加する場合、と振ったネタと関係ない方向に進み、全然違う方向に飛んでしま うのだ。
結局前段落で振ったネタのまとめは、最初の1文だけで、のこりの文は基本的 には関係ない話が続いている。起承転結じゃなくて、起承結転転 みたいな書 き方なのだ。
ファウラーが主要な著者であるところのこの本で、KentBeckの判りにくさが引 き立った。
2004/07/09