会社でレビューについて話し合い

先日、ソフトウェア・インスペクション・ワークショップ 2009に参加したのですが、資料がUpされていました。

ソフトウェアインスペクション／コードレビューを成功させる方法（前編）
ソフトウェアインスペクション／コードレビューを成功させる方法（後編）
当日行なった技法や観点など

また、このワークショップとは別ですが、研究のためにコードレビュー オンライン ハンズオンの協力者を募集しているようです。

当日は、何かを学んで来た...という感覚はあまり得られなかったのですが、考えてみるいいきっかけになりました。
んで、このセミナーの後に、会社のメンバーと共にレビューについて考えてみよう！ という機会を設けて、今日は第二回をやってきました。

レビューの目的って、知識や技術の差(属人性)を埋めるため というのも１つの大きな目的だと思うのですが、その目的からも分かるように、プロジェクト規模や、携わる人間の数/お互いのレベルの認識度 によって変わります。
ヌーラボ@東京は、社員数も片手ぐらいだし、現在新卒採用の人はいない という状態なので、このメンバーでやるとしたら、どんなものがいいのだろう？ という話を今日はしてきました。

みんなの意見も聞きつつの感想としては、小規模なメンバーだからこそ抱える不安/心配があるよなーと。

小規模案件 = 携わる人が少ない(1人の時もある)
だと...
ある特定の人のみしか仕様を知らないって事も当然増える。
案件の立ち上がりの時期はペアプロを...という話をした人もそこそこいたんですが、それって結構、同じ知識(要件や今の状態)を共有してる前提で、気軽に相談し合える人が欲しいって事なんだろーなって思いました。

「気軽に相談出来る人」というのが語弊があるかもしれないけど...
同じプロジェクトにいる人ならば、損益はお互い共通しているのでまぁいいんですが、違うプロジェクトにいる人の場合、
"すいませんが、相談のって下さい.."
"いいよ (...でもその分、自分の仕事は残業かな..)"
なんて感じがすると、気を使いますよね。

ワークショップでは、相談乗ってあげる、レビューをしてあげる 事についても、評価を設けるべきだ という話がでてきてはいましたが...作業を日毎に割り当ててスケジュールたてている時点で、なんかもぅ違う。
レビュー選任者を作って、"その人の仕事の30%はレビュー時間に割くように決める" とかも大規模なプロジェクトではありかな。
んが、5人程度のメンバーならば、もっと違う取り組みができるはず。。

まぁ、そんな事を考えていたら、以前、旦那と一緒に仕事してた時はやりやすかったなぁー。と思い出した。

なぜかって...
お互いの得意/不得意を把握してたし、気軽にタスクを交換できる(してもいい相手だと知っている)、こんな事で困ってさぁーって雑談できる時間も多かった。

その結果...

「ここの部分は引き受けるから、変わりにここの部分やってよー」
とか、
「コレには興味あるよなー。んじゃ、このタスク私の方で持つから、調査してみてよ。んで結果教えて！」
とかやってた。

2人で分担できるようになると、「あそこのプロジェクト大変やから、1日徹夜で手伝ったるか！」なんて事も1人の時よりしやすくなった気もする。

周りからも、たとえ一緒にやっていない仕様であっても...2人のどちらかに聞けば分かるんじゃない？ と多分思われていたと思う。

なんか、少人数でやっていく会社にとってみても、いい方向性突いてたんじゃないかって気もするな。

ASlimTimer 1.1.7リリース

ASlimTimer 1.1.7をリリースしました！

今回の変更は不具合修正の他に以下の機能を追加しています。

• レポート機能
• 経過時間を今日の合計時間を表示する機能を追加

ASlimTimerは、SlimTimerのサービスを使ったクライアントなのですが、SlimTimerではタスクの一旦停止という機能がありません。

例えば、お昼に行くとか、ちょっと呼ばれたとかのタイミングって、一旦停止したい！って思うのですが、データとして保存するのは結構難しい。

