レビューアーとしての立場

今、チームではどちらかというとレビューアーとしてレビューをする立場が少なくない。そんななかで最近読んだ記事が良いなと思ったのでメモがてらブログにも残す。

https://qiita.com/emjo1804/items/48f6e78237a04684ab38

詳しいことは元記事を読んでいただくとして、ここには感想を書いていく。

人格攻撃と誤解を与えかねない説明

残念な事だが、アカデミアにおいても、産業界でも人格攻撃をしている人を見かけたことがある。「攻撃」というとなんだかそれそのものが悪い様に聞こえるものの、人格攻撃をしている人はしばしば、その人の事を思い指導的に発言しているからまた難しい。

要するに、人の性格や習慣に対して、「ダメだし」をすることがあまり建設的でないということ何ではないかと個人的には思う。

なんでこんなこともできないの？

こう発言する人が善意でそれを発言しているとするならば、以下の通りに発言を改めると良いかも知れない。

これはできるようになっておくとよいでしょう。

当然できていて欲しい事ができていない事を両方とも指摘しているものの、後者はより次のアクションを具体的に示しており、良いアドバイスと言える。

理由の説明の欠如

「ここができてません」だけ残すレビュー。何が悪いのかを含め確認したいとき・相手に期待するときは、理由を聞くとかその人の死角をついてあげるというのがレビューアーとして良いのかも知れない。

#include <stdio.h>
int main(void){
  char a[3] = "abc";
  char b[3] = "abc";
  strcpy(b, "abcdefg");

  return 0;
}

こんなプログラムがレビューに出てきたとき、メモリオーバーフロー（ここではCの例なのでバッファオーバーフローとかバッファオーバーランが正しいのかな）が指摘事項としてあると思う。そのとき、単に「L5に脆弱性かバグがあるので確認してください」だけではちょい不親切。 「aとbの内容はデバッガを用いて期待したものか確認しましたか？」とレビューを残した方が、レビューイーの試行・思考を引き出せるし、具体的に行数を突き止めるところからできたりして力が伸びそう。

レビューアーをしていると、丁寧に説明するのは時間がすごくかかっちゃうなあと思うこともあるものの、チームメンバーも自分と同等以上に仕事ができるようにならないと、チーム全体としての効率は上がっていかないことをレビューアーも知っておくべき。

よくできているところとそうでないところを両方取り上げる

褒める、という言葉はなんとなく上からな気がするので、よくできているところとそうでないところとここでは書くが、レビューではこの両者をバランス良く配置しなければいけないと思う。良いところだけ書いて、良くないところを書かないレビューもダメだしその逆もだめ。 レビューイーが熟練者なら良くないところのみの指摘でもいいのかもしれないが、少なくとも初学者においては両方書かねば文字通り「右も左も分からない」のだから「良い悪いが分からない」ので、両方レビューで拾い上げるのがよさそう。 自分が初学者だったとき、誰かの太鼓判があると安心したり、不安なコードに指摘が欲しかった時を思い出すといいのかも知れない。

個人的にどういったレビューがいいという完成した定義はないけど

ないけど、それを常に考えていく事が大事なのかなあって思う。正直、自分のレビューは立派なものと自分自身評価してないし、もっと改善するところがあると思う。レビューイーがコードを直すようにレビューアーもレビューの仕方を改善していきたい。