私の仕事の常連読者の方々はご存知かもしれませんが、私はソフトウェア開発について推論するために他の職業の比喩を使うことに非常に懐疑的です。特に、エンジニアリングの比喩は、設計と構築の分離という概念を促進してきたため、私たちの職業に損害を与えてきたと考えています。

ロンドンのオフィスにいたとき、この問題はリーン製造という文脈で提起されました。リーン製造は、特にポッペンディック夫妻によって、アジャイルのコミュニティで頻繁に使用されている比喩です。もし私が土木工学からの比喩的な推論を好まないのであれば、リーン製造からの比喩的な推論をより好むのでしょうか？

ほとんどのバージョン管理システムは、成果物のバージョン間の変更（Unixで生成できるコマンドから派生したdiffと呼ばれることが多い）の利用と理解に依存しています。テキストファイルとバイナリファイルに対しては、優れたdiff（とマージ）アルゴリズムが存在します。これらのdiffの問題点は、かなり単純であることです。それらは単に2つの成果物のバージョンを調べて、一方からもう一方へ移行するための単純な方法を生成するだけです。

私たちは最近、恒例のダイビング休暇を取りました。この休暇を取るたびに、私たちはジレンマに直面します。私たちが非常に気に入っているサバ島に行くのか、それとも新しい場所を試してみるのかということです。私たちの答えは、サバ島と新しい場所の両方に行くことであり、凍えるような北東部からの長い旅の疲れを癒すための、より長い休暇となりました。新しい場所はドミニカでした。

常にバージョン管理を使用している者として、コンピュータの使用のより多くの分野に発展する可能性があると考えています。ソフトウェア開発者以外では、コンピュータユーザーがバージョン管理を使用することはほとんどありません。しかし、ソフトウェア開発者が知っているように、バージョン管理は共同作業のための優れたメカニズムであり、複数の人が単一のソフトウェアシステムで共同作業することができます。バージョン管理がより広く使用されることのメリットは何でしょうか？

セルゲイ・ドミトリエフは、IntelliJ IdeaやReSharperなどの素晴らしいツールを提供してくれたJetBrainsのリーダーの一人です。彼は最近、メタプログラミングシステムと呼ばれる探索的開発について記事を発表しました。彼はこのシステムを、彼が言語指向プログラミングと呼ぶより広範な運動の一例と考えています。

私は10年以上OOPSLAに参加しています。それは、多くの友人と交流し、彼らの最近の活動を知り、OOコミュニティがどこに向かっているのかを感じ取る場所となっています。

私の分散オブジェクト設計の第一法則：オブジェクトを分散させない（P of EAAより）。

明確なコードは良いですが、テスト可能性のために明確さを犠牲にするべきでしょうか？

アジャイル開発の基本原則の1つは、要件の変更は予想されるだけでなく、歓迎されるということです。これは、Thoughtworksのような外部企業がクライアントのために作業を行っている場合、特に課題となります。多くのクライアントは固定価格の契約を希望しており、これは実際には固定スコープの幻想を見ているため、スコープを固定することになります。しかし、固定スコープの契約はアジャイル開発とは完全に矛盾するため、私たちのような企業はどうすればよいのでしょうか？

私の仲間のThoughtBloggersに注目してきたなら、私のフォウルボットの1つがヒューズを飛ばしたようだということはご存知でしょう。オーストラリアの太陽は明らかにこれらのスウェーデンのモデルを焦がすのです。

ジョンはデータ転送オブジェクトに腹を立てていますが、DTOが悪いわけではありません。他のパターンと同様に、特定の状況で役立ちます。パターンには常に2つの部分があります。どのように実装するか、そしていつ使うか、いつ使わないかです。実装方法を知るだけでなく、いつ使用し、いつ見送るかを知る必要があります。

開発チームの作業について話を聞いていると、共通のテーマとして、静的に保持されているものに対する嫌悪感があります。通常、静的変数と静的イニシャライザに共通のサービスまたはコンポーネントが保持されています。静的（ほとんどの言語では）の大きな問題の1つは、ポリモーフィズムを使用して1つの実装を別のものと置き換えることができないことです。私たちはテストの大ファンであるため、これは私たちにとって大きな問題です。そして、適切にテストするためには、サービスをサービススタブで置き換えることができることが重要です。

Debianでのほとんどのもののインストールは驚くほど簡単です：`apt-get install package-name`。残念ながら、Javaは基本的なDebianシステムには含まれていないため、例外です。最近、Debian SidデスクトップにJava 1.5（または5、または最近の呼び方）をダウンロードしてインストールしました。簡単に手順を説明します。