タスクのTimeEntryのデータとして、開始時間と終了時間を保持している形だと、
今のタスクを一旦停止して、違うタスクを開始する...という場合、同じ時間で複数のタスクが実行された事になってしまう。
そのためにSlimTimerでは経過秒としてduration-in-secondsのデータ領域があるように見えますが、WEBベージ上で開始時間、終了時間を更新するとこの領域が自動計算されてしまう。

そこで、目線を変えて、「経過時間を今日の合計時間を表示する機能」というのを追加してみました。
この機能は、タスクの経過時間の表示を、今日に行なった同じタスクの合計時間を表示するというもの。
切替は設定画面で行ないます。

これをすると、今やっているタスクは、今日何時間やっているのか？がわかるようになっています。
まぁ、これも一長一短ありますが、私はこの表示の方が見やすい気がしますー

ASlimTimerですが、使っている人がいるというお話もチラホラ聞こえて凄く嬉しいです！
これからも作業が進めやすくなるものを目指して改造していくので、また機能要望などあればご連絡下さい！！

モニター体験

VoiceFarmでアンケートしてみました。
モニターとして何か答えるというのは、始めての経験だったんですが面白いですね。

モニターとして行ってみると結構色んな所が目についたりします。
こぅいぅ情報を企業がアンケートとして知る事は確かに凄い有意義な気がした。
私たちの業界でもそうだけど、客からの目線って「目から鱗」の事が結構ある。

今って接客業の方と触れ合う機会って凄く多いから普通の一般市民でも、接客についての目が肥えてたりするんかも。
味がどんなに良くても、接客が悪かったら 「もぅいかない」ってなることも今まで度々あったしなぁー。

味についても、○○だったら美味しいけど、××はイマイチとかあるじゃないですか？
始めに○○を購入したらいいえど、××の方を買ってしまったらもぅその店にはいかなくなる。
あの店はマズい！って判子をぽーんと押しちゃう。

売り上げをあげる為に、新商品を作る! という発想は安易にできるけど、それって博打ですよね。
接客のマニュアルでは、多分、新商品をオススメする というのがあるんだろうけど、それがあんまり美味しく無かった場合、新規顧客のリピートを減らしてしまうかもしれない。
まぁ、こんな事はプロの人からみたら当然の話なんだろうけど、素人目線から見ても、「力入れる方向間違っているよな、この店 」って感じる事も少なくはなかったりもする。

個人としては、新商品が無くても、気に入った美味しいものがあればその店にいくけどな。。
まぁ、気に入ったモノの味が落ちたら、行かなくなるけど。

あー、IT業界でも一緒か。
この製品が売れなくなってきたから、新しい製品をチョィチョィっとつくって売るか とかある話ですもんね。
んで既存製品のサポートに力が注げなくなって、新規顧客を得る為に既存顧客を手放すことになっちゃったとか。うむー。

ちなみに、このVoiceFarmでモニターとして登録しておくと、アンケート依頼メールが随時届くような仕組みになっています。
答えると謝礼もあったりするようなので、主婦されている方は登録しておくとよいかと！

2009 JavaOne報告会に行って来た

2009 JavaOne報告会に行ってきました。
iPhoneの充電を忘れていたため、Googleのマップも確認できないまま...会場に行けるかどうか不安になりつつ向かう。
あー、もぅiPhone無しじゃー何処にもいけないなぁ と改めて感じる。

会場には20分前に無事到着。眼鏡を忘れてしまったので、空いていた一番前に着席。
隣の席の方が、カメラと取り出した時点で、その方が岡崎さんだと言う事に気づく。
でも私の事は覚えてないだろうなぁ。川口さん交流会で少し喋っただけだし。。と思い、声はかけれなかった。私ってチキンww

最初は 丸山先生の Welcome & General Session Hi-light
JavaOne会場でのいろんな写真をみつつGeneralSessionの内容を伝えてくれました。
OracleCEOのLarry Ellisonは、開催前は 来ないんじゃないか？ くるとしても最終日？ とかいろんな噂が飛び交っていたそうです。
で初日に登壇したわけなんですが、冗談として、Larryの趣味のヨットに帆(?)にJavaのロゴがついていたり、次回のJavaOneはLarryの日本庭園(凄い趣味だ)でやるだろうとかとかを交えつつ進んだ様子。
Sessionの最後にスコットが壇上から降りた時に、スタンディングオーベーション。
JavaOneの最後にもSunの社員が壇上に上がったという話もあって....なんだか感慨深い感じが伝わってきました。

