リファクタリングの第1版と第2版の違いを簡潔にまとめたものです。

モノリスをより小さなサービスに分割する際に最も難しい部分は、モノリスのデータベースに存在するデータを実際に分割することです。データリッチなサービスを抽出するには、常にデータの単一書き込みコピーを保持する一連の手順に従うことが役立ちます。手順は、既存のモノリスで論理的な分離を行うことから始まります。サービスの動作を個別のモジュールに分割し、次にデータを個別のテーブルに分割します。これらの要素は、新しい自律型サービスに個別に移動できます。

表面上、アジャイルソフトウェア開発の世界は明るいものです。なぜなら、今では主流になっているからです。しかし、実際は問題が多く、行われていることの多くは偽のアジャイルであり、アジャイルの価値と原則を無視しています。私たちが重点を置くべき3つの主な課題は、アジャイル産業複合体とそのチームへのプロセスの押し付けの習慣との闘い、技術的卓越性の重要性の向上、そして（プロジェクトではなく）製品を中心としたチームの編成です。問題点にもかかわらず、このコミュニティの大きな強みは、学習と適応能力であり、元マニフェストの著者が想像もしなかった問題に取り組んでいます。

AppleScriptとRubyを使用してエクスポートスクリプトを作成した方法について簡単に説明します。

リファクタリングの新しい版を仕上げています。作業に関する詳細と定期的なメモをここに掲載します。

サーバーレスアーキテクチャは、サードパーティの「Backend as a Service（BaaS）」サービスを組み込んだアプリケーション設計、または「Functions as a Service（FaaS）」プラットフォームで管理された一時的なコンテナで実行されるカスタムコードを含むアプリケーション設計です。これらのアイデアや、シングルページアプリケーションなどの関連するアイデアを使用することで、このようなアーキテクチャは、従来の常時稼働サーバーコンポーネントの必要性を大幅に削減します。サーバーレスアーキテクチャは、運用コスト、複雑さ、エンジニアリングリードタイムの大きな削減というメリットが得られる可能性がありますが、ベンダーへの依存性の増加と比較的未成熟なサポートサービスというコストもかかります。

モノリシックシステムが大きくなりすぎて対処できなくなると、多くの企業はそれをマイクロサービスアーキテクチャスタイルに分割することに惹かれます。それは価値のある取り組みですが、容易ではありません。私たちは、これをうまく行うには、単純なサービスから始める必要がありますが、ビジネスにとって重要であり、頻繁に変更される垂直方向の機能に基づいたサービスを展開する必要があることを学びました。これらのサービスは最初は大きく、残りのモノリスに依存しないことが望ましいです。移行の各ステップが、全体的なアーキテクチャに対する原子的な改善を表していることを確認する必要があります。

アジャイル手法は確実に主流になっていますが、その人気は問題がないわけではありません。組織のリーダーは、期待した効果が得られないと不満を述べています。この記事では、アジャイルのアイデアを最大限に活用するのに役立つ熟達モデルを紹介します。熟達度合いは、それぞれ独自のメリット、必要な能力、主要な指標を持つ4つの異なるゾーンを経て進化します。

最近では、誰もがデジタル製品のデリバリーを大規模に高速化するために「プラットフォーム」を構築しています。しかし、効果的なデジタルプラットフォームを構成するものは何でしょうか？組織構造と運用モデルを最初に解決せずに、既存の共有サービスの上に構築しようとすると、組織はつまずくことがあります。

「テストピラミッド」は、ソフトウェアテストを異なる粒度のバケットにグループ化することを教えてくれる比喩です。また、これらのグループごとにどのくらいのテストを行うべきかというアイデアも与えます。テストピラミッドの概念はすでに存在していますが、チームはまだそれを適切に実践することに苦労しています。この記事では、テストピラミッドの元の概念を再訪し、それを実践する方法を示します。ピラミッドのさまざまなレベルでどのような種類のテストを探す必要があるかを示し、それらをどのように実装できるかの実践的な例を示します。

ソフトウェアプロジェクトは、ソフトウェア開発の資金調達と組織化の人気のある方法です。それらは作業を一時的なビルド専用チームに編成し、ビジネスケースで予測された特定の利益で資金提供されます。一方、製品モードでは、永続的なビジネス課題に取り組む、アイデア出し・構築・実行を行う持続的なチームを使用します。製品モードにより、チームは迅速に方向転換し、エンドツーエンドのサイクルタイムを短縮し、短サイクルの反復を使用して実際の利益を確認しながら、ソフトウェアのアーキテクチャの整合性を維持して長期的な有効性を維持することができます。

統合テストは、独立して開発されたソフトウェアのユニットが互いに接続されたときに正しく機能するかどうかを判断します。この用語は、ソフトウェア業界のあいまいな基準によってもあいまいになってきたため、私は自分の著作で使用することに慎重でした。特に、多くの人が統合テストは必ずしも範囲が広いと想定していますが、より狭い範囲でより効果的に行うことができます。