多くの企業は、スコープと価格を固定する契約を締結するというアイデアを好みます。なぜなら、それがリスクを軽減すると考えているからです。この幻想は、彼らの財務上の義務が取引価格で固定されていると述べています。満足のいくソフトウェアが得られなくても、費用はかかりません。

動的言語への関心の高まりに伴い、ラムダ（クロージャ、匿名関数、ブロックとも呼ばれる）と呼ばれるプログラミング概念に遭遇する人が増えています。C/C++/Java/C#言語のバックグラウンドを持つ人はラムダを持っていないため、それが何であるかわかりません。簡潔な説明を以下に示します。これらの言語でかなりのプログラミングを行ってきた人は、これは面白くないでしょう。

Subversionはオープンソースのバージョン管理システムであり、本質的にはCVSの後継です。これはCVSの最大の課題を解決し、アトミックコミットやファイルとディレクトリの名前変更のサポートなどの機能を導入しています。私はこれを数年使用しており、非常に堅牢であることがわかりました。

最近、エクストリームプログラミングの計画アプローチを使用する複数のチームで、標準的なストーリーポイントメカニズムを考案することについていくつかの質問を受けました。目的は、いくつかのチームが同等のストーリーポイントを使用することによって、あるチームの3ストーリーポイントの努力が別のチームと同じになるようにすることです。

これは、せいぜい限定的な価値しかなく、最悪の場合危険です。

数年前のクリスマスに、シンディは私にMagellan Meridian Gold GPSデバイスをプレゼントしてくれました。私は平均的な熊よりもナビゲーションが得意なので、これは本当に必要なものではなく、遊べるものだと思っていました。それ以来、私はこれを本当に頻繁に使用するものというよりも、興味深いおもちゃだと考えています。

プレミシラフ・ポクリフカによって提起された興味深い難問があります。書籍のリファクタリングの1つはNullオブジェクトの導入です。これは非常に便利なリファクタリングです（ジョシュの新しい本でも説明されています）。プレミシラフのポイントは、このリファクタリングが動作を変更できるということです。メソッドがnullを返し、そのnullでメソッドを呼び出すと、Nullポインタ例外が発生します。Nullオブジェクトを使用すると、何らかのデフォルトの動作が得られます。

プログラムのパフォーマンスを向上させるために変更を加える場合、これはリファクタリングですか？

Javaプログラムのメソッドやフィールドなどの宣言の順序を変更することは、リファクタリングですか？

リファクタリングメーリングリストで、何がリファクタリングであるか、またはそうでないかについて最近議論がありました。これらの議論と同様に、針の先端に何人の天使が乗れるかについて議論する危険性がありますが、境界について考えることはいくつかの有用な目的を持っています。

私のリファクタリングの本では、リファクタリングの定義をいくつか示しました。

ソフトウェアが不調に陥る場合、ジムはこのコラムで、なぜできるだけ早くクラッシュさせるべきかを説明しています。

私はしばしば、JUnitテストフレームワークの設計上の選択の1つ、つまり各テストメソッドの実行ごとに新しいオブジェクトを作成するという決定に関する質問を受けます。簡単なblikiエントリを正当化するのに十分です。（ただし、JUnitに関する私の記述が、他の形式のテストが重要ではないと考えているという意味ではないことを指摘する必要性を感じています。多くの有用なテスト活動があり、JUnitとその仲間はそれらの多くの活動に役立ちますが、万能の解決策ではありません。テストに関するさらに多くのブログについては、Brett Pettichord、Brian Marick、およびJames Bachのブログを参照することをお勧めします。また、xUnitテストに関する私の記述が、リファクタリング、ユースケース、フロッシングの重要性を示唆していないと推測しないでください。）

シンディは大工仕事における優れた技量を非常に意識しています。彼女は私が気づかないようなあらゆる種類の細かいディテールに気づきます。彼女は特に、それほど目立たないが、正しく行うのが非常に難しいことを高く評価しています。

クラスを作成する場合、ほとんどの場合、そのクラスの機能がそのクラスにとって意味のあるものであることを保証しようとします。しかし、クラスが自然には持つべきではない、より豊富なインターフェースに適合させるために機能を追加することが理にかなう場合があります。

古いメモを調べていて、Rich Garzanitiから教えてもらったシンプルだが便利なヒントを見つけました。

