2012年8月に「たのしい開発をするにはどうしたらよいか」という内容の本が技術評論社から出版されました。
https://amazon.co.jp/dp/9784774151663
Rubyを使ってたのしく開発できている著者たちがRubyを軸にどのように考えて開発しているかを紹介する本なのですが、だれが読むとうれしいのかが難しい本です。「Rubyに憧れを持っている人」、「Ruby界隈にどっぷりと浸かった人」が読むとうれしい本ではないでしょうか。そうではない人、例えば、「Rubyを当たり前のこととして使っている人」、「Rubyに興味がない人」などは読むと違和感があるでしょう。
この本にはRuby界隈で聞かれるキラキラした単語がたくさん詰まっています。「たのしい」、「いきいき」、「勉強会」、「DSL」。Rubyに憧れているけど、自分ではまだ動き出せていない人には、この本の内容が力強い後押しになるでしょう。「とある企業のRuby導入事例」で以下のような話がでています。憧れているだけのときは「Rubyを使うにはどうしたらよいか」視点でばかり考えてしまうでしょうが、そこを乗り越えて「このためにRubyが適しているから使う」と考えられるようになれればRubyを使える機会が増えるということを伝えています。これは「Rubyを当たり前のこととして使っている人」には普通の感覚ですが、憧れているだけの人はそこまで考えられていないことが多いので、この話が入ることでバランスがよくなっています。
まず、自分がやりたいことを言うときに「Ruby」や「Rails」と言わなくなりました。RubyやRailsはどうすごいのかということを語らずに、お客さんの課題や問題に対するソリューションという形を中心に話すようになりました。
また、この本にはRuby界隈の人の名前がよく出てきます。Ruby界隈にどっぷりと浸かった人は親近感を持って楽しく読めるでしょう。
一方、そうでない人にはなかなか難しい本です。というのは、この本全体が一貫性に欠けるからです。上記の人たちは勢いで読んでいって一貫性はあまり気にならないでしょうが、普通に読み進めていくと気になってしまいます。
例えば、この本の中では以下のようにチームで協力してたのしく開発したいという思いを伝えています。
問題をチームで捉え、チームにフィードバックしながら学び教え合うことで個人やチームはさらに大きく成長できる、そんな流れをイメージしています。そして、それはとてもたのしいことだと思うのです。
一方、Rubyの動的な性質をメリットとして紹介している部分では、動的な性質を使えば他の人と協力しなくてもよい点を挙げています。
ソースファイルを変更する権限がBさんにない場合は、Aさんに連絡をつけ、依頼して変更してもらわなければなりません。これはかなりの手間であり、時間の損失です。
また、Railsに関してはRailsの思想に従うべきだとしています。
Railsで開発を行うのであれば、Railsの思想に従うべきです。そうしないと、Railsの用意してくれた楽な道をたどることができず、各種のやりにくさに対抗しながら我が道を切り開くということになります。流れに逆らって進むようなものです。これではせっかくのRailsの良さを十分に活かすことができません。
一方、Railsの「高機能Scaffold」プラグインに関してはプラグインの思想から外れることが前提のように書かれています。
- デフォルトの設定にない機能を追加する際は、プラグインの用意したやり方で行う必要がある。そのやり方を調べるのに時間がかかる
- プラグインの想定外の機能追加をする際は、プラグインそのものをカスタマイズしないといけなくなり、苦労する
これはそのままRailsにも当てはまることです。おそらく、Railsとプラグインでは扱いが違うのでしょうが、その理由が明示されていないため一貫性がないと感じる原因になっています。
他にも、Rubyの名前付けの慣習がわかりやすいという説明もしています。
破壊的メソッドは概して「!」で終わる、真偽値を返す問い合わせメソッドは「?」で終わる、といった慣習があり、名前だけでかなりの情報を把握することができるようになっています。
その後、慣習ではなくルールで決めているものもあり、ルールなので他の言語よりもよいと説明が続きます。
定数名は大文字で始まる、インスタンス変数は「@」で始まるといった記法上の決まりも、名前だけで多くのことを判断でき、一貫性があって便利です注3。
注3) JavaやC++などでは、メンバー変数を「m_」で始めるといったやり方が使われますが、これは文法上の約束事ではないため、漏れが生じたり、チームによって作法が違ってしまいます。Rubyでは@の有無に統一され、このような問題はありません。
この本は複数著者で書かれているため単一著者の本に比べて一貫性が損なわれるのはしょうがないのでしょう。ただし、全体（300ページほど）の1/3強を使ってRubyとRailsを紹介してる部分を除けばそれほど一貫性を欠かずに読み進められそうです。すでにRubyとRailsを知っている人はこの部分を除いて読むという読み方がよいかもしれません。
おまけ: 「判断基準を伝えよう。（技を）盗むのは大変。盗んでないでもっと先へ行け。」を覚えていてくれたのはうれしかったです。
