リファクタリングとpublished

昨日、Erich Gammaのインタビューを読んだ勢いでid:wildcatsさんのところにコメントしたら、artonさんからもご意見が。
http://d.hatena.ne.jp/wildcats/20050726/1122389747
http://arton.no-ip.info/diary/20050727.html#p02

概念的にフレンドアクセスとそれ以外の2つに分けて、フレンドにはclassを触らせることを許可して、それ以外にはinterfaceしか触らせないようにする。ではどうだろうか？

フレンドって、新しい依存性のレベルを導入すると、ちょっと複雑さが増えて面倒かな、と思いました。結局みんな親友だね、みたいな結末が待ってそう。

複数の責務を持つpublishedなメソッドって別に構わないと思うので（サービスだ）そこは違和感を覚えた。レイヤー分けの問題に過ぎないと思うからだ。具体的にはpublishedなメソッドの中で複数の単責務なメソッドを呼び出すという考え方を取れば良いし、その単責務なメソッドを同一パッケージ内の複数のクラスやあるいは同一クラスの複数のメソッドとして分ければよいのではなかろうか？ というか、外部へ公開するということはそういうことだと思う。

納得。外から見たときの振る舞い、サービスっていう観点と、仕組み的・実現方法的な観点から見た責務っていうのは分けて考えないといけないかも。

アプリケーションつくりの人とプラットフォームつくりの人

ちょっと話がかみ合わないことがあるかなあ、と。
プラットフォームを作ってる人は、古いバージョンのAPIをStableに残しながら新しい要求に対応していく。アプリケーション（ここではGUI中心の業務アプリケーションを想定してます）を作っている人は、StableなAPIを作ることにはそれほど関心はなく、UIの変更を中心とした要求の変化に対応していく。（もちろん、アプリケーションにも基盤の部分があるので一概には言えませんが）
Gammaのインタビューにも「Eclipseはプラットフォームだから・・・」みたいな話があったし、先日のJ2EE勉強会でも、ひがさんが「俺はフレームワークを作ってるから、ちょっと違うかもしんない」というお話をされてましたんで、なんとなくそう思いました。

３周遅れくらいのところからTDDとかリファクタリングとかを見てみる

従来型（？ というか、私の会社では結構やってる）の、それなりに品質を高くしようとしているプロジェクトでよくある光景では、

後輩：「hoge機能の実装できました！検証してください！」（キラキラした目で）
（仕様書とソースをプリントアウトした紙とテスト仕様書とテストデータ、テスト結果のダンプ、さらにはコーディング規約に合致していることを示すチェックシートを積み重ねた紙束に、「検証依頼書」なるドキュメントを乗っけて抱えている）
先輩：「お、できたか。よしよし。」
（一時間後）
先輩：「hugoクン、ちょっと来て」
後輩：「！」（ビクッ）
先輩：「ここなんだけど… 処理が重複してるよね。」
後輩：「……」（硬直）
先輩：「あと、このメソッドすごく長いんだけど、こういう風に分けたらどうかな。」
後輩：「…………」（リーダーに「また手戻りか。きちんと仕事しろ」と怒られるシーンの想像で頭がいっぱい。もう聞いてない）
先輩：「それから、ここは引数の数が多いから、オブジェクトにまとめる方がいいよね。」
後輩：「………………」（涙目）
先輩：（後輩の様子を見て）「……でもまあ、バグはなさそうだよ。規約違反もないし。次から気をつけてね」
後輩：「はいっ！」（すばらしい笑顔で）

かくして、先輩の目から見れば「汚い」コードが生き残っていくわけです。
TDDでコードを改善するコストを下げ、リファクタリング（のパターン）でコードを改善する方法を伝える効率が上がれば、もっと技術者としての良心に従ったプログラミングをする（誇りを取り戻す！）ことができるように思います。