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