Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」 NAIST にて MeCab の作者としても有名な工藤拓さんの講演が行われました。 Google の開発体制とそれを支えるツールのお話です。 学校と拓さんの双方から ブログ への掲載許可が得られたので、まとめを公開します。この講義は NAIST の ソフトウェア 開発管理講義の一環です。 iPhone カメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り! 工藤拓さん NAIST 自然言語処理 学講座出身 Google に入社してから大規模開発や インフラ を経験 MeCab を開発 NTT コミュニケーション 科学基礎研究所に所属 その後 Google へ 研究より開発寄り Google での仕事 日本語の ウェブ 検索 「もしか ... もっと見る
Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」 NAIST にて MeCab の作者としても有名な工藤拓さんの講演が行われました。 Google の開発体制とそれを支えるツールのお話です。 学校と拓さんの双方から ブログ への掲載許可が得られたので、まとめを公開します。この講義は NAIST の ソフトウェア 開発管理講義の一環です。 iPhone カメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り! 工藤拓さん NAIST 自然言語処理 学講座出身 Google に入社してから大規模開発や インフラ を経験 MeCab を開発 NTT コミュニケーション 科学基礎研究所に所属 その後 Google へ 研究より開発寄り Google での仕事 日本語の ウェブ 検索 「もしかして」 機能 ダジャレサーチ エイプリルフール ネタを1ヶ月かけて実装 何千人もの開発者が単一の ソースコード リポジトリ の上で開発を行っている 大規模開発をサポートする インフラ が不可欠 Mondrian: ソースコード レビューシステム Protocol Buffer: 言語非依存のデータ交換 ライブラリ Google gflags: コマンドライン 処理 ライブラリ コードレビューとは 一人の開発者がコードを書いた後、別の開発者がそのコードをレビューする コードレビューも含めて コーディング 一行一行丁寧にレビュー あら探しがゴールではない 開発者間の協力 コーディング 全体における一つの プロセス 誰かのコードを デバッグ 中に「不本意に」コードレビューを行うことがある 感情的になりがち 良いことではない はじめからコードレビューをするという前提に立つ メリット 早期の バグ 発見 コーディング スタイル規約を強制できる 新人の研修目的 既存のシステムを壊すことなく多くのことを学ぶことが出来る 壊しそうになっても事前に止められる 開発者間の信頼関係を築く システムの引き継ぎが容易 次のプロジェクトに行きやすくなり、 流動性 が高まる ペアプログラミング の良い代替手段 地理 的・時差的に離れた開発者間で共同開発 世界に分散しているため OSS プロジェクトでのコードレビュー 開発者が diff コマンドで パッチ を作成 レビュワに パッチ を送る メールや SourceForge のpatch managerを使う レビュワはpatchコマンドを使い差分を手元のファイルに適用する 開発者とレビュワがメールでやりとり、内容を確認 レビュワが変更を レポジトリ にサブミット 信頼関係を築いた後で権利を譲渡 Google の 開発プロセス 全社的に単独のPerforce (p4) リポジトリ 開発者・プロジェクト毎にブランチは基本的にない 全社的な NFS 環境 他の開発者の ワークスペース を世界中のどこからでも アクセス できる アメリカ のホーム ディレクトリ も見れる チェックインされる全てのコード・ パッチ はサブミットの前に必ずレビューを受けなければならない 例外はない コードレビューのやりとりのメール誰でも参照できるように永久保存される p4を直接使わずにg4という ラッパー プログラム を使っている p4はコードレビューの機構を持っていないため 最初は3000行の シェルスクリプト 、今は python Google のコードレビュー(以前) コマンドライン とメールベース 1. 該当のコードを レポジトリ から ダウンロード (チェックアウト) 2. コードに変更を加え、テストを行う 3. ChangeList( CL )を作り、レビュワにメール CL :変更されたファイル名、 パッチ に対応づけられたID番号 以降 Cl で変更が管理する 4. レビュワとのメールのやりとり 5. レビュワがLGTMと返信するとサブミット出来る LGTM = Looks good to me 以前のコードレビューツール g4 change 変更点をまとめたChangeList IDを作成 g4 mail ChangeListをレビュワに送信 g4 diff レビュワが変更点を各員 tkdiffを デフォ ルとして使っていた g4 subumit 以前のシステムの問題点 VPN フレンドリーではない 自宅から作業するかも知れない Tkdiffが動かない、動いたとしてもとても遅い 行番号の更新が困難 良く和あるコメント「行番号のここをこう変更して」 行番号に対応づけられたコメントが更新されない レビュー中の任意の時点でのリビジョンとの diff がとれない レビュワが全てのリビジョンを管理する必要がある メールの山に埋もれてしまう レビュワ:このレビューは終わったんだっけ? 開発者:私のレビューは始まったのかしら? Mondorian Guido van Rossum ( Python 作者)を中心に開発されたコードレビューシステム Webベース VPN の問題がない 全てのリビジョンが サーバ 側で管理されている 変更をside-by-side diff で表示 コメントをインラインで挿入可能 Ajax を使いまくり 複数のコメントは自動的に一つのメールにまとめられる リビジョン毎に行番号が管理される メールベースの従来の管理もサポート 個人のダッシュボード( ポータルサイト ) Mondorianの中身 Bigtable を使用 ChangeLisの メタデータ (コメント、ファイル名リスト) コメント(レビューのやりとり) 開発者のホーム ディレクトリ にあるコードの スナップショット ユーザ毎の情報 ホーム ディレクトリ 、 bigtable ,perforceと通信 NFS もしくは SSH を用いてホーム ディレクトリ に アクセス メールの管理 スナップショット ユーザのホーム ディレクトリ にある変更中のファイルをMondrianが知る必要がある Mondrianに アクセス する度に更新する必要がある エディタ での変更履歴を全て確認可能 ユーザの スナップショット が NFS 上にない場合 SSH を使いユーザの Linux Boxに直接 アクセス スナップショット やコメントは永遠に保存される 後々参照するのに便利 同じようなことを試みている別の開発者に CL を指し示すことが出来る パフォーマンス 多くの場合十分高速 ほとんどの開発者はMondrianのみを使っている 多くの処理はMondrianの外 何が遅いのか? Perforce サーバ の高負荷 HTML の生成 巨大なファイルの diff ( Python のdifflib) レビュワはコードにimpressionを付けられる! looks good to me! コードにコメント書ける コメントにもレスが書ける 改変して、レスを付けてdoneすればOK チェックイン 何回かレビュワとのやりとり レビュワがApproval Rietveld オープンソース 版Mondrian 作者は同じ Guido van Rossum subversion Protocol Buffers Google が開発した構造化データのデータ交換 C言語 の構造体のような定義ファイル(*.protoファイル) から, C++ , Java , Python のコードを生成 なぜProtocol Buffers? XML に対する アドバンテージ バックエンド、フロントエンドで使える共通のデータフォーマット バックエンド C++ , フロントエンド Java , 社内ツール Python Gmail のフロントエンドは Java フォーマットの バージョンアップ に頑健 フィールドidが同じなら互換性が確保される 新しいデーターフィールドが追加削除されてもidが同じなら動く CPU 、 ネットワーク の負荷を小さくしたい 数千大、数万台規模の RPC XML のPersingは遅い、冗長、資源を使用しすぎる XML より3~10バイコンパクト 大規模開発に有益 フォーマットや エンコード 方法を完全に隠匿 データ交換フォーマットを議論しなくて良くなる 言語に組み込まれるので直感的に操作可能 Google 社内でのProtocol Buffes バックエンド・フロントエンド間の RPC Web検索フロントエンド スペルチェッカーバックエンド インデク サーバ ックエンド等 ログの保存 タイムスタンプ などの様座万情報 クロール してきたWebドキュメントの保存 クロール 時間、言語、 エンコーディング 、 URL といった様々なフィールド glfags Google が開発した コマンドライン フラグ のParser %foo --big_menu --language japanese getoptととの比較 getoptは コマンドライン の定義をmainの中に集中管理 gflagsはコマンドライの定義を個々のソースに分散管理 なぜgflags? 大規模開発でgetoptを使うと 自分の コマンドライン を追加したい! main 関数 があるソースを探し、そこに定義を追加 コマンドライン の内容を適当にディス パッチ 煩雑な手続き、その課程で バグ が混入 gflagsでは 自分の編集している*.ccファイルに フラグ を追加して ビルド 即座に反映 実験機能の追加に有益 既存のシステムを壊さない その他 Open source化された Google の開発ツール glog perftool gtest google C++ coding style guide まとめ 大規模 ソフトウェア 開発を支える Google の インフラストラクチャ Mondrian Protocol Buffes gflags 質問タイムのまとめ 質問をメモしていないなかったので、拓さんの発言だけをまとめてあります。 突然レビュー依頼が来ることもある Google では週報が義務づけられている 最近コードを弄った人かも分かるので、レビュワを依頼しやすい Experiment用の リポジトリ がある 基本的にレビューなし しかしExperimentalからリンクしようとすると ビルド ツールに怒られる Readability Review コード規約レベルでのレビュー 各言語の規約に精通した スペシャリスト たちがレビュー 本当に細かくチェックされる 誰でも規約に沿った コーディング ができるように! 公演後の交流会 基本的にメモをとっていなかったので、印象に残ったことだけ・・・。 MeCab ストーリー ナナロク世代 、大学入学と インターネット の 黎明期 がリンクしていた 京大 で3MBのホーム ディレクトリ に4MBの Netscape をどうやって入れるのかとか考えていた 黎明期 の日本語 検索エンジン を使ううちに、検索をやりたいと思うようになり、 NAIST 松本研に進学 既に ChaSen があり、 OSS で成功していた Outputを積極的に出して行く雰囲気 論文 を書いたら必ずソースも一緒に公開していた ChaSen はJumanをベースにしているため、コードベースが古かった メンテがしんどくなり、 フルスクラッチ で開発 MeCab 誕生 拓さんからのメッセージ 短期的な視点と長期的な視点、両方を持つ必要がある。長期的な視点で取り組めるのは学生のうち。会社に入ると短期的な視点で取り組むことが多くなる。長期的な視点を忘れないことが重要。
10/24 20時 追記 はてな との比較をして欲しいというリクエストがありました。僕は インターン をした際の知識しかないので、あまり大きなことは言えないのですが、一応書いてみます。 インターン はみんな ペアプロ をしていたので、自動的にコードレビューをしていた感じでした。また基本的に数千人もの開発者がいる Google と、数十人の はてな ではかなり規模が違います。 はてな でもレビューはやっていますが、専用のシステムもありませんし、行ごとにコメントを付けるようなこともしていなかったように思います。ただ、開発者が1フロアに集まっているため、 コミュニケーション のコストはあまり高くありません。そのために当事者間で結構解決してしまっている気もします。evidenceを重視するのであれば、専用のシステムが必要かもしれませんね。(コミットログである程度はできると思いますが) 偉そうに書いてしまった・・・。違ってたら指摘をお願いします−。 さらに追記 拓さんにメールを送って、この記事をレビューして貰いました。 LGTM happy hacking ! と言ってもらえました! 10/27 追記 はてな にもレビュー管理システムがありました。 タスク 管理システムの「あしか」と統合されているようです。 git コミット単位での参照・レビュー・担当者関連づけ・メール飛ぶとかいろいろあるのになー。 インターン 期間中は使っていなかったため、誤った情報を伝えてしまいました。 id:secondlife すみません! ツイートする Permalink | コメント(0) | トラックバック(2) | 15:50 戻る


























