コードレビューってどうやるの？

1 ：09/07/30 〜 最終レス ：10/11/09

俺の会社は設計者に一通りしゃべらせて終わり

2 ：

レビューなんてしないほうが多いのか？

3 ：

一応決まりになってるから形式的にやってるだけなのか

4 ：

1行目から順に全部読み合わせていけばいいんだろ

5 ：

プログラマを徹底的に虐める場ですね

6 ：

神が決めたルールを守っていることを確認するための場

7 ：

単なる連帯保証人

8 ：

個人の趣味範囲の指摘がひかり捲る時間

9 ：

客先の新人がレビュアーだったときは最悪だった

10 ：

コーディング規約も無い会社でコードレビューとか、馬鹿か？

11 ：

>>10
処理に抜けが無いかとか、セキュリティ的に問題になる箇所が無いかとか、
たまたま動いてるけど本当は間違ってる箇所が無いかとか
そういうのをチェックするためじゃないの？

12 ：

>>11
それをコーディング規約って言うんじゃないの普通は。

13 ：

言わないでしょ。

14 ：

規約はコメントの書き方とか命名規則だろ。
ライブラリの使い方まで言及してるとこもあるかもしれんが、せいぜいそのくらい。

15 ：

コーディング規約は命名規約とかの事じゃないかな？
ソースが納品物にふくまれたり、再利用性が高い場合に、何かしらの変な部分や無駄を見つけるのがコードレビューかなと、勝手に思ってたんだけど。違うかな？

16 ：

ケアレスミスの起こし易い表記法禁じてたり、代入を必ずするようにと規則にあったり、
普通はコーディング規約って、コードの品質上げる為にあるんだけどね。
その最低限のルールも無しにコードレビューしても、個人的な趣味の押し付け合いになるだけだろ？

17 ：

コーディング規約で防止するミスと、コードレビューで発見するミスは
全然種類が違うだろ。
> その最低限のルールも無しにコードレビューしても、個人的な趣味の押し付け合いになるだけだろ？
コードレビューってコーディング規約(俺様規約も含む)に沿ったコードを書いてるかどうかのチェックの場
じゃないよ？

18 ：

コードレビューだけして金もらえるプロジェクトがあったんだが。
適当にやってもいいもんだから、
割り当てられたのはＣ言語しらない新人ばっかｗ
もうアホかと

19 ：

本当は
・作った人が「ここはコウユーことをしています」って説明をして、仕様を知っている人が「ん、それ違う」って指摘してもらう
場だったん
今じゃ"規約"のコメントの書き方があってる/あってないを確認する場にw

20 ：

>セキュリティ的に問題になる箇所
確かにこれは「やっちゃいかん」って規約でおｋ、
>処理に抜けが無い
>たまたま動いてるけど本当は間違ってる
これを規約で？

21 ：

は >12 ですた。すまそ

22 ：

レビューアー：仕様知ってるSE3人
・ソースはレビュー前にレビューアが任意に
選択し、分担してチェック
・レビューアーがソース見せながら気になるところを順次発表。
・他のレビューアーはそれにコメントしたり適当にだべる
・コーダーは部屋の隅でガクブル
・締めは「じゃあそういうことだから他も直しといてね(-ω-)/」
チェックするのはコーディングダケダヨネ

23 ：

>チェックするのはコーディングダケダヨネ
？意味不明

24 ：

ま、むしろコード自体に云々言うようなレビューは時間ばかりかかってしゃあないからって
仕様通りの動きをするかどうかを寄って集って机上デバッグする場になってます。

25 ：

>17
> コードレビューってコーディング規約(俺様規約も含む)に
> 沿ったコードを書いてるかどうかのチェックの場じゃないよ？
本来はそうだろうけど
大抵はどうでもいい宗教戦争みたいな流れになって
時間の無駄じゃね？って感じになってるのでは

26 ：

ソース読む気のない客がレビューに参加することになってて
そいつへの説明用にいちいちフローチャートとか作成しなきゃいけないので困る

