問題解決のしかたを本で読んで、実際にやっていくときにどう使っていくのかのイメージがつかない人が多そうなので書いてみる。 理解が深いほどある程度解決のための型があって、フレームワークの評価から実行へ移したくなったりもするけれど、過程で関わる人の理解がそろっていくのも大切なのでそこをどんなスピードとプロセスで進めていけるかが実地の問題解決者としてのアートな部分でもある。
の順で説明をしていく。
こんな指針がいいのかなー 2013 夏 ver.
.NET の「例外のデザインのガイドライン」にもこう書いてある。
名前は使われる場面で使い方を指示したり制約したりするような意味合いを名前で表現できるとよい名前になります。
表現しているクラスだったり変数の実装を見ながらつけると名前をつけるもの自体を中心においてそれを説明する名前になります。良い名前にしたいなら、そのオブジェクトやメソッド、変数が使われる場面で、どのように使うと読みやすいか、ミスしやすい部分をミスしないように導けるかを気にしながら、使う人へメッセージとなるような名前をつけます。
これを実装ではなく意図に名前をつけると呼んでいます。CODE COMPLETE 上巻の 11.1.2 に『問題指向の名前』という半ページくらいの文章があり、 How でなく What に名前をつけるという主旨のことが書いてあるのが元ネタ (の一つ) です[^1]。
意図 というすばらしい語彙は Kent Beck が Smalltalk Best Practice Patterns というこれまたすばらしい本に Intention Revealing Names という話を書いているということを以前一緒に働いた Java エンジニアに教えてもらって以来、気に入って大事に使っています[^2]。
何が起こっているのでしょうか？ それはコミュニケーションです。最も重要なのは、一行だけのメソッドでも、意図を伝えるために存在する価値があるということです。
どこの層まで Thor であることを意識させるかというのはポイントになりそうな気がします。 database は Thor 以外からはけして呼ばれないでしょうか？ たとえば、Web インターフェイスをかぶせた場合。bot を呼出し元として使い始めた場合。 実際にそれらを作り始めて不都合が出てから変えてもいいのですが、今の時点で
+--------------+ +-----------+
| dispatcher | | view |
+--------------+ +-----------+
+----------------------------+
| class Foo | |
| extend Ruby::Spock | |
| spec 'maximum of two numbers', ->(*) { | |
| expect { | |
| assert { [a, b].max == c } | |
| } | |
| where [ | |
| [ :a, :b, :c ], | |
| [ 1, 3, 3 ], #=> . |
基礎知識
読み物系
| require 'digest/sha1' | |
| def room_id(name) | |
| digest = Digest::SHA1.new | |
| digest.update(name) | |
| digest.hexdigest.slice(0,20) | |
| end | |
| def encryption_key(seed) | |
| alphabets = ('a'..'z') |