http://martinfowler.com/bliki/SpecificationByExample.html XP/Agile Universe 2002のワークショップで「Specification By Example（実例による仕様書、SbE）」という言葉に心を奪われた。これは、XPにおけるテストのあり方のひとつではないか。 （このところ、テスト駆動開発(TDD)のテスト部分を語るのは流行遅れなのだそうだ。ひどい話だ。Jonと同じく、私も、そんな副次的なものなんかよりも包括的な自動テストにこそTDDの真髄があると考えている。 例えば、誰かに「100万ドルあげるから山にハイキングしておいで」と言われたとしよう。私は胸を張ってこう言うね。「今回のハイキングの目的は、自然の美を堪能するためである」と。いや、まあ、もちろん、懐もあたたかくなるけど……ね。 ） 仕様書について議論する際、

http://martinfowler.com/bliki/VeryLowDefectProject.html XPについて話すとき、たいてい「適応型の計画手法」や「進化的な設計手法」といったものに注目が集まりますが、私がとりわけ興味を持っているのは、少ないながらも着実に伸びてきている「低欠陥XPプロジェクト」の数です。ここで言う「低欠陥」とは、バグの発生が月に1つ以下というレベルのことを指します。 最初に出会ったのは、Kentによる、ある企業についての記述でした。 この企業は食料を分類する機械を持っていました。機械にはベルトコンベアがついており、それがカメラを通り抜け、センサーをくぐり抜けるようになっています。そうして、果物や野菜がそれぞれのカテゴリに分類されていくわけです（これらの仕組みはSmalltalkで動いています）。 以前は既知のバグが100ほどありましたが、XPを適応してから

以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ

http://martinfowler.com/bliki/LocalDTO.html （最後の部分を更新） ThoughtBloggersをよく見ているんでしたら、 fowlbotのひとりが怒っているのをご存じかもしれません。 オーストラリアの太陽がスウェーデンのモデルをジリジリと焦がしています。 JonはData Transfer Objects（邦訳）にムカついているようですが、 これはDTOが悪者ということではありません。 他のパターンと同様、ある文脈内でのみ有用というだけのことです。 パターンは常に2つの部分に分けられます。 「どのように使うか（How）」と「いつ使うか（When）」です。 実装の仕方を知るだけでなく、 いつ使う（使わない）べきかも知っておく必要があるのです。 彼はポイントを突いています。 私はリモートインターフェースという文脈でDTOを語っていますが、 パターン

http://martinfowler.com/bliki/HarvestedFramework.html 使えるフレームワークを作るには、フレームワークの構築から始めるのではなく、アプリケーションを作ることから始めよう。アプリケーションを作る時でも、汎用的なコードを開発しようとしないで、うまく分割され設計されたアプリケーションを作るのだ。 あるアプリケーションを作ったあとで、同じような要求をもつほかのアプリケーションを作ることがある。こんな時は、一番目と二番目のアプリケーションの間にある重複に気を配ってみる。重複を見つけたら共通領域に入れてやる。この共通領域がフレームワークの前段階（プロト・フレームワーク）になる。 さらにいくつかのアプリケーションの開発を続けていくと、そのフレームワークは徐々に洗練されていく。 最初の二つのアプリケーションのコードは、すべてを単一のコードベースに留めてお

http://martinfowler.com/bliki/PeopleMatterMost.html 最近、考えるようになったことがいくつかある。 それは、私のソフトウェア開発観の基礎となるものである。 ソフトウェア開発の鍵となるものをまず1つ挙げるとしたら、 それはソフトウェア開発に欠かせない要素、つまり 「働く人」だ。 優秀な開発者の生産性は、平均値よりも遥かに高い。 その差は給与の差よりも大きいだろう。 つまり、費用対効果の高いソフトウェア開発を行うために最も重要なことは、 できるだけ優秀なチームを雇うということである （たとえ開発者のコストが平均より高くてもだ）。 少数の優秀な（単価の高い）開発者の生産性は、 多くの平凡な（単価の安い）開発者の生産性よりも遥かに高い。 つまり、少数精鋭の開発者は、日換算ではコストがかかるかもしれないが、 トータルで見るとより低価格なソフトウェアを

http://www.martinfowler.com/bliki/TechnicalDebt.html システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リ

http://www.martinfowler.com/bliki/RoysSocialExperiment.html 2005/3/29 私たちは、ThoughtWorksのことを「ソフトウェアアプリケーション開発企業」だと言ってる。 時には、その価値観や他社との差別化について語ることもある。 しかし、そうしたことはすべて的を射ていない――ThoughtWorksとは本来、企業ではないのだ。 ThoughtWorksとは、Royの「社会的実験」なのである。 Roy SinghamはThoughtWorksの創業者だ。 彼は、自分の作りたい企業が本当に作れるのかを確かめるためにThoughtWorksを起業した。 それが今も続いているのである。 この会社には、みんなが彼に「できるわけがない」と言ったことが数多く存在している。 有能な人しかいない会社なんて無理だよ。有能な人が利用する普通の人

