レビュアーのコメントについて

そう捉えられる余地はありますね。

マーフィの法則ですね

事実ベースだとしても、感想のように言うとまろやかになりますよ。
インターネットではキレられることもありますが。

txt
1このようなコードの書き方は問題あるかと思います。
2複雑で可読性も非常に悪いコードなので、修正をお願いしたいです。

PRを上げる前に改善が必要だと思ったところは、再度確認をしてからPRするようにお願いいたします。

この文は不要にも思えます。
誰にとっての｀改善｀なのかよく分かりません。｀気になったところは｀とかに置き換えても良いと思います。

再度確認をしてからPRするようにお願いいたします。

・再度確認をしてからRPするようにしてください。
・RPをする前に再確認をお願いいたします。

とかでいいんじゃないかな、まあどっちでもいいですが回りくどいと感じる人もいるかもしれません。

煽りつつ丁寧語で喋るなら自分は以下のようにしますね。

txt
1コードを確認致しました。
2書き方に問題がございましたので修正をお願いいたします。
3複雑で可読性が低くなっていますので、シンプルで読みやすいコードにして頂けると幸いです。
4
5また、込み入っており申し訳ございませんがPRを上げる前に問題ないか確認していただけないでしょうか。
6お忙しい中恐縮ですが、よろしくお願いいたします。

あえて除外したのか、単に書き漏れただけなのかわからないですが、どのような背景があるかも重要だと考えます。

例えば、コードの作者側が同様の問題を何度も繰り返していたような場合、言葉がきつくなるのも致し方ないところです。

このレビュアーのコメントについて、どう思いますか？
きつい言い方ですか？

あなたの立場は何でしょうか？レビューア？レビューイ？第三者？

このようなコードの書き方は問題ありですね。
複雑で可読性も非常に悪いコードです。修正をお願いいたします。

PRを上げる前に改善が必要だと思ったところは、再度確認をしてからPRするようにお願いいたします。

ニュアンス次第かなと思いますが、最初の二文は”きつい”というよりもっと具体的に指摘した方が良いと思います。最後の文は少し嫌味っぽいかと思います。只、他の方も言及されているように今までのやり取りやレビューイの態度等によってはそう思わないかもしれません。

投稿文を読んで思ったのは「もしかしたら前回のレビューの結果が反映されていないのでは？」「コード規則が守られていないのかもしれない？」ということです。
”非常に”や”再度確認を”の言葉は強めの言葉遣いだとは思いますが、そこに至るまでの経緯があるのではないか？と推測します。

またレビューのコメントが上記で全てだとしたらこれだけで修正するのは無理でしょう。そうではなくこの後に詳細な指摘・指導があるなら印象も変わってくると思います。

背景
レビューコメントはこれだけ
今回が最初のレビュー

実際に対面/リモートどでのレビューがあったのでなく、このコメントのみであったとした場合の感想です。

このようなコードの書き方は問題ありですね。
複雑で可読性も非常に悪いコードです。修正をお願いいたします。

どちらについても、指摘するのであれば具体的に記述すべき。具体例がまったく無いのは問題ありですね。
また、このような主観的で抽象的な内容だと、指摘どおりに修正したかどうかの判定もできません。

PRを上げる前に改善が必要だと思ったところは、再度確認をしてからPRするようにお願いいたします。

何を言っているのかわからない。
事前に根回しをしろということでしょうか？そういう文化なのかもしれないが、レビューのコメントに書くことではないと思う。

#4

tom

総合スコア8

投稿2025/05/14 21:54

背景
レビューコメントはこれだけ
今回が最初のレビュー

情報が全体的に不足しています。

あなたの立場は何でしょうか？レビューア？レビューイ？第三者？

と書かれているのに、それすら書かないのは何なんでしょうか。
私はレビューされた側だと思っていますが、誰もその視点で書いてないので、もしそうだったら意味がなくなる可能性すらあります。

あと、これはどのような状況でのコメントなのか分かりません。
「GitHubでOSSのPRを送ったら、これだけ返された」なら分からなくもないですが、そうでなければ事前に何かあったはずです。

具体的な理由なしで、具体的な情報が無いので、「まっとうに議論するつもりはない」と思われますよ。
まあ、雑談のつもりなら別にいいですけれども。

#4

tom

総合スコア8

投稿2025/05/14 21:54

背景
レビューコメントはこれだけ
今回が最初のレビュー

