転職初日

今日から転職。とりあえずearly small successをしばらく意識したいと思う。

転職初日で色々と自己紹介やら既存コード見るやらその他いろんな設定やらで大変だったけど、心機一転ワクワクした気分で初日を迎えることができた。 前職にいた先輩社員が「とにかくearly small sucess！やれることなんて限られてる。最初のうちは小さいことをコツコツやって、成功を見てもらえ。」みたいなことを言ってた。いきなり大きな事やろうと思って、経験も能力も不足しているので中途半端な状況になってしまうことが多い。最初のうちは変な見栄を張らないで、小さくコツコツ、徐々に大きく仕事をこなしていきたいと思う。 （このearly small successって誰が最初に言い出したのか。）

開発の備忘録メモ

railsにおけるdecoratorの役割の再確認

今日コード呼んでてdecoratorがrailsプロジェクトにあったのだけど、ふと「あれdecoratorってなんだっけ？」みたいになったので備忘録。

完結にまとめると * モデル部分に書くビューへの表示ロジックを、別モジュールのDecoratorという（Railsでは主にモデル）ラッパーみたいな物に切り分けて、FatModelを軽減させるデザインパターンの一種 * 表示ロジックはhelperに書く考え方もrailsにはあるけど、各モデルにロジックが同様で重複したhelperメソッドが出来てしまう。これは小さいアプリケーションなら余り記にする必要はないかもしれないけれど、大きくなるに連れてコードの見通しを悪くする。そこで、decoratorという層を作って、モデルから表示ロジックを生やすイメージ。 * 要はモデルにある責務を、他の層（decorator）に移譲する考え方と認識しました。責務の整理。 * decoratorからhelperを呼び出せるので、helperの処理を継承したdecoratorメソッドみたいなものも作るのはありかも。 参考

railsで作る分には（他の言語やWAFでもそうかもしれないけど、）decoratorの目的は、「表示ロジックなど、モデルなどのDBに近い？層とは切り離せる処理を、別の層に移してFatModelを防ぐ」って感じだろうか。 gemも色々あってよく見るのはDraper, activedecorator。

あと単一のモデルオブジェクトからロジックを作るには、decoratorでいいけど、複数のモデルオブジェクトを跨ったロジックを書く場合は、presentorというパターンに沿った設計をすると、更にメンテ性が上がるサービスになるのも頭の片隅入れておいて良いかも。。参考。 あとPORO（Plain Old Ruby Object）というActiverecordを継承しない素のrubyオブジェクトを定義して、そこに汎用的な処理をまとめるという記事も参考になった。参考

どれもある程度成長したサービスに適用できそうなパターンだけど、今後このあたりのリファクタリングとかを任されたら、色々役に立てるかもしれない。