2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コードレビューを依頼されやすくするには

Last updated at Posted at 2024-10-18

概要

  • 私がコードレビューをする際に気を付ける点をあげます
    • 実務では typescript がメインです
    • 「コード」を題材に扱ってますが、設計書のレビューなど、レビューと名のつくもの大抵に共通して言えることだと思います
  • コードレビューの仕方によっては, それが原因でチームの空気が悪くなることもあります. チームの空気を悪くせずにコードレビューを行うことは生産性を担保することにもつながる大事な要因
  • 「コードレビュー = ダメ出し」みたいな感覚を、レビューイへ与えないようにするにはどうするべきなのか、個人意見のまとめ

ポジティブなフィードバックも忘れない

  • あるあるですね. 単純に精神的な不安定さがかなり軽減します
  • 「何ができていないか」を指摘しがちですが「どこまではできているか」は伝え忘れてしまうもの. 感情のない AI ですら,「何は正しかったか」というフィードバックがないと成長しないんです. 単なる感情論ではなく、「どこまではできているか」という点数を、点数を出さずに相手に伝えるための表現です
  • また、レビュワーが知らなかったことを伝えるのもよきです

具体例

  • 効率的な処理ですね!さらにパフォーマンスを鑑みて、--- してみて下さい
  • この変数 だけ , 現在のままでは後から見た時に ,,,
  • こんなふうに処理実現できるですね!!! :eyes:

自然と褒めるのがめちゃ上手い人もいますよね. もてそう

「指摘する」というより「気づかせる」

  • 自身の行動に対して、受動的に改善点に気づくのと、能動的に改善点に気づくのであれば、後者の方が心理的にプラスですし、記憶に定着しやすいのでその後の実力向上にも繋がります
  • ただ、人によっては気づくのに時間がかかったりするのが難点ではあります

具体例

UI の修正が入った際に、説明欄にどこを修正したかだけ書いて、具体的にどう変化したかのキャプチャがなく、私としては (どう変化したのか、どうせ作業する時のついでにキャプチャ載せといて欲しい) と思っており

動作確認したついでに、変化内容のキャプチャメモっときますね

と、PR にコメントで載せておいたところ、そのうち PR 発行者が説明欄に貼ってくれるようになりました。

具体例は「遠回しの指摘」になりうるので, 関係性のよってはあまり理想的な例ではないかもです

これに関しては「理想論」に近いので、全てが能動的に気づかせるのは時間かかって現実的ではないです.

レビュイーが判断すべきことを増やさない, 残さない

  • 端的に言えば、「対応しないといけないの?別にいいの?」とレビューイに思わせないこと
  • 「ほんとはここはこうしたほうがいいんだが、やれって言うには些細すぎるしな,,,」という動機から、つい「〜してみてもいいですね」なんて言い方をしてしまいがちですが、そのコメントを受け取る側は対応に困ります。「判断する」という思考リソースをいたずらに増やさないこと。
    • もちろんチーム内の言葉の文化にもよります。「〜してもいいですね」が、実質 MUST 対応で浸透してるならそれでいいと思います。
    • ただ、新規参画メンバーはそんなこと知らなったり、長くいるメンバーでも実は曖昧だったりするので、はっきりどっちの対応か伝えるようにすべきというのが個人意見です。
  • 自分がコード品質管理のポジションを担っている以上、この修正は「今してほしい」or 「タスク化して後でまとめてしよう」かを明確に伝えましょう

でもつい判断まかせちゃいがちだよね. わかる

客観的判断に基づいた意見を出すように意識

  • 「このままでは わかりにくい ので」や「読みにくい」は、主観に基づいた意見のように見えます
  • 実際、それは自分だけが思っている可能性があります. 他の人が見た時や、将来の自分が見た時も納得できるような、客観的根拠と主にコメントするとよい
  • もし主観的な意見の場合、その旨も一緒に伝えるとよき

具体例

const isShow = ... // <- 何を show するかどうかのフラグなのかわからないので、 isShowBtn と明示的な名前にしてください

interface ComponentProps {
  setData: (data: unkown) => void // <- Component の Props で イベントハンドラーは on* という命名規則が通例です (React がどっかで資料出してます)
}

または、コメント時に

個人的な感覚で恐縮ですが、...

と添える

とりあえず全てのコメントにリアクションしとく

  • コメントでなくとも、 :thumbsup::bow: :tada: あたりを残すだけでも印象かなり変わります. コードレビューに限った話ではなく、slack 等の社内コミュニケーションにおいても同じですが

結論

仲良く開発したいが、仲良しこよしで終わらず、互いに切磋琢磨したい

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?