RailsあるあるがRailsあるあるじゃない件 - Qiita
http://www.slideshare.net/tricknotes/rails-possiblestory ここに記載されているのはRailsどうのでなく設計の問題なので、これを「Railsのあるある」という人は、他の言語やwebアプリのFWでもまた同じ間違いを犯ちゃうのでは疑惑。 1.社員レコードは論路削除で… 問題の原因は、モデルの状態遷移・各状態で機能がどう振る舞うかを検討せず（設計をせず）に実装にとりかかってることでは。 やるべきだった手順 現実世界での対象モデルの状態を整理する 内定、有効、休職傷病、産休、退職、一時退職（役員とかになる場合の）とか？ アプリケーション内で定義すべき状態を整理する （社員だと、権限に関わるのでそれに関係しそうな状態を整理する） {準備, 有効, 休職, 退職, 無効, ロック}とか？ 最適な実装方法を考える 状態を管理する属性をモデルに持たせ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブログが続かないわけ | ログイン処理が簡単と言い切れるか 〜 フィッシング対策も忘れずに
