Pipeline Authoring フロントエンドアーキテクチャプロセス
概要
このページでは、Verify:Pipeline Authoring グループで使用するフロントエンドアーキテクチャプロセスをドキュメント化します。
なぜこれをやるのか？
他のチームはこのようなアーキテクチャプロセスを持っていない、と思われるかもしれません。なぜ私たちは必要なのでしょうか？
このプロセスは、Pipeline Authoring グループが業務の過程で遭遇した障害 - 土壇場での予期しない問題、コンテキストの欠如など - を回避するためのアプローチです。これはアーキテクチャエボリューションワークフローよりも軽量で、フロントエンドプロセスよりも Pipeline Authoring チームのニーズと知識に特化している必要があります。
計画を書き留めることで、以下が実現できる空間を作ることを期待しています:
- ドメインエキスパートが予期しない落とし穴を早期に指摘し、知識を共有できる。
- 目標と決定に関するコンテキストが記録され、休暇に行ったり / クジラに食べられたりしても、すべての知識が消えないようにする。
- エンジニアが実装準備ができたときに、グローバルな思考と詳細な思考を切り替える回数を減らすことができる。
いつこのプロセスを使用する必要がありますか？
このプロセスは、新しいセクションを作成する場合、大幅なリファクタリングを行う場合、または既存のパターンの拡張ではない大きめの機能を追加する場合に使用すべきです。
必要かどうか確信が持てない場合は、とにかくやってみてください！最悪の場合、計画について考える時間を費やしただけで、追加のドキュメントは誰も傷つけません。
納得できました！これはどのような形であるべきですか？
機能 Issue に ~"Needs Architecture" ラベルを追加し、以下を含む説明の新しい Issue にリンクします:
- この作業が解決しようとしている問題の説明
- この作業の目標
- 一つまたは複数のオプションを含む可能性のあるアーキテクチャの提案
スケジュールに対処する必要はありません。それは従来の本番 Issue で処理できます。
提案には以下を含める必要があります:
- コンポーネントの分解。完璧である必要はありませんが、例えばやっていることをセクションに分解する方法をリストアップするのは良いことです。これは…のインプットになります。
- データストーリー！表示するデータはどこから来ますか？どこに行きますか？サブコンポーネントはどのようにアクセスしますか？バックエンドは何をし、フロントエンドは何をカバーしますか？
app/assets/javascripts/pipelines/とapp/assets/javascripts/pipeline_editor/のユーティリティ関数を見ると、既にやっていることのヒントが得られます。 - これらの変更が既存のコードとどのように適合するか。パターンに従っていますか？逸脱していますか？共有コンポーネントを使用しますか？
- 未知のリストです。何を知らないのですか？何が不確かですか？地図であれば、どこに ここには竜がいる と書くでしょうか？
- 最後に、以下の基本的な仮定のいずれかを覆す場合は、明確に示し、理由を説明してください。
このリストは長く見えるかもしれませんが、小さな変更の場合は、1〜2 文で対処できます。
すべてのアーキテクチャの基本的な仮定
- 部門レベルのガイドラインとチームリソースページで概説されている両方のガイドラインに従います。
- データフェッチとステート管理のニーズには Apollo と GraphQL を使用します。
- 現在のデータ構造と同一のデータ構造を使用することが、可能な限り良い計画です。フロントエンドではかなりの量のデータを処理しますが、そのデータのわずかな変化に対処するためにその処理に例外を追加することは最善に避けられます。
- 例えば
app/assets/javascripts/pipelines/components/graph/graph_component_wrapper.vueやapp/assets/javascripts/pipelines/components/dag/dag.vueで使用されているようなreportFailureエラーパターンをエラー処理に使用します。 - 最初のデータコールとエラーを処理するために
app/assets/javascripts/pipelines/components/graph/graph_component_wrapper.vueのようなラッパーコンポーネントをトップレベルで使用し、他の機能はサブコンポーネントでインスタンス化します。このパターンはテストでのモックを制限し、あまりにも多くをマウントせずにテストパターンをサポートするのに役立ちます。
誰がレビューすべきですか？
計画ができたら、残りのフロントエンドチーム、バックエンド、ドメインエキスパート、プロダクト、UX と共有します。
このリストの誰もが計画のブロッカーになるべきではありませんが、彼らの意見は求められるべきです。
どのくらいの時間がかかりますか？
プロセスは 1 週間から 1 マイルストーンの間に終わるべきです。プロジェクトが 1 マイルストーン以上かかる場合は、スパイクが必要かもしれません。
