物理エンジンの設計を視覚化する方法は？

私は物理エンジンを作成していますが、全体を把握するのが非常に難しくなっています。多くの場合、休憩後にコードに戻ると、なぜそれが機能しないのか覚えていません。ほとんどの問題は、単純なプログラミングの間違いではなく、物理エンジンの設計上の欠陥です。そのため、プログラミングする前に設計を終了する必要があります。

ただし、物理エンジンの設計全体を紙に書く方法が必要です。さもなければ、明日それを忘れて再び失われます。UMLクラス図は、物理エンジンの設計にはまったく適していません。私はクラスではなくプロセスについて本当に気にします。プロセスの単一ステップ（フレーム）をモデル化しても、多くのステップでのエンジンの最終的な動作を理解するのに役立たないため、ビジネスプロセス図は本当に便利だとは思いません。

したがって、プロセスを追跡するためにどのような図を使用する必要がありますか？物理エンジンを作成するためにどのようなダイアグラムの専門家が使用しますか？

TO DOリストは素晴らしいものです。

// #TODO：なんとかコメントについては言っていません。神に正直なノートブックを手に入れるということです。

重要なことをいつ思い出すかわかりません。ノートブックは静かにそこに座って、手書きがコンパイルされないことについて文句を言うことなく考えることができます。私の最高のアイデアのいくつかは、トイレで起こります（はい、防水ノートを持っていますが、そこまで行く必要はありません）。

縫い付けられた（糊付けされていない）ポケットサイズのものを手に入れることができるので、ポケットでバラバラになりません。ブックマークが組み込まれた豪華なものを手に入れることができませんでしたか？テープ、はさみ、リボン、誰も知らないでしょう。

アイデアが思いついたら、それを書き留めてください。各アイデアの横に小さなボックスを描画すると、簡単に完了マークを付けることができます。ページの上部にボックスを配置すると、ページがいつ完成するかがわかります。

どのシーケンシャルアクセスでは不十分ですか？うん、彼らはポケットバインダーも作っています。これは少し多く思えるかもしれませんが、ポストイットノートにdrれたり、Jiraですべてをキャプチャしようとするよりはましです。

物事を半分実装したままにしないでください

改善を小さく、達成可能なままにしてください。一度に終わらせることができないものを始めないでください。それが大きすぎる場合は、小さなステップに分割します。コンパイルしてテストに合格するコードを常に残します。ああ、あなたが失敗したのを見たことがないテストに合格したままにしないでください。テストを成功と失敗の両方にすることは、テストのテスト方法です。

紙にデザイン全体が必要だと考えるのをやめる

あなたがする必要があるのは、あなたの進化する計画を捉えることです。終わったら物事がどのように見えるかわからないので、ふりをするのはやめてください。できる限り把握したものをキャプチャします。必要に応じて、ナプキンとクレヨンを使用します。とにかくUMLの90％を理解している人はほとんどいません。できる限りの方法を使用して、表示する必要があるものを表示します。私は自分のインターフェースと何を知っているかを示すことに焦点を当てています。

コーディングを停止したらメモを書く

キーから指を離した瞬間は、あなたが今やったことだけでなく、あなたがしたこと（そしてあなたが計画したこと）を理解する最後の時です。いくつかのメモで、できる限りその理解を獲得してください。あなたが持っているすべてがコメントである場合、あなたはまだコンピュータに縛られており、椅子に水たまりを残す可能性があります。繰り返しますが、ノートブックを持つことは素晴らしいことです。

このようにして、カフェインや歯ぎしりに頼らずに、脳を優雅に着地させ、膀胱を保存し、後で再び離陸することができます。

「最初の場合を除き、すべてをトップダウンで構築する必要があります」と彼らは言います。

最低レベル（基本的なベクトル演算など）から始めて、それをよく理解し、テスト範囲が良好であることを確認しました。次に、その上にもう1つのレイヤーを構築し、より抽象的な操作（グループ/エンティティ、衝突検出、衝突メカニズムなど）を可能にします。繰り返しますが、テストでカバーします。エンジンでのこれらの抽象化の実際の使用例について考えるのに役立ちます。

エンジン全体を非常によく理解していない限り（たとえば、よく知られている既存のエンジンを再実装する場合）、これらのレイヤーを用意することは通常良いことです。これにより、特定のレイヤーを前のレイヤーの観点から考えることができ、通常はこれ以上深くなりません。新しい便利な抽象化を使用して、レイヤーを実験して構築できます。実際に実用的であることが判明したものは、多くの場合、最初のアイデアから逸脱しています。

各レイヤーが十分に小さく、複雑な図を必要としないか、便利な図を簡単に作成できることを願っています。

有用な複雑なコード図に出会ったことはありません。ただし、相互作用図とライフサイクル図は便利です。多くの場合、このような図は1〜2層に制限されているため、単純です。