JavaOneは最後なんじゃないのか？ という噂がありますが、まぁ...いまだにどうなるのか分かりませんが、１つの区切りだった というのは間違いないのでしょう。

私自身も、Javaでご飯を食べさせてもらっていて、大分助けられています。こぅやってオープンソースにこだわって進めてくれたSunには本当に感謝しなくちゃ と改めて思わされました。

Update From Sun Microsystems 下道さん

---

キーワードは、"クラウド" "Crossbow" Crossbowというのは、ネットワークの仮想化技術。
これからは、「どこにサーバあるのか知らんけど、1台に見えるサーバで、すんごい大きいアプリも、小さいアプリもどんどん作っちゃう” って時代になるんですかねー。凄いなぁー。
Sunのホスティングサービス Kenaiもぜひ見てください！との話だったのでみてみました。
オープンソースのプロジェクトを作れるんですね。5つまで作れるのかな？
プロジェクトは1768ぐらい登録されている様子。

ホスティングサービスも色々あって、何処にコミットしていくか悩むぐらいになりましたね。
今まで使っていた Assemblaが最近重くなってきたので、違う所に移行するか丁度悩んでいた所でした。
GitHubと思ったのですが、Eclipseで操作しやすいSVN,CVSがいいなぁと思っていて。でもなんかSunのサービスって重い！って先入観があって、二の足踏む。サイトの表示は軽かったけどね。

ここでBreak. 前でうろうろしていた櫻庭さんに発見してもらって声かけてもらえました。
「 197Xにいかなかったの？」
「旦那が行ってますー」 的なww
異性だから覚えづらいだろうに...覚えていてもらって嬉しかったですっ

Java Desktop / Mobile Session 櫻庭さん

---

JavaFX TV。ゲームやストリーミングもあるとか。実際どこまで出来るんか楽しみですよね。
多分TVのハード自体にJavaFXが実行できるなんらかの仕組みが必要なんでしょうが、私にはまったく検討が付かない。
でも、もしペペっとプログラム書いたらTVで実行できるような環境ができたら、「あー、プログラム書ける仕事でよかった」と感動できそうだ。
しかしながら、まだリリース未定らしい。残念。

JavaFX 1.2ではmobileでも使えるGUIコンポーネントや、mixin, ローカルストレージなども。
また、デザイナー用ツールとしてAuthringToolも。これは、Flashのタイムラインの開発のような感じのものらしい。
...これも無料で提供してくれるのかな？ だったら、私のような貧乏人でもタイムラインをいじってのFlashっぽいものの作成ができちゃぅの？おー、遊んでみたい。
今年の冬には出したいという話があったらしいので...来年には出るのかも？？

話はそれるけど、以前のJavaOneで話が出てたのに、全然出てこないものとか消えてしまったものとか結構あるんですね。
こぅいぅ所、個人的には結構びっくりなんですよね。先、どうなるか良くわからないようなものも、そんなに大きなイベントで言っちゃうんだーって所が。
この前Adobeのイベントに行った時は、これはまだ言えない...とかって話が多かったのが気になったんだけど反対だな。
どっちがいいか？っていったらSunのような方針の企業の方が好きだな。

次はJavaSE7の話。
OSGiの対抗っぽく作られていたJAM(JSR277)が消えてしまった話は、裏話っぽくて楽しかった。
検索してみたら、InfoQ:JSR277とOSGiは１つになるか？なんて１年前の記事もあったりしたみたい。
今は Project Jigsawというのでやっているらしいです。

Project Coinというので細かな仕様の修正の検討をしているらしいです。
small change = 小銭 = Coinらしいww
例えば、
Map map = new HashMap();
って書かないといけないのはウザイから
Map map = new HashMap<>();
にするとかってのが有るらしい。これは是非採用してほしーな。
InfoQ:Project Coinによる2つ目の候補リストの発表って記事もありました。

Java in Enterprise Session 木村 さん

---

