オフショア開発におけるソースレビュー事例の紹介
はじめに
こんにちは。次世代システム研究室のT.D.Qです。ソースレビューには品質保証と開発者の教育という2つの理由について、前のエントリーにまとめてみました。
今回、次世代システム研究室でGitlabによるオフショア開発におけるソースレビューの事例を紹介したいと思います。
※GitLabとは、GitHubのようなサービスを社内などのクローズドな環境に独自で構築できるように公開されたオープンソースです。
オフショア開発のソースレビューの特徴
オフショア開発のソースレビューは以下の特徴が挙がられます1. オンラインコードレビュー
2. 非同期レビュー
3. レビュー回数が多い（コミュニケーション不足、異文化などで仕様の誤解が多いため）
日本とオフショア先（インド、中国、ベトナムなど）は場所と時差のため、 伝統的レビューミーティングはなかなか難しいと思います。
次世代システム研究室でGitlabでマージリクエストを使うことで、オンラインでエンジニアは非同期でレビューをリクエストできます。
レビューアーが自然な中断状態にある時に、より効果的なフィードバックを提供しやすくなります。また、オフショア側は、口頭より文章（コメント、コード）で問題を理解しやくなるので、レビューするとき、良い例、悪い例のコードをGitlabのマージリクエストに貼付けて説明すれば、何が悪いのか、理解しやすくなると思います。レビュー後、指摘された問題や解決方法をノウハウとしてwikiに保存できます。
レビューの流れ
Gitlabでは、マージリクエスト単位でレビューすることになります。以下の流れはGitlabによるソースレビュー開始から終了までの流れですStep 1. ソースレビュー依頼の作成
開発者は実装したソースコードをGitlabへPushします。Gitlab上でマージリクエスト作成する同時に、レビューアーをアサインします。Gitlabのアカウント作成をしておけば、メールでソースレビュー依頼を通知します。
＋Assign To：レビューアーを指定する
+ Milestone：プロジェクトのゴールです。Milestoneの期日と名称を設定し、期限まで解決しないといけない問題（Issues）を管理することで、オフショア開発チーム全員のゴールを明確になるので、 Milestoneを設定しましょう。
＋Labels: Gitlabのラベルによるレビューのステータス及び優先度を設定でいます。以下の図で、レビューステータスをまとめて見ました
レビューのステータスは、以下の５状態があると思います
- レビュー待ち: マージリクエストをレビュー可能になっているが、レビューアーはまだ未着手の状態
- レビュー中: レビューアーがマージリクエストをレビューしている状態
- キャンセル: マージリクエストが承認されず、クローズされた状態
- 確認待ち: レビューアーがレビューしたが、問題点や確認事項があるため、マージリクエストを未承認の状態
- 終了: レビューアーがレビューを確認した後、マージリクエストを承認した状態
Step 2. ソースレビュー依頼確認
レビューアーは、Gitlabにアクセスし、ソースレビューを確認します。
次は、マージリクエストの編集機能でレビューステータスを更新します
Step 3.レビュー結果登録
レビューアーは、ソースコードをレビューし、結果（コメント）をGitlabに登録します。レビュー結果をレビュー依頼者（開発者）にメールで通知します。Gitlabで変更履歴・差分を確認できます。インライン表示と左右に並べて表示を選択し、差分を確認できます。
 |
 |
Issues機能によるタスク管理
ソースレビューを行うとき、GitlabのIssues機能を使うことで、発見した課題を登録し、担当者の割当や課題解決後にクローズすることが出来ます。以下は、登録したIssuesのひとつです。
Step 4.レビュー結果確認
レビュー依頼者はレビュー結果をGitlabで確認し、レビューアーが指摘された項目ごとを回答します。ソース修正する必要の場合、マージ元のブランチに修正して再度GitlabへPushします。最新ソースコードは、マージリクエストに自動的に反映されます。ソースを確認し、問題なければ、マージリクエストを承認します。次のレビューアーにアサインする必要の場合は、コメントに「:+1:」を入力することで、自分のレビューが問題なく終了したことを明確にします。
Step 5.レビュー終了
レビューでOKの場合、最終レビューアーがマージリクエストを承認し、ソースレビューを閉じます。マージ元のブランチが残ってもあまり意味が無いので、「Remove source branch」をチェックして削除することをお勧めです。オフショア開発に手戻りが発生したときは、同じブランチ名を切って同じマージリクエストを作り直しても問題ないでしょう。
レビューに関連するissueがあれば、クローズします。
今後のために、レビューで得たベストプラクティス（レビューのガイドライン、チェックリストなど）をGitlabのwikiに残りましょう。
ここまで、レビューが終了となります。
終わりに
以上、Gitlabによるオフショア開発のソースレビューの事例を紹介しましたが、いかがでしたでしょうか。Gitlabを利用することにより、オフショア開発における場所、時差とコミュニケーション問題をオンラインで、非同期レビューを解決できるようになります。また、品質のレベルをオフショア開発チームに伝えるのは難しいところもあり、オフショア開発チームにレビューを行う文化を築くことが大切だと思います。参考URL
1. Code review guidelines2. OWASP CODE REVIEW GUIDE
3. Effective Code Reviews Without the Pain
4. GitLab Flavored Markdown
次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。
