今の仕事はアプリ開発な割にけっこう platform と密着しており、エッジケースのバグなどを踏むことが多い。というか自分がやっているプロジェクトが踏んでしまい困っている。

本来なら platform のコードを持ってきて直したいところなのだけれど、ビルドするのも動かすのもデバッグするのも大変。やりかたもよくわからない。そしてコードが雑然としている割に繊細な部分なので下手に触ると壊しそう。現実問題あまり直せる気がしない。いちおうビルドはしてみたが・・・。

アプリの開発をしていてサーバのコードを触るより、アプリの開発をしていて platform のコードをさわるほうが大変。実行環境の距離を考えると納得いかないけれど、スケールを考えると仕方ない気もしてくる。特定アプリの都合だけでどうにかできるものではない。

Platform とアプリの間の壁は受け入れるとして、連携している別アプリとの壁もけっこう厚そうに見える。そして platform 内部でもモジュール間の壁を感じる。

自分たちのアプリは monorepo に住んでいて、platform は monorepo 外の git repo 群にある。platform の中の壁は、たぶん git repo の間にあるのだろうと思う。連携しているアプリは同じく monorepo に住んでいるけれど、リリースサイクルの違いなどが壁になっている、気がする。

壁があるといっても、別に反目しあっているわけじゃない。相手のコードベースに踏み込んで直すのがやりにくいという話。かわりに相手に直してくれと頼む。頼むのが悪いとは思わないけれど、自分はよそのコードに踏み込んでいくのは得意だと思っていたのでやや物足りない。誰かに依存すると相手の都合に引きずられてしまうし。でも郷に入りてはで、頼み力を上げないといけないのだろうな。組織の壁というのも少しはあるし。

あるときコード解析ツールのグローバルな設定更新にあわせ自分たちのコードベースが間接的に依存しているどこかのプロジェクトのコードが壊れた。そのプロジェクトは解析ツールの設定を変えている問題に気づいていない。

壊れて困ってますとバグをファイルしたあと、ふと自分で直してしまう方が早いのではと思い立つ。たかだか数行の修正。ためしにレビューをもとめアップロードしたらあっさり受け入れられた。修正完了。二時間くらいでビルド回復終了。

壊れたコードのチームが何をやっているのかも、コードをレビューしてくれたのが誰かも、自分は知らない。にもかかわらず 1-2 時間で他人のコードに踏み込んでいって直せる。この壁の低さは monorepo と unified build system の力だと思う。じぶんは monorepo そんなに好きじゃないけど、いいところもあるね。レポジトリやビルド方法が違うと、なかなかこうはいかない。

思えばこのずかずか入っていって直すスタイルは Chrome 時代に身につけたものだ。Chrome もどちらかというと monorepo よりで、一つのツリーになるべく多くのコードを突っ込んである。だからチームやモジュールの垣根を超えてコードをいじりやすい。そして V8 や Skia を直すのには壁がある。この壁は明らかにレポジトリに起因している。意味的に似た関係である WebKit と JavaScriptCore のあいだの壁は低い。同居しているから。

Monorepo にはコードのでかさという代償がつきまとう。ソフトウェアを小さく分割し、壁の向こうは触らないと決めれば小さなコードの身軽さを楽しめるのかもしれない。けれど可能性があるなら踏み込みたいと自分は思ってしまう。価値観とチームのやり方にズレがあるのは悲しいけれど、異文化体験ということにしておく。