チーム開発（特にweb開発）を行なっていると、githubのPR（プルリク）で、２次的な問題点が発生する場合があります。
それは、コードレビューをする場合に、適切なコードレビューができているかという点ですね。
そんなコードレビューのやりかた指南の書籍があったので読んでみました。
レビュー
★★★★☆
ストーリー仕立てでの進行で非常に読みやすい本でした。
プルリクの中にもパワハラやモラハラなどは存在していて、コードレビューをする側の人はいわゆるメンター、管理職、先輩、上司・・・などの上の立場の人が大半ですが、こうした人の所作によって、そのチーム開発がうまくいく場合、いかない場合などがあることは、開発経験者または今まさに現場をやっている人はよく理解できると思います。
そんな、上に立つ人が読むべき本として、非常にいい内容だと感じました。
ただ、中に書かれている内容は、技術的というよりは、コミュニケーションスキルアップの内容に近く、レビュアーのコメントでレビュイーがどういう気分になるかということが延々書かれています。
でも、人間関係ってこういう些細な一言、相手のことを考慮できるかできないかで、その後の結果が大きく変わってくるので、機械的に思えるプルリクにも、ちゃんとコミュ力を発揮する必要があるというのがよく理解できる書籍でした。
この書籍から学べるポイント
コードレビューの難しさと利点
コードレビューの5大ルール
1. 決めつけない
2. 客観的な根拠に基づく
3. お互いの前提知識を揃える
4. チームで仕組みを作る
5. 素直さを心がける
スムーズなコードレビューを行うための守るべきルールです。
性善説で考える
不具合が発生した場合、コードを書いた人を責めるのではなく、バグを憎むようにするというのは、エンジニア誰もが考えます。
コードレビューも、こんなコードを書くヤツが悪いのではなく、能力不足からくるコミュニケーションギャップであると考えることで、相手に対してではなく、書かれたコードに対してレビューする気持ちになることができます。
相手の人格そのものを否定してしまう、レビュワーもいるみたいですが、そういうコミュ力では、いいコードレビューはできないでしょう。
自分の考え・意見を添える
言葉足らずでのコメントを返すと、レビュイーは悪い様に受けとらえがちです。
悪い点ばかり羅列するのではなく、悪い場合に自分ならどういう風にコーディングをするかを提案することで、悪く受け取る事は避けられます。
言葉足らずで、質問のラリーがお互いに続く様なコミュニケーションは避けましょう。
聞きたいことを絞る
箇条書きで、複数の気になる点を羅列すると、受け取った側は、お腹がいっぱいになります。
本当に指摘をするべき内容をできるだけひとつに絞ってコメントする様に心がけましょう。
また、複数あるのであれば、コメント事態を複数に分けるというのも悪くないでしょう。
その方が１つずつにレスがつけられるし、受け取る側もそれぞれに対して納得することができるでしょう。
あれもこれもは、受け取る側にとってのストレスが膨らむだけのようですよ。
テンプレートを用意する
チームルールとして、コードレビューの内容をテンプレート化するというのは、非常にいい施策です。
・やったこと
・やってないこと
・動作確認
・確認手順
・その他
あくまでサンプルですが、こんな内容でのコメントテンプレートを使うことで、さほどコミュニケーションを気にすることなく、やりとりできるようになります。
相手の理解の段階を踏む
クイズを出さない
レビュアーは、レビュイーに対して、疑問をそのまま問として投げかけない様にしましょう。
「これどう思います？」とか「どっちが正しいと思います？」これらは、答えのないクイズとして受け取られがちです。
こうしたオープンクエスチョンではなく、クローズクエスチョンを心がけましょう。
あとがき
開発現場の数ほど、問題数は無限に存在します。
でも、そんな中でも、後ろ向きにならずに前向きに向き合った開発者にのみ、作業完了後の達成感と、チームの共有感が得られるはずです。
コードレビューのコミュニケーションがうまくいっていないチームは、うまくいっているチームと比べて、無意味な問題がさらに上積みされてしまうことでしょう。
そんな中、自分もコーディング初心者時代を思い出して、コードレビューしてみるのはいかがでしょうか？
ちなみに、フリーランスエンジニアも昨今増えてきていますが、新しい現場に行くと、大体の場合、レビュイーになるケースも多いと思います。
そんな時は、レビュアーの質を見極めて、その開発チームのレベルを測ってみるのも悪くないかもしれませんね。
この書籍はそんな時の参考になるかもしれないので、一読しておくといいかもしれませんよ。
0 件のコメント:
コメントを投稿