はてなブックマーク

http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備

大規模なソフトウェア開発、たとえば大企業向けのソフトウェア開発では、多くの人を必要とします。 多くの人が関与するときには、うまくチームに分ける方法を考える必要があります。 ビジネス機能中心のチームを作れば、顧客のニーズに対応したソフトウェア開発ができるでしょう。 しかし、求められるスキルの範囲が膨大になります。 チームトポロジーとは、ソフトウェア開発チームの組織化を記述するモデルです。 Matthew SkeltonとManuel Paisによって開発されました。 チームトポロジーでは、4つの形態のチームと3つのインタラクションモードが定義されています。 ビジネス機能中心のチームが価値あるソフトウェアの流れを提供できるように、 健全なインタラクションを促すモデルです。 このフレームワークにおける主要なチーム形態は、ストリームアラインドチームです。 ストリームアラインドチームとは、ひとつのビ

情報がリッチなプログラムをモジュール化する一般的な方法は、大きく3つのレイヤーに分割することです。 その3つとは、プレゼンテーション（UI）、ドメインロジック（ビジネスロジック）、データアクセスです。 ウェブアプリケーションであれば、HTTPリクエストをハンドリングしてHTMLをレンダリングするウェブレイヤー、バリデーションや計算が含まれるビジネスロジックレイヤー、データをデータベースやリモートサービスに永続化する方法を管理するデータアクセスレイヤーに分けられます。 これは多くのアプリケーションに使えるモジュール化の形式です。 また、私が定期的に使用したり推奨したりするものです。 （私にとっての）最大の利点は、意識のスコープを狭められるところです。3つのトピックを比較的独立して考えることができるからです。 ドメインロジックのコードに取り組んでいるときは、UIをほぼ無視したり、データソースを

私が敬愛するソフトウェアアーキテクチャの専門家たちは、この分野のあらゆる一般法則に対して懐疑的です。 優れたソフトウェアアーキテクチャはコンテキストに固有であり、さまざまな環境下で異なる解決をしなければならないトレードオフを分析するものだからです。 とはいえ、彼ら全員が同意するものがひとつだけあります。 それは、コンウェイの法則の重要性とパワーです。 私がこれまでに経験したすべてのシステムに影響を与えるほど重要であり、抗えないほどのパワーがあります。 この法則を説明するには、作者の言葉がいちばんでしょう1。 システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。 ―メルヴィン・コンウェイ コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。 元々は、1つのチームでコンパイラーを作

https://martinfowler.com/articles/202107-what-doing-now.html 数か月前、私は講演活動から退くことを記事にしました。執筆活動は続けているのかと疑問に思った方もいるでしょう。その記事の中では執筆中であると書きましたが、最近取り組んでいることについて、もう少しお話したほうがいいのではないかと考えました。 これまでの執筆活動と違うのは、本になるような大きなテーマには取り組んでいないことです。『リファクタリング』の第2版を完成させてからは、ほとんどの期間をこのウェブサイトに費やしてきました。数年間ずっと悩んでいたソースコードブランチ管理のパターンの記事にも数か月かかりました。それが終わってからは、放置したままだった2つの大きなテーマであるフロントエンドアーキテクチャとイベントに改めて取り組んでみようと考えました。しばらくの間、フロントエンド

https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 私が気に入っている引用の一つに「もしそれが痛みを伴うのであれば、さらに頻繁にそれを行え」という引用がある。 この言葉は、表面的には馬鹿げたことに見えるという幸せな性質も持っているが、深く探れば価値のあることがわかる。 このことを説明するための例示できる文脈は、統合だ。 ほとんどのプログラマーは、自分の仕事を他の人と統合することは苛立たしくてつらい経験であることを早い段階で学ぶ。 そのため、自然な人間の反応として、できるだけ統合を先延ばしにしようとする。 上記グラフのように、その行動を起こすまでにかかる時間と、その行動に伴う痛みに指数関数的な関係がある場合、その行動をより頻繁に行うと、痛みを大幅に軽減できる。 そして、これが継続的インテグレーションで起こることだ。毎日