J2EEはいろんなアノテーションが増えて、使いやすくなってきましたね。
仕様も膨大なものでしたが、サイズを適正化...って事で、削除するものを検討していっているようです。
他にEJB3.1での@Singletonとか、並行実行性の指定とか、非同期の指定、FileUploadのサポート、Servlet/Filterの動的追加、BeanのValidationとか。
Validationでは @NotNull とか @Length(max=80) とか書けるようです。
この前、こぅいぅValidationのアノテーションを自作しちゃぅか？なんて思った事がふっと思い出されます。。。こぅいぅ仕様を作ってくれると、指定方法自体についても参考になりますね。(真似しやすくなりますね)

Lightning Talk Session

---

岡崎さんの AIR JavaOne(日本でJavaOneの情報を得る方法)、マイコミの杉山さん、Gihyoの馮さん の 記者の目から見たJavaOne
、櫻庭さんの JavaOneで飢え死しない方法、太田さんのEeePC+OpenSolarisのセッションの内容のご紹介 でした。


最後になりましたが、有意義なイベントの開催有難うございました！

こぅいぅイベントとか、本当に有り難いです。
私も何かお手伝いして貢献したいなぁ〜 どこかで募集してませんかね？

ソフトウェアインスペクション・ワークショップ 2009に行って来た

ソフトウェアインスペクション・ワークショップ 2009に行ってきました。

定員は60名だったと思うのですが、100名ぐらいが結局参加している様子で、席もいっぱいいっぱいだった事を考えると欠席者も少なかったんじゃないかと思います。
それだけ興味/注目をもって来た方が多かったって事でしょうか。

このワークショップですが、メインはハンズオンとして、実際に個々人でコードレビューを行いその結果を研究材料にするという感じ。
ソフトウェアインスペクションとは？ どうやったら効率いいのか？ というのを聞きに行くようなものじゃありませんでした。
「コレがベスト。一番効率いいっす！」なんてものはまぁないですしね。

ハンズオンの内容ですが、「仕様書」 と 「コード」 を対象に、或る人は Adhoc, 或る人は SGIT, 或る人は Guided Checklists が手渡され、その観点を元に一定時間内に欠陥を見つけ出す というものでした。
システムはWEBベースの書籍通信販売、レンタルシステムのプログラム。
コードは、JSPとServletがなんと紙ベースで配られた。結構な厚みのを。。。うへぇ
Adhocって？SGITって？ とかよーわからんままレビュー開始。紙ベースのコードなので、呼び出し先コードを探すのが、もぅイライラ(笑) しかも使える机のスペースが狭いから、ばーーっと広げることも出来んし、結局時間切れ。
IDEがないとツライ事を実感ww

AdhocとかSGITとかの説明は結局無かったんですが、周りの人のをぱっと見せてもらった感じでは、
Adhocは チェックの観点を簡単に記述したもの。「シングルサインオン」とか、「パスワード再発行」とか観点のキーワードのみって感じ。
SGITは、Adhocよりも細かくチェック観点が書かれていて、Tree形式になっていました。
○○は出来ているか？ 　yes ----> ××はできているか？
　　　　　　　　　　　no ---->
のような感じで。
ChecklistsもSGITみたいに細かいチェック観点が書かれているようでしたが、表形式でした。
多分、どれが一番効率的だったか？を測りたかったのだと思いますが、私のチームではどの方式の人も欠陥はあまり発見できず ???な感じで終了。なにが ??? で詰まってしまったか？を聞いてみたら、言葉の定義が人によって違う所とか、そもそもの前提がわかんなくなったとか、わたしゃJSP/Servletなんて随分前にしか見てないから思い出すだけで時間くったとか、そんな感じでした。。あはは。。

そんな感じのイベントでしたが、頂いた資料や開催中のお話で自分なりに理解したこと、気になったキーワードをピックアップします。

