読書会(リファクタリング - プログラミングの体質改善テクニック)第3回議事録

[ 戻る ]

読書会(リファクタリング - プログラミングの体質改善テクニック)第３回議事録
2003年1月18日10:00〜16:30
参加者
高橋（智）、山本、小川、角野、砂生、高木、新井、高橋（徹）、百瀬、門脇、
村上、西海、（以上ホワイトボードに名前があった方）他の方々

自己紹介

■第４章　テストの構築

○テストの追加

p.101
どの程度の組み合わせをてすとすべきか。
クラス間の独立性、依存性、直交性が少なければ、
組み合わせを減らせる。
設計が重要で、テストを意識した設計という考え方。
品質管理の手法とCMMがあわない？

JTestの性能はどのくらいか？
JTestが自動生成したコードに手を入れるのはむずかしい。

仕様変更にあわせてテストを書き換えるのは大変だ。
変更クラスとテストユニットが対応づけられていれば。
シナリオごとにテストケースを設けるアイデアもある。
（XP,オージスのメーリングリストにこの話題があった）

JTestは、コードを修正する根拠を示してくれる。
Togethre Controll Centerはコードも直してくれる。

モデル図（シーケンス図ほか）はテストケース作成に利用できるのでは。

■第５章　リファクタリング・カタログに向けて

初期のカタログとは「たたきだい」の意味であろう。

○参照の検索
Eclipse は常に文法的な解析を行った上で、適切な参照を見つけてくれる。

○本書のリファクタリングの成熟度
最新のリファクタリング情報のWEBはないだろうか。
（[jfriends-ml 10442] リファクタリングのホームページより
www.refactoring.com）

Fawlorさんは最近はデータベーススキーマのリファクタリングに興味があるらしい。

開発現場では、DBモデリングツール、スキーマ設計のツール（シルバー、アーウィ
ン）
をつかい、DBの管理チームで集中して管理をおこなっているのでは。

EclipeのDBアクセスTOOL（クオンタム？）は便利ですよ。

■第６章　メソッドの構成

○メソッドの抽出(Extract Method)
短いメソッドを抽出することに抵抗感がある。
抽出したメソッドにどれだけ適切な名前を見つけられるかが大切である。
しかし、クラス名にIDを使っている場合があるが、
画面系などで、多くのクラスを管理する場合は有効だとおもう。

あらたなメソッドはprivate  で宣言するべきでは。

○メソッドのインライン化(Inline Method)

「アクセサ」に関する言葉（query / mutator、geter / setterなど）
さまざま言葉遣いがあるので注意が必要でしょう。

○一時変数のインライン化(Inline Temp)

メソッドの返り値の型が変数として明示されていると
テキストとしてクラスの参照を探す場合に有効な場合もある。

この本のリファクタリングには、コードをまとめる方向のリファクタリングと
分解する方向のリファクタリングが用意されているようだ。

○問い合わせによる一時変数の置き換え(Replace Temp with Query)

p.123 discountFactor () の抽出を自動化できないか？

○説明用変数の導入(Introduce Explaining Variable)
isMacOS (), isIEBrowser ()まで関数化する。

ローカル変数につねにfinalをつけますか？

コメントは取り除けるか。
Javaではシンボルを日本語でかけばコメントをなくせる。

○一時変数の分離(Split Temporary Variable)
perimeter : 周囲長

○パラメータへの代入の除去(Remove Assignments to Parameters)
パラメータにfinalをつけたからといって、渡されたオブジェクトに
副作用を及ぼさないとはいえないので安心できない。
→考えすぎでしょう。
仕様がよくわからないものをリファクタリングする場合と
仕様をわかっていいる場合は分けてかんがえないといけない。

パラメータに対する扱いに関しては、コンパイルでのチェックだけでは無理で
設計やコーディングでの規約を設ける必要がある。

○メソッドオブジェクトによるメソッドの置き換え(Replace Method with Method
Object)
Gammaオブジェクトはクラスとして意味がはっきりしないのでは。
　分解によって、引数のないメソッドが多くなる
　compute ()メソッドのオブジェクト
　
ここで導入されたメソッドオブジェクトは、あくまでも一連のリファクタリングの
過程で作られる一時的な状態なので、この後に続くリファクタリングによって、
ちゃんとした役割を持ったクラスにしてゆくものと考えられる。

○アルゴリズムの取替え(Substitute Algorithm)
この例では、パフォーマンスは犠牲になっているかどうか？
可読性はリファクタリング前のほうがわかりやすいのか？

ここでの「アルゴリズム」とはわかりやすくするために、
手続きの改良を意味しているだけ。
本来の「アルゴリズム」の改良を意味しているわけではない。

■第７章　オブジェクト間での特性の移動

○メソッドの移動(Move Method)

○フィールドの移動(Move Field)

○クラスの抽出(Extract Class)
p151 TElephoneNumber._areaCodeが元のクラスから名前が変わっている。
例としては不適切ではないか。

○クラスのインライン化(Inline Class)
インラインされるクラスはクラスを選択するのか。

「簡単な葬儀を執り行う」とはどういう意味か。
クラスがなくなったことを公知する。
公開させれていれば、クラスはなかなかなくせないので、deplicatedにしておく。

○委譲の隠蔽(Hide Delegate)

○仲介人の除去(Remove Middle Man)
（p84 「連鎖の長さ」を読む）
ツールで連鎖の長さやクラスの関連性を計る方法はないのか？

マーキングにコーディング規約が必要
ライブラリのバージョンアップ時に更新を依頼する。

サブクラスを使う場合equals ()の対象性をみたせない。
フィールドが追加された場合は難しい。
Effective Java にある５つのルールに従う必要がある。

○外部メソッドの導入(Introduce Foreign Method)
かつてCなどでオブジェクト指向的なプログラミングスタイルとして
第１引数にオブジェクトを渡すようなアイデアと同じ。

○局所的拡張の導入(Introduce Local Extension)

■テキストに直接関連しない話題
---------------------------------------------------------------
○定数定義はどこで（普通は実装クラスに定義）
インタフェースに辞書的に定数を定義したい。
---------------------------------------------------------------
○JDK 1.5での改善点
コンカレントパッケージ？
generics.
auto boxing.

次回は第８章「データの再編成」から

[ 戻る ]