Eradicating Non-Determinism in Tests 自動化されたリグレッションスイートは、ソフトウェアプロジェクトにおいて本番環境の欠陥を減らし、進化的設計を実現するうえで重要な役割を果たします。開発チームと話をする中で、私は非決定的なテストの問題についてよく耳にします。非決定的なテストとは成功したり失敗したりするようなテストのことです。制御されていないまま放置された非決定的テストは、自動化されたリグレッションスイートの価値を完全に破壊してしまう可能性があります。この記事では、非決定的テストに対処する方法の概要を説明します。手始めにはそういったテストを隔離することで他のテストへのダメージを減らすことができますが、それでもすぐに修正しなければなりません。そのため、非決定的テストのよくある原因である、分離の欠如、非同期的な挙動、リモートサービス、時間、リソースリークなどへ

https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン

http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる——ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが”唯一の”ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重

ソフトウェアの世界では、ソフトウェアプロセスの方式を説明するときに「ウォーターフォール」という言葉がよく使われる。これは、反復型あるいはアジャイル方式の考えとは対照的なものだ。ソフトウェアの世界でよく知られている用語の多くがそうであるように、この「ウォーターフォール」も意味が明確に定義されておらず、起源もあいまいである。だが、その本質的なテーマは「大きな労力を活動をベースにしたフェーズに分割する」ことだと私は考えている。 「ウォーターフォール」という言葉がどのように広まったかは定かではない。だが、その起源はWinston Royceの論文とされており、以下の図を参照することが多い。 この論文は（滝のようにタスクが流れ落ちていく形状から）ウォーターフォールの考えの起源であると広く認知されている。だが、「ウォーターフォール」という言葉は、この論文には登場しない。この名前が後にどのように登場した

[source and translators] 原文: https://www.martinfowler.com/eaaCatalog/dataMapper.html Mapper (473) レイヤは、オブジェクトとデータベース間でデータを移動させる。データは、オブジェクト、データベース、およびMapperから独立させる。 解説の全文は『PofEAA』 165 ページを参照。 オブジェクトとリレーショナルデータベースは、 異なるメカニズムでデータを構成している。 オブジェクトの多くの部分（コレクションや継承など）は、 リレーショナルデータベースでは表すことができない。 多くのビジネスロジックを伴ったオブジェクトモデルを構築する場合、 データおよびデータに付随する振る舞いをうまくまとめるために、 このメカニズムを使うことは非常に大切である。 これによりスキーマが異なったままとなる。 つま

http://martinfowler.com/bliki/ValueObject.html プログラミングをする時、物事を複合物として表現すると便利だと思うことがよくあります。 例えば、2次元座標はx軸とy軸で構成されます。お金の額面は数値と通貨で構成されます。日付の範囲は開始日と終了日で構成されます。日付は年、月、日で構成されることもあります。 これを実践してみると、2つの複合オブジェクトが同じものであるかどうかという疑問が湧いてきます。 例として、2つの点オブジェクトを考えてみましょう。それらは両方とも(2,3)のデカルト座標を示しています。この2つの点オブジェクトを等価として扱うことは理にかなっています。 プロパティの値が同じであるオブジェクト（この場合のプロパティはx座標とy座標）はバリューオブジェクトと呼ばれます。 しかしながら注意してプログラミングしないと、意図した動作になら

