WEBアプリのフレームワークの選定について

まず、フレームワークにおいてどこで何をするのかをまとめます。

着眼点

環境構築のしやすさ

  • 各種インストールのしやすさ
バージョン問題が発生して、このバージョンだとうまくいかない等があるかどうか
  • プロジェクト作成コマンド
プロジェクト作成コマンドがあるかどうか

オートロード or import

  • ディレクトリ配下のファイルをロードする
オートロードされるディレクトリ配下にアプリケーション内で共有するものを置きます

※コントローラー等でimportやrequireが不要なので、コード量が少なくなります
※使用していないものもオートロードされます

  • 各ファイルの依存モジュールがわかりやすいように都度import
各ファイルにおいて使うものだけを読み込みます

※依存するファイルが一目で分かります
※importやrequireが大量になることも
※使用するもののみ読み込みます

ディレクトリ構成は決まっているか柔軟性があるか

  • 決まっている
設定より規約の考え

※すでに決まっているディレクトリ構成を変更しやすいかどうか

  • 柔軟性がある
開発者がディレクトリ構成の大半を決める

※プロジェクトによってディレクトリ構成がまちまちで混乱の元
※結局はベスト・プラクティスのディレクトリ構成に収束する

testフレームワーク

  • CIとの連携が可能かどうか
ほとんどのフレームワークが可能

※どのCIと連携できるかも重要

言語

コード量が少なくて済む
  • js
ECMAScript6以前の書き方がレガシーコードになる可能性が高い

ルーティング

  • コントローラーのアクションとビューの紐付け
フレームワークとして暗黙的に決まっている
or
アクションとビューの紐付けを明示的に記載する

※前者の場合は暗黙的な規約を覚える必要がある ※後者の場合はアプリケーションが成長すると共に設定ファイルが大きくなってしまう
※後者の場合はアクションとビューの作成に設定ファイルへの記述という一手間が必要

誰でも触りやすいかどうか

  • ジェネレーターの有無
コマンドだけで一連の大枠は作成できる
  • 暗黙的な規約が分かりやすいかどうか
他のフレームワークと似たような規約か独自の規約か

※AngularJSは独自の規約のような印象です

フレームワークの作りの分かりやすさ

  • 暗黙的な規約が分かりやすいかどうか
他のフレームワークと似たような規約か独自の規約か

※AngularJSは独自の規約のような印象です

記述量が少ないかどうか(DIの観点)

  • 設定ファイルへの記載
少ない方が生産性が高いと考えられます

※この場合は暗黙的な規定を理解することが前提です

環境(production,staging,testing,development)による設定をどう分けるか

  • どこで設定するか
環境指定用のファイルと各種設定ファイルのセクション
or
ファイル名に環境プレフィックスを付ける(production.rb)

アプリケーション起動時の流れ

  • 主な設定内容



アプリケーションの依存モジュールの分かりやすさ




生産性

グローバル変数の定義

ログ

ロジックの切り分けやすさ

設定より規約(デフォルトは規約。変えたければ変えて良い)