島までは遠い

佐藤正志@サークルアラウンドのことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる予定。しばらくは工事中。

コードレビューの仕方は一定ではないと思っています

f:id:ms2sato:20180113201511j:plain little-hands.hatenablog.com

とても素敵な切り口で好きです! 多分表明されていない文脈として存在していると思うのですが「レビューによって育てる」という目線が強くなっていると感じました。

私はプログラマのトレーニングを生業としつつ、受託の開発にも参加しています。トレーニングは「現役のプロが全てのコードをレビューする」という触れ込みなのでレビューしまくる形になります。受託現場でもコードを書くよりもレビューする立場にあることは多いです(たまにそれがストレスになるくらいです。もっと私にコード書かせて!w)。

同じ私個人ですが、実は上記の二つのパターンでレビューの仕方、アプローチは異なります。

トレーニングの場合(育てたい)

  • 問いかけが中心。
  • 直して欲しい場合には勿論、正しい場合にも理解の確認をする為に問いかけることがある。
  • 考えてもらうきっかけを作ることをレビューの中で意識している。座学で教えらえるのではなくて生の学び。

受託の場合(バランスよく進めたい)

  • 指摘が中心。
  • 今の締め切り感などと合わせて指摘の深さが変わる(「まぁ、いっか」の程度が違う)。レビューの為に開発者が進捗遅延のストレスを感じないようにしたい。
  • こちらが「どうして欲しいか(直して欲しいのか、意見を求めてるのかなど)」を明確に示すことを意識している。曖昧だとレビューの突き返し回数を増やしてしまう。
    • 最近は場合によって「提案PR」をすることもある。コードで示す方が早い時もよくあるので。

共通

  • 相手にあまり冷たく見えるような表現は避けています。文意は明瞭でも、表現方法はある程度考慮します。
    • 「xxxしてください」よりも「xxxにしましょう」的な表現が多い気がします。
  • その為もあって「どうしてもここは大事」というところはあえて無感情な指摘の仕方にすることがあります。
  • 罵倒・嘲笑などはもってのほか(なんか世間にはそういうレビューする人もいる様子なので念のため)。

余談ですが

プログラマにとって、コードレビューの学びの効果は絶大だと思っています。コード品質を上げながら同時にメンバーを成長させることができるとすれば、長期目線だとコードレビューの費用対効果はすこぶる高いのではないでしょうか。

たまにまだこれからなチーム/プロジェクトのコードを見せていただくこともありますが、そういう場合はメンバーに安心感も与えることができるようです。そういう意味でも先達にコードを見てもらえることは大事にした方が良いと思います。もしも見てもらえる人いないチームがあったら、弊社なら声かけもらえれば何かお役に立てるかもしれません(と、ちょっと宣伝)。