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/TestCancer.html 2007/12/6 本の執筆に専念するようになってから、ソフトウェア開発の現場と疎遠になるのがよく心配になる。 これまでに現場を離れた有名人を何人も目にしているが、私は彼らと同じような運命をたどりたくはない。 私にはThoughtWorksという最高の情報源があるので、まだ地に足をつけていられるのだ。 ThoughtWorksはまた、現場からのアイデアの源でもある。 同僚が発見し開発したものについて書くことは楽しい。 本当に役に立つものなので、読者のみなさんには是非とも使ってもらいたい。 さて、本日の話題は、あまり気持ちのいいものではない。 答えの出ていない問題についてである。 話はこうだ。 我々はプロジェクトを成し遂げ、ピッカピカのソフトウェアをクライアントに納品した。 納品時には自動テスト一式も
Martin Fowler's Bliki in Japanese - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
Martin Fowler's Bliki in Japanese - 言語ワークベンチ
以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」 の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriente
Martin Fowler's Bliki in Japanese - アジャイルの押しつけ
http://martinfowler.com/bliki/AgileImposition.html 2006/10/2 （更新：XPメーリングリストで有益な議論があった。特にKentの返信は読んでおくべきだろう。議論を有益な方向に導いてくれた。） アジャイルアライアンスのボードメンバによると、アジャイル方法論は「キャズムを超えた」そうだ。 つまり、より多くの人に知れ渡ったということだろう。 これはアジャイルの利点だが、同時に問題も起きている。 方法論や設計手法が単なる流行になってしまったために、流行にのみ注目して、使用したり、教えたりする人が多い。 また、アジャイル設立者の原則とは正反対のことをして、アジャイルの名を汚しているという報告もある。 Webを巡回していると、ある開発チームが上層部からアジャイル方法論を押しつけられているというコメントを見つけた。 チームにプロセスを押しつけると
「SOAはベンダーがツールを売り込むためのバズワードに過ぎない」，Martin Fowler氏語る
「私はSOA（サービス指向アーキテクチャ）に対してはシニカルに考えている」。「Refactoring」や「Patterns of Enterprise Application Architecture」といった書籍の著者として有名な米ThoughtWorks チーフサイエンティストのMartin Fowler氏は2006年5月30日，東京都内で講演し，SOAの現状に疑問を投げかけた。SOAは意味のあいまいないわば“バズワード”であり，ベンダーがツールを売り込むための宣伝文句になっているというのだ。ただし，SOAの中には優れたコンセプトもあり，そうしたコンセプトはSOAという言葉とは切り離して考えるべきだという。 「最初は意味があってもすぐに意味がなくなってしまういつものパターンの言葉」というのが，Fowler氏のSOAに対する第一印象だったという。「（同じSOAといっても）人によって言うこ
Martin Fowler's Bliki in Japanese - 建築家
http://martinfowler.com/bliki/BuildingArchitect.html 「ソフトウェアアーキテクト」という言葉を使うとき、 アーキテクトの役割を理解しやすいように、建築のメタファーを使う。 だが皮肉にもこのことが原因で、建物のアーキテクト（建築家）の本来の役割が正しく理解されずにいる。 ソフトウェアアーキテクトとは、チーフ設計者であり、 プロジェクトのメンバを率いる存在である。 しかしこれは、建築家がやっていることではない。 建築家は、クライアント（建物が欲しいひと）とのやり取りに専念しており、 クライアントにとって重要なことにしか関心がない。 たとえば、建物のレイアウトだとか外観だとか、そういったものだ。 けれども、建物に必要なものは他にもまだたくさんある。 建築家には、建物の構造が確かかどうかについての責任はない。 それは、私の妻Cindyのような、建
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