まずは、講師の方の発言の気になった もしくは勝手に読み取ったキーワード。
・レビュー/テストは泥臭い所だけど、カッコいいよね。
・見つけた欠陥は全て記録し、2度と再発しないための根本原因を考える事。
・大きい範囲でやるより、小さい範囲を何回かに分けてやった方が効率がよかった
・何も見ない段階で「欠陥の仮説」をたてるのは有効。
・定型的なミスはコードで検出。検出できないものを目視で という分担を。
・何事にも楽しく行なうのが重要。個人攻撃はもっての他。
・レビューをしても評価がないと、自分の時間を削られるだけ = やりたがらない、適当に終わらせてしまう
・AssistPointの評価、同僚の評価を！
・形式的にやると決められているから、しょうがないけどやらないといけないです という状態になってしまう
・事実をベースに話す (一般的に...、普通は...、前のと比べると...という言葉は使わない)
・レビューは効率的に人を育てることができる
・レビュー専門の職種だと、1年に200程の案件のレビューをできたりする。長年の経験が或る人でも200の案件をこなしている人もあまりいないのでは!?
・なぜ、レビュー/テスト をするのか？ → 安心したいから。
・品質については、日本は一目置かれている。 (日本人が品質を話しようとすると黙って聞いてくれるらしい)

---

「インスペクション」という言葉に、しっかりとした定義はない。
レビューと同等の意味で使われていることの方が多い。(実装者ではレビューという人の方が多い)
ただ、レビューといってもいろんなレビューがあるから、それを分類するのにお互いの合意のもと単語を使い分けても良さそうな感じ。
いろんなレビューですが、例えば、納期前に行なう品質チェックもあれば、技術的部分のレビューもあるし、隣の人にちょっと見て〜！ってお願いするレビューもある。。。

まずはIEEE1028の抜粋記事の抜粋ww

Inspection
目的：欠陥の発見、修正の検証、ソフトウェア品質の検証
意思決定：事前に定義された対処方法を選択。発見された欠陥は修正。
参加人数：3〜6名
主導者：訓練を受けた進行役
データ収集：必須
成果物：指摘欠陥リスト、実施報告書

Technical review
目的：仕様、計画との一致の評価。変更の一貫性の判断。
意思決定：参加メンバーの提案に基づいて管理職や技術リーダーが判断
参加人数：3名以上
主導者：技術リーダー
データ収集：プロジェクト要件ではないが、参加者で共有されることが多い
成果物：実施報告書(担当、完了予定日が記録された対応予定を含む)

Walk-through
目的：欠陥の発見、代替案の検討、製品の改善、習得のための議論
意思決定：作成者の判断を参加メンバーが合意
参加人数：2〜7名
主導者：進行役、作成者
データ収集：推奨される
成果物：指摘欠陥リスト、対応予定、決定事項

私が感じたイメージですが、
Inspectionは計画的に行なうレビューで、実装前の仕様決定のような早いタイミングで行なうもの。(もちコードも対象だけど)
これじゃー仕様満たせないよね？とか、経験上ここらへんヤバいからもっと詳細に仕様書いた方がいいんじゃね？的な感じかな。
この場合は、解決方法を考えるのは無しで、ここは欠陥！とかここは再検討！とかの決定だけをバシバシやっていくのが良さそう。
今回やったハンズオンはInspectionだったんですよね？？？

Technical reviewは、コードに対して、こうやった方がコードスッキリするんじゃね？とか、こういう処理は、よく○○って名前をつける事が多いからその名前にした方が皆に伝わりやすいよ？とかそういう系のやつですかね。
Walk-throughは、「ここ、こぅしてみたんだけど、あんまり自信ないから、見てほしーどぅおもう？」ってやつですかね。

まぁ、全部やれればいいんでしょーが、只でさえ時間を削る所にされてしまうレビューですから、内容やタイミングによって選択しつつ...ですね。
やる時に、Inspectionしまーす！ とか Walk-throughtしまーす！ とか名前出したら、目的もわかって良さそうですな。

---

今の感想としては...実際やってみないと分かんないし、やってみながら、メンバーとこぅした方がよりいいとか楽しいとか話し合えたらいいよなぁーなんて思ってます。今日の参加者の皆さんは、みんな(形式的な)レビューをやっているという人がほとんどだったんですが、私自身経験がそんなにないんですよねー。つーことで、ぜひ、やってみたい。