背景
レビューコメントはこれだけ
今回が最初のレビュー

”最初”とは今回のレビュアーからレビューを受けたのが最初という意味でしょうか？それとも今回のコードの初回レビューという意味でしょうか？
仮に最初の意味だとしても、過去の他のレビュー結果が共有されてるとするとそれによってきつ目の言い方になってしまったかもしれませんね。「非常に悪いコード」という表現は中々しないと思いますが、そのレビュアーの方は普段から厳しい物言いの人なのでしょうか？

例え本当にひどいコードだったとしても、レビューを受けた人がレビュアーのコメントで傷ついたのであればその事実は伝えるべきだと思います。相手を責めるではなく「こう感じた」「こうして欲しい」と伝えるのが良いかと思います。

レビュアーと実装者の能力や関係値によりますが、パット見は淡白で冷たい感じはします。
ただ、信頼関係と能力が釣り合っており、お互いが納得していればなくはないコミュニケーションのように感じもします。

そのうえで自分の考えとしては、レビュアーのほうが基本的に能力が高いと思うので、レベルを実装者に合わせた言い方にする必要はあると思います。
なので、どこのコードがどういった理由で問題があるかは伝えないと、同様の指摘を今後も続けなければいけないし、無駄に考える分パフォーマンスは落ちると考えてます。

背景として以前にも同様の指摘があったなら、事細かく書く必要はないが、それでもどの部分が指摘箇所かは教えてあげないと、意図しない方向の修正に何時間もかかる結果になるのも考えられるなと思います。

このレビュアーのコメントについて、どう思いますか？
きつい言い方ですか？

という質問内容からズレていってるようにも感じますが、
こういったトラブルを事前に防げなかったのかはひとつの観点としてありますね。
こういう書き方は禁止ですだとか、規約が決まっているなら防げることです。
内容からしてそのレビューをしてる人がイライラしていて余裕が無さそうなのは明らかです。
ただ、悪意を持っているわけではないと思います。

まあでもそんなレビューコメントなんて過去のものです、
気になるならちゃんと話し合ったり忘れたり謝ったりして、
あんまりこだわり続けても意味無いですよ

このようなコードの書き方は問題ありですね。
複雑で可読性も非常に悪いコードです。修正をお願いいたします。

→実際はもう少し踏込んだコメントなのかもしれませんがコードの文脈を踏まえたとしても、具体的な悪い根拠が汲み取れないため修正が難しいと感じてしまいました。
また、相手の感情を不要に逆撫でする可能性がある文書は仕事である以上、関係値に依らず控えた方が良いと感じました。
『このような根拠でこう思いましたが、いかがでしょうか？』
あるいは断定できる場合
『このような根拠で修正が必要そうです』

上記のような言い回しをする事で、相手も根拠が分かれば修正し易いですし成長にも繋がり信頼を損なう可能性は少ないと思います。
私がいままで本当に優秀だと感じた開発者は、コミュニケーションにおいても上記のような配慮が自然と出来る方が多かったです。

逆に相手との関係性を壊すような物言いしかできない方は経験上直ぐにチームから離れる、もしくはチームから人が離れてプロジェクトが失敗します。

チームギークという書籍にHRT(謙虚、尊敬、信頼)という言葉が出てきますが、この事例にも適用されると思います。
(ただ、レビュイーに関してあまりにも仕事にならず努力も見られない場合は論外だと思います)

PRを上げる前に改善が必要だと思ったところは、再度確認をしてからPRするようにお願いいたします。

→こちらも同時に修正根拠となるコーディング規約や参考コードが提示されている、あるいはタイポや不具合が繰り返し見つかる場合の指摘としては正しいと思います。
トリッキーなコードや命名センスなどについては努力でカバー出来るため、リーダブルコードなど学習リソースを提示できると親切だと思います。
(こちらもレビュアーが負担できるキャパシティを外れる場合は、採用が失敗している可能性があります)

恐らく、このコメントの前後関係（過去同じ指摘をしているなど）あるかもしれませんが、
一般論として、

複雑で可読性も非常に悪いコードです。修正をお願いいたします。

複雑性および、悪いと断言している具体的な観点が欠落しており、建設的に改善に向かうべきコメントとしては適切でないように見受けられます。
私なら、具体的コードを示し改善を促しますが、もし似た具体的指摘を過去受けているとしたら、相談された方が結果的に仕事がスムーズに進むかと思います。