ある QCon の講演 で, Facebook の Nick Schrock が Facebook コードベースの進化を, Eric Evans の言葉を借りるなら “しなやか/supple” になる様を紹介している. 技術的面倒とアプリケーションの面倒の双方をねじふせるデザイン, そして理解にいたるプロセスをよく伝えている.
Facebook の技術的面倒はまずなんといっても scalability だろう. 巨大かつ多様なデータをかきあつめて一刻も早くページを返したい. データベースは当然のように分割されており, live なデータが多いのでキャッシュの効き目は弱く, クエリーは並列に投げなければならず, けれどよりよって PHP なので非同期のコードを書きづらい.
アプリケーションの難しさはデーターソースの数と細かなプライバシ指定に由来する. 誰に何を見せていいのかを常に気にしなければいけない. きわどいデータを扱う割に機能はガンガン増えていく.
技術的制約が厳しいのでナイーブなモデリングはできない. ザッカーバーグ先生のひどいレガシーを何とか立てなおす必要もある. PHP はうんざりだけどユーザも開発者も機能も増えすぎちゃった上に サーバがモジュラーじゃないせいで違う言語に書き直す暇もない. (半分くらい誇張なので正確な内容はビデオで確認ください.)
そんなハードコアデスマの中から Preparable と呼ばれる擬似非同期プログラミングフレームワークと プライバシーを組み込んだオブジェクトグラフトラバサール DSL の Ent が生まれる. どうみても Facebook 以外では使い道がなさそうな API にしびれる. それは少しずつ問題を理解し, 無念なコードを飼い馴らしてきた獣使いの証だ.
質疑応答の中で “なんで PHP なんですか?” なんて聞いてるやつがいたので, おもわず “おまえは何もわかってない! Twitter で Scala でも書いてろ!!” と 恫喝したくなったが個人の見解ですし私も Scala の方がいいですがそういう話じゃねーんだよ!
半年くらい前に投稿された Facebook Engineering の Note が説く残念なコードに対する心構えも Nick Schrock のストーリーに符合している. 彼らのたたかう問題が垣間みれるようで面白かった.
