タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
http://www.martinfowler.com/bliki/CodeAsDocumentation.html アジャイル手法はプログラミングをソフトウェア開発の中心的役割に押し上げた、とよく言われる——ソフトウェア エンジニアリング コミュニティがやってるようなことよりもずっと優秀だよなあ。 プログラミングが中心的役割となったのは、コードをソフトウェア システムにおける「（最）重要なドキュメント」と位置付けたことが理由なんだと思う。 おっと、よく誤解されるので先に反論しておこう。 先ほどの「コードは重要なドキュメントだ」という原則だけど、 「コードが”唯一の”ドキュメントだ」とは言ってない。 「XPではコードがドキュメントだ」とよく耳にするけど、 XPのリーダー達がそんなことを言ってるのは聞いたことがないなあ。 コードを補完するには、他にもドキュメントが必要なんだ。 なぜコードが重
https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 私が気に入っている引用の一つに「もしそれが痛みを伴うのであれば、さらに頻繁にそれを行え」という引用がある。 この言葉は、表面的には馬鹿げたことに見えるという幸せな性質も持っているが、深く探れば価値のあることがわかる。 このことを説明するための例示できる文脈は、統合だ。 ほとんどのプログラマーは、自分の仕事を他の人と統合することは苛立たしくてつらい経験であることを早い段階で学ぶ。 そのため、自然な人間の反応として、できるだけ統合を先延ばしにしようとする。 上記グラフのように、その行動を起こすまでにかかる時間と、その行動に伴う痛みに指数関数的な関係がある場合、その行動をより頻繁に行うと、痛みを大幅に軽減できる。 そして、これが継続的インテグレーションで起こることだ。毎日
https://martinfowler.com/articles/202107-what-doing-now.html 数か月前、私は講演活動から退くことを記事にしました。執筆活動は続けているのかと疑問に思った方もいるでしょう。その記事の中では執筆中であると書きましたが、最近取り組んでいることについて、もう少しお話したほうがいいのではないかと考えました。 これまでの執筆活動と違うのは、本になるような大きなテーマには取り組んでいないことです。『リファクタリング』の第2版を完成させてからは、ほとんどの期間をこのウェブサイトに費やしてきました。数年間ずっと悩んでいたソースコードブランチ管理のパターンの記事にも数か月かかりました。それが終わってからは、放置したままだった2つの大きなテーマであるフロントエンドアーキテクチャとイベントに改めて取り組んでみようと考えました。しばらくの間、フロントエンド
私が敬愛するソフトウェアアーキテクチャの専門家たちは、この分野のあらゆる一般法則に対して懐疑的です。 優れたソフトウェアアーキテクチャはコンテキストに固有であり、さまざまな環境下で異なる解決をしなければならないトレードオフを分析するものだからです。 とはいえ、彼ら全員が同意するものがひとつだけあります。 それは、コンウェイの法則の重要性とパワーです。 私がこれまでに経験したすべてのシステムに影響を与えるほど重要であり、抗えないほどのパワーがあります。 この法則を説明するには、作者の言葉がいちばんでしょう1。 システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。 ―メルヴィン・コンウェイ コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。 元々は、1つのチームでコンパイラーを作
ソフトウェア開発で目撃したものを説明するために、私は造語を作る習慣があります。 便利な用語が少ないので、ソフトウェア開発の分野の書き手はこのようなことをよくやります。 造語を作るときの問題は、意味の希薄化により本来の意味が失われ、別の意味が追加されてしまうことです。 意味の希薄化が発生するのは、個人やグループが作った用語があり、適切に定義されていたにもかかわらず、歪められた定義がコミュニティに広まったときです。 これにより、用語の定義が完全に失われる危険性があります。 また、それに伴い、用語の利便性も失われてしまうでしょう。 私が本記事を書こうと思ったのは、「アジャイル」と「Web 2.0」に意味の希薄化が発生しているからです。 いずれも数年前に作られた用語であり、しっかりとした定義があります（アジャイルにはアジャイルマニフェストがあり、署名者たちが執筆した書籍や記事も多数あります。Web
ソフトウェアの世界では、ソフトウェアプロセスの方式を説明するときに「ウォーターフォール」という言葉がよく使われる。これは、反復型あるいはアジャイル方式の考えとは対照的なものだ。ソフトウェアの世界でよく知られている用語の多くがそうであるように、この「ウォーターフォール」も意味が明確に定義されておらず、起源もあいまいである。だが、その本質的なテーマは「大きな労力を活動をベースにしたフェーズに分割する」ことだと私は考えている。 「ウォーターフォール」という言葉がどのように広まったかは定かではない。だが、その起源はWinston Royceの論文とされており、以下の図を参照することが多い。 この論文は（滝のようにタスクが流れ落ちていく形状から）ウォーターフォールの考えの起源であると広く認知されている。だが、「ウォーターフォール」という言葉は、この論文には登場しない。この名前が後にどのように登場した
大規模なソフトウェア開発、たとえば大企業向けのソフトウェア開発では、多くの人を必要とします。 多くの人が関与するときには、うまくチームに分ける方法を考える必要があります。 ビジネス機能中心のチームを作れば、顧客のニーズに対応したソフトウェア開発ができるでしょう。 しかし、求められるスキルの範囲が膨大になります。 チームトポロジーとは、ソフトウェア開発チームの組織化を記述するモデルです。 Matthew SkeltonとManuel Paisによって開発されました。 チームトポロジーでは、4つの形態のチームと3つのインタラクションモードが定義されています。 ビジネス機能中心のチームが価値あるソフトウェアの流れを提供できるように、 健全なインタラクションを促すモデルです。 このフレームワークにおける主要なチーム形態は、ストリームアラインドチームです。 ストリームアラインドチームとは、ひとつのビ
https://martinfowler.com/bliki/DDD_Aggregate.html 集約(アグリゲート)はドメイン駆動設計のパターンです。 DDDにおける集約はひとまとまりとして扱えるようなドメインオブジェクトの小集合です。 例えば、「注文」と「品目」は別々のオブジェクトになりますが、注文を(品目と一緒に)集約として扱うと便利になります。 集約はひとつのコンポーネントであるオブジェクトを集約ルートとして持ちます。 集約の外部からの参照は集約ルートにのみ行くべきです。 このようにして、集約ルートは集約全体としての整合性を保証します。 集約はデータストレージ転送の基本要素となります - 集約の単位でロードや、保存を要求します。 トランザクションは集約の境界は超えてはいけません。 DDDにおける集約はたまにコレクションクラス(リスト、マップなど)と混同されてしまいます。 DDDに
Cindyとオーストラリアに行ったとき、クイーンズランド州の沿岸にある熱帯雨林でしばらく時間を過ごした。 この辺りの自然の素晴らしさのひとつに、巨大なストラングラーフィグがある。 ストラングラーフィグは、他の木の上の枝に種を蒔き、その木をつたわりながら下りていき、最後には土に根を張るのである。 宿主である木を絞め殺しながら、長い年月をかけて幻想的で美しい姿に成長するのだ。 このメタファーは、重要なシステムの書き換えの方法を表すのに使えるんじゃないかと私は思った。 私のキャリアの大半は、クリティカルなシステムの書き換えであった。 書き換えなんて、新しいシステムに古いシステムと同じ動作をさせればいいだけの簡単なものだと思うかもしれない。 だが、書き換えは思ってるよりもずっと難しいし、リスクがいっぱいある。 移行日が不気味に迫る。お尻に火がつく。 新しい機能が求められているのに（新しい機能は常に
Kent Beckが1990年代にエクストリームプログラミング（XP）を開発したときに、シンプルな設計の4つのルールを考案した。私なりに表現したものが以下になる[1]。 テストをパスさせる 意図を明らかにする 重複を排除する 要素を最小限にする ルールには優先順位がある。たとえば「テストをパスさせる」は「意図を明らかにする」よりも優先される。 このルールで最も重要なのは「テストをパスさせる」だ。XPが革新的だったのは、テストをソフトウェア開発におけるファーストクラスの活動に持ち上げたことである。このルールのなかでテストが最も重要な役割を担うのは当然だろう。ソフトウェアで何をするにしても、第一の目的は意図どおりにソフトウェアが動作することであり、テストはそれを確実にするためのものである。 「意図を明らかにする」は、Kentの言葉を借りれば、コードは理解しやすくなければならないというものだ。コ
Eradicating Non-Determinism in Tests 自動化されたリグレッションスイートは、ソフトウェアプロジェクトにおいて本番環境の欠陥を減らし、進化的設計を実現するうえで重要な役割を果たします。開発チームと話をする中で、私は非決定的なテストの問題についてよく耳にします。非決定的なテストとは成功したり失敗したりするようなテストのことです。制御されていないまま放置された非決定的テストは、自動化されたリグレッションスイートの価値を完全に破壊してしまう可能性があります。この記事では、非決定的テストに対処する方法の概要を説明します。手始めにはそういったテストを隔離することで他のテストへのダメージを減らすことができますが、それでもすぐに修正しなければなりません。そのため、非決定的テストのよくある原因である、分離の欠如、非同期的な挙動、リモートサービス、時間、リソースリークなどへ
情報がリッチなプログラムをモジュール化する一般的な方法は、大きく3つのレイヤーに分割することです。 その3つとは、プレゼンテーション（UI）、ドメインロジック（ビジネスロジック）、データアクセスです。 ウェブアプリケーションであれば、HTTPリクエストをハンドリングしてHTMLをレンダリングするウェブレイヤー、バリデーションや計算が含まれるビジネスロジックレイヤー、データをデータベースやリモートサービスに永続化する方法を管理するデータアクセスレイヤーに分けられます。 これは多くのアプリケーションに使えるモジュール化の形式です。 また、私が定期的に使用したり推奨したりするものです。 （私にとっての）最大の利点は、意識のスコープを狭められるところです。3つのトピックを比較的独立して考えることができるからです。 ドメインロジックのコードに取り組んでいるときは、UIをほぼ無視したり、データソースを
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
コードがドキュメントだ - Martin Fowler's Bliki (ja)
高頻度は問題を容易にする - Martin Fowler's Bliki (ja)
最近何をやっているのか - Martin Fowler's Bliki (ja)
コンウェイの法則 - Martin Fowler's Bliki (ja)
意味の希薄化 - Martin Fowler's Bliki (ja)
ウォーターフォールプロセス - Martin Fowler's Bliki (ja)
Amazon.co.jp: リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES): Martin Fowler 著 (著), 児玉公信 (翻訳), 友野晶夫 (翻訳), 平澤章 (翻訳), 梅澤真史 (翻訳): 本
チームトポロジー - Martin Fowler's Bliki (ja)
DDDにおける集約 - Martin Fowler's Bliki (ja)
ストラングラーフィグアプリケーション - Martin Fowler's Bliki (ja)
ケント・ベックの設計のルール - Martin Fowler's Bliki (ja)
テストにおける非決定性の排除 - Martin Fowler's Bliki (ja)
プレゼンテーションドメインデータレイヤリング - Martin Fowler's Bliki (ja)
技術的負債の四象限 - Martin Fowler's Bliki (ja)
pascle.net
b.hatena.ne.jp
note.com/canafr
pakapaka.jp
pakapaka.jp
news.yahoo.co.jp