設定より規約
convention over configuration
「設定より規約」の字義を理解するには背景を知っておく必要がある ref 古いframeworkには設定ファイルを大量に書かせるものがあったらしい
例えば、classとDBのmappingのための設定など
class名とtable名、property名とcolumn名を整合するために設定ファイルに書く必要があった
しかしこれはかなり煩雑になるし、メンテコストが高い
設定ファイルというのは、xmlとかymlとかにごちゃごちゃ書くやつmrsekut.icon
mrsekut.iconはSymfonyを触ったことがあるのでそのイメージがわかる
そこで、「class名とtable名は同じにする」という規約を入れる
そうすると、設定ファイルの記述は不要になる
例外的にclass名とtable名を異なる名前にしたいときだけ設定ファイルを書けば良くなる
例
Kohana
Grails
Grok
Zend Framework
CakePHP
Symfony
参考
いろいろ書いていて面白い
認知資源が乏しい人は車輪の再発明をよくやってる、という話はあまり同意しない 規約か設定かの2項対立になってるのがおかしくて、設定も規約もないに越したことはないmrsekut.icon
文章に呪詛を感じるので、過去のチームが辛かったんだなという感じがした
とはいえ、暗黙的な規約は辛い印象があるmrsekut.icon
規約を全部頭に入れておかないといけない
これは、実装する側もそうだし、読む側もそう
仕様を知らないと全く理解できない
ヒントがなさすぎてググりようがないこともある
そのフレームワークを使ってプロダクトを作り始めた人なら良いけど、
後からprojectに参加した人からするとかなりしんどい
明示的に書かれていないのに、挙動が決まっている
何でそういう挙動をするのか？を実装から予測できない
Symfonyでgetter名をShipping.get_delivery_dateとし、
TwigでShipping.deliveryDateと書くと、
getDeliveryDateとかget_delivery_dateとかが探される
これは一見便利だが、getDeliveryDateをgrepしてもSymfony上のEntityに辿り着くことができない
制限をかけなさすぎることで、逆に辛さが増している
Symfonyはこういうのが多すぎてめちゃくちゃしんどいmrsekut.icon
まあ暗黙的な規約があっても、全体としての仕様が少なければ何の問題も起きない
10分ドキュメント読んでから参加して、といえばいい
何より、人の作った規約を覚えるのは大変に苦痛な作業であり、プログラミングの楽しさをスポイルしている
そして彼らのいう「規約」は、単に彼らにとってのローカルルールであり、一度ドメインをはずれれば役に立たない
「規約を覚えれば楽」という思想は、もう今の巨大化したフレームワークでは形骸化していると思っている
わかるmrsekut.icon
これって動的型付言語特有の言葉なん？
そんなことはないな