WEBアプリケーションの言語・フレームワーク選択について

今新たにWEBアプリケーションを作るとしたら、どのようにサーバーサイドの言語・フレームワーク選ぶか。今の自分の立場を書き残しておきたい。

結論（追記）

フレームワーク選定ももちろん大事だが、チームで設計の合意を形成することの方がもっと大事なのではないか。

選択肢

• Ruby on Rails
• Laravel
• Play Framework
• Symfony

※私が触ったことがあるものの中でという意味で。
※言語を統一できていない時点で、フレームワーク自体の比較には失敗している。

選定軸

1. 厳密性: そのアプリケーションでバグが出ることで、ユーザーやオーナーにどれだけ重大な影響が発生しうるか

これを意識するほど重要なアプリケーションを作った経験がないのだが、おそらくこれが一番重要なのかもしれない。
バグが人の生き死に、大きな金の流れに影響を及ぼすアプリケーションであれば、RubyやPHPなどコンパイルを必要としない言語を積極的に採用する理由はない。ランタイムエラーくらい普通に開発していればまず発生し得ない、CIを回せばいい、と言いたい気持ちもあるが、わずかに残る可能性すら許されないか否かが基準になる。

2. 開発規模: 将来、そのアプリケーションの保守・開発にどれだけの人数が必要となるか

大規模になるのであればコンパイルを必要とするJava（あるいはScala）を選ぶし、そうでなければPHPを選ぶ。どんなアプリケーションであれ、インターフェースを定義できる、IDEレベルで型チェックができる、十分に使えるレベルのエンジニアを揃えられる言語を選ぶ。

自分が信頼できるエンジニア越しに束ねられる人数を超えたら、それは大規模に入るのだと思う。コンパイルすら通らないものを成果物として提出されても困る。それを人為的にチェックする体制を築くのに大きな労力を割くのはできるだけ避けたい。これもある程度CIで代替可能ではあるが、そもそもテストコードを書いてもらうか、自分で書くかしなければCIではチェックできない。

インターフェースが定義できると、知らない人に開発を依頼しやすいように思う。極論、インターフェースを定義し、具象クラスの用途さえ伝えれば実装してもらえる。そういう意味でインターフェースを定義できる言語であれば、開発規模の拡大に対してある程度のスケーラビリティを備えることができるのではないか。また、インターフェースを定義せず、関数の引数に型を指定するだけでも、安全かつ意図を明確にできる。引数の取り得る値がどのようなものか想像しづらいのは開発効率がよくない。

人手を揃えやすい、十分に熟達していなくてもアサインしやすいという意味において、Java、PHPはやはり秀でていると思う。古く、異臭を放つPHPに悩まされてきた人たちには信じられないかもしれないが、PHPも一応型で縛れる安心感がある。

3. 開発速度

正直なんでもいいよという気分である。 2〜3名規模のチームを保てるのであればRuby on Rails、それを超える規模になるのであればLaravelを選ぶだろうか。

フレームワークが想定しているアプリケーションの規模があると思っていて、そこから外れるとそのフレームワークの開発効率が落ちるのではないだろうか。小規模開発では手数を減らしてくれるようなツール、クラスも大規模開発では使えなかったり、大規模開発では使える枠組みも小規模開発では手数ばかり増えると言った具合である。
Ruby on Railsは純粋なMVCフレームワークであり、それ以外の構造化について開発者を縛る枠組みがない。MVCの構造に従って密結合に作っていられるうちは確かに速い。ただし多くの人が経験したように、規模が大きくなるとModelやControllerがファットになって見通しが悪くなる。
Laravelは同様のMVCフレームワークであるが、IoCコンテナが用意されている。その分、疎結合に作りやすく規模の拡大に耐えやすいだろう。
SymfonyはBundle, Entityの2軸でテーブル、カラムのアクセス権を実装できるので、DB操作がセキュアに設計できそう。しかし実際のところ手数がかかるだけで、全カラムが結局publicになってなんの意味があったんだ状態に陥る気がする。何がしたかったんだお前は。

5人以上の開発規模になるチームの人数が3人を超える(*1)のであれば、インターフェースを定義できる言語を選ぶ。規模が大きくなるにつれ、他人の書いたコードに触れる頻度が多くなったり、自分の書いたコードを覚えていられなくなる。その際にインターフェースをIDEが認識できる言語はキャッチアップを助けてくれる。おそらく、それくらいの規模になるとコーディングにかかる時間よりも、コードを読む時間や設計を考える時間のほうが増えやすくなっているだろう。

後書き

正直、Ruby on Railsをdisりたくてこの記事を書きはじめた。 しかし、自分がRubyおよびRuby on Railsに対する理解が浅いだけだと、冷静に思い直している最中である。

以下、Ruby on Railsに対するdisりを書き残しておく。

Ruby on Railsはチームがごく少人数にとどまらない限り採用しない。素早くアプリを開発できるというのは確かにそうだが、それは 小規模な0=>1 か MVCの枠組みに収まり切る か 対面で意思疎通を取り切れる規模 の話に限られた話だと思っている。そのアプリ、新しい機能のリリースが１分１秒を争うというのなら話は別だが、そうでない限りは採用しようと思わない。（そもそも、そういったシチュエーション自体が想像できない。） Ruby on RailsがMVCの枠組みを外れると、設計者の意図を知らずにコードを読み解くことは非常に困難になる。（それはどのフレームワークでも、枠組から外れたらそうなのかもしれない。） Ruby Gemsは非常に強力だが、後から参画したメンバーがそのgem特有の機能を使ったコードを見せられて理解できるかといえば、そうではない。そもそもRuby自体が強い動的型付け言語であることが、コードリーディングの妨げになっているのではないか。 総じて、ドキュメントを十分に用意するなどスキトラを十分にこなせるのであれば良いが、そんな現場を見たことがない。

*1: 2018-09-04 updated