Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)
Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日本語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ（日本語） クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート
技術的負債 - Martin Fowler's Bliki (ja)
ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。 あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。 クラフトがあると、変更するのに余分な労力がかかる。 技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。 私のコードのモジュール構造が複雑だったとしよう。こ
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)
以下の文章は、Jason YipによるIt’s Not Just Standing Up: Patterns of Daily Stand-up Meetingsの日本語訳である。Jasonの許可を得て、ここに掲載する。 立ってやるのはミーティングの時間を短くするためだ 朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル(訳注：ハドルとは群になって集まること)、朝のロールコール(訳注：ロールコールとはメンバが順番に答えていく方式)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、その
HarvestedFramework - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/HarvestedFramework.html 使えるフレームワークを作るには、フレームワークの構築から始めるのではなく、アプリケーションを作ることから始めよう。アプリケーションを作る時でも、汎用的なコードを開発しようとしないで、うまく分割され設計されたアプリケーションを作るのだ。 あるアプリケーションを作ったあとで、同じような要求をもつほかのアプリケーションを作ることがある。こんな時は、一番目と二番目のアプリケーションの間にある重複に気を配ってみる。重複を見つけたら共通領域に入れてやる。この共通領域がフレームワークの前段階（プロト・フレームワーク）になる。 さらにいくつかのアプリケーションの開発を続けていくと、そのフレームワークは徐々に洗練されていく。 最初の二つのアプリケーションのコードは、すべてを単一のコードベースに留めてお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting…
