システムエンジニアとして働いているとコードレビューは避けられないものですね。
そして、時にはコードレビューという工程がイライラ製造につながってしまうことがあります。
これはレビュワー(レビューする側)とレビュイー(レビューされる側)の双方に言えることですね。
レビュワー
同じ指摘を何度もさせるな！
レビュイー
そんな細かいところを直して何の意味がある！
僕自身、レビュワーもレビュイーも経験がありますが、コードレビューでイライラするのはコミュニケーション不足では無いかと感じています。
テキストベースでのやり取りだと、どうしても相手の意図が読み取れないことが多いですからね。
というわけで今回は、コードレビューでイライラしないための方法についてお話ししてきます。
コードレビューでイライラするのはコミュニケーション不足が原因？
コードレビューは基本的にテキストベースで行ごとにコメントを残していく形式ですね。
テキストベースでのやり取りというのは、直接話すのと比べて、圧倒的にコミュニケーションが不足していると言えます。
日常生活で言うなら、たとえば、LINEでやり取りするのと電話で話すなら、電話の方が伝えられる情報量が多いのは明らかです。
テキストベースだと、要点だけをまとめて伝えようとするからですね。
このやり方だと、コードレビューでは特に、自分が想定した通りに相手に伝わらないことがよくあります。
レビュワー目線で、「こう書けば大丈夫だろう」と思っていても、レビュイー目線では「これってどういう意図の指摘なの？」と思ってしまうようなケースですね。
そのため、レビュワーには相手に自分の意図だとか指摘の理由というのを伝えることが求められます。
また、時にはレビュイーの実装方法の意図を聞く必要もあるでしょう。
自分が想定した実装では無いからといって、必ずしも誤りとは限りません。
必要に応じて、レビュイーがどういう考慮をしながら実装したのかを把握することも大切です。
逆に、レビュイーはレビューの意味が分からなければ、レビュワーに質問しなければいけませんね。
不明点や疑問点を解消するのは、システムエンジニアの基本とも言えます。
レビュイーがイライラするケースと解決策
コードレビューはレビュワー、レビュイーの双方がイライラする可能性のある作業ですね。
では、レビュイーはどういう時にイライラするのでしょうか？
- 細かい指摘
- 修正の必要性が分からない指摘
- 自信のある実装で受けた指摘
- 言葉使いの悪い指摘
①細かい指摘
誤字脱字の指摘、コメント文の修正、関数名や変数名の指摘などといった、製品の品質自体とは関係無いような細かい指摘を受けた時に、人によってはイライラしてしまうことがありますね。
「細かい！そこを直す手間を考えてほしい」
「動けば良いんじゃないのか？」
「それくらいの指摘なら自分で直せ」
といった感じでしょうか。
しかし、細かい指摘をするのにも意図はあります。
僕の場合は基本的に可読性の向上を目的としていることが多いですね。
製品が正しく動くなら、その場では特に問題はありません。
ただし、以下の点を考えると、直せるうちに直しておきたいものです。
- 後々改めてそのソースコードを見た時にすぐに意味を理解できるか
- 後任の開発者がそのソースコードを見た時に読みにくくないか
ソースコードのメンテナンスのしやすさを考えると、細かい点も直しておいた方が親切ということですね。
実装した本人が理解できれば良いわけではなく、他の人が見ても理解できるソースコードになるように指摘しています。
また、「それくらいの指摘なら自分で直せ」という意見も聞きますが、それはレビュワーとしても「レビューされる前に自分で気付いて直してほしい」という思いがあります。
誤字脱字のような細かい指摘をするというのはレビュワーにとっても面倒ですからね。
そもそも細かい指摘を受けないためには、レビュー依頼を出す前に自分でしっかりチェックすることが重要と言えるでしょう。
②修正の必要性が分からない指摘
「ここはこういう実装に変えてください」、「ここの文字サイズは○○にしてください」といった指摘の中には、「なんでその修正が必要なの？」と感じるようなものが混ざっていることが時々あります。
それを見た時にレビュイーとしてはイライラしてしまうこともあるわけですね。
「そこを直して何の意味がある？」
「それってあなたの好みでは？」
「動けば良いんじゃないのか」
といった感じでしょうか。
このような、レビュイーに意図が伝わっていない指摘こそ、十分なコミュニケーションが求められます。
そして、レビュイーはイライラしたまま指示にしたがって修正するのではなく、質問することが大切です。
そのような指摘には以下のようなパターンが想定されるからですね。
- そもそも仕様と違う実装になっていることの指摘
- 性能面でもっと良い書き方があるという指摘
- バグが発生しないための指摘
- コーディング規約に合っていないという指摘
- ただ単にレビュワーの好み
- 指摘誤り
上の4つに関しては、修正が必要ですね。コーディング規約に関しては細かい指摘はイライラするかもしれませんが、ルールとして定められている以上、修正しなければいけません。
問題なのが、下の2つのケースの場合ですね。
まずは、レビュワーの好みのパターン。
好みの違いであれば、どちらの書き方で進めるかの認識合わせをし、その後はその書き方で統一するというところまで決めておくと、もう同じ指摘でイライラする必要はありませんね。
次に指摘誤りのパターン。
レビュワーも人間ですから、ミスをすることがあるわけですね。
誤った指摘の可能性もあるので、指摘が腑に落ちなければレビュワーに確認する必要があります。
確認せずに指示通りに修正したら、余計なバグを生むかもしれませんからね。
というわけで、指摘の意図が分からない場合はレビュワーに質問してみましょう。
③自信のある実装で受けた指摘
ある程度経験を積むと、自分の実装にもある程度自信を持てるようになってきますね。
自信があるからこそ、レビューで自分の実装の誤りを指摘されると、イライラを感じてしまうこともあるでしょう。
しかし、実装の誤りであれば自分の能力不足ですから、仕方ありません。
次は同じ指摘を受けないように気を付けましょう。
むしろ、そこでイライラを感じるのは、自分の向上心にもつながって良いかもしれませんね。
ただ、イライラを周りにぶつけないように注意は必要です。
④言葉使いの悪い指摘
レビュワーの性格も人それぞれで、コードの指摘をしているのに、客観的に見たら人格否定にも見えるような指摘の仕方をするような人もいるでしょう。
それに対して、レビュイーはイライラを感じてしまうこともありますし、人によっては傷ついてしまうこともあるでしょう。
レビュイー側の対策としては、相手の言葉使いではなく、指摘内容に注目することですね。
言い方は簡単には変えてもらえないでしょうから、そこを気にしたら自分が疲れるだけ。
自分の頭で「この指摘はつまり、こういうことを言いたいんだな」と上手く変換しましょう。
また、あまりにも言い方がひどい場合は上司などに相談するのも重要です。
余計なストレスを抱えないためにも、労働環境の改善は大切ですからね。
レビュワーがイライラするケースと解決策
ここまではレビュイーがイライラするケースを見てきましたが、一方でレビュワーはどういう時にイライラするのでしょうか？
- 同じような指摘を何度もしないといけない
- 指摘した箇所が直っていない
①同じような指摘を何度もしないといけない
「前も同じ指摘をしたのに、また同じミスをしている」ということが繰り返されると、レビュワーとしては段々イライラしてきます。
僕自身もイライラまではいきませんが、レビューしている時に誤字脱字のようなちょっとした指摘箇所が10～20個出てくるとストレスを感じてしまいますね。
他にも、「if文のネストが深い」とかも何度も指摘することがあります。
「これくらいはセルフチェックで気付いてほしい」というのが本音です。
指摘箇所が多いほどレビューに時間がかかってしまいますし、レビュワーとしては、仕様の誤りが無いかなど、品質に関わるところをメインで見たいですからね。
解決策は、その指摘の重要性をレビュイーに理解してもらうことでしょう。
特に新人のうちは仕様通りに動くものを作るというのが精一杯で、細かい部分まで意識できないということがありますからね。
ただ指摘を繰り返すだけでなく、理由や重要性も伝えながら指摘していくことで、相手も意識するようになっていくでしょう。
そして、レビュイーも人間ですから、意識していてもミスをしてしまうことはあります。
ある程度は許容できるだけの広い心を持ちたいですね(僕自身もですが)
②指摘した箇所が直っていない
レビュー指摘した後に、「レビュー箇所を修正しました！」と再度レビュー依頼が来てソースコードを見てみると、問題点が直っていないということがあります。
こうなると、「指摘したのに何で直ってないんだ！」とイライラしてしまうこともあるでしょう。
ここで意識したいポイントが、「そもそもレビュイーに修正意図が伝わっているのか？」ということですね。
テキストベースでの指摘だからといって、色々と説明を省いてはいませんか？
僕自身も何度も経験がありますが、たとえば「この処理は○○でしか使わないから、共通部分には書かないようにしてください」と指摘しても、処理の一部が共通部分に残っていたりしますね。
なぜ共通部分に書いてはいけないのかなど、理由だとか問題点まで説明しないと、レビュイーがその意図を理解してくれないことがあります。
その結果、同じ指摘をもう一度しないといけないということがよく発生しましたね。
相手と自分の理解度が同じとは限らないので、自分基準で指摘をしてはいけないということを学びました。
テキストで説明するのが大変な場合は、口頭で説明するのも良いでしょう。
というか、口頭の方が効率が良いです。
コードレビューは必要に応じて、口頭で行うべき
先ほども言いましたが、コードレビューは必要に応じて直接話した方が効率が良いです。
簡単な指摘ならわざわざ話さなくてもテキストベースで完結できますが、実装方針に関わる部分などはテキストベースで長々とやり取りをするよりも、数分会話した方が早いでしょう。
テキストではコードの指摘箇所を示し、指摘内容をメモ程度に残しておく。
「詳しくは口頭で説明します」という形にした方が認識の齟齬無く実装を進められるので、双方にとって好都合です。
近年はリモートワークが主流になってきてコミュニケーションも不足気味ですから、会話出来る時はしておきたいですね。
まとめ
さて、今回はコードレビューでイライラしないための方法についてお話ししてきました。
簡単に言えば、十分なコミュニケーションを取るのが重要ということですね。
テキストベースだと冷たい印象を感じてしまったり、意図した通りに相手に伝わらないこともあります。
上手くかみ合わない場合は、直接話しながらコードレビューをするのも大切ですね。
