キーストーンインターフェース

2020年4月29日

ソフトウェア開発チームは、できるだけ頻繁に作業を統合すれば、より簡単に作業を進められることに気づきます。また、頻繁に本番環境にリリースすることも価値があると気づきます。しかし、チームは開発途中の機能をユーザーに公開したくありません。この緊張に対処するための便利なテクニックは、バックエンドのコードをすべて構築し、統合するが、ユーザーインターフェイスは構築しないことです。機能は統合してテストできますが、UI は最後に、キーストーンのように、機能が完成してユーザーに公開されるまで保持されます。

この手法の簡単な例としては、顧客に特急注文のオプションを与えることが挙げられます。そのような注文には、顧客の居住地や、そこで営業している配送会社に応じて価格を設定する必要があります。商品の性質は、倉庫で使用されるピッキングアプローチに影響します。特定の顧客は、配送場所、季節、注文された商品の種類によっても、特急注文を利用できる資格がある場合があります。

全体として、特にさまざまな倉庫、カタログ、およびカスタマーサービスシステムとの複雑な統合が伴うため、かなりの量のビジネスロジックとなります。これには数週間かかる可能性があり、他の機能は数日ごとにリリースする必要があります。しかし、ユーザーに関する限り、特急注文は注文フォームのチェックボックスにすぎません。

このチェックボックスをキーストーンとして使用して構築するために、チームは数回の本番リリースにわたって、基盤となるビジネスロジックと内部システムへのインターフェースの開発作業を行います。ユーザーは、この潜在的なコードをすべて認識していません。最後のステップでのみ、キーストーンのチェックボックスを表示する必要があり、これは比較的短時間で行うことができます。このようにして、すべての潜在的なコードを統合して本番環境に移行するシステムの一部にすることができ、長期にわたる機能ブランチに伴う問題を軽減できます。

潜在的なコードは、アクティブな場合と同程度の信頼性でテストする必要があります。これは、システムのアーキテクチャが、ほとんどのテストがユーザーインターフェイスを通じて行われないように設定されている場合に実行できます。単体テストおよびテストピラミッドの他の下位レイヤーは、この方法で簡単に実行できる必要があります。ブロードスタックテストでさえ、それらを皮下テストにするメカニズムがあれば実行できます。場合によっては、UI自体にかなりの量の動作が含まれますが、設計によって可視UIをハンブルオブジェクトにできるようにすれば、これもテストできます。

すべてのアプリケーションが、皮下で広範囲にテストできるように構築されているわけではありません。ただし、これを行うために必要な労力は、キーストーンを使用する機能がなくても価値があります。UIを介して実行されるテストは、プロセスを自動化するための最良のツールを使用しても、セットアップが常に面倒です。特に単体テストを、より多くのテストを皮下およびより低いレベルのテストに移行すると、デプロイメントパイプラインを劇的に高速化し、継続的デリバリーを有効にすることができます。

もちろん、ほとんどのUIはチェックボックス以上のものでしょう。ただし、多くの場合、キーストーンにするための作業はそれほど多くありません。Webアプリでは、複雑な機能は多くの場合、独立したWebページになり、完全に構築およびテストできます。キーストーンは単なるリンクです。デスクトップには、キーストーンがそれらを表示するためのメニュー項目である複数の画面がある場合があります。

とは言え、UIを単純なキーストーンにパッケージ化できない場合もあります。そのような場合は、フィーチャーフラグを使用する時です。ただし、この場合でも、キーストーンを考慮することは、フィーチャートグルがUIにのみ適用されるようにする上で役立ちます。これにより、バックエンドコード全体に多数のトグルポイントが散在することがなくなり、トグルを適用する複雑さが軽減され、単純なトグルメカニズムを使用できるようになり、時が来れば削除しやすくなります。

UIを最後に開発することには一般的な危険性があります。つまり、バックエンドコードが、一度構築されるとUIで機能しないように設計されている場合や、UIが遅くまで注意を払われていない場合があり、反復が不足し、ユーザーエクスペリエンスが低下する可能性があります。これらの理由から、キーストーンアプローチは、小さくても完全に機能する機能を迅速にリリースする、薄い垂直スライスを通じて製品を構築することを推奨する全体的なアプローチの中で最も効果的です。

ここではユーザーインターフェイスの例を使用しましたが、もちろん同じアプローチを、APIなどの他のインターフェイスでも使用できます。コンシューマーのインターフェースを最後に構築し、それをシンプルに保つことで、大規模な機能でさえ、小さなチャンクで構築および統合できます。

ダークローンチは、新しい機能が構築されると呼び出されるが、結果はユーザーに表示されないバリエーションです。これは、バックエンドシステムへの影響を測定するために行われ、一部の変更に役立ちます。すべてがうまくいったら、キーストーンを追加できます。

謝辞

この手法のキーストーンという比喩を最初に知ったのは、ケント・ベックのExtreme Programming Explainedの第2版でした。ピート・ホジソン、ブランドン・ダフ、ステファン・スミスは、私がこれを忘れていたことを思い出させてくれました。

デイブ・ファーリー、ポール・ハマン、ピート・ホジソンがこの投稿の草稿にコメントしました。