<h1 id="%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">
<a class="header-anchor-link" href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB" aria-hidden="true"></a> はじめに</h1>
<p>今回は、コードレビュー観点表を作った話について少し書かせていただきます。</p>
<p>社内ではGitHubを用いてコードレビューを行っていて、バックエンドの開発においては、コーディングガイドラインも策定しています。</p>
<p>しかし開発において、ガイドラインに書かれている事項が全てではないため、コードレビューを行う際のポイントが自分の中で綺麗に整理しきれていませんでした。</p>
<p>また、ガイドラインの重要なポイントを十分に把握できず、効果的なコードレビューができていない現状がありました。これを改善するために、コードレビューの観点表を作成したことで、コードレビューの質が上がった話についてお話ししようと思います。</p>
<h1 id="%E5%95%8F%E9%A1%8C%E3%81%A8%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%84%E3%81%9F%E3%81%93%E3%81%A8">
<a class="header-anchor-link" href="#%E5%95%8F%E9%A1%8C%E3%81%A8%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%84%E3%81%9F%E3%81%93%E3%81%A8" aria-hidden="true"></a> 問題となっていたこと</h1>
<p><strong>一貫性がないレビュー</strong><br>
毎回レビューを行う際に、自分の中のレビューポイントが明確に決まっていなかったため、的確にレビューができていないこと</p>
<p><strong>レビューにかかる時間が長い</strong><br>
自分の中でのレビューポイントがまとまっていないため、レビューに時間がかかっていたこと</p>
<p><strong>単純なレビュー漏れ</strong><br>
上記の二点も相まって、レビュー漏れが発生して開発の手戻りリスクが上がっていたこと</p>
<p>など。。。</p>
<h1 id="%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E8%A6%B3%E7%82%B9%E8%A1%A8%E3%81%AE%E4%BD%9C%E6%88%90">
<a class="header-anchor-link" href="#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E8%A6%B3%E7%82%B9%E8%A1%A8%E3%81%AE%E4%BD%9C%E6%88%90" aria-hidden="true"></a> コードレビュー観点表の作成</h1>
<p>いくつか問題が出てくる中で、自分なりにコードレビューの観点をまとめてみました。以下すべてではありませんが、観点表の一部を抜粋してお見せします。</p>
<table>
<thead>
<tr>
<th>区分</th>
<th>観点</th>
<th>優先度</th>
<th>コードレビュー基準</th>
<th>補足</th>
</tr>
</thead>
<tbody>
<tr>
<td>社内標準</td>
<td>安全性,性能</td>
<td>MUST</td>
<td>テストを書く</td>
<td>詳細はテストコード運用書を確認</td>
</tr>
<tr>
<td>社内標準</td>
<td>安全性</td>
<td>MUST</td>
<td>パスワードなどのセンシティブな情報をログに吐かない</td>
<td></td>
</tr>
<tr>
<td>仕様</td>
<td></td>
<td>MUST</td>
<td>仕様に沿った開発ができているかどうか</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>可読性,保守性</td>
<td>MUST</td>
<td>コードが複雑になっていないか</td>
<td>循環的複雑度など、linterでのエラーがある場合は修正</td>
</tr>
<tr>
<td>言語共通</td>
<td>可読性</td>
<td>MUST</td>
<td>マジックナンバーを書かない</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>可読性</td>
<td>MUST</td>
<td>他の人が理解し難い命名をしない</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>安全性</td>
<td>MUST</td>
<td>不正な値が入らないようにバリデーションを行う</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>安全性</td>
<td>MUST</td>
<td>握りつぶしている変数やerrorをなくす</td>
<td>エラーハンドリング箇所などで検索してreturn していないところがないかなどを確認</td>
</tr>
<tr>
<td>言語共通</td>
<td>安全性</td>
<td>MUST</td>
<td>適切なエラーメッセージを返せているか</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>保守性</td>
<td>MUST</td>
<td>実装は適切なレイヤーに実装されているか</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>安全性</td>
<td>MUST</td>
<td>scope以外の範囲をPRに入れていないかどうか</td>
<td></td>
</tr>
<tr>
<td>言語共通</td>
<td>パフォーマンス</td>
<td>MUST</td>
<td>loop内でdbの処理を行っている場合は、別の手段を考える</td>
<td>呼び出し回数が上がりパフォーマンスが下がる</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
</tbody>
</table>
<p>実際に自分で運用してみたところ、レビューが効率的に行えるようになり、レビューの速度も大幅に改善することができました。観点をそれぞれ分類することで、頭の中が整理整頓されてレビューしやすくなった感じがありました。</p>
<p>問題になっていた、一貫性がないレビューを行なっていたことで、レビュー漏れによる手戻りリスクが上がっていたことも、要点を整理できていない場合と、観点表を見る場合とで比較すれば、下げれるようになったのではないかと思います。</p>
<p>また観点表に優先度を新しく加えたところ、この部分はMUSTで対応、こっちはWANTだよねっていうのが明確になり、さらにレビューしやすくなりました。「時間がなく急ぎでレビューしてほしい」などの依頼があった場合は、MUSTをチェックするなどしてさらに効率化が図れると考えています。</p>
<h1 id="%E8%AA%B2%E9%A1%8C">
<a class="header-anchor-link" href="#%E8%AA%B2%E9%A1%8C" aria-hidden="true"></a> 課題</h1>
<p>課題として残ったのが、コードの質をあげることは、すなわちレビュー観点が増えていくことにつながるのではないか？と思っていて、レビュー項目が増えれば増えるほどレビューにかかる時間も増えて、質はあがる一方生産性が下がることにつながるように思っていました。</p>
<p>linterなど一般的に使われているツールはあるかと思いますが、上記のような社内標準観点や言語共通観点を網羅的にチェックしてくれるわけではないので、今後レビューを自動化するなどのフローを考えてないといけないなと思っています。</p>
<h1 id="%E6%9C%80%E5%BE%8C%E3%81%AB">
<a class="header-anchor-link" href="#%E6%9C%80%E5%BE%8C%E3%81%AB" aria-hidden="true"></a> 最後に</h1>
<p>コードレビューがしやすくなり、改善したい箇所が改善できて、作成して良かったと感じています。みなさんもぜひ自分でコードレビュー観点表を作ってみてはいかがでしょうか！！</p>
<p>CastingONE では、バックエンドを推進してくれるメンバーを大募集しています。カジュアル面談もやってますので、お気軽にご連絡ください！</p>


Discussion