MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
対象読者 ソフトウェアテストを勉強したい人 本を読むのが面倒で、手っ取り早くポイントだけ知りたい人 アリエル固有のことは書いていないので、テスト技術者の教育担当者は、講義資料として使ってください 1. テストの進め方 テストの前に対象ソフトウェアを理解すること バグ1件ごとにバグ報告を書くこと(複数のバグを同じレポート内に書かないこと) 正しく動かないはず、と思ってテストすること 境界条件を意識すること 最小限の再現条件を探す努力をすること 普通の使い方(正常系)でまともに動作しない場合、テストの中断も考慮すること(時間の無駄かもしれないので) wontfix(修正しない)の返答に対して、その判断を無批判に受け入れないこと(プログラマはwontfixの判断をよく間違えるので) リリース間際の場合、修正しない判断には高度に政治的な背景があるかもしれないので、こだわりすぎないこと 格言:優秀な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く