このページは非推奨になりました。このトピックに関するより良い説明については、ActivityOrientedを参照してください。

このページは非推奨になりました。このトピックに関するより良い説明については、OutcomeOrientedを参照してください。

このページは非推奨になりました。このトピックに関するより良い説明については、BusinessCapabilityCentricを参照してください。

Thoughtworksで働くことに快適に感じている理由はたくさんありますが、その多くは、ここのほとんどの人々が私と幅広い原則を共有しているためです。長年にわたって議論を引き起こしてきたものの1つは、私たち自身の知的財産に対する私たちの態度です。本質的に、私たちはそれを提供しています。

（マウス、Belkin KVMスイッチ、Linuxの問題）

これらは現在、Squeezeboxと呼ばれています。

時々、私のシグネチャシリーズに本を入れる方法について質問があります。多くの本のシリーズがあり、各シリーズには受け入れるものを決定する独自のやり方があります。これが私の決定方法です。

リレーショナルデータモデルは、ほとんどの人にとって、リレーショナルデータベースとSQL言語を通じて最もよく知られています。口語的には、データベースを一連のテーブルと見なし、各行にはデータが含まれています。クエリを行うために、これらのテーブルをさまざまな方法で操作できます。各クエリは別のテーブルになります。NetworkDataModelとは対照的に、テーブル間に明示的なポインターはありません。リンクは共通の値を持つ結合テーブルによって作成されます（ただし、サロゲートキーの使用は実際にはポインターがあることを意味します）。

オブジェクト指向設計について学ぶと、すぐにデータのカプセル化が重要であることを学びます。カプセル化の最も単純な形式は、アクセサ（取得と設定メソッド）またはプロパティを使用することです。言語がサポートしている場合。（一部はクラス内でこれを行います - SelfEncapsulation

オンサイト顧客は、エクストリームプログラミングの実践の1つであり、ホワイトブックで言及されている12のうちの1つです。開発者は、質問に答えたり、開発チームと交流したりするために、オープンな作業エリアにいる開発者と一緒に座るべきであると述べています。実際、彼らは開発チームの一員であり、チームの成功は開発者と同じくらい彼らにも依存していることを認識しています。そのため、通常の仕事を辞める必要はありませんが、物理的に出席する必要があります。

友人の友人の話です。少なくともどこかで真実であるはずです。

アプリケーションデータベースという用語は、単一のアプリケーションによって制御およびアクセスされるデータベースに使用します（IntegrationDatabaseとは対照的に）。単一のアプリケーションだけがデータベースにアクセスするため、データベースは、その1つのアプリケーションのニーズを簡単に満たすように具体的に定義できます。これにより、通常、IntegrationDatabaseよりも理解しやすく、多くの場合、単純な具体的なスキーマになります。

ネットワークデータモデルは、データをレコード型として構造化し、ポインターリンクを使用して1つのレコードから別のレコードに移動できるようにします。したがって、ネットワークデータモデルをクエリするには、1つのレコードから始め、ポインター参照を移動します。

数年前に、仕事生活の重要な側面を変更しました。それ以前は、1台のコンピューター（またはより厳密には1台のハードドライブ）でのみ作業しようとしました。すべての作業ファイルはラップトップのハードドライブに保存されていました。デスクトップマシンを使用する場合は、ファイル共有機能を使用してこれらのファイルを使用しました。

ユースケースは、要件を整理および収集するための手法です。元々は、1980年代後半から1990年代初頭にかけてIvar Jacobsonによって普及しました。

形容詞：明らかにばかげているほど単純すぎて役に立たない技術、ツール、または設計アイデアですが、使い始めると、そのシンプルさとは裏腹に力があります。

Knoppixは、いくつかの興味深い特性を持つLinuxディストリビューションです。

私の見解では、Gang of Fourは、オブジェクト指向設計に関するこれまでに書かれた最高の書籍です。おそらくあらゆるスタイルの設計の中でも最高の書籍でしょう。この書籍は、ソフトウェア業界に非常に大きな影響を与えました。Javaや.NETライブラリは、GOFパターンであふれています。

多くの期待の後、JetBrainsの皆さんから、彼らのC#ツールのアーリーアクセスプログラムが開始されました。残念ながら、彼らは私の命名アドバイスを無視し、代わりにReSharperと名付けました。私の同僚からの初期の反応は、熱心ではありましたが、まだ改善を求める声もありました。

C3は、クライスラーの給与計算プロジェクトであるChrysler Comprehensive Compensationプロジェクトの略称で、その後エクストリームプログラミングの「誕生プロジェクト」として有名になりました。

