GoogleにおけるIDEの歴史：開発環境はどのように進化してきたのか？

Googleの社内開発環境がどのような変遷をたどってきたのか、その興味深い歴史を辿ります。

"単一で拡張性のあるプラットフォームを持つメリットは、ますます明白になっている"
-- もしAndroidやChromiumのワークフローをCiderVやCritiqueに組み込めたら、どれだけの可能性が広がるか想像してみて！

記事の内容は「全Googler」向けに書かれているけれど、実際にはこれらのツールをまったく使えないGooglerもまだ大勢いるんだよね。

この1年、開発作業は全部会社が用意してくれたVS CodeのVM環境で行っているよ。これがどんどん良くなっている。ローカル開発みたいな感覚だけど、正直それ以上かも。今やローカルに開発ツールをインストールすることすらなくなったよ。自分のPCは単なるシンクライアントだね。

記事で触れられている分散コンパイルができない点だけが惜しいかな。90年代後半にdistccとかを使っていたのを思い出すけど、Java界隈では定着しなかったし、Mavenみたいなツールはすべてが一連の依存関係のチェーンになるように作られているからね。残念だよ。

私にとってCider-Vで一番驚いたのは、Cider（Vなし）が比較的短期間で消えてしまったことだね。他の社内サービスなんて、公式にEOLになっても永遠に生き残るのが当たり前なのに。

これにはもっと歴史があるよ。（注意：元Google社員 2010-2017）

働き始めた当初、使う環境は言語に完全に依存していた。C++とPythonの領域ではvimとemacsの対立があった。Javaはもっと複雑で、vim/emacsを使う人もいたけど、多くの人はEclipseを使っていたな。

当時、GoogleでEclipseはソース管理システムのせいで大問題だった。JavaのIDEは基本的にバイナリ（主にjar）をインポートするように作られているからね。社外ではAntやMaven/Gradleなどで依存関係を管理するけど。

Googleにはモノレポ（Perforce/Piper）があって、ローカルに一部をチェックアウトし、残りはネットワーク経由で（確かSrcFSだったかな）参照していた。これは、ローカルでファイルを編集すると依存関係が（Blaze経由で）自動的に再コンパイルされるから便利だった。

Eclipseだと膨大な初期化が必要で、すぐによく落ちていたんだ。一時期は10人くらいのチームがそれに対応していたよ。その後、「magicjar」という20%プロジェクトが出てきた。MagicjarはPerforceクライアントを使って依存関係をすべてjarとしてビルドし、ソースツリー全体を解析せずに直接インポートできるようにした。これのおかげでIntelliJが使えるようになり、自分もそうしたよ。Magicjarは最高だった。

C++でCLionをうまく使っていた人もいたな。あれは良かった。C++のヘッダーやテンプレートの扱いのせいで、もっと大規模で複雑な対応が必要だったけどね。

とにかくクライアントのチェックアウトは、ローカルツリーを最小限にしてもかなり重かった。Google3で作業するなら、何度もそれをやる必要がある。設定ファイルを少し変えるだけでもね。Ciderはその設定変更が楽にできるから、そこが普及の出発点だったんだ。

その後どうなったかは知らない。VS StudioをCiderのフロントエンドにする？それは初耳だ。エンジニアは環境が変わったり、少しでも挙動が違うと不満を言うものだけど、それが一番驚きがない話だな。

そうそう、当時はPerforce（P4）を直接使わず、「Git5」というGitフロントエンドを使っている人も多かった。私が在籍中には既に非推奨になりかけていたけどね。Git5はP4の変更をブランチとしてモデル化していたから、ローカルでGitコミットを試して、最後に一つのP4変更にスカッシュできるのがすごく気に入っていた。

一方でGoogleはWindsurfを買収してAntigravityをリリースしたけど、最近Google Workspaceユーザー向けにAI Ultraプランを削除して機能を制限しちゃったね。だから今Antigravityをちゃんと使うには、Google社員になるか、個人アカウントでAI Ultraを使うしかない。

https://knowledge.workspace.google.com/admin/gemini/ai-ultra...

Tritium[1]を開発している中でずっと言ってきたのは、「開発者はウェブベースのIDEなんて絶対に使わない」という例え話だ。同じ理由で、弁護士もウェブベースの法的IDEなんて使わないだろうと。その代わり、デモを動かすためだけにデスクトップソフトをインストールするという苦労を強いてきた。今回の件は、ウェブでも実用になる可能性があるという現実を突きつけていて、すごくタイムリーだね。

[1] https://tritium.legal

元Google社員（2014-2017）です。自分のチーム（広告部門）は主にJavaで、Eclipseを使ってからIntelliJに移行し始めた。

Ciderもよく使われていたけど、当時からviでもemacsでも好きなものを使っていいという人はいたよ。

Piper、Critique、そして例の有名なモノレポについても言及しておく価値はあると思うな。

[1] Piper: https://en.wikipedia.org/wiki/Piper_(source_control_system)
[2] Critique: https://books.google.com/books?id=V3TTDwAAQBAJ&pg=PA399#v=onepage&q&f=false
[3] Monorepo: https://dl.acm.org/doi/10.1145/2854146

2019年にGoogleからFacebookに転職したけど、Googleのツールが業界最高だと思ってたのが、Facebookの方が上だった。

GoogleのブラウザベースのCiderは可愛いものだったけど、FacebookがAtomからVS Codeに移行した時の先見性はすごかった。GoogleはMondrianやCritiqueで非同期のウェブコードレビューを先取りしたかもしれないけど、FacebookのDiffはスタック型Diffのサポートがあってより優れていた。Buganizerも、FacebookのTasksと比べると古臭くて使いにくかったよ。

Facebookを辞めて1年経つけど、Metaのツールが今どうなってるか気になる。まだ未来を先取りしているのかな？

2010年代半ばにGoogleを離れた時、いくつか珍しい制約があったんだ。

1. コードの大部分が巨大なモノレポに入っている。
2. このモノレポのコードをノートPCに保存することを禁止するポリシーがあった。

ほとんどの企業やプロジェクトはコードの規模が桁違いに小さいし、保存場所を制限したりはしない。Googleがその特殊な状況に対処するためにCiderなどのツールを作ったのは興味深いけど、そのアプローチが現代の多くの開発シナリオにおいて最適というわけではないことは覚えておくべきだね。