ソースレビュー時の心掛け
皆さんこんにちは!!
株式会社エムアイ・ラボの第4回目の記事として、今回は私たち開発チームが普段意識している、レビュー時の心掛けについて取り上げてみたいと思います!!
■ レビュー時の心掛け
Web開発をチームで行う際は大抵、複数名がコードを記載し、１名以上の方が開発途中か開発終了時にソースレビューをして、記載コードに問題がないか、問題があれば指摘やアドバイスをもらい、再度修正を行うかと思います。
私たちが普段、そのレビュー時に特に意識しているのは、「実施した目的・内容、確認して欲しい箇所、テスト結果、リクエスト・レスポンス」をまとめてレビュワーに伝えてフィードバックをもらうことです。
開発の規模や人数にもよりますが、規模が大きくなればなるほどソースレビューの時間が長くなり、下手をすれば午前中ずっとソースレビューの時間だったということもあり得ます。
レビュワーも他のタスクを抱えているので、できる限り内容をまとめてレビュワーの時間を必要以上に奪わないようにしていく必要があります。
質の高いレビューを受けることで、開発チームは様々な恩恵を受けることができます。
- 時間の削減
- レビューを受けたメンバーのスキル向上
- チーム内のコミュニケーションが活発になる
- 技術情報の共有
それでは、それぞれ紹介していきたいと思います。
■ 概要をまずはじめに
まず冒頭で、コーディングや修正した内容についての目的と概要を伝えます。またチケットがあれば、どのチケットについて対応したのかを明確にします。
いきなり実装した内容について話を切り出しても、レビュワーからすると「どの内容を実装したの？？」となってしまうので、最初に目的や簡単な概要を伝えた方が、頭に「このタスクの注意点は....」といったタスク内容が浮かびやすくなるので、レビューの質が上がります。
フロントエンドであれば、最初に想定される画面の挙動（実際に画面が表示されている方が望ましいです）と条件について合わせて伝えるとイメージしやすくなります。
この画面のボタンを押すことで、モーダルが表示されます、キャンセルすると別の画面に遷移します...などなど
■ 実装した内容
次に実装した内容について伝えます。完璧にする必要はないですが、実装した内容について、なぜそうしたのかを、目的に沿った機能なのかを明確しておくのが良いかと思います。
私の場合、実装した内容や最初に記載した概要についてある程度箇条書きにして伝えるようにしています。
例えば...
タイトル： 〇〇機能拡大に伴うAPI追加処理（チケット番号：〇〇 バックエンド）
目的：〇〇のため
対応１：〇〇API実装
理由：
対応２：〇〇のロジック追加
理由：
のように書いて、まとめるようにしていました。これはあくまで一例ですが、自分の頭を整理するのにも丁度良いのかと思います。
■ 特に確認してほしい箇所
ソースに不安があったり、正解かどうか判断がつかない箇所は、チェックを入れておき重点的に確認してもらうようにしましょう。
できれば全てのソースコードを確認してもらうのが理想ですが、レビュワーも忙しいと思うので、「この箇所は絶対に確認してもらいたい」という時にも使えます。
私の場合、Visual Studio Codeの拡張機能である「bookmarks」を利用してあらかじめブックマークにチェックをいれておき、ソースレビューに漏れがないようにしています。
該当箇所を探すために、ファイルをクリックしてスクロールするといった手間が大幅に削減できますし、探している間が気まずかったりするので、おすすめです。
■ テスト結果
単体テストであれば、テストスクリプトを作成して想定した結果が返ってきていることを伝えます。
最初にソースと実装理由を明確にし、ソースコードに問題なければ最後にテスト結果を伝え、バグがないことを確認します。
■ リクエスト・レスポンス
最後にリクエストとレスポンス結果を提示します。
- どのようなリクエストを送り
- レスポンス結果として何が返ってくるのか
を事前にまとめておいて、確認してもらうと良いかと思います。
■ まとめ
今回はソースレビュー時の心掛けについて記事にしました!!
この点が非常に重要だと思いました。
ソースレビューのために一手間工夫することで、レビューの質を効率的に向上させることができます。またバグの発見や技術的負債がないかどうかの確認のしやすいので、レビュワーがやりやすいような工夫を常にしておく必要があると感じました。
今回はここまでとなります。
最後まで読んでいただきありがとうございました!!
Discussion