NOTE: 2014-01-08 追記あり。 前回のエントリでレガシーな開発環境を改善している話をした。 レガシーな開発環境の上にはレガシーなプロジェクトが存在していて、これを改善するためにどうすれば良いかを考える課程で、MVCとDDDに対する考えがまとまってきたのでアウトプットしておく。（まとまってきただけで実務レベルまではまだ落とし込めていない感） 自分が担当しているとあるWebコンテンツの話。 本題ではないので簡単に前置く。 PHP 仕様書、ドキュメント無し テスト無し 独自カスタマイズされたWAF コピペ、使用されていないソース 使用されていないテーブル、カラムの点在 Fat Controller そんな状態なわけで、当然のように日々の改修や新機能の追加でエンバグを起こす。しかも大人の事情で開発メンバーは突然入れ替わったりする。 これまでは、気をつけようとかしっかりチェックしていこ
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
