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

[Arai Noric <noric2000@xxxxxxxxxxx>]

新井です
すいません、子供と戯れていて遅れましたが2回目の議事録です
変更してもらいたい内容が2つあります。
1つ目、黒板に書いてなかった参加者の方一人（入り口から3人目ぐらいの方）
2つ目、次回はどこからか
あと、誤りがありましたら、修正お願いします→智さん

////////////////ここから//////////////////////
読書会(リファクタリング - プログラミングの体質改善テクニック)第2回議事録
2002年12月

参加者
高橋(智)、高橋(徹)、中村、百瀬、西海、新井(記)、根本、高木、布留川、村山
金井、角野、天野、宮本、武川

自己紹介・・キーワードだけ
J2Meのスピードが非常に早い
ボーランドが買収、IBMが買収、FOP、XSLT、BCEL(バイトコードライブラリ)
aspectJ(1.1Beta)ゼロックス対象、BCL？、
■JTest
コードレビューを自動的にしてくれる
(例：notifyを使わずにnotiryAllを使用してくださいなど)
Jtestは、世界初のテストケースからテスト実行までを自動化する最先端のツールです。
ホワイトボックステスト、ブラックボックステスト、回帰テストを実行し、
エラーを自動検出します。また、Jtest は、Source Code Analysis テクノロジー
を利用して、ソースコードを静的解析し、コーディングルールに反するコードを検出。
コーディングルールが、320種類登録されています
1週間の無料DownLoadサービスがあります
http://www.techmatrix.co.jp/asq/jtest/

p58
三度目の法則・・「2度あることは3度ある」
p59
上の方：コードレビューを定期的に行ってる組織とは何か？
会社もしくは部署で、当たり前に行われているところもあるが、
やらないところはまったく行わない、行わないところは誰も
レビューしていないのでコードがぐちゃぐちゃになりやすい。
行うところでもコードをレビューするリーダが忙しくなりやすく
おざなりになりやすい
最後の方：XPのペアプロは頻繁に変わる
p61
現実的にCでモジュール化されていない、非常に大きいプログラムは
リファクタリング不可能らしいとのこと
１０−６１ｐ（最後の一行）
CにはJavaDocに相当する機能がないので
１１−あまりよろしくない、どこまで詳細にするかが問題となっている
ないでしょう・・・
p62
１１−６２ｐ（机上の設計真中ぐらい）
なぜ昔は机上の設計をしたか？
さすがにコンパイルに１晩かかったら流石に机上の設計をするようになる。
p64
１３--メソッドサーチ
Swingには存在するが、Treeを表現するCollectionがJava標準にはない。
コンポジションパターンでやるのが普通、JakartaCommonsにあるかも・・
グラフライブラリがどこかにあるらしい
１４−６４ｐインターフェースの変更
Exceptionの子クラスに変換して投げなおすのはいいのでしょうか？
publicインターフェースを公開してしまった以上しょうがないが
本当はCheckedExceptionを投げたい
66p
パターンをやたら使うのは問題である。
誰からも呼ばれないのにObserverパターンを使用していたり
設計が複雑になりがちである
Alistair　Cockburn−アジャイルプロセスのクリスタルの人
参考文献　JavaWorld11月号でした
http://direct.idg.co.jp/detail_1.msp?id=701&class=10005&n=2
文献
http://www.shoeisha.com/book/Detail.asp?aid=1245
(購入しましたがほとんど読んでいません)
アジャイルを導入しても使いこなせる人が少ないのが問題
アンチパターンの１つ、「パターンで何でも解決できると思ってしまう」
68p
KentBeckが作ったプロファイラーの話
さりげなく書いてあるが、すごいのではないか？？
あまりたいしたものではないと想像(System.currentTimeMillisのようなもの？)
スモールトークだから・・もっとビジュアル的なもの？？
■JDK1.4からの新機能(ドキュメントから引用)
HotSwap
この機能が追加されたことにより、デバッガの制御のもとにクラスを更新できるようにな
りました。 
■昔話(私にはさっぱりわかりませんでした)
MSの重い本で電車で読むと腕が・・
■パターンハッチングの本より
4人の中で23のパターンを抽出するときの裏話などが載っていて
裏話が面白い・・らしい・・
本の最初にコンポジットでディレクトリ構造をVisitorでうんぬんする話が永遠と
載っている。そのあとObserverをVisitorで変形するパターンがのっていて
Observerを挟むと複雑になるので
Observerを1つのVisitorとして作るみたいなやり方が乗っていて
プレゼンターパターンとなっているが・・ちょっとパターンにならないなと
(パターンハッチングが欲しくなりましたC++というのが・・)
２０：２回目でリファクタリングか３回目でリファクタリングか？
■■第3章
p76
「重複したコード」
前に3回と書いてあった突っ込みがありました。
p78
「巨大なクラス」の下五行
モデルからビューに対して通知の仕組み（Ovserverと読んでいいのか分からないが）
GUI側とモデル側で同じデータを持ってる時に
モデルだけ独立しましょうといった時にときに、一時的に、例えば
ユーザ名を変更したら、もう一方も変更しなければいけないときなど
(例が後に載っている)あとでここに戻ってもう一度みたいです。
「変更の発散」79p
データベースが変更の時に１つのくらすで3つのメソッドを
金融商品追加では4つ
修正しなければならないということなんですが、
2つの別の役割が混じっていることなんでしょう。
p81
「基本データ型への執着」
オブジェクト指向を始めたばかりの人は小さなオブジェクトを嫌がる
→小さなオブジェクトを作成しましょう
p83
「パラレル継承」
どういうこと？
AbstractFactoryパターン?
デザインパターンの弱点として挙げられている？
不吉な匂い系で具体例がないものは2度と出てこないので
理解できません、誰か具体例を作成しませんか？
84p「メッセージの連鎖」
a.getB().getC().getD()など？
後に例があるらしいです・・・（来年の5月あたり？笑）
時間があれば、最後の最後にやり直したいですね・・とのこと
p86「データクラス」
そんなのの出来ない？
■■第4章
p90
GUIのテストって難しいですという話、
→ボーランドが買収したトゲザーを買いましょう（高い？）
■ErrorとFailureは異なる。
大丈夫なテストを書きがちであるがそれはよくない
■assertの違い(JUnitとJDK)
基本的には前提条件である。
Javaのassertエッフェルのアサートを参考にしている。
出来ればリリースしても外してもらいたくないという記事があった。
単体テスト(JUnit)
製品コードの中で埋め込む(JDK)
p98
p99
for文の繰り返し回数合ってる、間違ってる論議

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/