勤務先のソフトウェア開発インフラやプロセスには良いところも悪いところもある。中でも一番良いものはたぶんコードサーチだと思う。コードサーチのできの良さが、他の様々なイマイチさを一定程度救っている。

コードサーチといっても検索だけでなく、シンボルをクリックしてジャンプできるとか履歴やら blame やらができるウェブブラウザ越しのコード閲覧環境一式や monorepo である事実を含めて良い。

まずコードサーチがあるとドキュメンテーションの重要性が下がる。この API なんだろ、という時にまずコードサーチをするようになるから。実装を見て、呼び出し箇所を見て、だいたい用が足りる。それでもダメならコードの冒頭なりディレクトリの README にドキュメントないかなーと探して、それでもダメなら仕方なくコードじゃないサーチを試す（だいたい何もでてこない）。エラーがおきたら、まずエラーメッセージをコードサーチする。

ライブラリを提供する側もユーザがコードサーチすることをわかっているので、サンプルコードとかは一通りチェックインされている。そして codelab とよばれるハンズオン方式のチュートリアルがドキュメンテーションの方法として幅を効かせている。

逆に Javadoc のビューアは知る限りどこにもない。Java 自体は広く使われているし、そのコメントも Javadoc フォーマットで書くのだが・・・。コードサーチ上ではコメント内の @link とかがちゃんとハイパーリンクになっててウケる。

設定ファイルの類がぜんぶチェックインされている事実もコードサーチの有用性を高めている。ダッシュボードや Web UI の類でよくわらからい項目があったら、とりあえずコードサーチする。

あるとき性能リグレッションのバグを割り振られたプログラマが、ベンチマークの CI を管理する QA チームの一人に質問していた。

「この指標の名前、コードサーチしても全然出てこないんだけどどうやってサーチすればいいの？このハイフンの前を削ればいい？」その場の誰にも答えがわからず聞いて回ってたどり着いた人いわく「その項目の横にある鉛筆のアイコンをクリックすると（コード上の名前とダッシュボード上の名前の）マッピングを編集できるよ」つまり答えは（サーチでたどり着けない）データベースの中にあったのだった。

データベースじゃ見つからないわと一同爆笑。そしてブーイング。サーチできるようにしとけよ！と叫んだそのプログラマは、すかさずラベルにコード内のシンボルを追記した。よしよしこれでサーチできるぞと・・・。

このエピソードはコードサーチのメンタルシェアを物語っていると思う。実際じぶんたちのチームが使っているダッシュボードは社内でもできの悪い部類に属しており、ちゃんとした部門の使っているできが良いやつは設定をチェックインする設計のものも多い。まあ設定ファイルをチェックインするのは infrastructure as code 的な意味でコードサーチ以外の利点も多いなのでサーチのためだけにそうなっているわけではないけれど。

コメントだけがドキュメントでない、独立したドキュメントにはそれはそれで価値がある。その主張は事実かもしれないけれど、コードサーチはドキュメントとしてのコードや設定ファイルの守備範囲を大きく広げる。おかげでプログラマの仕事がよりコード中心になる。副作用がないではないけれど、個人的にはけっこう好き。

あるとき社内インフラのサーベイがメールで送られてきた。諸事情でフラストレーションを溜めていた自分は脊髄反射で「中途半端な内製ツールを強要しないでオープンソースを使わせろばーかばーか」的なコメントを書いて投稿してしまい、あとで大人気なかったと反省した。

そうはいってもいいとこだってあるよな、と考え直して最初に思い至ったのがコードサーチ。罪滅ぼしにいい話でも書こうと思った次第。いずれ GitHub に完敗する日まではエンジョイしておきたい。