Future についての私見
この記事を読んで、記事の本筋からはそれますが、前から思っていたことをつぶやいたのでまとめておきます。
前後関係がある Future 処理を一つの処理として抽出すればシンプルなケースではおかしなことにはならないと思うけど real world では横からはさみこみたくなる要件が継ぎ足されていくとつらくなる。
— seratch_ja (@seratch_ja) 2015, 3月 26そういう要件は本当は同期処理でやるのがよいわけで、そこをあえて Future とかコールバック関数縛りでやらなければならない理由が何かを考える。リソース効率とか膨大な同時接続への耐久性を可読性を犠牲にしてでも得たいのかという。
— seratch_ja (@seratch_ja) 2015, 3月 26適当に作るとデバッグとか運用のトラブルシュートとか大変になるし、開発の難易度はそれなりに上がると思う。本当にトラフィック数や同時接続がすさまじい環境なら別だけど、そうでもない案件の場合だとそこを頑張るのって見合ってるのかなと。
— seratch_ja (@seratch_ja) 2015, 3月 26"Future の先の隠蔽された世界" 感
— seratch_ja (@seratch_ja) 2015, 3月 26向こう側では何ミリ秒タイムアウトなのか使う側は知らなくてもいい？そんなことないよね、みたいな感覚。同じアプリの中なんだけど別の何かと連携しているかのような。
— seratch_ja (@seratch_ja) 2015, 3月 26どういうアーキテクチャだろうが丁寧につくりましょうというのは変わらないだけかもしれないけど。
— seratch_ja (@seratch_ja) 2015, 3月 26「それ、今まで通り同期処理で Web ページ返す処理つくるだけで全然いいよね」という要件なのに、非同期縛りをやるのはちょっと不毛な気がするな...という。超高負荷な環境で CPU 使用抑えたい、同時接続が多いんで、とか何かしらの強いモチベーションがあることが大事で、それ以外は適材適所がよいと思うのです。
もちろん新しいアプローチにトライするのは楽しいことだし、そういうコミュニティの盛り上がりは素晴らしいことなので水を差したいわけでは全くないんだけど、仕事でやる開発において「Play とか Scala が盛り上がってる。Rails でやってた案件を今度は Scala でやろう。」みたいなことだとまず幸せにならないなと。小規模な案件は実はただもう少し静的型が欲しいだけなんじゃないかなって思ったりしています。
