INTP型のブログ

苦味があるな?

コードレビューって無駄じゃね?

いやいやそんなわけない、品質を保つためには必要だ

 

っていうのはわかるんだけど、作業時間とか見てると結局ペアプログラミングしたほうが教育効果も対人ストレスも減るくね?と思う

 

コードレビューのメリットはおおまか3つという認識で

 

1. 品質を保つ
2. 教育効果がある
3. テキストでやり取りができる(通話したくない勢向け)

 

これらかなと思う。

 

1,2の効果に関してはペアプログラミング(リモートだとしてもgit共有してるだろうから、画面共有でいい)でも十分に発揮されるという認識で、差異が通話 or テキストしか無いと思っている。なんなら通話のがまじで聞くほどでもない細かい要素を聞きやすいんで教育効果が高いとすら思う。品質に関してはペアプログラミングしつつレビュアーが実装していくほうが任せるより高いはず(コードレビューの仕組みが正常に動くならそうなる、レビュアー >= レビュイーなので)

 

で、これへの最大の反論はペアプログラミング > コードレビューで時間がかかる。だと思うんだけど、実際はそんなこと無い気するし、ペアプログラミングで間違いに気づいた人が「こう直したほういいと思うだけどそれで良い?」「いいよ」で直していったほうが開発スピードは早いと思う

 

そもそも実務は開発のために行われるべきであって、能力を養う場ではないはず。

 

弊社社長がコードレビュー対応のやり取りで5営業日タスクを10営業日使ってたんだけど、これに本当に意味ってあるのかと思う。(余談だけど鬼サビ残 + 休日出勤しててマジでやめてほしかった。こういうことして頑張ってる雰囲気出すやつが一番嫌いなんだよな、サビ残するなら周りから見えない形でやってほしい(わざわざ退勤後深夜にslackを動かしてたので))

 

1. レビュアーが提出されたコードを読む
2. 指摘点をまとめる
3. ペアプログラミングしつつレビュアーベースでコードを修正する

 

であれば、どれだけ長丁場だとしても1日はかからないはず。(というかペアプログラミングして1日以上かかるPRは分割したほうが良いと思う)

 

テキストベースでコードレビューした場合の

 

1. レビュアーが指摘する
2. それを直したコードが上がってくる
3. 再度見直すことで新たな指摘点が見つかる

 

このサイクルでコードの品質が向上するという見方もできるけど、3で見つかるようなものはテストや保守で見つかっていくべきものなような気がする

 

コードレビューにせよペアプログラミングにせよミスは残るという認識で、だからこそテストをしていくわけだから、だったらコードレビューが何度もサイクルして開発速度が著しく遅くなるよりも、やばい要素を拾うだけで十分な工程じゃないかと思ってしまう(やばい要素を拾えないのは単にレビュアーの力不足という話だし、人間にコードレビューは早すぎるという話でもあると思う)

 

なんにせよ実務は開発のためにあるべきであって、スキルアップのためにあるものじゃない。

 

というかスキルアップするやつはペアプログラミングでも十分上がるし、しないやつはコードレビューきても検索かけてコピってきたコードをベタ貼りするだけだろうから、形態によって成長度合いに差が生まれるように思えない。というか生まれたとしてもペアプログラミングのほうがレビュアーからの質問にレビュイーが口頭で答えることになるので、アウトプットの発生により記憶の定着率が高くなるはず = 教育効果が高い

 

話しそれたけど、実務は開発のためにあるもので、開発最中に開発速度を遅くするような工程があるべきじゃないと思っている。レビュアーが指摘するということは脳内にこうあるべきという想定があるはずで、だったらそれを自らが実装したほうが全体の作業時間は間違いなく短いはず

 

コードレビューが1回や2回のやり取りで終わるということはほとんどなく、大抵は何度も繰り返されるような認識があるし、テキストによる曖昧な指摘で発生するすれ違いで更に時間が浪費される印象がある

 

強いて言うならペアプログラミングは通話という点が特異であるけど、テキストベースよりは通話のが温和な印象を受ける傾向がやはり強い

 

世間体を気にする人の中には、チームメンバー全員が閲覧可能な場所だと形式張ったテキストを書いてしまい冷たい印象を与えてしまうが、1対1の対話だと非常に親しみやすい雰囲気の人もいる

 

逆に通話だとうざいけどテキストだとめちゃめちゃいい人というのはほぼ見たこと無い。これは主観だけど、通話で嫌なやつだと思う人はテキストでも嫌なやつだし、逆にテキストでいい人だと感じさせてくれる人は通話でもいい人だ

 

だからペアプログラミングでは悪い印象を与えてしまうというのなら、テキストベースのコードレビューをしたならパワハラモラハラ一歩手前の最悪コミュニケーション待ったなしなのではと思ってしまう。そういうやつはチーム開発に参加しているんだからコーディングスキルより協調性を磨いたほうが良い

 

※ここだけは反論できないというか、うーんとなるのは通話だと気疲れしてしまう勢力だけど、まあそれは知らんということで。一人で開発しなさいという感じになる

 

まとめ

 

「コードレビューするより、ペアプログラミングでレビュアーがレビュイーと相談しながら実装書いたほうが開発速度早いし、チームメンバーのメンタルも良好なんだからテキストベースでのコードレビュー無駄だろ」

 

っていう話でした。

 

慣習としてコードレビューはテキストベースというのがあるので、固定化されたチームメンバーじゃないとこういう文化を作るのは難しいだろうなぁと思います

 

あとOSSとかの場合は通話が難しいということもあると思うので、テキストでやり取りせざるをえないと思いますが…

 

朝会だの定期MTGだのやって口頭での意見交換の場を設けるぐらいなら、コードレビューのタイミングでその場作ったほうが良くねというのもあったりします。あれらはマジで無駄で、10人ぐらい集まったりすると、発言する人間としない人間が固定化されて無意味すぎる

 

発言する人間からするとみんなもっと喋ってほしいと思うけど、実際10人が全員些細なことまで持ち出したら関係ない人間を巻き込んで時間食うことになって凄いことになるからね。Meetは3人までとかにしたほうが間違いなく良い。共有したい情報があるなら参加者が要件まとめてドキュメント共有すればいいだけだし

 

てか主観として五月雨でレビューの指摘が発生していくの無駄すぎるから、ペアプログラミング1回or2回で強制終了とかにしたほうが時間が浪費されなくて良い。コードレビューという名目であら探しをすれば無限にできてしまうし

 

そんな感じのことを思ってました。こうは思っても現場を変える力もなければ責任を背負う気概もないし、そもそも自営を潰した自分が悪いので組織の流れに身を任せるだけなのですが…