http://martinfowler.com/bliki/CheaperTalentHypothesis.html 2008/2/8 ソフトウェア業界では、才能あるプログラマのほうが生産性が高いとよく言われる。 生産性は計測不能なので証明はできないのだけど、おそらくそれは正しいだろう。 人間の活動のほとんど全てにおいて、他人よりも優れた人がいるのである。 そしてその違いは、著しいことがしばしばだ。 ソフトウェア業界においては、プログラマ自身がその違いに気づくことが多い。 ただ、その場合も常に自分を「才能ある方」に入れているみたいだけど。 当然ながら、優れたプログラマは、フルタイムで雇うにせよ契約するにせよ、その単価は高い。しかし、たとえ単価が高いとしても、高価なプログラマのほうが実際には安価なのではないだろうか？ バカげた質問に聞こえるかもしれない。 何をどうしたら高価な人材が安価になる

http://martinfowler.com/bliki/TestCancer.html 2007/12/6 本の執筆に専念するようになってから、ソフトウェア開発の現場と疎遠になるのがよく心配になる。 これまでに現場を離れた有名人を何人も目にしているが、私は彼らと同じような運命をたどりたくはない。 私にはThoughtWorksという最高の情報源があるので、まだ地に足をつけていられるのだ。 ThoughtWorksはまた、現場からのアイデアの源でもある。 同僚が発見し開発したものについて書くことは楽しい。 本当に役に立つものなので、読者のみなさんには是非とも使ってもらいたい。 さて、本日の話題は、あまり気持ちのいいものではない。 答えの出ていない問題についてである。 話はこうだ。 我々はプロジェクトを成し遂げ、ピッカピカのソフトウェアをクライアントに納品した。 納品時には自動テスト一式も

http://martinfowler.com/bliki/BookCode.html 2007/12/4 最近はめっきり本番用のコードを書いてない。 ただ、コードは書いている。書籍の内容を説明するためのコードだ。これに何時間もかけている。 書籍用のコードは本番用のコードとは違うので、考慮すべき点も違ってくる。 まずは、言語の選択だ。 書籍用のコードは、多くの読者が読める言語で書く必要がある。 内容はできるだけプラットフォームに依存しないようにしているが、コードは正確でなければならない。 そのため、みんなが理解できる言語を選択する必要がある。 その昔、オブジェクト指向の2大言語はSmalltalkとC++だった。 どちらもイマイチなところがあって、Smalltalkは知らない人には読みにくいし、C++は正確に書くことが難しかった★。 Javaの登場は天からの恵みだった。 C/C++を知って

http://martinfowler.com/bliki/ModelDrivenArchitecture.html モデル駆動型アーキテクチャ(MDA)は、ソフトウェア開発において、アセンブラから初期の高レベル言語への転換以来の大きな転換となるだろう、という人がいます。一方で、単なる『ナイト・オブ・ザ・リビング・CASEツール／ゾンビの誕生*1』に過ぎないという人もいます。私は後者の立場ですが、こういったうまい言い回し以上の何かが必要だと感じています。 今までにMDAについて語られてきたことは、80年代にCASEツールコミュニティーで語られてきたこととまったく同じです。CASEツールが失敗したのにはいくつかの理由がありますが、根本的な理由は「一般的なエンタープライズアプリケーションを他の選択肢よりも生産的に構築できる統合プログラミング環境」ではなかったという点でしょう。 CASEツールは

http://www.martinfowler.com/bliki/UmlAsSketch.html この使用方法では、 開発者はUMLをシステムのある側面を伝えるのに使います。 設計図と同じように、スケッチをフォワードエンジニアリングやリバースエンジニアリングの方針として使うことが出来ます。 フォワードエンジニアリングでは、 コードを書く前にUMLを描きます。 リバースエンジニアリングでは、 既存のコードからUMLを作成し、 コードを理解しやすくします。 スケッチの肝は取捨選択が可能なところです。 フォワードスケッチングを行えば、 今から書こうとするコードのだいたいの項目を挙げて、 チーム内で話し合うことが出来ます。 スケッチを描くと、これからやろうとしていることについてのアイデアや選択肢を話し合うのに役立ちます。 すべてのコードについて話さなくてよいのです。 最初に同僚に説明したいと思

http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース（fluent interface）」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,

http://martinfowler.com/bliki/CommandQuerySeparation.html 「コマンド・問い合わせの分離」という言葉は、Bertrand Meyer氏が『オブジェクト指向入門』で最初に述べたものである。これは、オブジェクト指向黎明期における最も影響力のある書籍である。 （1版がその影響力を持っていた。 2版も優れているが、これを持ち運ぶにはスポーツジムに数ヶ月は通う必要があるだろう） 基本的な考えは、オブジェクトのメソッドを明確に2つのカテゴリに分類するというものである。 問い合わせ：結果を返し、システムの状態を変更しない（副作用がない） コマンド：システムの状態を変更し、値を返さない 「コマンド」という用語は他の文脈でも広く用いられるため、 私は「モディファイア(modifiers)」という言葉を好んで使っている。 あるいは「ミュテータ(mutat

http://martinfowler.com/bliki/DomainSpecificLanguage.html ドメイン特化言語(DSL:Domain Specific Language)とは、 ある特定の種類の問題に特化したコンピュータ言語のことです。 様々な問題に対応できる汎用的な言語のことではありません。 ドメイン特化言語についてはこれまでも議論されてきましたし、 コンピュータが使われてきたのと同じくらい長い間使われてきました。 DSLを頻繁に使用しているコミュニティにUnixコミュニティがあります。 そこでは、DSLは「リトル言語」や「ミニ言語」などと呼ばれています （この伝統について、Eric Raymondが素晴らしい議論を提供してくれています）。 最も一般的なUnixスタイルのやり方は、 言語の文法を定義し、コード生成機能を使ってDSLから汎用的な言語を生成する、 あるい

http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし