2013/6/22(土)「『レガシーコード改善ガイド』討論・品評会 #1 #lckaizen 」に参加してきました。
connpass
http://connpass.com/event/2537/Togetter
http://togetter.com/li/512794以下の書籍をターゲットとした勉強会なのです。
場所は #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がありました。
第一話で出てくるメインフレーム、ウチの会社も使ってますし、COBOLも現役バリバリなので共感ありますねー。
あとDBからデータを丸ごとファイルに履いて処理することも、よくやります。
この処理方式をそのままオープン系に持ってくると、けっこー性能問題に突き当たりますよね。
あと第二話に出てくる順序性の話も、「あるある」ですねー。
特にメインフレーム、独自の文字コードを採用してたりして、ソート順がオープン系環境と一致しなかったり。。。
第四話のDateクラス拡張ですが、日付が関わるテストはシナリオテストレベルになるとかなり難しいですよね。
システム日付を取得するAPIは、テストしやすいよう、プロパティファイルや環境変数に日付をセットしておけばそちらの日付を優先的に返す実装にしたりします。
そうしないと、日付を進めたり巻き戻したりするテストができないので。。。
LT、爆笑するというよりも「あるある」で共感しすぎて、皆様シンミリ（笑
とても勉強になるネタでした！
★感想：いろんな話が出てきて、大変興味深く勉強になりました。
書籍から大きく脱線して話があちこち飛んだり膨らむことがありましたが、個人的には大歓迎です。
これこそ社外勉強会の醍醐味なところもあるわけで。
案外、そーやって逸れた箇所にこそ有意義なネタが転がっている気がします。
あと今回、１～７章と読む範囲が広かったので、深く読む時間が個人的に取れませんでした。
一通り読んではいますが、疑問点を調べたりとかできてないところもありますし、スルーで流してしまったところもあるので、もう一度読み直して、必要に応じて写経とかもしたいと思います。
次回はもうちょっと早く予習しよう。
主催者様、参加者のみなさん、ありがとうございましたー
2013/6/20(木) 「JJUG Night Seminar ～ Java エンジニアのためのJava(再)入門 ～」に参加してきました。
こくちーず
http://kokucheese.com/event/index/96069/Togetter
http://togetter.com/li/521481場所は日本オラクルです。
参加者は100名以上だったようで超満席でした。Javaの人気も捨てたモンじゃない！
ちなみに5月にJJUGの大きなイベントがありまして、そちらにも参加してきました。
そんとき書いたブログはこちら。
今回のテーマも「Java再入門」とあり大変興味深く、参加することにしたのです。
日本オラクルに到着すると、この日の1F受付はOracleのJavaエバンジェリスト・寺田さんでした。
・・・受付からして豪勢であった。
以下、個人メモ。
■ 「JUnitを使ったJavaのテスト入門」(19:00～19:50)by 久保智氏
■JJUGの幹事をやっているとのこと。
■System.out.printlnでデバッグプリントする問題点
→ 記録・録画ができない。もう一度テストしたいとき、もう一回操作しないといけない。
■テストした内容を記録・再生するためにJUnitを使う。
■assertEqualsかassertThatか？
→ JUnit4使うなら、やっぱassertThatじゃね？
■７月に楽天でTDDBCがあるらしい。
■privateメソッドをテストするか？
・privateメソッドのテストについては何度も議論になってきた。
・この辺のサイトがツイートされていた。
①プライベートメソッドのユニットテストは書かないもの？
http://qa.atmarkit.co.jp/q/2784 ②privateメソッドのテストについて（Togetter）
http://togetter.com/li/361483・リフレクションを使えばテストできるが、メソッド名が変わればテストがコケる。
・privateメソッドをテストしたいようなら、privateメソッドが責務が持ちすぎ。
■ 「from old Java to modern Java ～職業プログラマに聞いて欲しいJava再入門」(20:00～21:00)by 谷本心氏
■日経ソフトウェアの記事執筆・７月号の特集記事が、今日の発表ネタ
・ちなみにmakopi23は、日経ソフトウェア、日経コンピュータ、日経Systemsの3誌を定期購読してます。
■定数クラス・J2SE 5.0から導入されたstatic importを使えば、定数クラス名を省略して記載できる。
・（会社のコードは古い方法で定数クラスを使ってるなぁ。static importを検討しよう。。。） by makopi23
・（JUnitを使う人は、static importはけっこー使いますねー） by makopi23
■OutOfMemoryError のハンドリング・Java SE 6からOutOfMemoryErrorの発生箇所がスタックトレースで明示されるようになった（らしい）
・この辺のサイトが参考になりそう。
Java SE 6 じゃじゃ馬ならし Heap http://www.javainthebox.net/laboratory/JavaSE6/heap/heap.html■Java SE 7のNIO2・Fileクラスのインスタンスをnewするんじゃなく、ファイルのpathを引数に渡して処理できるようになった。
→ コード量の大幅減
■Java SE 8・Functional Interface（実装すべきメソッドが１つだけのインターフェース）はlambdaに置き換えられる。
・イベントハンドラとか、メソッドが１つしかないやつはlambdaでどんどん書いていけるようになる。
■J2SE1.4からJava SE 7への作り変え・移行するより、全部作り変えたほうが良い。
・PreparedStatmentとかメジャーなAPIでも、仕様が変わっててコンパイルが通らなかったりする。
・そもそもAPIの戻り値が異なることがある。
・1.4から7への移行は止めたほうがいい。
・1.4から5へのジャンプはとても多い。まず、ジェネリクスの警告が大量に出るところにまず戸惑う。
・仕様が変わっているかどうかを一個ずつ変更を調べるのは現実的ではない。
・Swingの挙動が1.4と7で全く変わっていた、という事例がある。
・JUnitのテストで担保しきれないレベル。バグレベルのテストとかでは無理。
・ただ、Javaのバージョンあげると性能あがるし開発生産性も上がる。
★感想：JUnitの発表の方は、#junitbook の勉強会に参加してるので内容はほぼ理解できました。
Javaのバージョンアップに伴う変更について纏めていた後半のセッションは、目から鱗でしたねー
上手く纏まっていて大変参考になりました。
んで、このセッション聞きながら「あ、会社のあのコードのあそこ、直さなきゃ・・・」みたいのがチラホラと。。。
日経ソフトウェアの7月号も手元にあるので、さっき該当記事を読んでみた。良い復習になりました。
最近、ちょと積読になっているので、バックナンバー引っ張り出して、谷本さんの連載記事も読んでみようと思います。
最後に講師のお二方、スタッフさん、会場提供者様、ありがとうございましたー
2013/6/21(金) 「Scrum Boot Camp The Talk 春の増刊号」に参加してきました。
DoorKeeper
http://taoofscrum.doorkeeper.jp/events/4145場所はバンダイナムコ未来研究所です。
参加者は40人くらいでしょうか。
以下の書籍を題材にしたスクラム道のイベントなのです。
もちろん私も既読です。
この日は「No-Bull Know-How」という形式での進行でした。
参加者がスピーカーと一緒に壇上でディスカッションするセッションです。
「みのもんたの人生相談」をイメージするとわかりやすいとのことｗ by @nawoto
最初、壇上に上がろうとする参加者さんがぜんぜんいなかったんですが。。。。
さすがは西村さんでした。絶妙なトークと進行！
その後、壇上に相談に上がろうとする参加者が途絶えることはありませんでした。
この段取りと進行の上手さは見習うべきトコですね。
あと、今日はスクラム道のメンバーも多数参加されてました。いろんな意見が聞けてよかったです。
以下、個人メモ。
■ Q1. スプリントレトロスペクティブ（振り返り）の形骸化についてQ.スプリントレトロスペクティブ（振り返り）で、振り返りするネタが無くなって来たので止めたいと思っている。
理屈では振り返りは継続したほうが良いと思ってはいるのだが。
プロジェクト後期での、振り返りのオススメなやり方があれば教えて欲しい。
A.振り返りは自分達でしないといけない、ということを、プロジェクト後期までにチームメンバに理解してもらわないといけない。
振り返りって大事だよね、楽しいもんだよね、というのをまず理解してもらうのが大事。
改善アクションの効果が少ないのでやっても意味がない、という考えはいったん捨てる。
たまには「１００倍効率良くなる方法をブレストしようぜ」と言った感じに、ぶっ飛んだ発想を出させる。
美味しいお茶を飲みながら、１０分～１５分くらいの短い時間ででブレストをする。
そうすると「やめよう」とはなりにくい。
開発後期で忙しくて１０分～１５分の時間も取れないようでは、プロジェクト自体上手くいってない証拠。
振り返りが上手くいかない原因は、実は別のところにあるのでは。
まずは１０分、時間をとってみようよ。
■ Q2. スプリント期間内に作業が終わらない！ ～其の壱～Q.現場にScrumを導入しようとしている。
今問題となっているのは、１スプリント毎に見積もるけど、それがスプリント内で終わらないことが続いている。
それで、終わらないのが普通だよね、という感覚にチームがなってしまっている。どうすればいいか？
A. 「スプリント内に終わらすもんですよ！」と誰かが一度いってやる。
あと、計画を立てる能力が必要。その能力が養われてないなら、無理にやってもダメ。
まずは量を減らす。終わらすことが大事。
■ Q3. 設計書を作成するタスクの扱いQ.お客さんから「アジャイルで好きにやっていいよ」と言われている。
そこで、設計書いつ作るとか、どう決めればよいかわからない状況。
今は、イテレーションに「設計書を作る」というタスクを入れている。
他のプロジェクトってどうやってるのか知りたい。
A.Railsでやったらどうなるんだろうね、といった荒い設計は事前に実施している。
それでいけそうなら、スプリントを始めるようにしている。
■ Q4. 西村さんのお給料Q.西村さんの給料っていくらですか？
A.GREEさんの半分くらいちゃう？ｗ
■ Q5. 書籍の執筆についてQ.書籍の執筆はどのくらいしんどかったか？
A.これまでデスマーチを3回くらい経験したが、今回の執筆が一番しんどかった。
見積もりを間違えたのが原因。
Q.執筆で得られたものあるか？
A.Scrumのことがよくわかった。
章立てて書籍を書くことで、知識がかなり整理された。
普段考えないことまで考えた。
「相対見積もりなんて、なんでそもそもやるんだろ？」とか。
わかった気になってたのが整理された。
なので、本は書いた方がいい。
アジャイルサムライの著者のジョナサンが来日したときも「本は書いた方がいい」と言っていた。
自分の勉強のためにも書いた方がいい。
ちなみにジョナサンは、出版社さえ決まっていないのにアジャイルサムライを書き始めた。
書いてから出版社に持っていこう、ということで二年間書いていたらしい。
■ Q6. 書籍の執筆陣で意見が分かれた点についてQ.１年前くらいに、吉羽さんが講師のScrum Boot Camp Premiumに参加した。
そのときに吉羽さんがおっしゃっていたことと、書籍に書いてあることが違っている箇所があった。
Scrumを理解している人達の間でも、主張が違うことがある。
今回書籍を書いてて、ケンカとかなったことはあったか？
例えば、プロダクトオーナーとスクラムマスターは分けろ、と明確に主張している人もいる。
でも、書籍だとそこまで強く書いていなかった。
A.一番揉めたのが「完了の定義」。
@ryuzeeはスパッと行くタイプ。POが役目を全うできないならクビだ、という主張。
逆に、日本社会はそんなのは無理、という意見もあった。
その場合は、開発チーム側でどこまでできるかやってみて、纏めたものをPOと調整して完了の定義を決める。
■ Q7. デイリースクラムの形骸化Q.デイリースクラムでチームメンバーから「何も問題はありません」という報告が散見される。
それで「じゃ、コレはどうやるの？」とその人に聞くと、問い詰める感じになってしまった。
上手く気付きを導く工夫ってあるか？
A.観察はする。チームで気づいてもらわないと意味がない。
振り返りにもってくなり、「こんなことあったんじゃないの？」と軽く聞くようにすると良いのでは。
あとは、状況を見えるようにしておいてあげる。自分で気づくようにしてあげる。
例えば、各タスクにかかった時間をメンバに書かせてみる。
困ってることを言葉にするのは難しいので、気づけるようにしてあげる。
言ってあげるのも大事だが、毎日「どう？」と聞くのはダメ。
例えば、聞く曜日を決めておくとか。
■ Q8. スプリント期間内に作業が終わらない！ ～其の弐～Q.スプリント内に終わることが大事、と先程あった。
このことをメンバーに意識してもらう、気づいてもらうにはどうすればいいか？
A.まず最初、きちんと説明してあげないといけない。
「スプリント内に終わることが目指さないといけないこと」ということ。
目的と理由をちゃんと伝える。それでメンバに「なるほどねー」と納得してもらう。
言葉だけだとダメなので、そのあともケアしてあげる必要がある。
■ Q9. プロダクトオーナーが捌き切れない問題Q.「部長 - PM - 開発メンバ」という体制が長いこと続いていた。
その後、プロデューサという役ができた。
Scrumチームが５つくらいあって、一人のプロデューサがPOとして全部を見る。
でも、プロデューサがPOとして捌ききれなくなった。
チーム１つにPO１人が良いのは分かっているが、会社の都合上できない。
どうすればいいか？
A.POが問題をかかえている、ということが分かった。
なら、スクラムマスターは助けるのが役目。スクラムマスターがPOを助ける。
スクラムマスターって聞くと仰々しいが、大した奴じゃなくていい。下っ端でいい。
例えば、ジャンケンで負けた人がスクラムマスターをやるとか。
それで「だいじょうぶですか」と声かけるようにする。
今の状況を聞く限りだと、POを支援する人がどうしても必要になる。
ただ、POを手伝いにいくメンバーは、スクラムチームと分けたほうが良い。
■ Q10. 人事／人材についてQ.
そもそも「部長-課長-係長」って役職、いらないんじゃね？
他のプロジェクトってどうされてるのかなぁ。
A.
Scrumチームが人事まで踏み込むのは大変。
海外でもそこまで踏み込めているのは少ない。
プロジェクトを回せる状態を作って、そこで初めて「ウチの会社ってどういう人材が必要だろう？」とかステップを考えていく。
■ Q11. 西村さんを会社にお呼びしたい！Q.IPAが先日出した「アジャイル型開発におけるプラクティス活用 リファレンスガイド」を読むと、アジャイルコーチを呼ぼう、と書いてある。
http://www.ipa.go.jp/sec/reports/20130319.html西村さんは呼べば現場に講演に来てくれますか？
A.ビール一杯で行きます（笑
これ、けっこーあちこちで言っているんですが、行きますｗ
■ Q12. モチベーションが上がらないメンバへの対処Q.アジャイルなプロジェクトに参加したことがない。
書籍を読む限りだと、上手くチームで進んでいるように見える。
もし、モチベーションが上がらない人がチームいたら、どういうアプローチしたらいいか？
A.実は最初、書籍で題材としているチームに「慎重派君」を入れようとしていた。
いわゆるアジャイルに慎重派なメンバーとして。（実際は入れなかったが
チームメンバーには、小さい成功体験を積ますのが良い。
誰でも、知らないことには不安になるもの。
全員に話をきくこと。何か仕事で困ってることない？と聞いてみる。
それで、みんなから聞いてみた結果を踏まえて、みんなに関係がありそうなものから始めてみる。
そんな感じでちょっとずつやっていく。
誰が成果を出すかと言えば、現場。
自分が「よし、やるぞ！」と思えるよう練習したりとか。
不安なところはコミュニティで相談したりとか。
みんなが「おもしろい！」と感じ始めたら、その後のスピードは早い。
なので、ちょっとずつでいいからやってみること。
■ Q13. １スプリントの期間についてQ.Scrumをやり始めた。
スプリント期間を決めようと思って、ノリで決めてしまった。。。
実際、どうやって決めればよいか？
A1.まず２週間でやってみる。なぜ２週間かと言うと、１週間だと息切れするから。
１週間だと金曜が忙しくなる。心理的負担が大きい。
まず２週間でやってみて、そこから状況に応じて変える。短くしたり長くしたり。
A2.まず１週間から始める。
というのも、期間が短いプロジェクトだと、スプリントの期間が長いほどフィードバックの回数が少なくなるから。
あと、スプリントの切れ目も金曜ではなく、火曜とかにする。
そこはケースバイケース。
A3.スプリントの切れ目を１日にする。
スプリント最後のスプリントレトロスペクティブと、次のスプリントのスプリント計画ミーティングを同じ日にやる。
それぞれスプリント期間の2.5%の時間をかければよいという決まりだけなので、別の日にやる必要はない。
前のスプリントの振り返りと次のイテレーションの決め事を１日でやると、あと４日が丸々使える。
A4.まず１週間でやってみる。
それでチームに「しんどいか、しんどくないか」を聞いてみる。
大抵、１週間でやってみると終わらない。
しんどいのは嫌い。慣れる、とか無理しない、とかが好き。
■Q14. 新人のチームへの入り方Q.新卒でプログラミングが未経験。
どういうふうにチームに入っていけばよいか？
A1.まず技術力をあげるのが先。
やり方はチームの雰囲気があるので、そこに合わせていく。
新人に限らず、そこのチームの価値観とかクセとか習慣とかをまず知るのがよい。
やること／やらないことの基準とかを知ること。
あとはプロジェクト計画書とかをまず読む。
A2.自分が「わからない」ということをどんどんアピールする。
そうするとメンバと話す機会が増える。みんなとしゃべること大事。
新人の特権は知らないこと。
知って馴染んでしまうと、逆にできなくなることがある。
「わからない」というよりは、「疑問に思ったこと」を片っ端から突く。
A3.スクラムマスターは生意気な新人にやらせるのがいい。
生意気なことを言える人。
間違っていることはきちんと間違っている、と臆せず言える人。
■Q15. 新人が見積りをやるには
Q.新人だが、見積りってどうやればよいか？
A.見積もりは、新人には無理。
作業がイメージできないうちは、予想じゃなくて妄想。
まず技術力を付ける事。
まず自分の１日の作業の見積りからやってみるといいんじゃないか。
■Q16. 残業についてQ.Scrumだと、チームの残業が無いと期待している。
でも、書籍だとチームが夜遅くまで残業しているシーンが出てくる。
残業は是なのか？
A.残業は普通にある。
ただ、定時で帰れるようにしていかないとうまく行かない。なので残業無しは目指すところ。
無理のないペースじゃないと、継続できない。
書籍に出てくるチームも、最初からうまくできるわけがない。なので残業は発生する。
でも彼らは自分達の判断ミスによって時間内に出来なかったところに対し、残業をしている。
本当はリスクを前倒しで検討しておけば平和で過ごせたはず。でも、それができなかった。
残業は現実として発生する。
■ Q17. バッグログの見積りし直すタイミングQ.バックログの見積もりをし直すタイミングをどうすれば良いか？
自分のチームのタイミングは、書籍と違った。
A.違和感を感じたらいつでも見直してください。
見積もりは予想。最新な方が嬉しい。いつでもアップデートしたほうがいい。
いつでも、が見つけられない段階は、スプリントの中で見積りを直す時間をとる。
見直す必要がない、とわかったら、すぐに解散で作業に戻る。
まずはスプリントで１回。次は１週間で１回を目指す。次は任意のタイミングで見直す。
良いと思ったチームでは、デイリースクラムが終わったあと、「見積もりする？しない？」を会話してたチーム。
まずはスプリントで１回やってみるのが良いのでは。
■ Q18. XPとScrumの関係Q.XPとScrumの関係について教えて欲しい。
A1.XPとScrumは補完関係にある。
Scrumは技術的なことはあんまり書いていない。そこにXPがカチッとハマる。
Scrumだけやっても失敗する。これだけやればいい、というのはない。
きちんとアーキテクチャを設計したりとかもしないといけないので、いろんなことをして必要なエッセンスは取り入れる。
A2.XPもScrumも一緒。誤差の範囲。
ちなみに「アジャイルサムライ」はXPの本。
XPもScrumも目指すことは一緒で、アプローチが違うだけ。入り口が違うだけ。
ジョナサンがアジャイルサムライでこんなことを言っている。
「人によって好きなアイスクリームの味は違う。XPとかScrumはフレーバの違いでしかない」
やりたいことは取り入れてみる。ダメなら捨てちゃえばいい。
大事なのは考え続けること。
■ Q19. 大規模でScrumをうまくやる方法Q.スクラムチームメンバーからスクラムマスターに立場が変わり、更に、会社でScrumを推進する立場になった。
組織的にScrumを導入しようとしているが、ぜんぜんうまくいかなかった。
Scrumを大規模にしたときに、バランスをとることが目的になってしまい、うまくいかなかった。
Scrum of Scrumという言葉もあるが、大規模でScrumをうまくやる方法あるか？
A1.最初に30人でScrumをやってから、あとで30人を追加で入れてもうまくいかない。
追加で入った30人には、最初の30人にしたのとと同じように、まず引き上げることが大事。教育とか。
A2.規模が大きくてうまくいかなかった時は、チームを分けた。
サイズを小さくしてやる。どうやればチームを小さくできるかを考える必要がある。
A3.気を付けてるのは、小さな成功体型。
大きなプロジェクトだと、大きな成果をを求められる。それがプレッシャーになる。
なので、問題をちょっと小さくしてあげる。
どんだけデカいものに当たっても、目の前にあるものが小さいものになるようにする。
いっぱい人がいる、じゃなくて、小集団で考える。
1人の人として動けているか、をちゃんと見る。
まずは、小さくすること。
■ Q20. お金や契約の話Q.本にお金の話が出てこない。
契約に絡んでる人たちって、どういう知恵があるか？
期間内に出来ないからといって要件をどんどん切り捨てるとかしてたら、お客さんの信頼を無くすのでは。
A.契約面は今までと何も変わらない。
無理に案件を受けないこと。作業する人が自分でちゃんと見積もること。ジャッジはちゃんとすること。
案件を受ける／受けないは会社の判断。
リスクがある案件を取るなら、会社のサポートも必要。
お金を気にする層って今も昔も変わってない。お金を気にするのは営業とかマネージや組織の長のみ。
チームはそこは意識しない。
開発側が単価とか時間を気にしなくていいよう、逃げ道を用意する。
「お金のことは上の立場のと交渉して」と逃がしてあげる。
契約の時も、エンジニアの単価とかまで開発チームが気にしなくていいようにすべき。
■ Q21. Scrumの導入Q.Scrumをやりたいと思っている。
でも今は、業務委託で常駐形式でウォーターフォール。
なので、出来るところから取り入れていこう、とやっている。
アジャイルのキーワードを使わずに、デイリースクラムとかをチームでやってきた。
でもそこから先、開発プロセスのハードルが大きくて、できない。
具体的にScrumに近づけていくのにどうすればいいか。
A.まず二人を目指す。
二人いるとディスカッションができて、解ける問題が増えてくる。
自分達のチームをアジャイルで回すことを最初にやった。
あと、成果を見せる場をどっかにねじ込む。
上はモノを見ると、口を出したくなる。
んで、そこで出た要望に対して「はい、喜んで！」と言う。
バックログを作って、そこに入れて管理する。
これ、テクニック！
全員で「はい、よろこんで！」と言うと、上は任せてくれるようになる。
それで、他から「上手くやってるようだけど、それってなんなん？」と聞かれたら「アジャイルでやってるんです」と言う。
チームでうまくいってるなら、宣伝しまくる。それで、「聞かせてよ」となるようにする。
自分がやってみせて、真似したいな、と思わせる。
★感想：実際の現場での悩みや対処方法といった、生々しい話が直に聞けて大変勉強になりました。
イベントが終わった後の西村さんのツイート。
まさにその通りでした。
あと、職場に配属されたばかりの新人さんが3人くらい壇上に上がって質問していたのが、凄いなーと思いました。
私、新人の頃なんて勉強会の存在すら知らなかった。。。
あとバンダイナムコさん、自宅から自転車で行ける距離なんで、この日は自転車で行きました。
電車賃もかからないし、助かるわー。
品川シーサイドの楽天さんとか日立ソリューションズさんとかバンダイナムコさんでやってもらえるとお財布にも優しいです。
スクラム道のスタッフさん、登壇してくださった参加者さん、会場提供のバンダイナムコさん、ありがとうございましたー
2013/6/15(土) 「Scrum Boot Camp in NII」に参加してきました。
DoorKeeper
http://taoofscrum.doorkeeper.jp/events/4229場所は神保町の国立情報学研究所です。
参加者は２５人くらいかな。
私、アジャイルのお勉強会はこれまでもけっこー参加してきましたが、Scrum Boot Campは今回が初めてです。
一日みっちり、スクラムを楽しくお勉強できるということで、とても楽しみでした。
メイン講師は高江洲さん、サブ講師は今給黎さんと関さん。
こちらもお馴染みです。
この日の時間割ですが、Scrumを体系的に学べる講義と、学んだ知識を元に実践するワークショップを交互にやる感じです。
■座学編by 高江洲さん
Agile、Scrumについて体系的に学ぶことができる座学編です。
以下、気になった所、なるほど～と思った所、スライドに無く口頭説明のみだった所を中心に、個人メモ。
■サイロ型な組織「組織間の情報共有や風通しが悪く、組織運営が非効率な様」を言う言葉らしい。初めて知った。
■成功体験 ・「今までうまくやってきたんだから、わざわざ変える必要ないっしょ？」
・本当か？
数十年前の仕事のやり方がいいか、というと疑問が残る。
・それで成功していると思ってやっているが、実はそれって、成功していないんじゃないか？
■短絡的に考えない・その選択肢が取れなくなった場合のことも考える。
・先送りにした問題はそのままになりがち。
・あとでソースコードを綺麗にしようとしても、その時間はぜったいにやってこない。■ボーイスカウトを見習おう！・通称「ボブおじさん」（ロバート・C・マーチン）の言葉らしい。
・The Boy Scout Rule ：
http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule・「来たときよりも綺麗にして帰る」ということ。良い言葉だなぁ・・・
・ソースコードを綺麗に保て、ということに繋がる。
■問題にはみんなで向き合おう！・犯人探しは不毛
・「人 VS 人」じゃない。向きを変える。「問題 VS 私たち」として考える。
■アジャイルソフトウェア開発宣言・17人のうち、Scrumを提唱しているのはKen Schwaber氏とJeff Sutherland氏の2人。
・「ボブおじさん」こと、Robert C. Martin氏も17人の中に入っている。
・17人の中にいるJames Grenning氏は、先日のAgile Japan 2013で来日した。先日、組み込みの書籍の和訳が出た。
■12の原則(4)「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」・組織パターンの「信頼で結ばれた共同体」に該当する。
・原著はJames O. Coplien氏。和智さんが翻訳中。
・いくつかあるパターンの中で「信頼で結ばれた共同体」はMUSTのパターン。入り口。
・高江洲さんも査読を担当しているとのこと。
■12の原則(10)「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」・XPの「YAGNI」。
・この前、初めてYAGNIという言葉を知ったが、ここでも出てきた。「You ain't gonna need it.」
・機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則。
■Do Agile？ Be Agile？・「Agile」って形容詞なんだぜｗｗｗ
・「何々やってたらAgileなんだぜ」ってことは言えない。
・「美しい」と同じ形容詞。「する」のではない。
・DoじゃなくてBe。
・態度からアジャイルになっていきましょう。
・形容詞は度合いが測れる。どのくらい「美しい」とか。
・「～やっているからAgile」じゃない。
・「アジャイル開発の経験３年以上」という人材募集を見ると、アジャイルがわかっていないな、と思う。
・「プラクティスをやってる」じゃない。態度のお話。
・ぶっちゃけていうと、ウォーターフォールでもアジャイルに開発することはできる。
・「アジャイル開発、無理っすわー」じゃない。「する」んじゃなくて、なればいい。
・ひとり、ふたり、と仲間を増やして、組織としてアジャイルになっていけば理想。
・するんじゃなくて、なろうぜ。DoじゃなくてBe。
■Scrumの特徴・軽量
・理解が用意
・習得は非常に困難 （ちなみにScrum Alianceによると、Scrumの理解が低いワースト３に日本が入っているらしい）
■3本柱・透明性 ・・・ 関係者全員が共通理解を持つ
・検査 ・・・ 障害の検知。ゴールに向かっているか
・適応 ・・・ プロセスを調整
後者２つを纏めて
Inspect and Adapt と表現していた。
■優先度と優先順位・「優先度」と「優先順位」は違う！
・「優先度」は高・中・低。優先度付してもらうと大抵、全部が「高」になる。
・「優先順位付け」は、
一列に並んでいる状態にすること。
■サーバントリーダーシップ・この前ググったが、ここでもこの単語が出てきた。もう一度ググってみる↓
---
・「リーダーである人は、まず相手に奉仕し、その後相手を導くものである」というリーダーシップ哲学。
・サーバントリーダーは、奉仕や支援を通じて周囲から信頼を得て、主体的に協力してもらえる状況を作り出す。
・
http://www.servantleader.jp/about_servant.html■プロダクトバックログ・あとでいいなー、というユーザーストーリーは、優先順位さえまだ付けないでおく。
・さらに、まだざっくりレベルに留めておく。
・最低限必要な分だけ落とし込んで、きっちりと並べる。
■タスクボード・付箋の剥がし方で下から捲るのはNG。以下２つのどちらかがお勧め。
①横向きに剥がす
②下に引っ張る
■「完了」の定義・完了の定義は更新されることもある。（厳しめの方向のみ）
・最低限守れそうなものから始めて、広げていくのが良い。
■妨害リスト・（個人的に、これはいいなぁ、と思いました。）
・非公式だがよく知られたもの
・空調が効きすぎるのでなんとかしたい、コードが邪魔、椅子が動きすぎる、etcを挙げておく。
・スクラムマスターが管理、優先順位の高い障害から取り除く。
■Scrumで定義されたイベントの特徴・定義化されていないミーティングの必要性を最小化する。
・逆に、Scrumに書かれているものは必ずやる。書かれていないのは必要ならやる。■スプリント計画ミーティング第一部・スプリントの
2.5%の時間をかけてもよい。40hだと1h。
（2.5%って具体的な数値が決まってるのかぁ。知らなかった。目安になりそうですねぇ）
・見積もりは、基準値を決め、整数で考える。迷ったら大きい方を取る。
・1,2,3,5,8,13の6つのポイントを使う（フィボナッチ数列）。これはトランプで代用できる。
・プランニングポーカーで、全員が提示した数値が隣り合う数字だったら、大きい方に寄せて完了。（同じ数字になるまでやらなくてもいいらしい。初めて知った）
・１回目で全員が同じ数値を出した場合、根拠を話し合う。なぜなら、それぞれが提示した根拠が
被ってなかった場合、そこが考慮漏れになってる可能性があり、そのぶん見積りが増えることがあるので。
・カードじゃなくてもよい。紙一枚を用意して、全員が指を指すことで代用できる。
■KPT・Tryは挙げすぎても現実的じゃないので、できるもの優先で。ただ、最初はあんまり気にせず挙げてよい。
・Problemは、それを解決するためのTryを考えて入れる。Tryに挙げた項目は次のスプリントで実践する。
■ワークショップ編by 今給黎さん、関さん
ワークショップはチームで行います。私のチームは4名でした。
ちなみに、昼食もチームで外食に行きました。これもとても楽しかったですねー。
チームメンバーからいろんなお話が聞けて、これぞ社外勉強会の醍醐味です。
---
話は戻って、最初のワークショップはペーパープロトタイプの作成です。
これ、POStudyでも以前テーマになってましたね。私も参加してやったことあります。
私は復習ということで、今回も楽しく紙工作しました。
幼稚園児の頃は紙工作が大好きで、よく先生から褒められました。懐かしくもあります。
以下はP.21の「一括選択」のペーパープロトタイプ。クリアファイルを使うトコがミソです。
次は、「しりとりマンダラート」というのを使ってWebサービスの題材をチームで考えます。
P.26の用紙に書いていくんですが、このプラクティス、初めて知りました。
予想外にいろんなアイデアが出てきて、こんな手法があるのかぁ、なるほどなぁ～、と感心したり。
そのあと、各自で出したアイデアをチームで議論し、そこから１つを選択。
んで選択したそのWebサービスをペーパープロトタイプで開発します。もちろんScrumで。
このワークショップ、面白いですねぇ。みんなでワイワイガヤガヤ。
PO役にヒヤリングしてバックログ書いたり、先にやったペーパープロトの知識を応用してモノづくりしてみたり。
最後に、Scrumで開発したペーパープロトのシステムを使って、各チームでプレゼンします。
ちなみに参加者全員で採点も行うのですが、ウチのチームは同率で一位でした！
ウチのチームの模造紙＆ホワイトボードはこんなカンジ。良いチームだった！
★感想：とても有意義な１日でした！
Scrumを体系的に学べましたし、ワークショップでワイワイやって、とても収穫の多いイベントでした。
エンジニアなら是非、一度は参加したほうが良いと思います。オススメ！
純粋に、楽しいってのが素晴らしいですね。しかもこれで参加費たった３００円とかｗ
個人的には、Scrumの曖昧だった知識を補うことができたのが良かったです。感謝！
最後に講師の皆様、スタッフ様、チームメイトさん、参加者のみなさん、ありがとうございました～
2013/6/13(木) SQLアンチパターン読書会 「キーレスエントリー」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/4356以下の書籍をターゲットとした読書会なのです。
場所は御徒町（湯島）の株式会社アルティネットさんです。
参加者は8人かな。
和田さん、今回も参加で頼もしい限りです。
ちなみに今回のアジェンダ当番は私でした。なので、簡単なスライドを事前に作成し、当日簡単に説明しましたー
以下、個人メモ。
■遅延制約チェック（スライドP.16）・全部を参照整合チェックでやろうというのは性能上悪くなる危険性がある。
・それを防ぐために、遅延制約を使うことでコミット時まで制約チェックを遅らせる判断はありえる。
・ただ、やりすぎは危険。
・遅延制約は「ANSI SQL-92規格」で入ってきている。
■実際のプロジェクト現場における外部キー制約・外部キー制約を付けたプロジェクトを見たことがあるか？という参加者への質問に対し、約半数が「No」。。。
・外部キー制約を付けない1理由：「既存システムが参照制約を張ってないいから、張らないまま今まで来た」
■外部キー制約を付ける/付けないの判断・外部キー制約を使用しない理由は無い。ツッコミどころが無い。
・パフォーマンスの制約がでるまで、外部キー制約を使わないのはもったいない。
・ハイトランザクションになったら、参照性よりパフォーマンスが大事、ということもありえる。
→ その時になってはじめて外部キー制約を外す、という判断を下すのが良い。
■既存DBへの外部キー制約の追加・まずデータクレンジングをしましょう。
・DBに同じデータが2行あるなら、片方が重複ミスのはず。それは人間しか判断できない。
・そういう重複データを消してからでないと、外部キー制約は追加できない。
・そういう手作業をやりたくないから、外部キー制約を使うのである。
・舌打ちしながらデータ直した経験がある人なら外部キー制約は追加すべき。
■外部キーを付けない理由(1) 親データが無くなるかもしれない
→ でもそれは、モデリングとして「親がいなくてはいけない」としたのがそもそも強すぎる。
(2) テストデータ入れるのがめんどくさい
・これが一番多いかもしれない
(3) 業務フロー上、子テーブル側からデータが先に入る仕様になっている
・業務仕様上、詳細データから先にDBに入って、次に親伝票がDBに入るフローなどが該当する。
(4) 超高トラフィック
・パフォーマンスを重視して外部キー制約を外す判断はアリ。でも最初から外すべきではない。
(5) フレームワークがサポートしていない
・Railsとかはデフォルトで外部キーを無視するらしい。
(6) シャーディングしている
・テーブルを分割してると参照整合性制約を付加できない。
（必然的に、どこの領域にデータが入っているかわからないないので、参照整合性の付けようがない）
・その場合はアプリケーション側で参照整合性を担保する。
・シャーディングについては書籍のP.97に言及がある。
■外部キー制約のバージョン管理・ソースはバージョン管理システムで管理することが一般的だが、外部キー制約は管理しないことが多い。
・23章にバージョン管理の話がある。
・開発時にはDB定義の変更とかも生じる。例えばテーブルが増えたり、分かれたりとか。
・そこで、DB定義をスクリプトにして、DB定義も含めてバージョン管理システムの管理下に入れましょう、というのがベストプラクティス。
■DBのマイグレーションDBのマイグレーションをサポートするツールが増えてきている。
(1) Liquibase
・
http://www.liquibase.org/(2) Flyway : The agile database migration framework for Java
・
http://flywaydb.org/ ・flywayは時間的に進む方向しか管理できず、ダウンは無い（らしい）。
(3) Jiemamy
・
http://jiemamy.org/display/PORTAL/Home ・以前、データベースリファクタリング読書会で紹介された。
(4) Railsの「マイグレーション（migrations）」
・直接SQLを使わずに、データベースのテーブルやカラムなどの構造を変更できる仕組みらしい。
・Railsはデフォルトで外部キーを無視する（らしい）。
・外部キー制約補助のためのGem「foreigner」というものがあるらしい。
・フレームワークに選択の余地を持たせている。
■DDLの生成DDLを生成する手段としては大きく３パターンある。
(1) モデリングツールから生成
・ER/StudioなどでER図を作成し、そこかからDDLを生成させる。
(2) Excelツールから生成
・Excelでテーブル情報を書いておき、VBAマクロでDDLを生成させる。
(3) DSLから生成
・Railsとかはこの仕組みらしい。
・テーブル定義をDB非依存で略式機構で書く。(P.258のコラム参照）
・Railsプログラマは、カラムにアクセスするgetter/setterは使わないらしい。自動的にできるそうな。
■ORM（O/Rマッパ）・Hibernateとかはモデル主導らしい。DDLも生成できる。
・DRY（Don't Repeat Yourself）の起点になる。
・既存のDBからリバースエンジニアリングでクラスを作れる。
・Eclipseプラグイン「ERMaster」を使うと、ER図を書いたりクラス生成とかができる。
http://ermaster.sourceforge.net/index_ja.html・EXCEL → XML → JAXBという流れもある。ExcelでDB定義書いて、XMLに情報を履いて、Javaクラスを生成する。
■フィクスチャ(fixture)・「フィクスチャ (fixture)」とは、データベースに入れるデータをシリアライズして格納したファイル群のことらしい。
・Railsだと、事前に用意したテストデータを読み込み、常にDBの内容を一定に保つための仕組みのことを、フィクスチャと呼ぶらしい。
・結果取得の遅延ができるらしい。行為が行われないと決まらない、というのを定義できるとか。
■外部キー制約の一時的な無効化・ALTER TABLE DISABLE CONSTRANT
・外部キー制約を強制せず、外部キー制約の存在を明確にするためのコマンドらしい。（制約の無効化）
・書籍「データベースリファクタリング」のP.203に書いてある。
・セッションレベルで制約をオフにする。
・テストデータをDBに投入するときに一時的に外部キー制約を無効化したいときに使える。
■原則「迷ったら、寿命の長い方に寄せろ」・アプリケーションコードよりデータベースの寿命の方が長い。データは移行しながらずっと使うので。
・更に、データベースよりデータの寿命の方が長い。
・なので、変なデータがDBにいったん入ってしまったら、その後、何十年も苦しむことになる。
・設計に迷う場合は、寿命の長い方にとって良い設計となるように寄せるべき。
■カスケード更新・カスケード更新はあんまり使わないかも。
・4.5.1節でaccount_id列にON UPDATE CASCADEを定義しているが、そもそも主キーの付け替えなんてやらない。
・Bugsテーブルのstatus列にもON UPDATE CASCADEを定義しているが、これは10章のサーティーワンフレーバーなので、データは付け替えない。
・逆に、アプリの方はカスケード更新はよくある。すべてのO/Rマッパはカスケード削除はある。
・カスケード削除だと、ログには発行した１クエリしか残らない。なのでログから追えない。
（裏で子テーブルの削除が行われるが、この削除クエリはログには出ない）
■リレーションの種類・リレーションには3種類ある。
①依存リレーション
②非依存リレーション
③多対多リレーション
・ORマッパは依存・非依存・多対多の設定が大事。設定することで、DDLをほとんど手で書かなくても済む。
■既存DBへの外部キー制約の追加・既存DBにも頑張って外部キー制約を付けたほうが良い。
・ゴミデータが既存DBにないならば、外部キー制約の追加はそんなに大変ではない。
・「DBに変なデータが入ってしまったのでDBから削除します」となると、お客様への説明責任のコストがかかる。
・そうなるくらいなら、外部キー制約は張っておくべき。
・外部キー制約が無いDBが、顧客システムでなく社内システム場合は、「あえて追加しない」とい選択肢もアリ。
・DBをリファクタリングするかどうかは業務システムの特性による。
■新規DBへの外部キー制約の設定・新規システムの場合は、外部キー制約は最初から付けておくべき。これは間違いなく言える。
・ハイトラフィックでシャーディングとかやらざるを得ない場合は、ノーガード戦法（外部キー制約を外す）でいくしかない。
ちなみにこの日の模造紙＆付箋はこんなカンジ。
★感想：キーレスエントリーは私にとって、非常に身近で興味深いテーマでした。
というのも、私の会社ではモデリングにER/Studioを、DBMSにHiRDBを使うことが多いのですが、ER/StudioからDDLを生成する際、DBMSとしてHiRDBを選択していると生成DDLに外部キー制約が付かないのです。。。
問い合せてみるとこれは仕様だそうで、手動で付けて対応しているとのこと。
これもマイナーなDBMSの定めか。。。orz
あと、やはり私も、テストデータの投入で困ったことはありますね。
順序性を考慮するのって、テストが複雑になるほど大変なわけで。
この日出てきた、外部キー制約の無効化、今度使ってみることにしよう。
あと、Railsの機構にも興味が出ました。
和田さんがいろいろ紹介してくださったんですが、私、Rails触ったことないので。。。
どっかで勉強してみたい。
最後に参加者の皆様、ありがとうございましたー
2013/6/11(火) 「オブジェクト指向でコードが書けるようになろう。」に参加してきました。
DoorKeeper
http://devlove.doorkeeper.jp/events/4060場所は新橋のリクルート メディアテクノロジーラボさんです。
参加者は50人くらいでしょうか。
主催はDevlove＆CodeIQさんで、講師は増田さん。そして今回のテーマは以下だそうです。
今回のDevLOVEは、CodeIQさんの協力を得て、オブジェクト指向設計をテーマに開催します。
具体的な問題に対して、オブジェクト指向ではどのように考えるのか、トライしてみましょう。むむむ、いかにも楽しそう！
というわけで速攻で申し込んだら、いつの間にかTOPになっていた件。。。
ちなみに私、CodeIQ（コードアイキュー）というサイト、今回始めて知りました。
https://codeiq.jp/「自分の実力を知りたいITエンジニア向けの、実務スキル評価サービス」らしいです。
いろんな問題が公開されてて、それにチャレンジできるようになっており、出題者からフィードバックも受けれる仕組みだそうな。
エンジニアなら、腕試しにちょっと挑戦したくなっちゃいますね！
というわけで私も事前課題にチャレンジしようとしたら、その前日に回答期限が締め切られていた。。。
んで再掲載されないかなぁと思ってツイートしたら、@papanda さんが救済してくださいました！感謝！
というわけで、今回の出題を事前に解いてみてから当日参加しました。
■ちゃんとオブジェクト指向ができるようになるために -解説編-当日は参加者３～５人でグループを作り、出題内容を各自で考えてみた後、各グループでディスカッションを行いました。
んで、増田さんからオブジェクト指向設計に関するレクチャーと、CodeIQでの解答例の紹介などが行われました。
以下、メモ。
■出題１
あるWebサービスの会員登録の画面で、以下の入力が必要です。
・氏名
・メールアドレス
・パスワード
・パスワード（確認用）
入力は、以下のルールを満たす必要があります。
・氏名は２０文字以内
・メールアドレスは、正しい形式
・パスワードは、半角英数字で、大文字・小文字・数字の三つが混在
・パスワードと確認用パスワードが一致する
この入力チェックを実現するためのクラスを考えてください。
※ 一つの問に複数のクラス名を解答してもかまいません。
※ 同じクラス名を複数の問に重複して回答してかまいません。 |
私の解答と、グループメンバーの解答はこんなカンジ。
| 私の解答
| グループメンバの解答 | 備考 |
(1)
入力情報を保持するクラス名
| MemberRegistForm | ①MemberRegist
②Member
③InputData
┣ Name
┣ Password
・・・ | 私の解答は、画面毎に
【画面名+Form】というクラス名とする案。
③は構造体みたいなデータ構造とする案で、氏名やパスワードも子としてクラスにし、親のInputDataに持たせる階層構造としている。 |
(2)
氏名の２０文字以内をチェックするクラス名
| NameFormatChecker | ①NameLengthCheck
②Name | 私の解答は、【チェック対象+Checker】というクラス名にする案。②は、ドメイン駆動設計（DDD）を意識したもの。NameクラスやPasswrdクラスに、データとチェックメソッドの両方を持たせる。 |
(3)
パスワードをチェックするクラス名 | PasswordFormatChecker | ①PasswordFormatCheck
②Password |
(4)
パスワードと確認用パスワードの一致をチェックするクラス名 | PasswordEqualityChecker | ・PasswordDoubleCheck
・Password |
(5)
クラス名の数は全部でいくつ？ | 5 | | (1)～(4) ＋ ※ = 5 |
※
(1)～(4)の回答に登場しないクラスの名前も | MemberRegistFormChecker | | 画面毎にチェッカークラスを用意し、データ項目ごとのチェッカーを呼び出す指針。 |
ウチのグループは大きく２パターンに分かれました。
■パターン１・画面データ保持用のクラスを１つ作り、各データ項目はフィールドで持たせる。
・各データ項目用にチェッカークラスを作成する。
■パターン２・画面の各データ項目をそれぞれクラスとする。（氏名ならNameクラス、パスワードならPasswordクラス等）
・各データ項目のクラスに、データフィールドとチェックメソッドの両方を保持させる。
---
私はパターン１で設計しました。
パターン２は、ドメイン駆動設計を意識してますねー。
かくいう私も、パターン２も検討しました。
んでもDDD本、まだ途中までしか読んでないので、俺にはまだ早すぎる！ということで見送った。
あと(1)の③は、checkメソッドだけ持つInterfaceを１つ用意し、Nameクラスとかは全部このInterfaceを実装（implements）する設計だそうな。
他に出た意見としては、コンストラクタの引数で氏名やメールアドレスが渡されたときに、コンストラクタの時点でチェックを行う、という案がありました。
チェックで不備があったデータは、そもそもインスタンスやフィールドとして存在させない、というポリシーですね。
各グループの発表を聞く限りでも、概ね上記２パターンに分かれたグループが多かったようです。
他には以下のような案が出ました。
■複数種類のユーザの存在を考慮した設計・「User」というクラスに、フィールドとしてname（氏名）とかpassword（パスワード）を持たせる
・ユーザクラスとしては管理者権限（AdminUserクラス）とか一般権限（CommonUser）とか何種類か考えられるので、「BaseUser」という基底クラスを用意し、継承させる仕組みにする。
■データ保持とチェッカを分離した設計ユーザ情報を保持するクラスと、チェックを行うクラスに分ける。（パターン１とほぼ同じ）
■ストラテジーパターンを利用した設計妥当性を評価するポリシークラスを作って、ストラテジーパターンで依存性を注入する。
| クラス名（人数）
| 増田さんのコメント
|
(1)
メインクラス名 | ・User (21)
・Member (13)
・Input (13)
・Account (5)
・Regist (5)
・Signup
・その他 (26) | ・Inputというクラス名だと、何の入力か区別できない
・Registという単語は和製英語。本来は末尾に "er" が必要。
でも通じるなら使ってもいいんじゃないか |
(2)
検証クラス名 | ・xxxValidator (21)
・CheckxXxx (15)
・xxxChecker (9)
・その他 (24)
・なし (17) | 「その他」は、アノテーションでチェックする、という解答もあった。
個人的な感覚だと、「Validator」は技術用語になっているので、「Checker」のほうがお客さんに伝わるかな。
なので「validator」よりは「checker」に軍配をあげたい。 |
(3)
データクラス名 | ・なし (26)
・xxxInfo (20)
・xxxForm (13)
・xxxData (7) | なくても通じるなら短めでもいい。 |
■増田さんのフィードバック■今回の出題・設計の基本をテーマにしようとした。
・でも、テーマを失敗したかもしれない。。。入力のバリデーションに特化してしまったので。
・もっと一般的なネタがよかったかも。
・今回の問題は「他の人が今後メンテしていくこと考えた設計になっているか」を評価基準にした。
・出題どおりに設計して、「完了しました」と言っているようではダメ。もっと上を目指すべき。
・出題の文面から、「もっとこーゆうのがあるよね」とツッコミを入れられる技術者になるべき。
■
皆さんの解答例今回は、以下のようなカンジに回答が分かれたらしい。
① データを持たせるUserクラスがいて、それをチェックするUserValidatorというクラスが１ついるパターン
② データを持たせるMemberクラスがいて、チェック用のクラスとしてCheckNameとかCheckPasswordとかを個別に用意するパターン
③ Nameクラスとかを個別に作り、Nameのバリデーションまでそこに持たせるパターン
・他にも、以下のような解答例があった。
④ クラス数が6以上の案を回答した人も20名くらいいた。彼らはバリデーションの仕組みを自作していたのが多かった。
⑤ アノテーションを使ったバリデーションを徹底してる回答者もいた。
---
■増田さんのコメント・何が正しくて、何が間違っている、ということはない。ニーズによって変わる。
・自分がメンテナンス技術者だったら、「どの設計がいいか」という意見はあるはず。
→ 設計の良い/悪いより、他の技術者がメンテしやすいかを考える。
・ソフトウェアを成長させていくときに、どういう設計になっていがほうが他の人が理解しやすいか、３年後の自分が理解できるかを考える。
・創造力の勝負
■増田さんのオブジェクト指向設計・クラスは小さくしたほうがよいと個人的に思っている
・設計にこだわってみたい、とかの気づきが大事。
・ペアモデリングとかペア設計もガンガンやるべき。
・雑談レベルでいいので、同僚に「俺はこう考えたんだけど、どうよ？」って話してみるのがいい。
・「設計はかくあるべき」というのは無いと思っている。ただ、ある文脈の中で仕事しているので、設計にこだわりもある。
・例えば、「オブジェクトの役割は小さくする」というこだわり。
・後々、メンテナンス性とか保守性とか、変更が入った時の強さを考慮すると、単一責任は常に意識したいと思っている。
・「データ＋ロジック （オブジェクトの凝集性）」というのを、保守性を高めていく道としてこだわり続けていくのが良いのでは。
・ちなみに、「～Validator」とか「～Caliculatro」というクラス名は、増田さんのプロジェクトでは却下している。
→ 「～Validator」とかを許容してしまうと、考えずにそうしてしまうことが多くなるので。
・マーチン・ファウラーとケントベックの著書「リファクタリング」の最後の方に、「 大きな分離」という項がある
→ 手続き的な設計からオブジェクト指向らしい設計へ地道にリファクタリングしてきました、と書いてある。
・増田さんは、コテコテのケントベック派。鵜呑みにしている。
→ でも、それが正しい設計だと言うつもりはない。
・こだわってるのは、変更したときにたくさんいじらなくてよい、保守しやすい、ということ。
・どこに何が書いてあるかがすぐわかる設計が良い。
あとスライドには出題２に対する紹介と説明もありました。スライド公開が待たれる。。。
■質疑応答
■Q1.引っかかるのは「オブジェクト指向らしい設計とは」ということ。
今回の解答例で、「名前」とかをオブジェクトとして捉える、という考え方に引っかかっている。
というのも、現実世界の写像をオブジェクトとして捉えるべき、とこれまで習ってきた。
「名前」ってのは現実世界のオブジェクトではないはず。
なのでこれまでは、「名前」しか扱わない場合でも、「会員」というオブジェクトの属性として「名前」を扱え、と設計してきた。
「名前」でクラスすると、それだけで一人歩きする。
「会員」というオブジェクトの属性に「名前」を持つのがオブジェクト指向設計だと私はそう思っていた。
これについてどう思うか？
■A1.たしかにオブジェクトは「現実正解の写像」と言っていた時代があった。
でも、それはすごく嫌。
人間の頭の中の概念は、オブジェクトの候補になると考えている。
用語はルールを持っている。ルールの書き場所としてクラスを宣言してしまえという考えに立つ。
ただ、「名前」をクラスにすることががオブジェクト指向である、ということにこだわりはない。
どういう持たせ方をすべきか、にこだわりがある。
例えば今回の出題にあった「パスワード」なら、「パスワード強度」というクラスを抜き出すかもしれない。
「パスワード強度」というのは現実世界にモノとして存在しない。
でも、ルールとかポリシーの変更があるから、クラスとして抜きだしたい。
ビジネスとかルールの制約を書き込むのがクラスだと思っている。
集約の粒度を下げようとはおもっていない
メソッドに分ける感覚でオブジェクトを分けちゃう。
---
■Q2.データとロジックを１つに纏める、という設計で疑問がある。
複合データチェックはどのクラスに置くべきか？
■A2.一緒にあったほうが自然なら、一つのクラスに纏める。
データの発生のタイミングとか変更のタイミングが同じものはまとめたい。
タイミングが違うなら違うクラスにしたい。
例えば、「メールアドレス」と「パスワード」の変更のタイミングは違う。
一緒なのは最初の登録のタイミングだけ。なので、クラスは分けたい。
---
■Q3.クラスとかメソッドの名前を付けるときに、ロジックを作り込む以上に時間がかかる。
名前付けに悩むぐらいなら、一個のクラスに突っ込んでしまえ、とやってしまう。。。
増田さんは名前付けに一貫性を持たせてやってらっしゃるとおもっているが、プロジェクトごとにポリシーを分けたりしているのか？
■A4.名前は辛いよね。。。
８～９割は、こんなかんじかな、でいけちゃう。でも、残りの１割は悩む。
良いクラス名が思いつかないクラスは、メソッドが増えて肥大化してくるのが実態。
そのクラスはお客様のキーポイントになっているので、「楽しいリファクタリングの時間」として対処する。
幸いお客様と継続でやっているので、「いい名前わかった！」と後でなったらリファクタリングをしている。
---
■Q5.オブジェクト指向でプログラムを作ると、性能が気になることがある。
そこの折り合いはどうつけてるか？
■A5.最近思うのは、「良い時代になったなぁ」ということ。CPUもメモリも安くなった。
最近は性能を考えなくても痛い目をみることは少なくなった。
今は、早い段階で実データ規模を投入して実行してみて、ボトルネックを見つけてそこだけ手を入れるようにしている。
カットオーバー直前に性能をみるんじゃなくて、早めに見ることが大事。
ただ、個人的にはそんなにハイトランザクションのアプリにはぶちあたってない。
１０年前だと、「このオブジェクト指向設計でやると動かない！」とかあったはず。
でも、Javaの出た直後と今では、Javaの性能は全く違うものになっている。
---
■最後に増田さんから一言・今回CodeIQに提出された解答を採点してて、すごく勉強になった。
・他の人の意見を聞くことは大事。自分のスキルを上げる機会だと思う。
★感想：事前に出題に取り組んで、事前に提出して、事前に採点してもらい、解説を聞きに当日勉強会に参加する。
この流れは他の勉強会と違って斬新ですねー。素晴らしい企画だと思います。
自分でまず考える、という過程が入ることによって、理解度も格段に上がるのがデカいです。
他のエンジニアさんの解答例を紹介してもらえるのも良いですねー。
当日はディスカッションで他のエンジニアの考えを直接聞くこともできましたし。
大変勉強になりました。
こーゆうの、これからもやってほしいなぁ。
あと、けっこーDDD的な設計を意識している人が多かった気がします。
これはDDD本を読み進めざるを得ないッ！と思うヒトトキでした。
当日のスライドは後で公開してくださるとのことで、楽しみに待っていよう。
最後に講師の増田さん、papandaさん始めスタッフさん、CodeIQさん、ありがとうございました。
2013/6/8(土) 「DDD本 読書会(羊) #0」に参加してきました。
connpass
http://connpass.com/event/2445/以下の書籍をターゲットとした読書会なのです。
場所は鶴見区の矢向地区センター（Ｃ会議室）です。
自宅からだとDoor To Doorで30分くらい。近いのが良いですね。
参加者は9人かな。そのうち8人が顔見知りです。
というのも元々、身内でDDD本の読書会をやろうっ、って流れだったのです。
んでも、新規で1名応募があって良かったと思います。新しい風が入るの、重要。
ちなみに、私がDDDに最初に興味を持ったのは、「実践テスト駆動開発」という書籍を読んでいたときでした。
通称、GOOS本。
このGOOS本の読書会がグロースエクスパートナーズ株式会社さんであったのですが、訳者の和智さんも参加されてました。
和智さんはDDD本の訳者でもあるのですが、「DDD本の知識はGOOS本の前提になっている」とのこと。
あと参加者さんも「DDD本読んでるよ」ってことだったので、これは是非読まねば、と思ったのがキッカケ。
そんときのブログはこちら。
更にGOOS本の読書会の約2週後に開催された「java-ja.ddd」というイベントが、DDDに対する興味に火を付けたッ！
GOOS本の読書会のあとにすぐDDD本を買って読んでたんですが、この日の講演は私にとってすごく刺激的でした。
おまけに、和智さんにDDD本の見開きにサインを戴いた！
んでも本の分厚さから、独りで読み進めるのはなかなかツライ。。。
ってなことを @naopi さんや @grimrose さんと話してたら、@naopi さんが読書会を企画するとのこと！
「おおおお！」ってなカンジでこの日を迎えました。
ちなみに「アジャイルサムライ」のP.229にも「DDD本は必読」としっかり書いてありますね。
そういう意味でも横浜道場の門下生は読まざるを得ないっ！
■アジェンダ by @naopi さん
@naopi さんがアジェンダのスライドを作ってきてくださいました。感謝！
今回は「まえがき」から読み始め、「輪読＋ディスカッション」を繰り返す横浜道場方式で進めました。
以下、個人メモ。
---
■ドメインとは・書籍にいきなり「ドメイン」って出てくるけど、ドメインってなに？どっかに定義書いてあったっけ？
・P.xivの真ん中あたりに「複雑なのはドメインそのもの、すなわち、ユーザの活動やビジネスなのである」と書いてある。
・でも、「ドメイン ＝ ユーザの活動やビジネス」という定義ではあまり使われていないっぽくね？
・P.519の用語解説には、ドメインの定義として「知識、影響、または活動の領域」と書かれている。
・ここでは開発者とユーザが共有すべき「共通概念」といったカンジかなぁ。
■DDDの本質を説明するには・困るのは、DDDをエラいさんに説明したときに、「業務知識って重要だよね」という一言で終わること。
・P.xvに、「開発がイテレーティブである」ことが前提条件とされている。
→ 「イテレーティブ」がすっ飛ばされて「ドメイン大事」とかいわれても、それは間違い。
■ドメインエキスパートとは・ドメインエキスパートは、モデルまで一人で作れなくても良いのでは。
→ 開発者とユーザが密接に関わりながらモデルを作ることができれば良い。
・原著では、ドメインエキスパートは複数形で書かれている。
→ ドメインエキスパートはその業務の専門知識をもつ人。複数の場合も有り得る。
■ドメインモデル・開発者とユーザの共通言語である。
■モデルと曖昧さ・アジャイルプロセス協議会では、「曖昧さを極限まで無くせ」と提唱している（らしい）。
・「抽象化」が間違った方向にいくと「曖昧性」に向かう。
・本来の抽象化は、「余分なものを削ぎ落とした核の部分を作る」こと。
■DDDはウォーターフォールで出来るか？・書籍には「開発がイテレーティブである」ことが前提条件、と書かれている。
・ウォーターフォールだと、上流工程でモデルを作りきってしまう。修正できるか？
・「リファクタリング」でモデルを修正すれば良いが、「リファクタリング ＝ 手戻り」となると最悪よね。
・モデリング・設計・実装が分断されないほうが良い、と書籍にはある。
→ 分割発注の場合とかどうすんのやろ。。。
・ウォーターフォールの弊害についてはP.14に書いてある。
■ドメイン駆動チーム（P.xix）・開発者はドメインエキスパートといつでも会話できる状態にないといけない。
■現場で、モデルを作っていますか？・ER図は作っている。
・絵レベルで作成、お客さんに説明する。UMLとか厳密な書き方はしない。
・絵で書いたモデルは、その場限りで廃棄するものも出てくる。
---
最後に振り返りでKPT書いて、終了となりました。
そのあとは近場で飲み会。お酒とお好み焼き、みんなで美味しくいただきました～
★感想：今回は「まえがき」で終わってしまい1章に入れずじまいでしたが、いろいろ議論出来たので良かったと思います。
ただこの本の分厚さからすると輪読方式だと難しいかもね、って話は、その後の飲み会でも出ました。
JUnit写経会のように、事前に対象範囲を読んでくる方式にして、当日は黙読程度にとどめてディスカッションをメインにしたほうがいいのかもしれない。
いずれにせよ、この本を最後まで読みきりたい。
んで、読むだけじゃなくディスカッションで理解を深めたいし、写経とかもやりたいなぁと思ってます。
主催の @naopi さん、参加者の皆さん、ありがとうございましたー
おまけ
DDD Tシャツを着て参加された @aeg さん！
やべぇ、欲しい。。。
2013/6/7(金) AEP読書会 第二章「なぜ計画作りに失敗するのか」に参加してきました。
DoorKeeper
http://aepreading.doorkeeper.jp/events/3690以下の書籍をターゲットとした読書会なのです。
場所はアジャイルサムライ横浜道場と同じく、アットウェアさんです。
参加者は8名かな。ディスカッションに最適な人数です。
前回（第一章）のブログはコチラ。
もう二ヶ月近く前なのか。月日が経つのは早い。
ちなみに今回も、最初からピザとビールを飲み食いしながらの進行です。
注文＆買出し、ありがとうございますッ！
発表は前回と同じく @takaesu0 さんです。毎度準備ありがとうございます。
資料はAEP読書会のFacebookに公開されています。（上のは表紙の一部）
https://www.facebook.com/groups/aep.reading.tokyo/以下、個人メモ。
---
■ストーリーポイント vs 理想時間・著者のMike Cohnは、最近はストーリーポイントを使わず、理想時間で見積りをやっているらしい。
■"Plan Outcomes, Not Actions" 「成果を計画せよ、作業を計画するな」・WBSは作業じゃない！ by @haradakiro
・世界的な定義じゃない。
・wikipediaの説明を見ても一目瞭然。
http://ja.wikipedia.org/wiki/Work_Breakdown_Structure■計画作りが失敗する５つの理由「2.マルチタスク化が遅れを助長する」・Rubyだと、シングルコアでもマルチスレッドにした方が速いことがあるらしい。
→ I/O待ちが解消されるため。（Rubyに限らないかもしれない）
・クラークとウィールライトの研究のグラフ（書籍の図2.2）を見ると、同時に担当するタスクの数が１でも、タスクにかける時間の割合が70%までしか上がらない。
→ つまり、シングルタスクでも30%分は、他が原因で作業が止まることを表している。
・P.42「作業をグループではなく個人に割り当てたらより深刻な状況になる」
→ 作業は個人でなはくグループに割り当てるべき。
①グループなら、融通が利く。
②得意な人に作業を依頼できる。
③今のリソースでやろうとするすると無理なことがある。
■計画作りが失敗する５つの理由「3.優先順位の順にフィーチャを開発していない」・書籍「実践反復型ソフトウェア開発」では、期間を固定する「タイムボックス」に対して、開発する機能の数を固定するアプローチを「フィーチャーボックス」と言っている。
→ このアプローチはダメ（へっぽこ）だと言っている。
・その製品のその機能が必要で使う人にとっては、その機能は100%必要なものとなる。
→ 「だから作れ」と上層から言われることが、組み込み開発の場合だとあった。いかにも日本的。
■計画作りが失敗する５つの理由「4.不確実性を無視している」・「設計漏れ」と「要求分析漏れ」を切り分けないといけない。
→ 開発が上手くいかなかった場合に、一律「設計漏れ」とする風習がある。
■計画作りが失敗する５つの理由「5.見積りがコミットメントになっている」・６月から８月の間に出来ます、と言った場合、それは確率論になる。
→ ６月だと何％、８月だと何％の可能性で完成している、みたいな。
→ でも、結局はパーキンソンの法則で８月完成になるのでは。
■バッファの扱い・CCPMでは「バッファは隠すべきではない」というスタンス。
・スクエニでは、バッファをエンジニアに見せている。
・バッファはタスク全体に積む。タスク１つ１つに積むべきはない。
・バッファを積むのではなく、あえて短めの期間を割り当てることがある。
→ 長くとると、早く終わっても期間ちょうどで終わっても、「終わった」とひとくくりに纏められる。
→ そうなると、正しく評価できなくなる。
■見積りとコミットメント・見積もりは確率。
・コミットメントは確率ではない。
・自社で開発するスケジュールと、お客さんへのコミットメントが同一視されているのが問題。
・未来予測のスケジュールがコミットメントになるのが可笑しな話。
・そうは言っても、受託だとお客さんと契約を結ぶから、見積りとコミットメントを切り離すのは難しい。
・ベンダもユーザも、両方ともムリだとわかっていても、監査が通らないので非現実的な契約をすることがある。
・デルファイ法が発展してプランニングポーカーになった。
■2章まとめ「話し合ってみよう」■1. ユーザに提供するフィーチャではなく作業を基準に計画を立てると、どんな問題が発生するだろうか？・完了定義が難しくなる。
・タスクに落としちゃうと部分最適になっちゃう。
- フィーチャを実現する手段はいろいろある。なので「どうすれば実現できるんだろう」という方向に向く。
- でも、それを作業にすると、単に「もっと手を動かせよ」という方向に向いてしまう。
・何をするかじゃなくて、何が欲しいのか、に注力するのがいい。
・最後はタスクに落ちるが、それを落とすのは極力遅らせるのが良い、とスクラムではしている。
・フィーチャは「What」で、作業は「How」。
・タスクへは作業者が落とせばよい。PMが決めることではない。
・なぜみんなフィーチャでやらないのか、というと、「タスクのほうが上司への説明がしやすいから」
→ タスク完了は「完了報告書のハンコ」で済む。フィーチャの完了定義は難しい。
・そのような組織を変えるのもスクラムマスターの役割である。
・会議は、責任の所在を曖昧にするためのもの。
・作業に落とすと工夫しなくなる。
■2.あなたの周囲では見積りとコミットメントは同じだろうか？
その場合にはどんな問題が起きているだろうか？どうすればこの誤解を解けるだろうか？・見積りがコミットメントになる例として「引っ越し」の例が出た。
- 引越し業者が見積りに来て、「半日で終わる」と回答した。
- 実際に引越しが完了するまでに丸1日かかった。
→ 依頼者は半日で終わることがコミットメントだと思ってしまう。追加料金を要求されても逆に怒る。
・SIの世界では、コミットメントがあって逆線表的に見積もりをつくることがある。
「納期」が確定していて、それに間に合うようにスケジュールを作る場合、見積りはコミットメントかも。
■3.あなたのプロジェクトでマルチタスク化はどんな影響を及ぼしているだろうか？
どうすればマルチタスク化による悪影響を軽減できるだろうか？・自分が抱えている作業を明示する。そうしないと次から次へと作業が上から降ってくる。
・WIP(Work In Progress)で、同時実行数を制御する。
→ 完了しないタスクはいったんフリーズさせて、新しいタスクを振るようにしている。
・タスクボードのDoingの欄を細くして、物理的にDoingになるタスクが制限されるようにしている。
・逆に、マルチタスクで良いこともあった。
- プログラミングとかで良い方法が思いつかず悩みまくってハマッた際に、別のタスクへ作業を切り替えた。
- その後、またプログラミングに作業を戻した際に、良い解決方法がパッと気付くことができた。
→ 別のタスクをやることで頭をいったんリフレッシュしたほうが、閃くことが何回かあった。
★感想：19時半から開始だったが、あっという間に22時になった感じ。
人数的にも内容的にも、ディスカッションには最適な状況だったと思います。
んでも私、ビールを１リットル飲んでて少し酔っ払ってたぞ！
見積り、難しいですよね。。。
自分の数日分の作業を見積もるのも困難なのに、プロジェクト全体の見積りとなると、もう。。。orz
あと、小さく区切って見積もってイテレーティブに進める方法って、これまでの人生で自然と身に付いちゃってると感じています。
趣味のプログラミング然り。受験勉強然り。などなど。
自分の生活の範囲内ではWFでなくアジャイルな見積りで日々生きてる人のほうが多いのでは。
あとスケジュール作ると、それが確定情報として一人歩きするのが問題なんですよね。。。
と、参加者もいろいろ思うところがあったようで、話が脱線しつつも熱いディスカッションになりました。
勉強会のディスカッションって、脱線もある意味、醍醐味なんですよねぇ。むしろそっちのほうが意義があったり。
発表担当の @takaesu0 さん、会場提供の道場主さん、皆様、ありがとうございましたー
2013/6/5(水) 「Tech Guild - Non Designers Design -」に参加してきました。
DoorKeeper
http://devlove.doorkeeper.jp/events/4059Togetter
http://togetter.com/li/514036まえだかずひこさんがP4D デザイナー向けプログラム部で発表された「ノンデザイナーズデザインブックを読み解く」を、今回Devloveで再演いただく、というデザイン系の勉強会です。
やっぱデザイナーじゃなくても、綺麗なWebアプリの画面を自分で設計できるようになりたいし、日々作成する資料とかも綺麗に作りたいですよね。
そんなわけで、デザインの才能がない１エンジニアがデザインを学ぶべく、参加することにしたのであった。
■講演以下、個人メモ。
---
■DungeonCrawl・最近、DungeonCrawlというのをやっている。
・「死んで覚える本当のGitの使い方」
http://d.hatena.ne.jp/mizchi/20120730/1343654602■デザインをどう学んだか・就職後、仕事の幅を広げるために書籍とかで独学した。
・「ノンデザイナーズデザインブック」に出会って、デザイナーになろう思った。
・今日はこの本の前半について話す。
■４つの基本原則・近接 ： 関連する項目をまとめてグループ化すること。基本的な目的は組織化。
・整列 ： ページ上のすべてのものを意識的に配置すること。こちらも目的は組織化。
・反復 ： デザイン上の何かの特徴を、作品全体を通して繰り返すこと。目的は組織化の強化。
・コントラスト ： はっきりした違いを出すことで情報の組織化を支援する。目的は組織化の強化。
■ゲシュタルト原理・人間は各パーツをバラバラに理解するのではなく、ひとまとめにして理解している。
→ 「近接」は重要な要素。
■人間の特性・無意識にグループ化する。
・パターンを自動的に見つけ出そうとする。
・物体を４個までは一瞬で把握できる。（サビタイジング）
・縦線横線がないと目が泳ぐ。（文章をセンタリングしたりすると）
■基本原則その２「整列」の重要性・対象の「あらまし」をつかむのは、中心視野より周辺視野の役目
■基本原則その３「反復」の重要性・直前まで注意を向けていた物体や場所には「注意を向けにくい」
・例：探し物をしてて、机を一度探したら、机には注意が行かなくなる
■基本原則その４「コントラスト」・コントラストだけだと楽天みたいなページになってしまうので。。。
・注意の瞬き・・・何かを認識すると、0.5秒間他のことを認識できなくなる
・楽天メソッドだと、目立つものばっかになる。
→ 目立つものが少ない方が本来目立たせたいところに意識が行く。
・WordPressの「集中執筆モード」
→ タイトルと投稿欄だけになる。（余計なものが排除されて、執筆に集中できるようになる）
■デザインするときどこから手をつけるか・ワイヤーフレームから作る
・ブロック毎にちょっとずつ変化を足したり引いたりする
■グループダイアログ(対話)ウチのグループは６人くらいでした。みなさんエンジニアばっかりです。
以下、グループダイアログで出た意見。
---
■３年前に「「ノンデザイナーズデザインブック」を読んでみたが、デザインのスキルは上がっていない。
→ デザインの理論がわかっても、手を動かさないと身に付かない。
■プログラマをやってると、カラーコードを揃えたくなる。
→ 紙に書くとそれを意識しなくて済む。
■デザインするとき、黄金比とかを意識してやってみたことがある。
・きれいに見える比率は 1対1.6 とか。巻貝のようなカンジ。
以下、他のグループで出た意見。
---
■４原則でどれが一番イケてるか。
→ 「整列」がかなりイケてる、という結論になった。
■酷いデザインは気付いて直せたとして、「これは良いな」という評価基準はどうしてるか？
というのも、見栄えが良くてもアクセシビリティ的に良くないとか、評価基準はいくつかありそう。
・「視線誘導」を意識している。
・
ページをぱっと見たとき、目に入って読んだときに、重要なところがぱっとわかって、重要なことが伝わるのが良い。・細かい子とにひっぱられすぎるのは良くない。
・おしっこ行きたい状態で見てもらって、伝わるかどうか。■お客さんから「良いカンジで作ってくれ」と曖昧に言われた時にどうするか？
→ 「何がしたいか」を考えてデザインするようにしている。
・お客さんはあんまり考えずに言ってくる。なので、こちらから参考にサイトをいくつか提示したりする。
■フラットデザインに最適な日本語フォントはあるか？
→ 無いです！
■そのページを見る人の気持ちになってデザインする。
★感想：「おしっこ行きたい状態で見てもらって、伝わるかどうか」という表現、良いですね～。
インセプションデッキでいう「エレベーターピッチ」に近い気がしました。
デザインのノウハウや考え方は、エンジニアの仕事にも活かせるのが多いなぁ、と感じた。
あと、デザインがテーマだったからか、女性の参加者が多いように感じました。
分野によってこんなにも男女比が違うのか。。。
デザインの基本４原則、ちょと意識して使ってみよう。
KDDIウェブコミュニケーションズの雲野コアたん、オラクルのワンちゃんの絵、可愛かったなぁ。。。はぁ。
講師のまえだかずひこさん、Devloveのスタッフさん、会場提供の日本オラクルさん、ありがとうございましたー
2013/6/1(土) 『JUnit実践入門』写経・実践会 in 横浜 #7 に参加してきました。
connpass
http://connpass.com/event/2248/Togegger
http://togetter.com/li/511975以下の書籍をターゲットとした写経会なのです。
場所はいつもの横浜、タネマキさんです。
参加者は12人くらい？でしょうか。顔見知りばかりです。
今回は以下の章がターゲットでした。
・第14章 コードカバレッジ -テスト網羅率の測定 -
・第15章 継続的テスト -すばやいフィードバックを手に入れる -
つーか、この日は6/1。もう夏なんですねー。月日が経つのは早いもんだ。。。
以下、個人メモ。
■第14章 コードカバレッジ -テスト網羅率の測定 -■カバレージの数字は一人歩きする → 目標に対して低い or 高いとか、判断の基準を示さないといけない。
■カバレッジだけで評価する弊害カバレッジだけで評価するのはダメ。
というのは、カバレッジは満たしていても、以下のような場合があるためである。
・アサーションが無い
・アサーションが正しいのかを検証していない
→ カバレージの数字とは別として管理する必要がある。
■アサーションフリー問題・JUnitはアサーションない場合にテストしても、グリーン（成功）になる。
→ その仕様ってどうやねん！
■カバレッジを測定する目的・カバレッジを上げるため疎結合な設計しましょう、とか、設計改善が起こればいい。
・カバレッジを上げるのが目標となるのは本末転倒。コードの改悪とかが始まる。
■djUnit・djUnitなるものを使うと、privateメソッドまでテストできるらしい。
http://works.dgic.co.jp/djwiki/Viewpage.do?pid=@646A556E6974&qword=@646A556E697420446F776E6C6F6164・ちなみにIntelliJ IDEAは標準でカバレッジツールが付いているらしい。
■リスト14.2 「再現困難な例外処理」・文字コードを引数に指定するメソッドを作成し、try-catchの部分を抜き出せばテストは可能。
・だがそれに見合う効果は無い。
■第15章 継続的テスト -すばやいフィードバックを手に入れる -■リスト15.4 「surefireプラグインのカテゴリ化テストの設定この写経で少しハマッたので、質問してみました。
上記のコードで、Eclipseのコード補完を使うと＜exclude
dGroups＞になるのです。
ちなみに書籍の方は＜excludeGroupds＞です。
書籍の方にしないと、以下のようなエラーになってしまいます。（つまりEclipseの補完の方だとダメ）
XMLの冒頭で宣言しているスキーマがなんか違うんだろうか。
この件で質問してみたら、せとあずささんが以下のツイートをしてくださいました。
どうやら既知らしい。あざっす！
■MavenとGradle・maven
- カスタマイズが厳しい
- Javaで書かないといけない
・Gradle
- GroovyでJavaよりも短く書ける
■XML(Ant/Maven)とDSL(Gradle)・XMLは分岐とか繰り返しが書けない。
→ 連番のファイルとか作ったりとか、繰り返しを表現するのにXMLだと厳しい。
・Gradleだと、XMLでなくDSLで書けるのがデカい。
・Maven + カスタマイズ = Gradle
■Mavenのパッケージ管理で起きた弊害例・Mavenのpom.xmlで、最新のライブラリを取得してくるよう設定していた。
→ エンジニアによって、ライブラリのバージョンがバラバラになってしまった。。。
・回避策として、中間サーバをたてて、そこにバージョンを固定したライブラリを置いておき、そこから取得する設定に変えた。
⇒ 結論： バージョンは固定で指定しておくべき。（最新のを取得する、という設定にはしない方が良い）
■バージョン管理システムのフック機能（P.305）の弊害例・Jenkinsは社内ネットワーク内に構築し、Subversionをグローバルネットワークに構築した。
⇒ JenkinsからSubversionにはアクセスできるけど、SubversionからJenkinsにはファイアウォール等の制御がかかりアクセスできない、ということがあった。
→ フックで困った。設定追加が必要。
■Jenkinsのジョブ定義画面のシェル定義・Jenkinsのジョブ定義画面にシェルを書けるとこがあるが、なんでもできちゃう。
→ あんまりやらないほうがよい
・Jenkinsにやらせるべきなのかどうかを考える必要がある。
・Windows環境だと、バッチコマンドに空行をいれないと制御が途中で切れちゃうことがある。
■割窓理論（P.307コラム）・割窓理論は最近、否定的な意見があるらしい。
・つまり、統制が無い状態を放置しようが改善しようが、統計的な有意差が出ない、ということらしい。
・でもソフトウェア開発の分野では、割窓理論は確かにあてはまる。
・ユニットテストの効果をみんなが共有できている状態にあるなら、自発的に赤を放置しないようになる。
■TDDの自殺・「TDDの自殺」という話題が出た。@kyon_mm 氏のブログ。
・
http://d.hatena.ne.jp/kyon_mm/20121223/1358326642・テストがまったく無いよりはマシでしょ、という意見もある。
■Hudson・Hudson（Jenkinsの前身）はまだ別で生きているらしい。
・
http://hudson-ci.org/■Windows + Git + Jenkins・Windows + Git + Jenkinsという組み合わせだと大変らしい。
・fingerprintをとっておかないと固まるらしい。。。
■Ant1.9・3月にAnt1.9が出て、かなり良くなっているらしい。
・標準出力がきちんと絞られて出るようになった。
14章、15章のディスカッションの次は、LTタイム。
■LT1 「PyCon APAC 2013」の告知by @ryu22e 氏
Pythonのカンファレンスで、今年は日本だけでなくアジアまで対象を広げているそうです。
開催日はXP祭りと同日かあ。
---
■LT2 「俺の爺(Jenkins)がこんなにかわいいわけがない」by @sue445 氏
この日のスライドは、上記から更に修正が入っている模様。Jenkinsを使った考察がもりだくさんです。
Beer Pluginにフイたw
これは和むかもしれないっ！
---
この後は18時くらいまで各自もくもくタイムです。
@sue445 氏を講師に Travis.ciのハンズオンも希望者を対象に行われました。
★感想：14章は、コードはほとんど出てこないんですが、なかなか熱い議題がたくさん出ました。
「カバレッジ100％問題」とか、この日もやっぱ話に出ましたね。
弊社は「拝承」とか「～していただきたく」とかで有名な（？）某メーカー企業なのですが、テスト工程の終了判定としてカバレッジの提出を求められます。
なので、C0/C1という指標も一般的に使われますし、弊社で独自開発しているカバレッジ取得ツールもあります。
ちなみにやはり、基本はカバレッジ100％が求められる状況にあります。。。
100％にならない場合は、理由書を添えて提出しなければならないッ！
ただ、カバレッジが100％にならない理由をきちんと考え理解しておくことは重要だと思うのです。
あと、弊社で独自開発しているカバレッジ取得ツール、けっこうウンコなのかな？
というのも、プロダクトコードに対し、カバレッジ取得するためのコードを埋め込む処理を行わないとカバレッジが取れないのです。。。
んでカバレッジを見てからプロダクトコードを修正するときは、またコードをリバースして戻したりとか。。。
この作業がけっこーめんどくさい。そんなの裏でやってくれ、と激しく思った。
あと15章ですが、私、Mavenを本格的に使ったのはこの章の予習が初めてでした。
今まではずっとAntです。
Mavenのライブラリを自動で引っ張ってくる機能は便利ですねー。
Ant + Subversion+ Jenkinsの組み合わせなら、ビルドやテストを通すためにライブラリまでSubversionにコミットしておかないといけないのがネックでした。
でもAntをMavenに変えることで、ライブラリはテスト実行時にとってこれるようになるので、Subversionにjarとかライブラリをにコミットしておかなくて良くなります。これは良いですね～。
あと、「レガシーコード改善ガイド」という書籍をターゲットとした勉強会も新たに始まるとのこと。
こちらも楽しみです。
最後に、主催の @shinyaa31 さんはじめ、皆様ありがとうございました。
-->
![ノンデザイナーズ・デザインブック [フルカラー新装増補版]](http://ecx.images-amazon.com/images/I/41nvddaG9BL._SL160_.jpg)
