0

UIコードが同じチームによって開発されるプロジェクトがありますが、サービスレイヤー（REST / Java）とは異なる言語（Python / Django）で開発されます。各レイヤーのコードは、さまざまなコードリポジトリに存在し、さまざまなリリースサイクルに従うことができます。UIレイヤーの観点から、サービスレイヤーの重大な変更を防止/削減するプロセスを考え出そうとしています。

UIまたはサービスレイヤーをビルドするたびに実行する統合テストをUIレイヤーレベルで作成することを考えました（2つのGitリポジトリにあるコードをビルドするためのCIツールとしてJenkinsを使用しています）。障害が発生した後、サービスレイヤーの何かが壊れ、コミットが受け入れられません。

また、サービスレイヤーの開発者に、UIレイヤーに存在するRESTサービスのクライアントライブラリを作成して維持させ、重大な変更があった場合に更新することもお勧めします（ベストプラクティスですか？）彼らのサービスAPI？おそらく、UIコードが構築される静的に型付けされたAPIの利点があります。クライアントライブラリのAPIが変更された場合、UIコードはコンパイルされません（したがって、重大な変更があったことがすぐにわかります）。また、UIまたはサービスレイヤーの構築時に統合テストを実行して、UIとサービス間の統合が引き続き機能することをさらに検証します。

4

1 に答える 1

1

クライアント層は、インターフェースを管理するだけでなく、クライアント層を正しく構築するスキルを持っていない可能性のあるクライアントの開発者にとって便利なものとして、非常に良いアイデアだと思います。クライアントレイヤーを構築する人が必ずしもRESTfulサーバーAPIの開発者であることに同意しません。適切なスキルを持つ開発者を見つけて、その開発者にタスクを割り当てる必要があります。

コミットの条件としてテストを成功させるという考えは優れていますが、Mavenを使用している場合は、プロセス全体の中でこれらのテストをいつ実行するかについてもう少し選択することができます。

あなたが提案したものに対する私の唯一の提案は、サーバー、クライアント、およびテスト層を構築するタスクのために、軽量のテンプレートベースのコードジェネレーターを検討することです。M2TEclipseプロジェクトのEMFTJETは、非常に優れたソリューションです。あなたは他のコード生成技術が好きかもしれません。

于 2012-08-06T01:45:51.590 に答える