ぷっちん日記

■ だめすぎる

私もだめだけど。だめだなぁ。

問題解決で普通、これはするでしょう。

• その問題は本当に解決する価値があるのか
• とれる対応策を検討
• ほかに痛みが出てもとるべき対応策をとる
• 正しく原因を分析して次に備える

痛みが出るからって文句言って当たり散らさないでもらいたい。痛みのない解決策がない状態にヒスらないでもらいたい。

原因の分析能力がないと正しく責任も追及できない。人心離れます。

■ 負けていたので

悔しくなって合戦へ没入。てんでひよっこなので迷惑をかけるし道に迷うが、地道に勉強しようと意気込んでいる。

はじめて、敵国のまげを手にいれた。

■ 夢

そういえば、この前、また大学の単位がとれそうもない系の夢をみた。両親に、留年しそうであることを告げていた。

大学のとき、実際には、単位は0.5しか余りがなかったものの、すごく危なかったというほどでもなかったのに、どうしてこんなにも夢をみるのだろう。危なかった記憶がないけで当時は苦しかったのだろうか？ 自信がなくなってきた。

■ 合戦のあと

格別役にたつわけではないが戦場で何回か死んで明け方ちかくに寝ると、なにか、息苦しくて、そのまま死ぬんじゃないかという気持ちになる。たぶん合戦は関係なくて、夜更かしして血行が悪くて頭が働きつづけているとかそんな感じなのだけれど。

ただ、これで死ぬなんておかしい、こんなはずではなかったと思う。

思うのに、つい遊んでしまう。遊ぶのをやめるのは無理なので、次は、思い残すことはないとでも思うようにしてみようか？ でも、本当に死んだら嫌だよな、と思ったり。まあ、死ぬのは嫌でもいいのかな？

■ 小槌をバージョンアップリリース

１年以上ぶり（？）に、Web家計簿「小槌」をバージョンアップリリースしました。

私自身が、重すぎて使えないよ；；という状態に陥ってはや６ヶ月くらいだったのですが、にわかに使える状態になって気持ちが盛り上がってきております。会社も個人もデータが入って気分の良い状態になりました。

いろいろプランがあるので、時間はないけれど、無理にでも進めていきたいところ。

■ 呼び出し側から書く

Rubyを使うようになってからのような気がするが、私は日頃、コードを「呼び出し側から書く」ようにしている。とても役に立つ手法だと思うので、ここで紹介したい。

例えば、勤務表から総役務時間を得たいとする。

このとき「ええと、勤務表である MonthlyWork クラスのインスタンスには日ごとに DailyWork があって、それらのうち実役務時間と有給休暇を足して... 」といったことを考えたりは *しない*。

「どうやってその機能を実現するか」を最初は考えないようにする。「本当にその機能を実現できるだろうか、不安だ」というような感情が襲ってくることもあるだろう（特に初心者には）。しかし、大概のことは最終的には実現できるし、もし本当に実現できない問題があったとすればそれは個人のせいではない。

「どうやってその機能を実現するか」を考え始める代わりに、私はまだ存在しないその機能を「呼び出してみる」。

具体的な手順はこうだ。Railsならばコントローラなりビューなり、そのメソッドを呼び出したい場所が「何処」であるかを考える。そして、そこに行って、こんなかんじで打ち込んでみるのである。

総役務時間: <%= monthly_work.total_work_time %>

このようにすることで、最初に考えることは次の３つに絞られる。

• どこから使うか
• 誰（どのオブジェクト）の仕事にするか
• どんな名前や引数で呼び出すか

この３つは、オブジェクト指向プログラミングにおける基本的かつ重要な設計事項である。ここをいい感じにすることにまず力を注ぐ。

もし、.を打ったあと手が止まってしまうようであれば、SPACEALCなどで調べたり、Googleで検索したり、チャットで意見をもらったりして、適切な言葉を探す。この段階でけっこう時間をかけることもある。

書いてみて、なにか格好悪く感じたり、気に入らなければ、心ゆくまで書き直す。いわば、自分の感性を利用して、I/F設計を練るわけだ。そして、納得のゆく呼び出し側コードを完成させる。

呼び出し方が決まったら、次は実装だ。今回のようなケースではこの後にスペック（単体テスト）を書いたりする。MonthlyWorkクラスのtotal_work_timeというメソッドとして実装することがもう決まっているので、スムーズに書き始めることができる。（逆に言えば、どのクラスのなんというメソッドにするかが不安定な状態で闇雲にスペックを書こうとするよりも、まずI/F設計に集中したほうがよい。テストファースト以前に設計ファーストだ。）

スペックを書いたらそれが通るように実装を行う。冒頭に挙げた「どのようにして総役務時間を計算するか」を考えるのはこのタイミングである。これより前に考える必要はない。ちなみに、実装中に、たとえば日単位のデータを持つ DailyWork に新しいメソッドが必要であるとわかったら、ここでもまず呼び出し側コードを書いて同様の手順で実装していく。

最終的に、スペックが通るようになったら、ブラウザを起動して、一番最初に書いたビューを表示する。ちゃんと動いているはずだ。

以上、「呼び出し側から書く」手法について書いてみた。日頃「書いたコードがどうもしっくり来ない」「この機能はどこに書くのが正解なのかな？」というような悩みを抱えている人の参考になればうれしい。