NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。
学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。
iPhoneカメラしかなかったので、画像が荒くて済みません・・・。
会場は大入り!
工藤拓さん
コードレビューとは
- 一人の開発者がコードを書いた後、別の開発者がそのコードをレビューする
- コードレビューも含めてコーディング
- 一行一行丁寧にレビュー
- あら探しがゴールではない
- 開発者間の協力
- コーディング全体における一つのプロセス
- 誰かのコードをデバッグ中に「不本意に」コードレビューを行うことがある
- 感情的になりがち
- 良いことではない
- はじめからコードレビューをするという前提に立つ
メリット
OSSプロジェクトでのコードレビュー
- 開発者がdiffコマンドでパッチを作成
- レビュワにパッチを送る
- メールやSourceForgeのpatch managerを使う
- レビュワはpatchコマンドを使い差分を手元のファイルに適用する
- 開発者とレビュワがメールでやりとり、内容を確認
- レビュワが変更をレポジトリにサブミット
- 信頼関係を築いた後で権利を譲渡
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の中身
スナップショット
パフォーマンス
- 多くの場合十分高速
- ほとんどの開発者はMondrianのみを使っている
- 多くの処理はMondrianの外
- 何が遅いのか?
- Perforceサーバの高負荷
- HTMLの生成
- 巨大なファイルのdiff (Pythonのdifflib)
- レビュワはコードにimpressionを付けられる!
- looks good to me!
- コードにコメント書ける
- コメントにもレスが書ける
- 改変して、レスを付けてdoneすればOK
チェックイン
- 何回かレビュワとのやりとり
- レビュワがApproval
Rietveld オープンソース版Mondrian
Protocol Buffers
glfags
まとめ
- 大規模ソフトウェア開発を支えるGoogleのインフラストラクチャ
- Mondrian
- Protocol Buffes
- gflags
質問タイムのまとめ
質問をメモしていないなかったので、拓さんの発言だけをまとめてあります。
- 突然レビュー依頼が来ることもある
- Googleでは週報が義務づけられている
- 最近コードを弄った人かも分かるので、レビュワを依頼しやすい
- Experiment用のリポジトリがある
- 基本的にレビューなし
- しかしExperimentalからリンクしようとするとビルドツールに怒られる
- Readability Review
- コード規約レベルでのレビュー
- 各言語の規約に精通したスペシャリストたちがレビュー
- 本当に細かくチェックされる
- 誰でも規約に沿ったコーディングができるように!
公演後の交流会
基本的にメモをとっていなかったので、印象に残ったことだけ・・・。
MeCabストーリー
拓さんからのメッセージ
短期的な視点と長期的な視点、両方を持つ必要がある。長期的な視点で取り組めるのは学生のうち。会社に入ると短期的な視点で取り組むことが多くなる。長期的な視点を忘れないことが重要。
10/24 20時 追記
はてなとの比較をして欲しいというリクエストがありました。僕はインターンをした際の知識しかないので、あまり大きなことは言えないのですが、一応書いてみます。
インターンはみんなペアプロをしていたので、自動的にコードレビューをしていた感じでした。また基本的に数千人もの開発者がいるGoogleと、数十人のはてなではかなり規模が違います。はてなでもレビューはやっていますが、専用のシステムもありませんし、行ごとにコメントを付けるようなこともしていなかったように思います。ただ、開発者が1フロアに集まっているため、コミュニケーションのコストはあまり高くありません。そのために当事者間で結構解決してしまっている気もします。evidenceを重視するのであれば、専用のシステムが必要かもしれませんね。(コミットログである程度はできると思いますが)
偉そうに書いてしまった・・・。違ってたら指摘をお願いします−。
10/27 追記
はてなにもレビュー管理システムがありました。タスク管理システムの「あしか」と統合されているようです。
git コミット単位での参照・レビュー・担当者関連づけ・メール飛ぶとかいろいろあるのになー。
インターン期間中は使っていなかったため、誤った情報を伝えてしまいました。id:secondlifeすみません!