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