2/15/2017

Googleでのソフトウェア・エンジニアリング (2.4、2.5)

Googleでのソフトウェア・エンジニアリング」と題する論文。

2.4. テスト

Googleでは、ユニットテストが強く推奨され、広く実践されている。本番環境で使われる全てのコードにユニットテストを行うことを求めている。コード・レビュー・ツールはソースファイルが対応するテストをせずに追加された場合、強調表示される。コードのレビュー担当者は普通新しい機能を追加する変更には、その新しい機能をカバーする新しいテストを加える必要がある。モッキング・フレームワーク(大きなライブラリに依存するコードでさえ、軽量のユニットテストを作ることができる)は非常に人気である。

統合テストや回帰テストも広く実践されている。

前に「事前サブミット・チェック」で議論した通り、テストは自動的にコード・レビューとコミット・プロセスの一部として強制される。

Googleはテスト対象を評価するための自動化ツールがある。その結果はソースコード・ブラウザにオプションレイヤとして統合されている。

デプロイ前の負荷テストもGoogleでも必須である。チームは重要な数値指標、入力要求の割合によって変わる特にレイテンシーとエラー率がどのようになっているかを示す表やグラフを作成することを求めている。

2.5. バグ・トラッキング

Googleでは、バグ、機能要求、顧客が抱える問題、プロセス(例えば、リリース、クリーンアップ作業)のような問題の追跡にBuganizerと呼ばれるバグ・トラッキング・システムを使用している。バグは階層構造を持つコンポーネントに分類され、各コンポーネントはデフォルトの代理人(assignee)と、デフォルトのメーリングリストへのCCを持つことができる。レビューのためにソースの変更が送られると、エンジニアは変更と問題番号を結び付けるよう促される。

Googleではそれらのコンポーネント内の未解決問題を定期的に精査し、優先順位付けをし、特定のエンジニアへ適切に割り当てることがチームにとって一般的である(全員ではないが)。いくつかのチームはバグトリアージの責任を負う特定の個人がいて、他のチームでは定期的なチームミーティングでバグトリーアジを行う。Googleでは多くのチームが、バグに関するラベルを利用して、バグがトリアージされたかどうか、各バグの修正対象となるリリースが絞られる。