http://martinfowler.com/bliki/FlaccidScrum.html 2009/1/29 多くのプロジェクトで混乱が起こっているようだ。次のようなことになっているらしい。 アジャイルプロセスを使ってみたいと思ってScrumを選ぶ。 Scrumのプラクティス、そして原則を採用する。 しばらくすると動きが悪くなる。コードはぐちゃぐちゃ。 これはソフトウェアの内部品質に彼らが気を配っていなかったことが原因だ。思うように新しい機能が追加できず、生産性がガタ落ちしたことにすぐに気づくはずだ。ズルズルと技術的負債に陥り、Scrumがヘロヘロになってしまったわけだ。（本当のスクラムだったら、これが最悪なことだって分かるだろう） ここでScrumに言及したのは、この問題に気づいたときによく使われていた代表的なプロセスがScrumであったからだ。こうした状況はScrumによって悪化

[source and translators] 原文: https://www.martinfowler.com/eaaCatalog/repository.html by Edward Hieatt and Rob Mee ドメインオブジェクトにアクセスするためのコレクション ライクなインターフェースを使って、ドメイン—データ マッピングレイヤ間の仲介を行う。 解説の全文は『PofEAA』 322 ページを参照。 複雑なドメインモデルのあるシステムは、ドメイン オブジェクトをデータベースアクセスコードから分離するDataMapper(165)などのレイヤの恩恵を受けやすい。 そのようなシステムでは、クエリ構文を構築するマッピングレイヤ上にもうひとつ抽象的なレイヤを設けると良い。 ドメインのクラスやクエリが膨大になれば、このことは重要になってくる。 特にこの場合、レイヤを追加することでク

以下の文章は、Martin Fowler による 「Language Workbenches: The Killer-App for Domain Specific Languages?」の日本語訳である。 ソフトウェア開発における新しい考えの多くは、実は古い考えの新しい組み合わせ方です。この記事では、その新しい組み合わせ方のひとつ、私が「言語ワークベンチ(Language Workbenches)」と呼んでいるツールについて説明します。これは、現在広まりつつある考え方で、たとえば、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどが例として挙げられます。これらのツールは古い開発スタイルを採用しており、私はこれを「言語指向プログラミング(language oriented

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

http://www.martinfowler.com/bliki/EnterpriseRails.html Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。 先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。 これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌(訳注：Linux Journal誌だと思われ。)の表紙になった画像をうまく編集して、DH

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

http://martinfowler.com/bliki/DesignStaminaHypothesis.html ソフトウェアをきちんと設計するのは、その労力に見合うことなのか？ 「ソフトウェアをきちんと設計することって、そんなに大切なことなの？」という問題について、遠回しなやりとりをすることが時々ある。 あえて「遠回しなやりとり」と言ったのは、はっきりと「ソフトウェアの設計なんて無意味だ」と言う人を見たことがないからだ。 そういう考えの人は、たいていこんな言い回しをする。 「立ち止まっている暇なんてない。とにかく前に進まないと来年の目標を達成できないんだ。 だから、≪設計に関する何かの作業≫は省略するよ」 そこにあるのは、設計と素早い開発の間には何らかのトレードオフがあるという思い込みだ。 実際、「設計に時間を掛けると開発の速度は落ちるけど、プログラマーはそれを補って余りあるだけのメ

ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。 あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。 クラフトがあると、変更するのに余分な労力がかかる。 技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。 私のコードのモジュール構造が複雑だったとしよう。こ

http://martinfowler.com/bliki/FeatureBranch.html gitやMercurialのような分散バージョン管理システム(DVCS)の台頭と共に、ブランチ戦略やマージ戦略をどうするか、そしてそれらをどのように継続的インテグレーション(CI)に適合させるかという話し合いを数多く見てきた。その中で、特にフィーチャーブランチのプラクティスと、それをCIにどのように適合させるかに関しては、少し議論の混乱があるようだ。 シンプルな(分離した)フィーチャーブランチ フィーチャーブランチの基本的な考え方は、フィーチャー(あなたがその言葉を好むのならばユーザーストーリーでも構わない)の作業を開始する際、そのためのブランチをリポジトリ内で分岐させるというものである。DVCSでは、あなた個人のリポジトリでこれを行うが、中央集中型バージョン管理システム(VCS)でも同様の作