Martin Fowler's Bliki in Japanese - 進化的設計
Bill Venners: 「設計の終焉?」の中で計画的設計について述べられていますよね。計画的設計とはどういったものでしょうか？ Martin Fowler: 私は計画的設計と進化的設計とを区別しています。計画的設計とは、ソフトウェアを作る際にまず設計を行い、それからコーディングするようなことを指します。計画的設計はUMLダイアグラムの形をとることがあります。システムをサブシステムに分解し、サブシステム間のインターフェイスを定義するものだといえるかもしれません。計画的設計を用いれば、設計とコーディングとの間に明確な「スイッチ」が存在することになります。それぞれのタスクは普通、別々の人間が行います。設計者が設計を行い、開発者がコーディングを行うのです。必ずしも完全に確定したものではないにせよ、設計はほぼ確定したものとして扱われます。設計が優れていれば、コーディング時の変更が少なくなると言っ
Martin Fowler's Bliki in Japanese - 優れたほうが安い説
http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる
Martin Fowler's Bliki in Japanese - 設計力
http://martinfowler.com/bliki/PreferDesignSkills.html 2008/1/18 雇用について考えてみよう。 応募者が2人。どちらも経験が数年間。 青コーナーの人には、あなたが好きな設計スタイルの広範な設計力が備わっている（私の場合だと、DRY、分別のあるパターンの使用、TDD、伝わるようなコード、なんかが挙げられるけど、自分の好きなやつでいいよ）。ただし、彼女には、あなたが使っているプラットフォーム技術についての知識がない。 赤コーナーの人には、そういった設計の知識は（それに興味も）ないが、プラットフォーム技術についての知識はめちゃくちゃある。言語には詳しいし、どのライブラリが使えるかはよく知ってるし、ツールも流暢に使いこなす。 これ以外のことについては（こうした思考実験以外については）、2人ともまったく一緒だとしよう。 また、あなたのチーム
Martin Fowler's Bliki in Japanese - 流れるようなインターフェース
http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース（fluent interface）」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,
Martin Fowler's Bliki in Japanese - エンタープライズRails
http://www.martinfowler.com/bliki/EnterpriseRails.html Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。 先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。 これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌*1の表紙になった画像をうまく編集して、DHHは自らをソフトウェア界のネオ（救世主）として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
