少し前にSoftware Enginearing at Google (2017)というポストをHacker Newsで見た。
Software Engineering at Google
https://arxiv.org/pdf/1702.01715.pdf
内容の抜粋
- このドキュメントの目的はGoogleのソフトウェアエンジニアリングのキープラクティスを短くカタログ化することである。
- Google社のほとんどのソースコードは１つのリポジトリにあり、すべてのGoogle社のエンジニアがアクセスできる。
- ほとんどの開発はheadリビジョンで行われており、ブランチでは行われていない。
- 自動テストが頻繁に走っている。
- Blazeというビルドシステムを使用しており、リポジトリにあるコードをシンプルで素早くビルドとテストができる。
- ビルドシステムは何百・何千のマシンを使うため、非常に大きいプログラムもすばやくビルドでき、何千というテストを並列に実行できる。
- ビルド結果はクラウドにキャッシュされる。
- コードレビュー開始時や変更のcommit時に自動的にテストが実行される。
- Webベースのコードレビューツールがあり、コードの変更は少なくとも１人の他のエンジニアにレビューしてもらわなければならない。
- コードレビューにおける議論は自動的にメーリングリストにコピーされる。
- メインのリポジトリの他に、コードレビューが必須とされない実験的なリポジトリがある。
- レビュアーがレビューしやすいように大きな変更も小さな変更に分けてコミットする。
- Googleでは単体テストは強く推奨され、実践されている。
- Buganizerと呼ばれるバグトラッキングシステムを使用しており、バグや機能追加などのイシューの追跡に使っている。
- プログラミング言語は、C++、Java、Python、Go、JavaScriptの5つが強く推奨されている。言語の種類を少なく保っておくと、コードが再利用しやすく、プログラマー同士が協力しやすい。
- それぞれの言語にはコーディング規約があり、読みやすいコードを書く教育プロセスがある。
- これら5つの言語に加えて多くの特殊なドメイン固有の言語がある。たとえばビルドターゲットや依存関係を特定するためのビルド用言語。
- 開発プロセス（コード編集、ビルド、テスト、レビュー、バグ報告など）は、どの言語を使っても共通。
- リリースは、頻繁に（毎週や毎日）行われる。
- リリース候補のパッケージができると、ステージング環境にロードされ、少人数のユーザーによって（開発チーム自身など）総合テストされる。
- 次のステップは、カナリアサーバにアップされ、本当のユーザーにテストされる。
- 最後に全サーバにリリースされる。このとき、トラフィックが多いサービスや高い信頼性が要求されるサービスは段階的にリリースされる。
- Googleにはリリース承認ツールがあり、それぞれの製品に定義されたリリースのためのコンプライアンスの遵守やレビューなどの要件を満たしているかの確認に使われる。
- システム停止などの問題があった場合は報告書を書かなければならない。その内容は問題そのものや再発防止策にフォーカスされ、それを引き起こした人々についての非難などではない。
- ほとんどのGoogleのソフトウェアは2,3年で書き直される。
- エンジニアは業務時間の20%を自分で選んだどんなプロジェクトにも使える。上司の承認は必要ない。
- Googleでは個人やチームは目標を明文化し、達成度を評価することが求められる。
- チームは四半期と年間の目標を、達成度が計測できる主要な結果とともに設定する。
- Googleはエンジニアリングにおいて主に次の役割がある。
- エンジニアリング・マネージャー：人の管理だけをする人達
- ソフトウェア・エンジニア：ソフトウェア開発をする人達。Googleは人を管理することは昇進の要件にならない。リーダーシップを発揮することは要求されるが、大きなインパクトを与えるソフトウェアを開発するなどでも良い。
- リサーチ・サイエンティスト：リサーチ能力とコーディングの両方できないとなれない高度な職種。
- サイト・リライアビリティ・エンジニア
- プロダクト・マネージャー
- プログラム・マネージャー
- Googleにはゲームルームなどの楽しい施設がある。喫茶店などもある。スナックや飲み物を持ち込めるマイクロキッチンは堅苦しくないアイデアの交換に重要な役割を演じる。
- 社内における転籍は組織内で知識と技術を広めるのに役立つので奨励されている。
開発がheadリビジョンで行われているとか、コードレビューは必須とかリリース前のドッグフードのこととか参考になった。