27 ：

>26 やめろw 口頭だけで説明汁

28 ：

>仕様通りの動きをするかどうかを寄って集って机上デバッグする場になってます。
これこそ時間の無駄のような気がするんですが、どうなんですかね？
高級ＳＥ使って仕様通り動くかチェックとか・・・
そんなのコーダーがやることですよね。
いいものはできない気がします

29 ：

>大抵はどうでもいい宗教戦争みたいな流れになって
>時間の無駄じゃね？って感じになってるのでは
レビューアーがおばかさんだと
自分たちの主張の場になっちゃいますよねー

30 ：

俺がレビュアーになった時、間違いを見つけたら、
「ここよく解らん」と流れを切って、
コーダーが間違いに気付くまで黙って顔を伏せる。
本人が気付いたら「なんだそういう事か。」と言って退出。
俺にとってレビューワーになる事は睡眠時間の確保に繋がっている。

31 ：

要するに、XPでやれば時間の無駄も省けるって事だね。

32 ：

ペアプロすればもっと睡眠時間が確保できるのでは？

33 ：

もう一人が寝られるからな

34 ：

適当な用語を使って嫌いな奴をなじればいい。

35 ：

>>33
その場で２人でガヤガヤやるんだから、もう一人が寝られるとか意味不明。

36 ：

じゃあ二人で寝ればいいじゃん。

37 ：

仕様もソフトもろくに理解していない客先の新人が
レビュアなので悲惨

38 ：

コードレビューはいらん
新人教育にしかならない

39 ：

勝手なコードばっかり書くオッサンを
排除するためにやるんじゃねーの？

40 ：

コーディング規約すら守れない糞コーダーやら老害、中華なんかが多すぎるせいで
本来の目的を達成するまえに時間がなくなるのがオチなので、最近はやる意味ない気はする
でも品質結構厳しくなってくると避けられない
糞コードの為のコードレビューする時間つかって
全部自分で書いたほうが間違いなく効率いいと思うわｗ

41 ：

嘘こけw

42 ：

>>40
それは、人を使う能力が乏しいということでは・・・

43 ：

使いものにならない人間ほど「使う能力がないからだ」とか言い出すよね。

44 ：

レビューって形で人を集めてやる意味のあることはやったことないな
第三者がソースを確認するってのは有意義だけど
変数の綴り間違いとかコメントわかりづらいとかこんなロジック自力で実装すんなとかが
ウチで交わされる主な指摘内容だけど、こんなの各自時間があるときにソース見といてで十分

45 ：

品質部がレビューの指摘数を集計してるんだけど、意味あるのか？

46 ：

>>45
テストで不良摘出件数が少ないとマズイのと同じことやってるんだろう

47 ：

使い方わかってない奴らが多すぎる。
少ないとバグを捏造させて数合わせをさせたりとか。
バグがあるはずなんだ、とかさ。ねえよ、現実を見ろと。

48 ：

なぜバグを埋め込んでおかなかったのか。。

49 ：

>>44
個々人のレベルに違いがあり過ぎて、品質を一定にする意味はあるかなぁと思う
でも実際やってみると「何故そうなる！？」という品質以前に出荷できないものが発見されることが多い

50 ：

メンバーのスキルが不明な場合は、度の過ぎた無知もしくは馬鹿を発見するために絶対にやったほうがいい。
そしてそういう連中は排除する。

51 ：

俺が働いてるような業界の底辺だと、だいたいレビューするほうがレベル低いんでどうでもいい感じ。

52 ：

レビュー終了後。
「よく分からんけど動いててテスト済んでるんだろ？じゃいいよ、それで」

53 ：

逆ならあるw
「もうテスト終わってって動いているの確認済みだから直さなくてもいいよね?」
だとさ

54 ：

コードレビューって事前にある程度ソース読み込んで、
レビューの場では1行ごと追ってくぐらいの勢いじゃないと意味無いよな。
中途半端にコードの説明されてもいくらでもごまかせるしな。

55 ：