階層型データモデルは、階層またはツリー構造の形式で整理されます。初期のデータベースとプログラミングデータ構造は一般的に階層モデルを使用していましたが、これらは廃れていきました。データベースの世界ではRelationalDataModelが主流になり、ほとんどのインメモリプログラミングではNetworkDataModelが主流になっています。これは、階層は単純な整理ツールですが、データが複雑になるにつれて破綻するためです。

最近数ヶ月で、Debian Linuxのインストールに大量に時間を費やしました。ここ数ヶ月で、私の設定に多くの新しい環境が登場しました。Windows XPをインストールした新しいデスクトップマシン、MacOS Xを搭載したPowerbookラップトップ、Windows XPを搭載した新しい仕事用ラップトップを購入しました。これらすべてには、仕事用のラップトップでさえ、Thoughtworksが構成したWindows XPがすでにインストールされていましたが、私の仕事で使用しているさまざまなアプリケーションをインストールする作業が必要でした。

誰もが独自の重要な設計ガイドラインのリストを持っています。スコットはインターフェースに集中し、正しく使用しやすく、誤って使用しにくいように設計する方法を説明します。

アセットキャプチャは、StranglerFigApplicationを開発するための戦略です。多くのアプリケーションは、主要なアセットセットを管理していると考えることができます。給与計算システムは従業員を管理し、取引システムは取引を管理し、リースシステムはリースを管理します。新しいシステムに徐々に切り替えるには、新しいシステムで開始するアセットのサブセットを特定することから始めることができます。多くの場合、最初に開始するのに最適なアセットは、単純なアセット（開始が速いため）または古いシステムでは特に処理が困難なニーズを持つアセットです。

シドニーと私がオーストラリアに行った時、クイーンズランド州沿岸の熱帯雨林でしばらく過ごしました。この地域の自然の驚異の一つは、巨大な絞め殺しのイチジクです。それらは木の高い枝に種を付け、徐々に木を下って土壌に根を下ろします。長年にわたって、それらは幻想的で美しい形に成長しますが、一方で、その宿主であった木を絞め殺して殺します。

XPスタイルの計画を使用している場合、開発者から迅速にコンセンサス見積もりを得る必要があります。見積もりをざっくり出すことで、開発者が見積もりについて同じような見解を持っている場合（それを記録して先に進むことができます）、または意見の相違がある場合（ユーザーストーリーについてより詳細に話し合う必要がある場合）を迅速に判断できます。

私は多くのUMLダイアグラムを描きますが、CASEツールは使用しません。UMLをスケッチとして扱うことに興味があり、リポジトリ関連の機能には関心がないためです。これまで、私の通常の選択はVisioでした。VisioにはUMLテンプレートが付属していますが、組み込みのテンプレートは使用しません。Pavel Hrubyのテンプレートの方が好みです。

これは残念ながら一般的なアーキテクチャスタイルだと感じています。あなたの会社は非常に高価なインフラストラクチャソフトウェアを購入します。そして、たとえそれがプロジェクトに適していなく、余分な労力を必要とする場合でも、そのソフトウェアをプロジェクトで使用しなければならないと言われます。そんなに多くの費用を支払った後では、無駄にしたくありませんよね？

アジャイルプロジェクトに関するよくある質問の一つは、別のチームへの引き継ぎ方法です。開発チームが離れて、サポートチームにサポートを引き継ぐ場合、アジャイルプロジェクトは計画駆動型プロセスよりもはるかに少ないドキュメントを生成する傾向があるため、どのように対処するのでしょうか？

統合データベースは、複数のアプリケーションのデータストアとして機能し、それらのアプリケーション間でデータを統合するデータベースです（アプリケーションデータベースとは対照的です）。

データベースとアプリケーションの関係について話すとき、アプリケーションデータベースと統合データベースの2つのデータベーススタイルを区別することが有用であることがわかりました。この2つの違いは、データベースが単一のアプリケーション境界内で制御され、カプセル化されるかどうかです。

ソフトウェア開発に関するライター兼スピーカーとして、私は私たちの職業に関する膨大な量の一般的なアドバイスを提供しています。デコレータコマンドの動作方法など、具体的なものから、ソフトウェア開発の姿勢についてどのように考えるかなど、哲学的なものまで、私が出すノイズは尽きることがありません。さらに、私は一般的なアドバイスを提供する大規模なコミュニティの一員に過ぎません。著者、アナリスト企業、ジャーナリストなど、誰もが読むことができる以上の情報があります。

