connpass
http://connpass.com/event/2537/
Togetter
http://togetter.com/li/512794
以下の書籍をターゲットとした勉強会なのです。
 | レガシーコード改善ガイド (Object Oriented SELECTION) (2009/07/14) マイケル・C・フェザーズ 商品詳細を見る |
場所は #junitbook と同じく、横浜のタネマキさんです。
参加者は12名くらいでしょうか。
前回のJUnit写経会で告知されたこの勉強会ですが、個人的に、前々からこの本に興味はあったんですよね。
・・・が、中々読む機会がなく、今回ちょうど良い機会ということで、書籍を購入して参加することにしました。
今回は5～6章が範囲でした。
しかも、1～5章も事前に読んできなさい、と。。。
なかなか初回から読む量がハードでございました。
以下、個人メモ。
■第6章 時間がないのに変更しなければなりません
■レガシーコードの定義
・書籍には、テストが無いコード、という定義がある。
・テストがあっても、ウンコードならレガシーと言えるのでは。
・以下のサイトでうんこマークが10個ついてやつとかは、レガシーコード。
ウンコード・マニア
http://unkode-mania.net/
■言語特性
・この本で紹介されている手法って、言語によっては適用できないの、あるよね。
・でも、6章のラップとかスプラウトとかは手続き型でもいけるのでは。
■スレッドセーフのテスト
・非同期のメソッドとかだと状況が違ったりテストがダメになったりするよね。
・メソッドの入口からは分からなかったところで上手くいかないとか、けっこーある。
・スレッドセーフって、テストでどうやって担保するのかが難しい。
■サーブレットがインスタンス変数を共有する弊害
・サーブレットクラスの中でstatic使ってインスタンス生成して爆発。。。（これ以上はオフレコ）
・[参考]参考事例がないかググってみた。この辺の記事が参考になる？
マルチスレッドのいたずらに注意―あなたのJSPやServletは大丈夫？―
http://www.atmarkit.co.jp/ait/articles/0205/14/news002.html
①サーブレットはマルチスレッドで呼ばれる点に注意。つまりスレッドセーフな作りにしなければならない。
②サーブレットのクラスでは、staticフィールドもstaticでないフィールド（クラスのメンバー変数）も使ってはならない。
・静的解析ツールでマルチスレッドのスレッドセーフ性とかはチェックできるのでは。
・マルチスレッドは、優秀なエンジニアにしか書かせない、という手もある。
・マルチスレッドのテストは、再現性が無いので難しい。
・マルチスレッドは言語仕様上、まだ弱いとこなのでは。
■レガシーコードのきっかけ
・プログラムを急いで直して、奇跡的にデグレが生じない状態が続くと。。。
→ オブジェクト指向ではなく手続き型のような、コードが太った状態に次第になる。
→ そしてレガシーコードへ。。。
■引数に関するリファクタリングの失敗事例
・メソッドの引数が多すぎたので、引数をそのクラスのフィールドに移動させて、引数を渡さなくて済むようにした。
・いつの間にか、そのフィールドにアクセスする他のプログラムが存在していた。。。
・意図しないバグが起きた。。。
■トランザクション制御
・Javaだとフレームワークにトランザクション制御を任せていた。
・C#で、トランザクション制御をスクラッチでやっている人がいた。
・その人曰く、「フレームワークに任せると自分でコントロールできないのが怖い。自分でやればいいよね」
・でも、その人がいなくなると保守ができなくなるので、問題アリ。
・メモリが足りないとか制約があると、トランザクションを自分で制御したりすることはある。
■ラップの階層化
・ラップが複数階層になっていて、二分木のようになっていたことがあった。
・気にしなければ気にならない程度。
・でも、名前で苦労した。～Wrapperとかが連続して。。。
・なんとか動くけど、コードが読めない。。。
■ラップメソッドとラップクラス
・ラップメソッドの方が使う。ラップクラスはあんま使わない。
・ラップクラスじゃなく、デザインパターンの「アダプタパターン」といえばプロっぽい。
■レガシーコード改善ガイドの良いトコ
・レガシーコード改善ガイドの良いところは手札、引き出しが増えること。
・「名前」があること重要。
・（↑はSQLアンチパターンの著者の@t_wadaさんも以前おっしゃってましたね。共通の認識を持てる、ググれる等）
■レガシーコードを改善するか否かの判断
・2回以上使うなら、レガシーコードは改善すべきでは。
・でも移行プログラムとかは、そこにコストかけなくてもいいんじゃね？
・人がレガシーなのを変えるのは難しいので、先にレガシーコードを変えるべき。
・COBOLを悪く言う人がいるが、COBOLが悪いんじゃない！COBOLを使う人の思想がレガシーだったりするだけ。
・言語じゃなくて、書いたコードの善し悪しをきちんと見ないといけない。
・手続き型だと接合部が少ないが、慣れればできる。言語じゃない。
■ソースコードのコメント
・コードを書いた「意図」を、ヘッダコメントとかに書いておいたほうが良い。
・コーディング基準書が、コードの修正履歴をすべてコメントアウトで残せ、となっている。
→ コメントが大量になってコードの可読性が落ちる。。。
→ いまどき、変更履歴なんてバージョン管理システムで管理すべき。
・バージョン管理システムがいつでも使えると思わないほうがいい。客先常駐の環境で使えないことがあった。
→ 例えば客先で緊急対応する場合とかだと、コメントアウトが残っていたほうがいいことがある。
・ソースコードをGrepすると、コメントアウトの箇所とかも全部ひっかかってしまい、結局自分を苦しめる。。。
■差分コンパイル＆差し替えの弊害
・定数クラスを差分ビルドすると、定数の部分だけ変更前の値が生き残ることがある。
・なので、フルビルドすべき。
・（この辺の記事が参考になるかも↓）
定数フィールドへの参照はコンパイル時にバイナリに展開される
http://d.hatena.ne.jp/altcla/20091225/1261743137
■第7章 いつまで経っても変更作業が終わりません
■7.2節 遅延時間
・この節の「時間」の話に関連して、P.16に時間の話がある。
・P.16では、「実行に0.1秒もかかる単体テストは、遅い単体テストである」と言っている。
・更にP.16では、「データベースとやりとりするテストは、単体テストではない」とまで言っている。
■レガシーコードとレガシーエンジニア
・レガシーコードは所詮、生成物でしかない。
・なので、レガシーコードを作るレガシーエンジニアを変えないといけない。あと、文化も変えないと。
・でも、人を変えるのは難しい。
・ひとまずテスト文化は自衛に使える。なので自分だけでもやる。
・テストが自衛に使えることがわかると、他にも広まるかもしれない。
■その場で懇親会＆LTタイム
6章と7章のディスカッション後は、@toru_inoue さんによる「Unityとレガシーコード絡みのお悩み相談室」がありました。
@toru_inoue さんの悩みを皆で考え、ディスカッションする形式です。
なんとかお悩みが解決された（！？）ようで良かったです。
その後は、同じタネマキさんで引き続き懇親会です。
ピザが到着するまで、少し長めの休憩がありました。
休憩時間にテーブルみんなでジョジョを読んでいる異様な光景は、タネマキならではですな～
ピザと冷たい瓶ビール！レガシーコードについて語りながら、おいしく戴きました。
あと、懇親会で @skowata さんによるLTがありました。
Legacy code事件簿 from skowata
第一話で出てくるメインフレーム、ウチの会社も使ってますし、COBOLも現役バリバリなので共感ありますねー。
あとDBからデータを丸ごとファイルに履いて処理することも、よくやります。
この処理方式をそのままオープン系に持ってくると、けっこー性能問題に突き当たりますよね。
あと第二話に出てくる順序性の話も、「あるある」ですねー。
特にメインフレーム、独自の文字コードを採用してたりして、ソート順がオープン系環境と一致しなかったり。。。
第四話のDateクラス拡張ですが、日付が関わるテストはシナリオテストレベルになるとかなり難しいですよね。
システム日付を取得するAPIは、テストしやすいよう、プロパティファイルや環境変数に日付をセットしておけばそちらの日付を優先的に返す実装にしたりします。
そうしないと、日付を進めたり巻き戻したりするテストができないので。。。
LT、爆笑するというよりも「あるある」で共感しすぎて、皆様シンミリ（笑
とても勉強になるネタでした！
★感想：
いろんな話が出てきて、大変興味深く勉強になりました。
書籍から大きく脱線して話があちこち飛んだり膨らむことがありましたが、個人的には大歓迎です。
これこそ社外勉強会の醍醐味なところもあるわけで。
案外、そーやって逸れた箇所にこそ有意義なネタが転がっている気がします。
あと今回、１～７章と読む範囲が広かったので、深く読む時間が個人的に取れませんでした。
一通り読んではいますが、疑問点を調べたりとかできてないところもありますし、スルーで流してしまったところもあるので、もう一度読み直して、必要に応じて写経とかもしたいと思います。
次回はもうちょっと早く予習しよう。
主催者様、参加者のみなさん、ありがとうございましたー
