これは、小規模なプロジェクトに取り組んでいたときにこれを行った方法です。次に、それをどのようにスケーリングできるかについての考えを書きます。
これらは、GUI の開発プロセスで実行された手順です。
一般的なコンセプトを持っています (プログラマーは関与しません。デザイナーは UI/UX または顧客とこれを決定します)。
デザイナーとプログラマーは、前のステップで作成された一般的なスキームを確認し、プログラマーは、デザイナーが作業の結果として生成する SWC に存在する必要があるシンボルやその他のアセットに必要な定義を作成します。
設計者は「ダミー」定義を受け取り、それらをプロジェクトに接続します。新しいシンボルを作成したり、アセットをインポートしたりするたびに、そのアセットを既存の定義にリンクします。
ステージの後、いくつかのシンボルがすでに SWC にある場合、デザイナーは SWC をプログラマーに渡します。プログラマーは独自の定義を使用します (そこからデザイナーが導き出したものです)。プログラマーはこれらの定義を使用して、インターフェイスの機能部分を記述し、それらをプログラムの他の部分に接続しました。
これらのステップを繰り返すことで、プロジェクトにコンポーネントを徐々に追加し、それぞれの部分を独立して開発することができました。(デザイナー間でワークロードを分割して、それぞれが以前に作業することを選択した一連の定義を使用して独自の SWC を作成することができます)。
落とし穴:
設計者は forklfow を使用するためのトレーニングを受ける必要があります (シンボルを既存の定義に接続する方法、SWC をコンパイルする方法を知っている人はほとんどいません)。しかし、その機能は Flash CS にあります。
人的エラー (デザイナーがリンク時にタイプミスをした場合、ライブラリーがプログラマーに渡されるまで、デザイナーはそれに気づきません)。
ヒューマンエラーの回避
私の小規模なプロジェクトでは、swfdumpユーティリティを介して SWC から抽出した SWF を実行し、それを grep にパイプして、シンボル定義が存在するかどうかを確認していました。数が少ないので、手作業で行うことができました。
ただし、ご指摘のプロジェクトは規模が大きいため、作成したアウトライン (ActionScript ソース ファイル) と SWC ライブラリを入力として受け取るスクリプトを作成します。SWC を解凍し、そこから SWF を抽出して実行しswfdump、ソース ファイルのすべての定義が SWF に存在することを確認します。デザイナーは、SWC を送信する前にこのスクリプトを実行し、少なくとも最後の更新時に追加したシンボル/アセットが実際にライブラリに作成されていることを確認する必要があります。
分析にはまだいくつかの技術的な問題があります: 重複した名前、高レベルの「ノイズ」の可能性、たとえばフックをコミットするのと同じようにする代わりに、このチェックを実行するのに人間に依存することになります。しかし、これらのどれもが解決できないようには見えません。十分な努力と創意工夫があれば、完全性を保証するアプリケーションを思いつくことができるはずです。