レビューの仕方を考える。
Oさんからレビューについて考えようとコメントがありました。
あと一点レビューについて考えることがあるな、と。ソフトのレビューのやり方ていくらでもあると思うのだけど、どういうやり方が一いいのかね？？
以前やったコードレビューみたいに、バグだしのみを行うレビュー（ウォークスルー）のようなこととかやってみたいです。毎回うちらがやっているレビューって GUIのレビューなのか基本設計のレビューなのかよくわからない、と感じることが多々あるんだよね。参加者のコメントがあちらこちらに飛んだり、何の目的でレビューを行っているのかと。まあそいう文化（ソフト開発に無頓着？）なのだろうけど、これからはなおしていきたいな、と個人的に思ってます。（レビューの目的、参加者の担当、レビューの結果を明確にするとかね）。
と言いたいことを書きました。
ので、やりたいこととか、反省点とか、エントリー書くより手軽かなと思ったのでレビューについてコメントできるエントリーを用意しました。(エントリっても良いよ。)
参加者には以前メールしましたが、ざっと集めたLinkを下記に置いておきます。順不同ですが前半はレビューの土台である心得、後半はレビューをどう行うか技術的なことのLinkになっているはずです。
プログラミングの光景：連載｜gihyo.jp … 技術評論社
コードレビューでレビュアーが気をつける事 – せつないぶろぐ
Peace Pipe: 効率の良いコードレビュー [software]
http://www.sooey.com/journal/2008/12/28/901/
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
Search Result: コードレビュー - Schi Heil と叫ぶために
http://sigmor.cocolog-nifty.com/toppako/2007/01/post_7ff2.html
Googleのコードレビュー：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
「コードレビューの方法について」（1） Insider.NET − ＠IT
セキュリティの観点から見たソースコードレビューのガイドライン「OWASP Code Review Guide」：濃縮還元オレンジニュース｜gihyo.jp … 技術評論社
