Web+DB Press Vol. 72のpp. 18 - 58の「コードレビュー実践入門」をソフトウェア開発者の端くれ ＆ 研究室で学生を指導する教員の観点で読んだ。おもしろかった。おもしろかったので、まずは、SubversionからGitへ移行しようと思う。
pp. 21に書いてあるコードレビューの教育的側面は見逃せない。研究室というのは、1〜3年でほとんどの学生が入れ替わっていくので、同じことを何度も何度も教えなくてはならないという宿命がある。学生間で教えあう仕組みを作らないと教員の負担とモチベーション（こちらの方が深刻）がやばい。
さらに、コーディングについての教育的な側面もメリットとして挙げられるでしょう。
たとえば、新入社員であったり、敬虔の浅いプログラマに対してのレビューについて考えてみます。単なる座学や研修に比べると、現場でのコードの考え方を直接教えられることから、彼らの成長にとって非常に効果が大きいと言えるのではないでしょうか。あるいは、経験者であってもプロジェクトに入ったばかりで、既存のコードベースへの理解が浅いような状況にも同様のことが言えるでしょう。既存のシステムのキャッチアップのために、コードレビューによる指摘は効率的です。
で、p.22に「ピアレビューという言葉があります。もともとは学術論文を学会誌などに掲載する際に行われる『査読』を指す言葉ですが、ソフトウェア開発においては、同僚同士による技術視点に立ったレビューのことを指します。」とある。もともとが、査読から来ているならば、本家の論文指導にレビューシステムを適用できなくもないはず。
現在のところは、メールと紙を用いて研究指導および論文指導をしているわけだけど、メールの場合、前回 or 前々回との差分を見るのがむずかしい。また、複数人での指導の場合、誰の指示にしたがってどう修正したのかがわかりづらい。
今回のGitベースのコードレビューの仕方では、指摘ごとにブランチをきり、修正したら本流に合流させる方法でソースコードの改善をしている。これは、まさに「複数人での指導の場合、誰の指示にしたがってどう修正したのかがわかりづらい」の解決方法の一つ。紙ベースでの指導は無理としても、メールベースの段階ならば置き換え可能な気がする。記事中にあったPullRequestを使ったGitHubやGerritのレビュー機能が非常に興味深い。
また、複数の学生が同時にいろいろなテーマ、いろいろな進捗状況で研究を進めているとき、誰が何をどこまで進んでいるのかが一目で分かると指導する側としては便利。そして、研究のアウトプットとして作られる様々な文書や図、表、ソースコードを管理するリポジトリがあるならば、学生にとっても便利（自分でバックアップ環境を整えなくても良い）。
うまく、要求を分析して、必要な機能を明らかにすれば既存のツールの組み合わせで結構良い環境を組み上げられそうなのだけど。
以上、とりあえずメモ。
余談：対話形式のドキュメントは苦手
私は知識収集時に対話形式のドキュメントを読むのは本当に苦手なのだと再確認した。対話形式だと頭が小説読みモードになってしまい感情移入してしまう。そうすると、会話の不自然さが気になって読み進められない（何か読んでいて恥ずかしくなって、いたたまれなくなってしまう）。