私が最も重要だと思うのは、各レベルで提供されるインターフェイスの説明と保証です。例えば、ベクトル演算の形式、数値エラーで何が起こるか。より大きなオブジェクトの記述の形式（常に凸？常に時計回り？、交差方法など）、相互作用の機械的パラメーター（時間の進み方、質量の処理方法、運動量は常に保持されますか、力の計算方法）適切な相互作用（摩擦、変形、断片化の処理方法は、機械的エネルギーを熱損失に変えることですか？）

各レイヤーは、導入し、提供することを保証できるほどの量を確保できるほど小さくする必要があります。この記述は、実装コードを（まだ）書かなくても作成できます。これにより、3層の深さで何かひどい間違いを犯したと判断する可能性が低くなります。行った場合、すでに最大で2層の深さで表示されます。

アーキテクチャの図を作成してください！シーケンス図でOpenGLパイプライン FrustratedWithFormsDesignerはコメントで掲示さは、プログラムのための素晴らしい例です流れが、それは便利です図の一種類のみです。

図を設計するときは、コードを簡単かつ直感的に理解できるようにする必要があります。これには、高レベルの概念（そのOpenGLパイプラインダイアグラムのノードの一番上の行など）または非常に詳細な技術的詳細（関数呼び出しグラフなど）の両方が含まれます。

理想的には、ドキュメントは他の人がコードを理解しやすいものにするべきです。これにより、コードレビューやオープンソースのコラボレーションなどが簡単になります。大規模なプロジェクトを見て、これがどのように達成されているかを確認してください。数十万行または数百万行のコードを操作する場合、コードを読み取らずにプログラムがどのように機能するかを理解することは、コードベースを追跡したり他の人に紹介するために非常に重要です。130万LOCのVimリポジトリには、これに関する非常に優れた高レベルのドキュメント（IMO）が/src/README.txtにあります。紹介します：

• 各ファイルのコードが行うこと
• 重要なグローバル変数とその値
• メインループで何が起こり、それが呼び出す関数
• 各モードで起こること、およびそれらを処理する主な機能
• ネイティブデバッグ機能とは

パッチを提供したい場合、私は一般的にどのファイルを修正する必要があるかを知っています。

Vimの最も優れた機能の1つは、/src/README.txt見つけやすさと包括性です。どんな意味でもきめ細かくはありませんが、srcGithub のフォルダーをクリックすると自動的に読み込まれ、他のコードやドキュメントを見つけるための指示が与えられます。これとは対照的に、Powershellリポジトリを例に挙げましたが、これはVimに相当するファイルを見つけることができませんでした/src/README.txt。（988千LOCのプロジェクトの悪い兆候！）

図やドキュメントを作成する必要がある場合があります。

• 概念的なプログラムの流れ（プログラムは何を達成し、どのような順序で？）
• 実装されたプログラムフロー/関数呼び出しグラフ（プログラムはどのように目標を達成しますか？どの関数が呼び出されるか、クラスが作成されますか？）
• どのファイルにどのコードが含まれていますか？組織体系とは何ですか？また、新しい機能がどこに行くかを決定するためにどのようなルールがありますか？強力な組織スキームがある場合、IDEまたはIDEのような「プロジェクト全体を検索」機能がなくても、特定の関数またはクラスを探すファイルを簡単に知ることができます。
• 関連して、どのファイルに他のファイルが含まれていますか（関数呼び出しグラフに関連する）？
• どのクラスが他のどのクラスから継承しますか？各クラスの目的は何ですか？

これらの図をどのように作成できますか？あなたのレベルで、そして最初のドラフトでは、鉛筆と紙がおそらく最良/最速の方法です。図とドキュメントがさらに洗練されたら、次のことを検討できます。

• Dot / Graphviz、.dotファイルからグラフを生成するためのプログラムのセット。
• LaTeX / TikZ、あらゆる種類のグラフや画像を生成するための非常に複雑で冗長なツール-特にすべてのノードの配置が手動であるため、ニーズには多すぎるかもしれませんが、特に紙またはそのようなものは後で。
• Cの場合、gson は呼び出しグラフにegyptフックしgccて出力し.dotます。自動化することも、makeコマンドに埋め込むこともできます。
• 関連して、GNU cflowはCのテキストのみのコールグラフを生成できます。他の言語の同等のツールが存在する場合がありますが、一般的に自動化ツールから離れる場合があります。複雑な詳細レベル（どの関数呼び出しprintf()が行われているのかを知ることは、通常非常に役に立ちません）。

ペトリネットに基づく図を使用してみてください。体系的な方法でダイアグラムをコンピュータープログラムに変換することができ、高レベルのダイアグラムを低レベルのダイアグラムに統合することができます。

参照資料

ネット要素と注釈：汎用視覚プログラミング言語（2016）。https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Languageで入手できます。

コンピュータープログラミングのネット要素と注釈：PDFでの計算と相互作用（2014）。https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDFで入手できます。