今更公開するのも何だけど2015/5/29のJaSST東北のレポート。 今年のテーマは「レビュー」。
togetter: JaSST'15東北まとめ - Togetterまとめ
現在のレビューに必要な次の一手を把握するレビュー実践ウォークスルー
www.slideshare.net
ドキュメントレビューについて
100の問題があるプロダクトを与えたときの問題検出率は、
- レビュー：80％
- テスト：50％
レビューの方が問題が見つかりやすい。 バグは混入してから直すまでの時間が短いほど効率的に修正出来る。
レビューによるコミュニケーション効果
- レビュー後に、チーム内の認識を一致させることができる
- チーム作りができる
- レビューを通して、プロダクトへの理解を深められる
レビューの開始基準
もし、突然レビューを頼まれたら？
- まともな欠陥は見つからない
- 何となくレビューすると、書いてあることだけのレビューになる
- 思いつきでレビューが出来るほどのスキルを持っている人はほとんどいない
構造化されたドキュメントは、短い時間で多くの指摘が出来る。
人にレビューお願いする前にセルフチェックは実施しておいてもらう。
そのスキルもない人だった場合は事前方針を決めてからレビュー。
レビュー対象だけではなく、その対象物のInput情報も一緒に見る。
安達さんがレビュイに求めるレビュー条件
- レビュー観点が言えるか
- どう作ったかを言えるか
- 単純な指摘(誤字、脱字等)ばかりが出てこないか(レビューに耐えうるものか)
- 設計相談にならないか
レビュー観点
立ち位置(役割)によって観点は変わる。
- 開発者：「作れるか？」
- テスター：「テストしやすいか？」
- 企画者：「使いやすいか？」
- マネージャ：「売れるか？」
レビュー観点にも粒度がある。
レビュー観点の粒度の例：
- 使いやすいものになってるか？
- 文字は見やすいか？
- フォントサイズが適切か？
- フォントカラーは適切か？
- ボタンは適切なものになっているか？
- 押しやすいサイズになっているか？
- 誤解を招く名前になっていないか？
レビュアのスキルによって、観点の粒度(どこまで具体化するか)も調整がいる。
何をどこまで書くか？ IEEE830 1998 に情報がある
よくある欠陥
- 開始・終了条件のアンマッチ
- 非機能用件の抜け
観点の体系化は目的の整理になる
レビュー実施方法
ラウンドロビン：章毎に別担当にレビューを割り当てる インスペクション：効果は最大だがコストも最大
状況によりレビュー方法も使い分ける必要がある
この本がお勧め。
- 作者: 森崎修司,日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2013/09/19
- メディア: 単行本
- この商品を含むブログ (2件) を見る
確認方法のシナリオ化
表現形式
図・表を自分の解釈で書き直してみる
テスト因子の洗い出し ラルフチャートを使うとよい
意地悪漢字
裏のワードも書かれているか？
全てやっていると時間が足りなくなるので、どこまでやるかはPJ毎に考える必要あり。
メトリクス
何に使うか？
ソースレビューは、150～200行/時間 くらいが効率が良い。
レビューは個別->全体 の順に。いきなり全体レビューは効率が悪い。
レビューコメントの書き方
レビュー指摘の仕方は一歩間違うと雰囲気が悪くなる。
主語を「あなた」ではなく「私」でコメントする。
× 「あなた」のこの書き方はおかしい
○ 「私」はこの書き方は修正した方がよいと思う
レビューの振り返りはレビューの後すぐやる。短い時間でやる。
改善をより効果的に回すためのレビューへの取り組み (CookPad 松尾さん)
www.slideshare.net
見るものをGitHubに集約
振り返りで人的な負荷が毎回課題に上っていた。
個人の意識だけでは継続が出来ない。
見るものを分散すると、人の負荷になる。
一カ所に集約することで、忘れることもなくなる。
レビュー観点
- ソフト全体 価値あるソフトになっているか？
- 計画、ドメイン、設計
- コード誤り
- 成果物
- ドキュメント
チェックリスト
PullReqを出す前にセルフチェックする
静的解析(Dokumi)
変更差分に対してのみ静的解析を行い、コメントする仕組みを用意。 自動的に行う。
まとめ
- 計算機が出来ることは計算機にやらせる
- 分散させない
効率的なレビューの運用について (村上さん)
PMPは書類が多い
打ち合わせが多い
実作業＜管理作業になる
バグトラッキングシステムで指摘を管理するように
- 指摘と修正もチケットで管理
- コミットログで修正履歴を管理
議事録も全てチケットで管理。 全文検索が出来るので便利。
達人の指摘から学ぶレビューのポイント (根本さん)
不具合の印象は強く残っているが、レビュー指摘の印象はあまり残っていない。 喉元すぎると忘れてしまう。
知識がないのにレビューをしなければいけない立場になった。
→達人のレビュー指摘から学ぶことにした
達人のレビュー指摘から観点とキーワードを導出。 自分が同じ指摘出来るようなレビュー観点を作成する 注意するキーワードを見つける
分からない事はすぐに確認。後に回さない。
業務改善コンサルからソフトウェアテスト効率化へ ～ 株式会社SHIFTサービス紹介 ～
テスト支援ツール chibinekoの紹介 https://chibineko.jp/
ライブコードレビューで学ぶ！「納品のない受託開発」を支えるコードレビューの取り組み
倉貫さんパート
レビュー＝成果物に対する指摘
マニュアル通りに書けるプログラムはない
人を育てるには、作らせて、指摘するしかない。 教育効果も狙える
相手の事を考えられる人を増やすには？
全てを担当する。
毎週、「成果」を提供する。「時間」を提供するのではない。
仕様変更はビジネス価値最大化のための選択。
ビジネスモデルとビジョンを共有する。
作る物をミーティングで合意して、翌週届ける。
動くソフトウェアが設計書。
設計内容はボード等で説明。後に残す必要はない。
ソフトウェアに求められる特性
- 常に仕様を追加・変更できること
- 常にリリース可能であること
- スピード感を持ち開発できること
- 不具合はすぐ修正可能であること
完全にはなくせないが、検知できること。放置しないこと - 上記の特性により、持続して変化できること
ソフトウェアは塩漬けにはできない。 外的環境が許さない。何もしなくてもOSやミドルウェアのバージョンアップが発生し、追随しなければならない。
西見さんパート
www.slideshare.net
ソースコードで全てを回す
以前はペアプロでコードを共有していた。効果はあるが時間がかかる。 レベルの高い人同士であれば、コードレビューで理解し合えると気づいた。
出来ない人がコードレビューするのは時間の無駄。
一人前の人は「良いコードは何か？」の共通認識を持っている。
ランチタイムのディスカッションで共通認識の醸成をやっている。
レビュータイミング
- ローンチ前の全体レビュー
- 本番リリース前レビュー
- リリース前レビューは毎回実施
レビュー観点
- 意図を読み取れるソースコードか
- テストコードは書かれているか
- リリース時に問題が起こらないか
- 障害時のリカバリは考えているか、問題時にすぐ対処できるか
- 環境周りの変更はないか
読みにくいソースコードは「読みにくい」と素直に言う。
価値観
コードレビュー ７つの秘訣
- レビューの観点を明確にすること
- 我が身に返る事を恐れずに指摘すること
- 何故悪いコードなのかを論理的に説明すること
- 良いコードについての共通認識を持つこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
ディスカッション みんなにとって分かりやすいものにする
個人の趣味で指摘をしないこと
まとめ
- 自分たちの開発プロセスに適したレビュー観点を設定する
- レビュー観点に基づく、良いコードの共通認識をチームで持つ
- レビューは小口化して継続的に実施する
人の目を入れてコードを腐らせない
レビューに関するQA
自分の質問と、パネラーから頂いた回答。
質問) 効率的にレビューを実施するにはどうすればよいか？
十分な時間がない中でレビューを実施する事があり、短い時間の中でもレビューを有益なものにするにはどうすればよいか？
- 小さく作ってレビューする。
いきなり全部作ってではなく、5～10％くらい作った時点でレビュー。
大きい固まりが一度に「ドン！」と来たら既に負け戦。 - 「気になるところ」をチームでレビューする。
どういうところが大事かを事前に決め、そこを見る。
時間割を決めてやる
- 大事な所からやる
リスク部分、難しい所、重要な所など - ゴールを決める 何が出来るようになればOKか？
- 人間特性、手薄い所、異常系の記述量が薄い所を見る。
他のQAでなるほど、と思ったコメントなど。
「レビューをやって良かった！」と思わないと継続できない。 レビューの効果を測定し、見える化する。
レビューの時間は予め予定に組み込んでおく。
大きいプロダクトのレビュー終了条件は「時間」。 レビューが遅れたら後行程の作業はその分遅れる。
期間を予め決めて、その期間の中でプロダクト品質を高めるにはどうすればよいかを考えた方がよい。
改めて思った事など
ドキュメントは読み手のレベルに合わせる必要がある。 万人に対して大丈夫なドキュメントなど存在しない。
ソースがドキュメントになるには、プログラマのスキルは必須だが、言語も選ぶと思う。
Rubyはともかく、手続きのコードが多くなりがちなC言語のソースを「ドキュメント」というのは辛いように思う。
ソニックガーデンさんがRubyを選択してるのはRuby on Rails使える以外に、ソースがドキュメントになり得るという所もあるのかな、と思ったりした。
前のプロジェクトで、こっちが作った設計書に「あれ書いてない」「これ書いてない」「フレームワークが分からない」と散々ダメ出しされた事があって、チームの雰囲気が最悪になった事を思いだした。
気にするポイントはその設計書を見る人の数だけあるので、事前にサンプル出して相手と意識合わせする事が重要。