とりあえず社員がレビューで確認したっていう事実を作っておけばおk。

56 ：

ウォークスルーと勘違いするのはよくないんじゃね？

57 ：

case 1:
goto 1;
case 2:
goto 2;
case 3:
goto 3;
default :
goto err;

58 ：

他人に処理の説明をしている過程で、辻褄の合わないことが出てきて、
自分でバグを発見してしまうことがよくあるな。
自己レビューとか、「ソース見といて」のレビューって、かなり見落としが多いと思う（俺だけかな？）。
要は、誰かに聞いてもらう、ってのが重要だから、レビュアーのスキルは意外と問わなかったりするｗ
もちろん、スキルの高い人に聞いてもらうと、おかしい点をバシバシ指摘されるんで、効率がいいのは確かだけど。

59 ：

それはちょっと・・・
そういうことも確かにあるけど、かなり多いと思うなら、
詳細設計をもっと堅くするとか、ユニットテストを導入してみるとか
の方向で対策した方が良いんじゃ？

60 ：

コードレビューやるから、参加者は対象コードを事前に読んでおくことって指示したら、
外注のおっさんが「そんなやり方聞いたことない、レビュー時に印刷したコード配布して
全員で読み進むもんだ」って切れられて唖然

61 ：

www

62 ：

コードレビューすると何故そうやるのかが全く読み取れないスパゲティを作る中華が多い
コピペコーダーは理解せずコピペするから、意図を聞くと自信ありげな顔で「わかりません」
コードレビューするまえに教育と自習させるべき

63 ：

>>60
知らないなら覚えてくださいでおｋ
未だに印刷して全員であつまって見ていくなんていう
かなり非効率的なことに貴重な時間割いてるとこ多いけど
無駄に人数集まって紙に出して全員でソース追っていくのは時間の無駄が多すぎ
それに実際、昨今はレビューやっても>>19が主だしな
レビューアーに知識がないから机上デバッグがペン1時代のPCを下回る実行速度だったり
そもそもコンパイラが対応してなくて実行すらできないなんてことも稀によくある

64 ：

初代pentiumで動かすとどれくらいか予想ができん

65 ：

>>60
事前にコード読んでる前提のコードレビューのやり方がわからないから、このスレがたったんじゃないかな
俺もやり方がわからないからこのスレ張り付いてるけど

66 ：

俺もやり方知りたい
でも事前の準備に時間がかかるんだったら
ソースを印刷してその場で説明していくのに戻るかも

67 ：

変更履歴の差分をレビューしたら

68 ：

流れを説明してもらわないと理解できないレベルの人間がレビューに参加しても足しにならん
無駄な時間に大人数割くくらいなら、役立たずには雑用でもさせておいたほうが有意義

69 ：

>>68
そもそも、コードレビューは規約云々とか言語的なミスバグとかではないよね。それは書いた人がやるべき事。
そうではなく処理方式（コード）が「仕様（書）とマッチしているか？」ってことを確認するためのものですね。
だから、仕様を把握している人がレビューアをやらねばそもそも無意味。
仕様そのもののレビューなら、そこにあてはまるのは顧客。自身の要望がちゃんと過不足なく入ってるかを確認する
レベルだけどね。

70 ：

>>69
＞そうではなく処理方式（コード）が「仕様（書）とマッチしているか？」ってことを確認するためのものですね。
仕様と合っているかはコードじゃなくてテスト項目書を見ればよい。
コーディング規約のようなテスト項目書から読み取れない部分や、実装方法として
良くない書き方をしているかを確認すればよい。

71 ：

新人の頃いきなりコードレビューやらされた時に先方が競馬新聞持って肩膝付いていたなあ
なめんのも大概にしろよと思ったけど

72 ：

肩肘？

73 ：

a

74 ：10/11/09

ttp://www.atmarkit.co.jp/news/201011/08/nar.html
ttp://codezine.jp/article/detail/5564
ttp://se.naist.jp/events/srw2010/report1.html
ttp://wiredvision.jp/news/201011/2010110821.html