まずは、勉強会とか研究会的に、サンプル用意、実際レビューしてこぅやとやりやすいねー！とか、次はこぅしてみたらどうだろう？ このツール使ってみる？ とかやってみたいなぁ。
技術とかは一人でも学べるからいいんですが...こぅいぅ事こそ、興味ある人同士集まって、試して、話して...ってしたいなぁ！
会場のアンケートでも半数以上が 「あまり上手くいっていない」 って事だった事も考えたら、とりあえず方法を先決めて形式的に入れる つーのはあんまり良くないんだろうし。

会社のみんなは、業務時間外でもやってみたい位の興味あるかなぁ??

org.eclipse.ui.commandsはナカナカいけるのね

Eclipseの3.3からActionではなく、Commandを使うのを推奨しているらしい。
Commandをつかわなきゃなぁーって思いつつ、ついActionを使ってしまってあまり試せていなかったので、今日ちょっと使ってみました。
なかなか便利ですねー。こいつ。

Commandの場合は目的によって綺麗にモノが分かれている感じです。
plugin.xml には、

• commandの定義
• Commandをどこに表示するのか？の定義
• どんな処理を行なうのか？のHandler定義

...など に分かれています。分かれているからこそ、すっきりとした定義も出来、今まで出来なかったけど出来るようになった事！があるんですね。

例えば....
＊ commandを複数作成するがHandlerのクラスを１つで使い回すパターン。
　この場合、commandにcommandParameterを設定してHandlerから取得する ことで実現。

＊メニューアイテムをOn/Off切替(チェックボックス)にするパターン
　command定義の子要素にstateを記述してHandlerから状態を取得して処理する。
　ここのtoggleの所

＊複数のメニューアイテムをラジオの選択形式にし、１つのHandlerで処理してしまうパターン
　ここのradioの所

なんて事とか楽に....というよりスッキリ?....出来ちゃうんですね。
しかも、処理を書くHandlerのクラスではラベル文字も書き換えできるようになっているもナイス。

ここらへんで参考になるのは Eclipse Tips のCommandsラベルが付いている記事。
一通り読んだだけで、全て試してないけど、ISourceProviderとか...なんか夢が広がるww

Commands以外でもEclpse Tipsのサイトは凄いいい記事多いですねー。
今度ゆっくり読んでみる事にする！

あと、もう１つほほーっと思ったのが、Contributionに書くlocationURI.

<extension point="org.eclipse.ui.menus">
  <menuContribution locationURI="****">
    <command commandId="****" />
  </menuContribution>
</extension>

ここのlocationURIで色々表示場所を切り替えれるみたいなんですが、
昔よりも分かりやすい表示になった気がする。
メニューのIDさえ分かれば、ここの後ろに...とか入れれるって事なんですよね。

locationURIの指定で見かけたものをpickupしてみました。

popup:#CompilationUnitEditorContext?after=additions
　JavaEditorのコンテキストメニューのaddtionsの下に追加

popup:org.eclipse.ui.popup.any
　すぺてのPopupmenuに追加? この場合詳細はVisibleWhenとかで指定する感じってことかな。

popup:org.eclipse.jdt.ui.PackageExplorer
　PackageExplorerのメニューに追加

menu:org.eclipse.ui.main.menu?after=navigate
　メニューに追加する時。上記の場合メインメニューのNavigateの後ろに追加

toolbar:org.eclipse.ui.main.toolbar
　ツールバーに追加する時。

AIR GEAR v1.0.3リリースしました

AIR GEARのv1.0.3をリリースしました！
修正内容は、
ActionScript3のフォーマット機能とアウトライン表示機能を追加
ActionScriptエディタでクラス名のコード補完機能を追加
コンポーネントのColorPickerとSpacerを追加
各種不具合の修正
になっています。

インストールは、Ecllipse/dropinsに入れて、念のため -clean付きでEclipseを起動してください。
アウトラインとコード補完については、デフォルトでオフになっているので、Workspaceのプロパティページで有効にする必要があります。

ですが、まだクラスの変数とfunctionしか解析できていないので、コード補完は或る程度...のレベルです。
これからまた解析できる部分が増えるように頑張ります。

ぜひぜひ使ってくださいねー！