がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

「設定より規約」がいささか怖い

結論を先に書いちゃうと「好みとさじ加減」って話ではあるのですが。
なんとなし、「設定より規約」に対する、肯定的意見は山盛りに見れど、否定的な見解をあんまり見かけないので、書いてみようかなぁ、っという天邪鬼的意図です。
なので、いささか「意図的に否定的」にしてるので、話半分、気軽に読んでくださいませ。


前提。
「複雑な設定ファイル イクナイ!」ってのは、自明の理というか「地と汗と涙と怒号と悲鳴で」体感してきた事実。
設定ファイル自体はよいのよ。コード内のマジックナンバーとか大変だし、「この辺はユーザがいじってもいいヨん」なところは触らせた方が早いし。
ただ、そこから段々膨れあがって「あれもこれも設定できる」で、太って散らかって奇々怪々。


JavaとかSOAPとか系の長々したXML設定ファイルはぶっちゃけ「見るもうんざり」な分量になるケースがあるし。
そもそも、昔懐かしい悪名高い sendmail.cf を、直接でも間接でもメンテしてる世代なので以下略。
そこから「設定ファイルしんどい!」経由でCoCが出てきたのは大体歴史的経緯としてわかるざんす。


ただ…なんとなし、結局のところ「規約が設定ファイルと同じような道をたどってないかい?」って疑問が以下略。


で、設定より規約(CoC:convention over configuration)。
基本的には「特に指定しなきゃデフォ(規約)の設定で動くよ」ってのがあって。
そこから「デフォのままでよけりゃややこくて長い設定書かなくていいよ」「デフォと差異をつけたい所だけ書いてちょ」ってのがあって、これはとても便利だと思うのです。


デフォが「自明の理であるか、あるいは量が溢れるほど大量でないか、あるいはちゃんと情報がまとまっているか」でありかつ「自分の肌にあう」んなら。


ん…「肌に合わないデフォ」ってんなら、単に「設定を上書けばいい」だけだと思ってるので、好みの問題だと思うのですが。
なんとなし最近気になるのが「デフォの規約が特盛りつゆだくだく」なケース。
かつ、そのデフォがじゃぁ「どこかにわかりやすく一覧でまとまってりゃ」まだよいのですが、いまひとつその辺が整理されてなかったりするケース。


そのツールだフレームワークだを「ある程度しっかりやっている人たち」にとってはもはや空気なのでしょうが。
見ず知らずの人間が入っていくと、そこは結構な「地図無しの魔境」になってしまって。
おいちゃんは「ソースコードをおもむろに読み始める」とかやりますが、そこまでやる人も少ないしねぇやるにしても労力かかるのよ、っていう。
で「肌に合わない」系の設定をおもむろに紐解きつつ読み込んでいくのって、結構しんどいのよ(苦笑


そうすると「全部設定に書いてある、のほうが、解読するとき楽ぢゃね?」とか思う瞬間が、まぁぶっちゃけ、ちらほら。


どちらかというとおいちゃんも「ものぐさer」なので、設定書かなくてもいいよん、ってのは嬉しいはずなのですが。
その為に事前に把握すべき「規約」があんまりにも「てんこ盛りな上で未整理しかも好み外」だと、そっちを読み解くコストのほうがかかったりするのですだね。
「ソース全部読み解く」くらいなら「全部設定に書いてある」ほうが、まだぶっちゃけ読みやすい。


そーゆーのを見るにつれ「設定より規約、も、よしあしだなぁ」とか思う瞬間があったりあったり。
さじ加減って、重要ですよねぇ、ってなお話に落ち着くわけなので。


で…この辺を思ったのはぶっちゃけますと、直接の発端はchef。
実際には「設定できない」ので、「設定より規約」ぢゃなくて「規約」なのですが。


なんていうかなぁ…「Attribute書けるファイルがあっちらこっちら散らかってる( http://dev.classmethod.jp/server-side/chef/attribute-overrides-pattern/ )」とか「Attributeの強さは弱い順にdefault→force_default→normal→override→force_override→automaticと分かれています( http://dev.classmethod.jp/server-side/chef/attribute-overrides-pattern/ )」とか。
散らかってるって話だと、 http://tech.blog.piyo.org/2012/05/23/chef-attribute%E3%81%AE%E7%90%86%E8%A7%A3/ とか http://wadahiro.hatenablog.com/entry/2013/01/05/201309 とか。
正直これですでにお腹いっぱい(苦笑


っつか初手のころは「なんで、 default[:hoge] = 10 って記述のブツを見る時に node[:hoge] になるのさ」ってあたりから疑問の嵐。
勿論ちゃんと「それなりの理由と背景があった結果」なのは分かるんだけど、これをもって「コードが書ける」とかいわれても、些か、読み解くのがしんどい。


背景もまぁ…分かるんだけど「もうちょっとダイエットでけんかったん?」とか、色々思う。
ディレクトリも。そりゃ色々理由はあるんだろうにしても、何種類もあって使い分けが見えない見えない。


結果として。具体的に「ナニが見えない」って、さりげにサイトとか人によってディレクトリの使い方が「微妙に」異なるのと、さらに「現場はそれとも異なる」から。
背景哲学とコンテキスト読み切らないと、かみ砕く事もできやしない。


一回「理解できる」と、多分その辺を使うのが楽しいんだろうなぁ、と思うのですが、それって「道具の乱用」に割と直結しないかしらん? という危惧もびしばし。
プライベートならともかく、お仕事現場でそれ見るのは、些か、しんどいんだよなぁぶっちゃけ、という雑感。


なので、 http://chopl.in/blog/2014/01/19/chef_makes_me_tired.html あたりに割と共感するわけなのです。


この辺は、CoCではなく「単にツールの設計の問題ぢゃね?」って気もするのですが。
ただ、ここを基点に考えてみると「ルール(規約)を作る」「整理せんまま、追加追加でルールが太る」に加えて「サル山のフルボッコ( http://d.hatena.ne.jp/gallu/20090403/p4 )が発生する」とかなると、色々としんどいんですねぇ、っと。


ンなことをつらつらと考えている時に、たまたま「設定より規約」をググるタイミングがありまして。
ふと見ていると、皆「規約まんせ〜」ばかりで、その規約が「暴走暴発した時のこと」があんまり書いていなかったので。


で…まぁこの例については「勉強せぇ」で終わるんではあるのですが。
学び初めの子達にとっては。PHPは一通り何となく読めても、いきなりフレームワークの「URL マッピング」とか出てくるとパニクるわけですよ。
いやまぁいい「勉強のとっかかり」にはなるので、URLマッピング自体をNGと言うつもりはないのですが(とはいえおいちゃんは嫌いだけどなw)。


ただ、そーゆーのを見ていると、勿論「如何に規約を整理して伝えるか」「学ぶか」ってのもあるんだけど。
その一方で、あんまり規約まんせ〜にして「規約を積み上げていく」と、些か危ないんじゃないかなぁ? とか思うですだよ。
ただ、目にするのは割と「規約まんせ〜」で、規約を増やす、規約が増える事に対して、あんまり記述がなかったりする。


なので。
「設定より規約」はいいんだけど、その「規約」をちゃんと「整理して理解してる?」とか「追加する時に後先考えてる?」とか、ちょっと立ち止まってもらえると、もしかしたら「不幸にならないで済む人」もいるんぢゃねぇかなぁ? とか思うのですだよ。


ってなわけで、いつもの如く、ダダ漏れに思考をmemoり。