Hatena::ブログ(Diary)

杉風呂2.0 - A Lifelog -

2015-12-01(火)

else に書かれるべきロジック

2 種類が混ざって使われていないか?という気づきをメモしておく。

  • 正常系パス
    • 例えば、boolean を返す問い合わせメソッドのように 分岐のコードパスが 2 つしかない場合
    • これは何も問題ない
  • 例外を避けて安全側に倒したデフォルト
    • これが正常系パスのように扱われているケースがないか?
    • ほんとに後続処理をして問題ないか?
    • 例外を出せない理由があるなら、ログを追加して運用で対処したりすべきではないか?(と考えているが、そのように判断されることがないように思うのでこの記事をメモした次第。)

2015-01-13(火)

[]RailsRESTful な URL にこだわらないと...

備忘録。

ダメなルーティングの臭い

  • 名詞ではなく動詞が使われている
  • resources/resourceよりもget/post/put/patch/deleteが使われている
  • コントローラ内にscaffoldで生成される7つのアクション以外のアクション定義が多い
  • resources/resourceのonlyオプションで本来使われるべき7つのアクションがcollection/memberブロック中に登場する

ダメなルーティングだと起こりえる問題

  • リソースの発見を逃す
  • モデルとテーブルの発見を逃す
  • 機能追加の際に、テーブルにNULL可なカラムを追加し、レコードをUPDATEする処理を書くようになる
  • 1つのテーブルに複数の要件が盛り込まれ、モデルのコールバックなどで「関心事の分離」ができない状態になる
  • しばしば正規化が崩れ、状態管理が複雑になる/過去の状態が追跡不可能になる
  • コントローラにアクションが増えるにしたがって、モデルにあるべきロジックがコントローラに残る(Fat Controller)

避けるためのヒント

  • resource/resources の単数/複数の違いを知る(inflector なども調べとくとよい)
  • shallow/module/namespace/path オプションとコントローラの書き方を学ぶ
  • scaffold で生成される以外のアクションを極力書かない
  • 永続化しないモデルを導入してエントリポイントとする(サービスパターン、ファサードパターン)
  • DB のイベント系エンティティと REST のリソースを対応させて考えてみる
  • UPDATE SQLがリソースの更新以外で発行されたら検討の余地あり

2014-11-03(月)

[]エンジニアが事業計画を知らなくてモノが作れるのか?

駄文ポエムです。

  • 先のことなんてわからないし、事業計画通りにいくわけがない。だがしかし
    • 何ヶ月後にどのくらいのユーザを集めたいのか、それがどれくらいのトランザクションを発生させるのか知らなくて作れる?
    • たとえYAGNIといっても直近作るfeatureぐらいは知っているべき
  • 事業規模に合わせて段階的にスケールさせていけばいいが、そのタイミングがいつなのか知っているか?
    • プロトタイプレベルの実装とプロダクションレベルの実装は違う
    • 機能が変われば最適なデータモデルやアプリケーションアーキテクチャも違う
    • チーム体制だって違う
  • エンジニアは、トレードオフを都度判断し、決定する
    • エンジニアリング上の判断がサービスの成長や企業の収益に直結する時代
    • 設計を統合したり、ビジネスサイドや経営層にリスクを説明したり諸々提案、交渉する役割を担う人が重要
  • プログラミングできればそれで満足なエンジニアなんてほとんどいない
    • サービスが提供する価値は何か、自分のやったことが会社にどういった利益をもたらすのか、世の中にどう役立つのかを知らないで仕事できないよね
    • にんげんだもの
トラックバック - http://d.hatena.ne.jp/suginoy/20141103