URLマッピングは規約ベースベースがいいな

Architecture Programming Java 
Webフレームワークは星の数ほどあります。
それぞれ色々なスタイルがあって、
それぞれ色々な場面に最適になるようにできています。

しかしながら、ここ数年で、
「とりあえずこれはこうあって欲しい」
というのがふんわり固まってきたのが...

「事業会社だと、
URLマッピングは規約ベースベースがいいなっ」

って。
少なくともjfluteの身の回りでは、
自分もそう思ってるし、周りと話しても、
わりとそう思っている人が多いです。

規約ベースの弱点は？

Teeda や Ymir、そして、SAStruts がそうなってます。
元々は、Railsの発想から来ているはずです。

URLが "/sea/land/" だったら、
sea.LandAction#index() もしくは、SeaAction#land()
URLからクラス名が決めるやり方。

規約ベースの弱点の一つは、自由度が少ないこと。
いざってときに、特殊なURLを表現することができない。
Ymirはとても柔軟ですが、TeedaやSAStrutsはもろにそうでした。
SAFluteでは、拡張で変更できるように。

規約ベースの弱点は、クラス名やメソッド名が引きずられること。
IndexActionだらけ、index.jspだらけ。
ctrl+shift+Rしても、うへー（＞＜。(特にSAStruts)
SAFluteでは、拡張で...
"/sea" だったら sea.SeaIndexAction とか、
sea_index.jsp とかの名前に変更できるように。

と、弱点はそれなりにあるわけなのですが、
最近よく使っている SAFlute では、
その辺を回避できるようにしちゃいました。
 -> SAFluteトップページ | DBFlute

規約ベースのうれしいとこは？

すると、今度はメリット。

とにもかくにも、

URLとパッケージ・クラス構造が一緒になる

ということ。
これが担保されると何がうれしいかと言うと、

探しやすい

ctrl+shift+Rですぐに辿れる。
クラスを見た瞬間にURLと直結するので、
画面をイメージしやすい。

なんのドキュメントもなしに、
なんの特別なツールもなしに、
それができるってのうれしい。

開発スタイルが違えば...

「別に規約ベースでなくても、
そんな大はずれなクラスにはしないでしょ？」

と、普通は確かにその通り。
受注開発とかであれば、
最初からしっかりURLとそれに対応するクラス名も決めて、
そしてそれが、途中でそんなに大変わりすることもあまり
ないかと思います。(あるときゃあるけど)
マッピングのドキュメントもしっかりメンテされているでしょう。

だがしかし！

事業会社、特に、
社内にエンジニアを集めてビジネスサイドと近い場所で、

運営しながらそのビジネスを一緒に作り上げていくような

スピード重視のリーンスタートアップ・インクリメンタル開発、
こういう現場だと、途中でどんどん大変わりしまくります。

まず、ドキュメントをキープしていくのは辛いです。
成長の段階で新しいエンジニアが次々と参画していき、
コーディング規約なんかも浸透しづらいものです。

そんな中だと、
どうしても「えっ、このURLでこのクラス名!?」ってのも、
ちょっとずつ発生してきてしまうもので...
いやっ、そんなにひどいものでなくても、
規則的でなければ、やっぱり探しにくいのです。

# ちなみに、よくあるのが、
# クラスのURLパートとメソッドのURLパートの分割されてると...
# @Foo("sea")
# class Xxx {
#     @Bar("land")
#     public void yyy() { ... }
# }
# だと、"/sea/land" という文字列でgrepかけても
# ヒットしないという...（＞＜

実際、行き来してると...

実際、jfluteは、
「規約ベースのプロジェクト(SAFlute利用)」
と
「そうでないプロジェクト」
のプログラムを行き来していますが...

そのクラスやテンプレートファイルなどの探しやすさ、
URL構造のわかりやすさが断然に違います。
規模的には既にまるごと記憶できるレベルのものではありません。
分析のスピードにも影響がでるなぁ、といつも感じています。
(厳密には、探すためのツールは用意されているのですが、
最新のEclipseだと動かないとかあったりして...
なんとか移行しようと...ちょい苦戦...（＞＜)

そして、HotDeployのエントリでも書きましたが...
 -> HotDeploy、いつどこでだれと？

既存コードの分析をする場面がとにかく多い

その探しやすさとわかりやすさが活躍する場面が、
じっくりの受注開発のときよりも圧倒的に多いでしょう。
(息を吸うかのごとく既存コードの分析はします)

なので、

放っておいても ※これ重要

クラスとURLが一致するフレームワークの方が、
安心感あるなーというのが実感です。
Railsがサービスの現場で多く使われてるってのも、
一理あるのかなって思ってしまいました。
（HotDeployのこともあるしね）

規約ベースをベースに

で、もちろん特殊なURLを表現できないと苦戦するときも
あるので、基本的に規約ベースなんだけど、
いざとなったらカスタマイズできるっていうのが、
ちょうどいいのかなって。

だから、

規約ベースではなく、
「規約ベースベース」なのです。

最近、ちょっとずつ SpringMVC にアプローチしていますが、
ちょっとした工夫で、RequestMappingを空っぽにして、
クラス名やメソッド名からURLを導出できるように...
なーんてできないかなって模索中です。

というか、そういう機能あるのかも知れないけど...
まだまだこれから(^^

【追記】
さっそく、makiさんからTwitterでコメント頂きました。
なんとぅ、あるみたいです！やったー。
 -> 17.13.1 The Controller ControllerClassNameHandlerMapping

※いつもいつも、アドバイスありがとうございます(感謝感謝)