via Androidにおけるパフォーマンスチューニング実践 - Speaker Deck

世間の期待値的には性能の話がこれでいいのか・・・別にリンク先のひとを腐したいわけではなく、2019 年にこんな話なのか・・・と割と心の底からびっくりしてしまったのでひっそり記録したかったという話。なお別にこういう話をしているからその人たちのアプリが遅いといいたいわけではない。地味にコツコツやればそこそこ速くなるジャンルはたくさんあるから。それでいいならそれでよいのです。

つい Twitter に余計なことを書いてしまったが完全に言いがかりだったと反省。

講演きいてないのでわからないけれど、リンク先の資料に問題があるとすれば計測して、詳しく見て問題を特定して、それを速くする、というサイクルが感じられないところかな。高速化、そのサイクルが一番下にないとカーゴカルト黒魔術みたいのになりがち。

追記

スライドの人が dex.fm に出ていたことに気づいたので聴いてみた。ちゃんと仕事してる人だった。我ながら言いがかりよくないわ。

dex.fm — 064: Performance Tuning

こういう人の話を聴いてみると、自分のやってる仕事は単に職場のインフラを exploit しているだけだなあと思う。たとえばベンチマークの自動化にしても lab なり dashboarding なり scheduled execution なりの仕組みはもうあるので、それを寄せ集めれば良い。

というか自分はそれすらできず、半年くらい前にやってきた別の人が別の目的で寄せ集めた自分のチーム向けのセットアップに相乗りしている。一番大変な connecting pieces 作業はそのひとが済ませてくれたので、自分はその上でちょっとコードを書けば良い。

自分の作業はアプリ側からメトリクスを expose する側に寄っているのでちょっと守備範囲が違うとも言えるが、そのアプリ側の仕事にしても昔だれかがやったまま放置していたコードを整理復旧して使い物にしただけで、特にすごく何かをがんばったわけではない。まあこれは前のチームで割とがんばった部分なのでやればできるとは思うが・・・。

こうした仕事に価値がないとは思わない。実際自動化によってカバレッジがあがり、早い段階で性能バグを発見できるようになったわけだから。ただまあ、リンク先の人のような全方位的活躍とは程遠い。

他人の仕事を寄せ集めるだけで成果がでるのも、他人の仕事を寄せ集めるのが大変なのも、大企業であることよ。最近やってきたできるエンジニアは「俺はコードは書かない。他人のコードをコピペするだけだ」と冗談交じりに言っていて、そういう面なあるなと思う。コピペ元コードの出処が社内コードサーチか SO かの違いで世間のプログラマも割とそんなもんなのではという気もする。はさておき。

部品を寄せ集める大変さを考えると大企業で社内インフラに乗るのだろうがスタートアップでオープンソースに乗るのだろうが大差なくね、というのは常々感じているオープンソースもっと使わせろという不満につながるわけだが、自動化のインフラはコードだけでなくサービスの operation も必要な類なのでまあ仕方ないかなと思う。過剰な大変さはなんとかしてほしい気もする一方、サーバ側と比べた時の社内のモバイル回りの筋の悪さには諦めもある。