そして今日、私はあなたのために以下の考えを持っています：
変数の文書化
本当に大規模で複雑なアプリケーションを開発する場合、おそらく変数を使用する必要があります。 たとえば、ユーザーのタイプを判別するために、インターフェースがユーザーごとに異なる場合、対応する変数を作成し、表示された機能をその値にバインドできます。
多くの変数があり、しばらくしてプロジェクトを開いた後、それらが何を意味するのかをもう一度覚えておく必要があります。
これらの苦しい思い出を避けるために、私は簡単なトリックを使用します。 変数を開始するたびに（もちろん、大部分はグローバル変数「グローバル変数」に関するものです）、その名前と可能な値を別のマスターに書き込みます。これは、原則として「変数」と呼びます。 次に、自分自身の説明、変数が正確に何をするのか、どこで使用したのか、その値の説明を書きます。 これは、どの変数が既に関係していて、どのように機能するかをすぐに覚える必要がある場合に大いに役立ちます。 はい、はい、実際には、一般的なコードのコメント。
機能的構造化
複雑なアプリケーションの開発について話している場合、原則として膨大な量の機能について話します。 この機能は、さまざまな画面に複製して、わずかな変更を加えて表示することができます。 しかし、いずれにせよ、デザイナーの欲求に関係なく、ほとんどの場合、修正する必要があります。 そしてもちろん、できるだけ迅速かつ簡単に編集したいと思うでしょう。 この作業を容易にするために、マスターページを使用することは非常に便利ですが、マスターページとしてだけでなく、ウィジェットを構造化されたフォームに保持し、結果としてすばやくアクセスできるコンテナとしても考えています。 私は次のように進みます-最初に最大量の機能マスタを作成し、明確な階層を持つマスタツリーに個別のカテゴリを編成します。
このアプローチは、いくつかの理由で非常に便利です。
ボタンの碑文を変更するために、プロトタイプ/動的パネルとその状態を深く掘り下げる必要はありません。 必要なマスターを見つけるだけです。 （例：クライアントカードはMain \ Clients \ Toolsフォルダにあります）。
マスターはマスターです。異なる画面で同じことを何度も行う必要はありません。
ウィザードの構造により、プロジェクトをより適切に制御できます。 何が行われたのか、何が足りなかったのかをすぐに確認でき、画面間でウィジェットをすばやく表示して、意思決定の均一性をよりよく制御できます。
一般に、このアプローチではプロトタイプの開発段階でもう少し時間がかかりますが、6か月でプロトタイプを開くと感謝します。
やること
私の仕事でよく使うもう1つの動きは、この仕事が行われる画面上で、今後の仕事を文書化することです。 この画面で行う予定をテキストで書き、進行に応じて削除します。 すべてを一度に実行できない場合は、すべてを1つのグループにまとめて非表示にします（たとえば、プロトタイプを誰かに見せたい場合）。この画面に戻っても、まだ行っていないことを確認するための要件に進む必要はありません。 これにより多くの時間を節約できます。 時々、十分なテキストがない場合、グループ（たとえば、自分に合ったソリューションをどこかで見た場合）やリンクなどに画像が表示されることがあります。 とてもシンプルで論理的に聞こえますが、何らかの理由で、同じことをしているデザイナーにはまだ会っていません。 なんて残念。
外的要因のシミュレーション
インターフェースは、ユーザーのアクションに依存しない、または間接的に依存するが、それでも試してみてプロトタイプで表示する必要がある外部要因の影響を受けることがよくあります。 例を挙げましょう。 物理コンポーネントの温度が変化したときのシステムの動作を設計する必要があります。 個別の画面で大きなガイドを作成して各加熱しきい値を達成したり、プロトタイプの本体に直接説明を書いたり、同じ場所にすべてのアイコンと警告を含むポップアップウィンドウを作成したり、もう少し論理的な方法で行ったりすることができます。 インターフェイスを変更するトリガーを含むウィジェットを取得してプロトタイプを作成できます。 つまり、プロトタイプに直接、「温度変動のシミュレーション」ボタンを配置します。このボタンは、「最初の限界に到達」、「2番目の限界に到達」などのトリガーで構成されます。 テストに感謝します。 一箇所ですべて、すべてが変化し、システムの動作を視覚的に確認できます。
ユーザーに依存しないシナリオフォークでも同じことができます。 たとえば、サーバーへのフォームの送信をシミュレートしたいのですが、ある場合にはユーザーに依存せずにフォームが送信され、別の場合には送信されません。 そのような場合、できるだけデザインが異なるウィジェットを表示します（システムウィンドウではなく、万が一に備えてシステムの動作をシミュレートするためだけに必要なテキストを使用）。パスを選択する機会を与えます。 このようにして、プロトタイプの整合性が維持され、画面間の接続が直接かつ理解可能なままになります。
simパイロットリリースについては、完了することが可能であると考えています。 記事があなたにとって有用であることが判明した場合、私はうれしく思います。また、コメントでネイティブアメリカンのトリックを共有していただければさらに嬉しく思います。 そしてそれが今日のすべてです。 また会うまで。