これは、今日完了する作業量は昨日完了した作業量と同じになるという原則です。反復型プロジェクトでは、今回のイテレーションで前回のイテレーションと同じだけの作業を行う計画を立てるべきであることを意味します。この用語は、エクストリームプログラミングコミュニティから来ています。

私は多くのカンファレンスのパネルに参加し、自分でいくつか主催しました。私が主催する際には、英国のテレビ時事番組パネル「質問時間」をベースにした特定のフォーマットを使用するのが好きです。私はそれを何度か行い、従来のパネルよりもはるかに好んでいます。

次のような寸法付き数値の処理：12フィートと9.99ドル

10月22～25日などの値の範囲を単一のオブジェクトとして扱う。

時々、私が言ったことに同意しないだけでなく、私が言ったことに驚いている人もいます。「あなたのようなグルが何かを言うと、多くの人が盲目的にあなたの言うことを実行します」。

エクストリームプログラミングと短期間接触する多くの人にとって、XPはソフトウェア設計の終焉を招くように見えます。多くの設計活動は「大きな前もっての設計」として嘲笑されるだけでなく、UML、柔軟なフレームワーク、さらにはパターンなどの設計技法も軽視されたり、完全に無視されたりします。実際、XPは多くの設計を伴いますが、確立されたソフトウェアプロセスとは異なる方法で行われます。XPは、進化を現実的な設計戦略にすることを可能にするプラクティスにより、進化型設計の概念を活性化しました。また、シンプルな設計の方法、リファクタリングを使用して設計をクリーンに保つ方法、進化型スタイルでパターンを使用する方法を学ぶ必要があるため、設計者にとって新しい課題とスキルを提供します。

OOPSLA 2003で、Dave Thomas（OTIの創設者）は、モデル駆動型アーキテクチャについて思慮深く強力な批判を行いました。このコラムでは、彼がなぜ普遍的なモデル駆動型アプローチが失敗する可能性が高いと考えているのかを説明し、UMLとドメイン固有言語はまだ価値があると指摘しています。

アジャイル手法の認定プログラムが必要でしょうか？

旅行から戻ってきましたので、メールでいただいたヒントのお返しとして、3週間の日本旅行の感想をいくつかお伝えします。

平均的な開発者はアジャイル手法を使用できますか？

2002年のXP/Agile Universeのワークショップに参加していたとき、「例による仕様」というフレーズが、XPにおけるテストの役割の一つを説明する方法として頭に浮かびました。

私は設計について書いていますが、やや抽象的な設計パターンについて議論している場合でも、ソースコードの例を提供することが有用だと考えています。もちろん、これにより、コード例がパターンであると考える人が出てしまう可能性がありますが、コードが提供する精度によって、そのリスクは上回ると考えています。何度か、あるアイデアについてよく分からなかったのですが、コード例によってそれが明確になりました。そのため、設計に関する文章では常にコード例を提供するようにしています。

ソフトウェア開発における多くの議論は、話者が指示型姿勢を持っているか、支援型姿勢を持っているかによって左右されます。これらの異なる姿勢は、言語、設計、ツール、プロセスなど、多くの選択に影響を与えます。

2つのソフトウェア開発の姿勢の1つ。指示型姿勢は、ほとんどの開発者はそれほど優れていない（平均を下回る開発者が約50％いるという噂がある）ため、彼らの仕事のやり方を指示する必要があると言っています。この指示は、彼らが作業しているシステムに害を及ぼすのを防ぐためです。通常、この姿勢は、開発者が特定の作業を行うのを防ぎ、複雑な領域から遠ざけるためにできることを制限する設計とツールとして現れます。

2つのソフトウェア開発の姿勢の1つ。支援型姿勢は、開発者は責任ある専門家であるため、必要な作業を行う自由を与えるべきであるという見解を取っています。この姿勢に従う設計は、使いやすくする必要がありますが、開発者は自分が何をしているかを知っていると想定し、したがって何かを誤って使用することを防ごうとはしません。そのため、これらのツールは誤用される可能性がありますが、ユーザーはもっとよく知るべきであり、そうでない場合は自業自得であるという姿勢を取っています。

モジュールプログラミングは、インターフェースへのプログラミングだけでなく、さまざまなモジュールがどの具体的なモジュールと通信しているかを知ることなく、モジュールをアセンブルすることでもあります。

