オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

不毛な議論をなくすための仕組み 『大規模ソフトウェア開発を支えるGoogleのテクノロジー』から

»

講演をまとめたエントリ(ここ)のはてブが300超えそうだ。1時間半のプレゼンはあっという間に終わり、講演内容からはコミュニケーションオーバヘッドを減らすためのうまいしかけを端々に感じさせた。講演はGoogle工藤拓氏により奈良先端科学技術大学院大学情報科学研究科で行われた。

網羅的・キーワード中心の紹介は、はてなダイアリのほうにお任せするとして、ここでは大まかな話と私の印象をピックアップしたいと思う。ご講演はGoogleで実施されているプロセスや開発されたソフトウェアに関するものであり、以下の3つから構成されていた。

  • コードレビュー
  • Protocol Buffersという通信用フレームワーク・ミドルウェア
  • google-gflagsというコマンドライン引数解析のためのライブラリ

いずれも大規模な開発における問題を解決するものであり、私の印象では、全てコミュニケーションオーバヘッドを減らす仕組みとして捉えることができ、コードレビュー以外はシステム(サブシステム)間の相互依存を減らすための仕組みと感じた。

コードレビューの話では以下が印象に残った。一部の話はここ(本ブログの過去エントリ)でも紹介している。

  • コーディングのガイドラインがあり、タブはスペース4個だ、2個だと議論しなくて済む、また、カッコが絡む改行も改行場所が決められている。
  • 品質に関するピアレビューと、コーディングスタイル維持のための(どちらかというと)インスペクション的なものにわけてある。
  • コードレビューには信頼感を築くという目的もある。
  • レビュー完了条件やレビューフェーズは開発プロセスの一部として定義されている。
  • 非同期、メールベース型のレビューであり、メールが積みあがっていくのを防ぐ支援ツール(Mondrian)が存在する。(講演ではMondrianのスクリーンショットを拝見した)
  • レビューのコメントとして「褒める」機能がついている。

Protocol Buffersの話の概要は以下のとおりであり、システムやサブシステム間の通信による相互依存をかなり減らしてくれることが期待できる。Protocol Buffersの解説がここ(CNET Japan)にある。

  • カンマ区切りだとか、スキーマ定義だとか、通信時のフォーマットやエンコーディングに関して個別のプロジェクトで議論しなくてもよくなっている。
  • 専用のデータ定義言語(構造体定義のようなもの)と言語バインディングがある。
  • ストリームとして使え、ファイルやネットワークへのデータ送出時など共通的に使える。
  • エンコード方法や通信方法は言語や計算機非依存。
  • データ定義は新しい定義を追加した場合でも上位互換性がある。

google-flagsの話の途中で、大学の手続き的な話でいったん退席する必要があったので、一部しか拝聴できていない。get-optなど、コマンドラインオプションの解析は通常main関数で扱うが、規模が大きくなるとこのやり方では相互依存の度合いが高くなったり、改変に多くの人のコードレビューが必要になる。この強い依存を防ぐためのライブラリがgoogle-flagsだ。解説がここ(Google Japan Blog)にある。

工藤氏には、お忙しい中準備&お越しいただき、たいへん感謝している。また、大石氏、稲田氏にもたくさんお手間をいただいた。ありがとうございます。工藤氏はきちんと考えてモノをおっしゃる方、ナイスガイだ。工藤氏が奈良先端大で学び、博士号を取得して修了されたことは私が誇りに思うことの1つだ。

講演後の工藤氏のお話で、私も非常に共感をもったのは「学生のころに長期的な視点をもつことは重要」ということ。そのためにはいろいろなものを見聞きする必要があると思っている。奈良先端大では、講義の一環として積極的に外部の方に講演いただくための講演枠があるので、これを利用し、規模が大きくなっていくソフトウェア開発に企業がどのように対応しているかを講演いただけるようお願いした。ここ(本ブログの過去エントリ)にも書いたが、今回は3回のうちの1回目。就職後、ソフトウェア開発に携わる学生さんのためと思っていたが、私も非常に楽しめた。

Comment(0)