推測するな、計測せよ

この記事は #祭り化 Advent Calendar 11日目の記事です。

マツリカ株式会社にバックエンド (寄り) エンジニアとして入社して半年近く経った。
「祭り化」に対する自分の見解や、地方フルリモートで働くことについて、また初めて自社プロダクト開発に携って感じたことなど、色々候補は浮かんで悩んだが、最近CTOに言われた言葉が心に響いたので残しておこうと思う。

ある機能の設計段階で、データをMySQLに保存するか、Redisに保存するかという議論があった。
当初は読み書きが速そうという理由でRedis推しの流れだったが、最終的にCTOが「推測するな、計測せよ」の格言 (今調べたらRob Pikeが言ったらしい) を出してきて「まずは計測用のプロトタイプを作って、実際に動かしてボトルネックを突き止めることからしないと何も言えないですよ」と言って再検討となった。
当たり前っちゃ当たり前だが、自分の視野が狭くなってしまっていることに気付かされた。

考えてみるとこれまでの自分でも気付ける観点のはずだった。
対象こそ違うが、プログラムを実行してエラーが出たらまずはエラーメッセージを読み誤りを発見しようとするし、不具合対応では最初にシステムのそれぞれの箇所の調査を行い問題の切り分けをする。
それがパフォーマンス観点になるとRDBをNoSQLにしようとか、ApacheをNginxに置き換えようとか (これは今回は関係ないが) 、実態を調査する前にどこかで聞いた使えそうな手段を安易に検討してしまっている。

僕はまだまだ経験が浅くこの手のパフォーマンス検討をあまり考える機会がなかった。
N+1クエリになるような処理はRailsならinclude、Laravelならwithを使って回避すべきみたいな一般論的知識だけはあるが、まだまだ自分の血肉になっているとは言えない。
「とりあえず速くしないと……」という思いだけが先行し「まずは計測」という当たり前の工程がすっぽり抜けてしまっていた。

僕は「プログラムは思った通りに動くのではなく、書いた通りに動く」という言葉が好きで、コンピュータの世界はどれだけ因果を突き詰めるかが大事だと思っている。
にも関わらず雰囲気で議論していた自分への戒めと、改めて上記を念頭に置いて作業することの大切さを認識した話でした。