tag:blogger.com,1999:blog-20698238.post116128600288249702..comments2023-12-18T18:49:45.754+09:00Comments on Peace Pipe: 効率の良いコードレビュー [software]Toshiya Hasegawahttp://www.blogger.com/profile/07861046321399030443noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-20698238.post-1161368272192875832006-10-21T03:17:00.000+09:002006-10-21T03:17:00.000+09:00> ただ、ペアレビューの進め方がかなりポイントになりそうですね。まさにそうなんですよ.コードレビュー...> ただ、ペアレビューの進め方がかなりポイントになりそうですね。<BR/>まさにそうなんですよ.<BR/>コードレビューに限った話ではないけど,開発プロセスっていくらでも工夫できる気もするし,凝りすぎても逆効果だろうし.<BR/><BR/>ただ,今回の引用記事を読んで一番感銘を受けたのは,「メンバーが『やらされてる感』を感じるようではダメ」ってことなんです.<BR/><BR/>…で,引用記事の中にもいろいろアドバイス書いてありますが,一番はやっぱり「リーダーに技術力があること」なのかな,と.<BR/><BR/>以前も <A HREF="http://peace-pipe.blogspot.com/2006/06/memo_25.html" REL="nofollow">この辺り</A> で書いたんですけど,「名選手,名監督にあらず」とも,「名監督は名選手」でなければいけないと.<BR/><BR/>技術が分かっていないリーダーが「コードレビューは大切だから実践しよう」なんて言っても全然説得力ないですもんね.<BR/><BR/>コードレビューに関して言うと,コミュニケーションがよく取れた,チームワークの良いチームで行う程効果が高いと思うので,チーム運営を重視すると共にコードレビューも「やり続ける」ことが大切なんでしょうね.Toshiya Hasegawahttps://www.blogger.com/profile/07861046321399030443noreply@blogger.comtag:blogger.com,1999:blog-20698238.post-1161293482045012492006-10-20T06:31:00.000+09:002006-10-20T06:31:00.000+09:00まさに今仕事でコードレビューの進め方を考えていたので参考になりました。チームレビューとペアレビューを...まさに今仕事でコードレビューの進め方を考えていたので参考になりました。<BR/>チームレビューとペアレビューを分けるのはまったく同感です。<BR/>ただ、ペアレビューの進め方がかなりポイントになりそうですね。コンパイラが見つけてくれない問題というのは、コーディングルールが徹底されていてかつその該当モジュールのアルゴリズムが分かっていることが前提にしないと、有意義なものにならない可能性があります。<BR/><BR/>僕のチームの場合は、チームレビューを教育のため、ペアレビューをコード品質を保つため、と明確に分けています。<BR/>ペアレビューの前提として、レビュアーが該当モジュールの副担当であることにしています。モジュールの外部仕様、内部構成が分かっている上でコードレビューを進めてもらう、と。つまりペアレビューの目的をユニットテストのカバレッジを稼ぐのと同じとし、レビュアーが副担当としてやっていけるように仕立て上げる活動のうちの一環にしてしまうのですね。<BR/>ただ、このようなやり方はいきなり他人から渡された数万行レベルの外部仕様書のないモジュールの「レビュー」にはむきませんが。<BR/><BR/>そして時間の都合上、「教育」のためのチームレビューがなかなかできないのですが…。Anonymousnoreply@blogger.com