私の初期のお気に入りの本の1つは、TsichritzisとLochovskyのデータモデルに関する本でした。この本では、データについて考えるためのさまざまなモデル、特に当時最も議論されていた3つのモデル：リレーショナルデータモデル、階層型データモデル、ネットワークデータモデルについて説明しています。

最初にC#に出会ったとき、最初からプロパティの概念が好きでした。C++/JavaのgetXとsetXの規則は、私にはいつもかなりばかげて思えました。obj.X = other.Xと書く方がはるかに自然です。getメソッドとsetメソッドを持つプロパティを提供することで、一般的な規則が言語の自然にサポートされている機能になります。

一部の人は、モデル駆動型アーキテクチャ（MDA）が、アセンブラから最初の高水準言語への移行以来、ソフトウェア開発における最大の変化になると考えています。他の人は、それが「リビングケースツールの夜」以上のものはないと考えています。私は後者の陣営にいますが、巧妙な言葉以上のものが必要だと感じています。

これは非常に一般的なパターンであり、非常にシンプルでもあります。コマンドに適用されたデコレータパターンにすぎません。コマンド指向インターフェースでよく使用されているのを見ました。これはインターセプタ、およびアスペクト指向プログラミングの一種としても呼ばれています。

人々がエクストリームプログラミングについて話すとき、彼らはしばしば、その適応型計画スタイルや進化型設計アプローチなどのことに焦点を当てています。しかし、私が特に興味を持っている小さな成長しつつある傾向として、非常に低い欠陥率（月に1件未満の運用上のバグ）を持つXPプロジェクトの数がわずかに増加していることがあります。

Javaコミュニティでは、異なるプロジェクトのコンポーネントを統合的なアプリケーションに組み立てるのに役立つ軽量コンテナが急増しています。これらのコンテナの基盤には、それらがワイヤリングを実行する方法に関する共通のパターンがあり、これらは非常に一般的な「制御の反転 (Inversion of Control)」という名前で呼ばれています。この記事では、より具体的な「依存性注入 (Dependency Injection)」という名前でこのパターンがどのように機能するかを掘り下げ、サービスロケータの代替案と比較します。それらの選択は、構成と使用の分離という原則ほど重要ではありません。

Bruce Eckel氏の最近のAntとMakeに関する投稿に触発され、ビルド言語に関する私の考えを共有したいと思います。AntとMakeの両方とも、ビルド方法を指定します。つまり、ビルドを記述するための言語です。どちらも広く使用されており、成功を収めています。しかし、どちらも限界に達しており、大規模システムでは、他のプログラムからAnt/Makeファイルを生成している人を見つけるのはごく普通のことです。

最近気づいた興味深い対比があります。規模が似ている（約10万行）2つのエンタープライズアプリケーションプロジェクト、環境もJavaと.NETと似ています。一方のプロジェクトは、完全なビルドとテストを1時間で実行できますが、もう一方は2〜3分かかります。

多くの人にとってアジャイル手法を理解するのが難しい点の1つは、アジャイルの人材重視の考え方です。アジャイルプロセスに関心のある人々は、プロジェクトの成功に対するプロセスの影響は二次的なものであることに全員が同意しています。アジャイル宣言の最初の価値は、「プロセスやツールよりも、個人と対話」が重視されることです。

XMLはしばらく前から存在しており、広く使用されています。実際、必要以上に多く使用されています。ほとんどのツールと同様に、XMLは特定の用途には適していますが、他の用途には適していません。

かつては一部の人しか知らなかった用語である「リファクタリング」は、現在ではコンピュータ業界で一般的に使用されています。私はこれが一部原因であると考えており、一部のプログラマーの生活と一部の企業の収益を向上させたことを願っています。（重要な点として、私はリファクタリングの創始者でも発明者でもありません。単なる文書作成者です。）

リファクタリング、JUnitなどのツール、エクストリームプログラミング（XP）などのアジャイル手法の人気が高まるにつれて、新しい設計スタイルが登場しました。継続的な設計とは、リファクタリングを使用してプログラムの設計を継続的に改善するプロセスです。このコラムでは、Jimが国際化やトランザクションなど、難しいと思われる設計上の問題を中心に、継続的な設計に関する経験について説明します。

オブジェクト指向開発の初期から、OO設計は反復型および増分型開発と関連付けられてきました。しかし、多くの人が指摘するように、両者には本質的な関連性はありません。ウォーターフォールでOOを行うことができ、オブジェクトなしでIIDを行うこともできます。では、なぜこの2つは密接に関連付けられているのでしょうか？