時は2005年ごろ、Officeはスレッドを有効に使うべく悪戦苦闘していた。Outlook2007などは外部から見てもその苦闘が見られただろう(不安定、とも言う)。社内にいれば、そのずっと酷いバージョンのアルファやベータもドッグフードする機会があり、なかなかに絶望の淵を覗く思いだった。

その当時のたくさんの失敗の経験とその分析から、社内には割とたくさんの非同期プログラミングのノウハウがあった。
といってもかっこいいテクノロジとかデザインパターンのような華々しい物では無い。もっと地味な、Writing Solid Code非同期版のような感じだった。Avalon以前の地味な、面白くもない世界。

非同期と並列は違う。直交はして無いけれど。
「ブロックしてるコールを非同期コールに差し替えればいいんでしょ？」そう思って作られた大規模アプリは、すぐに動かなくなった。非同期のアプリとしてただ普通に振る舞うだけですら、それよりずっと多くの物が必要な事が分かった。手痛い失敗の山の後で。

非同期は並列の前提となる所だ。非同期に作れても並列とは限らない。
だがその非同期ですら、ちゃんとやらないとうまく行かない事がたくさんあり、細かいロックのストラテジ、UIデザインの仕方、非同期ではかならず盛り込まなきゃいけない仕様、非同期の時に望ましい仕様、避けるべき落とし穴などいろいろな事を知らないと、非同期の恩恵は受けられない。小手先のコーディングの変更ではうまく行かず、結局根本のデザインから考え直さないといけない。その時にどう考えれば良いのか、には、幾つか原則がある。
と言っても別にそんな大した話でも無く、同じ問題に挑んだ会社ならどこでも似たような結論になっただろう。当時デスクトップのアプリをやっていた所なら皆同じ事に苦しんでいたはずだ。

自分はトレーニングも割と受けたし、社内のホワイトペーパーやブラウンバッグの動画などをあさったりして、結構いろいろ学んだ。
web上のスケジューラをつくる仕事をしていたので、Outlookチームとは連携が多く、組織階層的にも近かった。だからOutlookのコードとノウハウを学ぶ機会が多かった。そこでは非同期の失敗がいかに致命的かを、嫌になるほど見る機会があった。
といっても地味な話ばかりで、将来的にはもっと環境レベルなりライブラリなり、決定版が出るに違い無い、とか思って、軽く見てた。
何にせよ2000年代中盤の事である。まだデスクトップアプリが、少しは生き残っていたような、遠い昔の事だ。
その後クライアントアプリは全滅し、webの時代が来た。予想通り非同期プログラミングの知識はまったく使い道も無くなり、記憶の奥底に捨て置かれ、忘れ去られていた。

時は流れて時代はモバイル。
Androidに限って言えば、非同期に関しては当時と何も違いが無い状態で、プロセッサ数と解像度だけは増えました。
マジかよ、とか思いつつも昔学んだ古臭いやり方で、とりあえず非同期の基本は抑えたアプリは書ける。大した事はしていないけれど、一応2000年代中盤は超えているなりのデザインだ。
このままでマルチプロセッサの時代を乗り越えられる気は全然しないけれど、4コアくらいまでならなんとか。

そんな状態でふと回りを見回すと、非同期の基本を完全に無視したようなアプリがたくさんある。
いや、それは全然ダメだろ、Outlook2003だってもっとマシだったぜ？とか思ってしまう物とか。
しかもそれまでwebの世界でstate of the artと呼ばれていたチームから出てくる物がそんなだ。

何故こんなに非同期をまともに書けないのか？としばらく考えてみると、思えばwebサービスのクライアントサイドには非同期のノウハウがほとんど無い事に気づく。何故ならそもそもにロックが無いからだ。
だがUIの非同期化は特有の、しかもかなり大量の落とし穴があり、何の知識無く普通に振る舞う物が作れるような世界では無い。
でもJSの非同期なんてリクエストを非同期にする程度の話で、それ以上のことはそもそも出来ない、だから失敗のノウハウが貯まらない。

そう思うと、自分が見てきたおそらく歴史上トップクラスに複雑なクライアントアプリの古臭い非同期の話、というのは、実は今でも最先端なのかもしれないなぁ。
当時はあまりのドロドロした地味な結論にうんざりだった非同期の設計たが、意外と現在役に立ってて、なんか棚から牡丹餅のような、得した気分だ。
地味な事もやっておくもんだねぇ。