@nihonbuson さんから、アジャイルでのレビューについて話してほしいというご相談をいただいた。そういえばレビューについてあまり調べたことがないし、カンファレンスでもテーマとしてそれほど聞いた感じがしない。
森崎先生が書かれた連載が本になっていて大変勉強になったのだけど、ご本人曰くこれは設計レビューであってコードレビューではないとのこと。スプリントレビューもまた違う観点もあるかなと思いつつ、指摘のダメパターンはだいたい共通している気がしている。
なぜ重大な問題を見逃すのか?間違いだらけの設計レビュー改訂版(日経BP Next ICT選書)
- 作者: 森崎修司
- 出版社/メーカー: 日経BP社
- 発売日: 2015/10/06
- メディア: Kindle版
- この商品を含むブログを見る
Erik Dietrich さんの Manual Code Review Anti-Patterns という記事が出てきた。
- The Gauntlet - ガントレット - 審査員が撃ってくる
- The Marathon - マラソン - 長くて枝葉末節
- The Scattershot Review - 乱れ打ち - 指摘に一貫性がない
- The Exam - 試験 - 説明によって合否が決まる
- The Soliloquy - 独り言 - 本当にレビューしてる?
- The Alpha Dog - アルファドッグ - 特定の人々が牛耳って学ぶ意欲がなくなる
- The Weeds - 雑草 - 枝葉末節に時間使う
需要あるなら、ちょっと時間とって訳したい気もします。
レビューといえばパターンランゲージのコミュニティの人たちは時間をかけてレビューにレビューを重ねる文化を持っていたので、参考になる気がする。文章に対して真摯で、英語圏ってそういうものかな(とういうと日本語も真摯な人がたくさんいるのでよくないけれど)。
と思ったら、検索順位のその下に、C2Wiki に「Code Review Patterns」というのがあった
http://wiki.c2.com/?CodeReviewPatterns
- Read PeerReviewsInSoftware :
Peer Reviews in Software: A Practical Guide (Addison-Wesley Information Technology Series)
- DoInspections - インスペクション
- FormalStandards (are these the same as CodingConventions?) - 正式な標準
- FormalReviewProcess - 正式なレビュープロセス
- ReviewProblemAreasFirst - 問題のある領域をまずレビュー
- ArchitectReviewsEverything - アーキテクトはあらゆる点をレビューする
- AtLeastTwoReviewers - 少なくとも2人のレビュワー
- CodeReviewTeam - コードレビューチーム
- InvolveNewbies - 新人を巻き込む
- InvolveExperts - 達人を巻き込む
- DefectSeeding - 欠陥埋め込み (チェック前にいくつか欠陥を埋め込んでおく)
- PeerReview - ピアレビュー
- HighlightChanges - 変更点をハイライト
- CodeWalkthrough - コードウォークスルー
- AllowRedesign - 再設計も許可
- MakeReviewsFun - レビューを楽しく
- MakeReviewsConstructiveNotCaustic - 原因追求より建設的に
- ReviewBeforeCheckin - チェックイン前のレビュー
- ReviewsBeforeBigChanges - 大きな変更の前にレビュー
- CodeReviewDay - コードレビューデー