物理エンジンの設計を視覚化する方法は？
私は物理エンジンを作成していて、その全体を追跡するのが非常に難しくなっています。休憩後にコードに戻ると、なぜそれが機能しないのか覚えていないことがよくあります。ほとんどの問題は単純なプログラミングの誤りではなく、物理エンジンの設計上の欠陥です。それが私がそれをプログラミングする前にそれを設計し終えるべきである理由です。
ただし、物理エンジンのデザイン全体を紙に書く方法が必要です。そうでなければ、私はそれを明日忘れてしまい、また迷子になるでしょう。 UMLクラス図は、物理エンジンの設計にはまったく適していません。私はクラスについてはあまり気にしませんが、プロセスについては気にしません。プロセスの単一のステップ（フレーム）をモデル化しても、多くのステップでのエンジンの最終的な動作を理解するのに役立ちません。
では、プロセスを追跡するにはどのような図を使用すればよいですか？物理エンジンを作るためにどのような図の専門家が使用しますか？
TO DOリストは素晴らしいものです。
// #TODO：何とか何とかコメントについて話しているのではありません。私は神のノートに正直になることを意味します。
重要なことをいつ思い出すかはわかりません。ノートブックは静かにそこに座って、手書きがコンパイルされない方法について文句を言わずに考えることができます。私の最高のアイデアのいくつかはバスルームで起こります（はい、私は防水のノートブックを持っていますが、それほど遠くに行く必要はありません）。
縫い付けられた（接着されていない）ポケットサイズのものを入手できるので、ポケットの中でバラバラになりません。ブックマークが組み込まれた豪華なものをどうにか入手できませんでしたか？テープ、はさみ、リボンなど誰も知らないでしょう。
アイデアがヒットしたら、それを書き留めます。各アイデアの横に小さなボックスを描画すると、簡単に完了マークを付けることができます。ページの上部にボックスを配置すると、ページが完了したことがわかります。
どのシーケンシャルアクセスでは不十分ですか。うん、ポケットバインダーも作るよ。これはすべて少し似ているように思えるかもしれませんが、ポストイットノートに溺れたり、Jiraですべてをキャプチャしようとするよりはましです。
物事を半分実装しないでください
改善を小さくして達成可能な状態に保ちます。一度に終わらないものを始めないでください。それが大きすぎる場合は、小さなステップに分割します。コンパイルしてテストに合格するコードは常に残してください。ああ、あなたが見たことがないテストに合格することを忘れないでください。テストを成功させることと失敗させることの両方が、テストをテストする方法です。
紙全体のデザインが必要だと考えるのをやめる
あなたがする必要があるのは、あなたの進化する計画をとらえることです。終わったらどうなるかわからないので、ふりをするのはやめてください。把握したことをできる限りキャプチャします。必要に応じて、ナプキンとクレヨンを使用してください。とにかく、UMLの90％を理解している人はほとんどいません。できる限りの方法で、何を表示する必要があるかを示します。私は自分のインターフェースと何について何を知っているかを示すことに焦点を当てています。
コーディングを停止するときにメモを書く
キーから指を離した瞬間が、今やあなたが何をしたか（そしてあなたが計画したこと）を理解する最後の時です。いくつかのメモにできる限りその理解を記録してください。あなたが持っているすべてがコメントであるなら、あなたはまだコンピュータに縛られていて、水たまりを椅子に残しそうです。繰り返しますが、ノートブックを持つことは素晴らしいことです。
このようにして、あなたは脳を上品に着地させ、膀胱を救い、そしてカフェインや歯のグリッティングに頼らずに後で再び離陸することができます。
「初めてのものを除いて、すべてをトップダウンで構築すべきだ」と彼らは言う。
私は最低レベル（例えば、基本的なベクトル計算）から始めて、それを十分に理解し、テスト範囲が十分であることを確認しました。次に、その上にもう1つのレイヤーを構築し、より抽象的な操作（グループ/エンティティ、衝突検出、衝突メカニズムなど）を可能にします。繰り返しますが、テストでカバーします。エンジンでのこれらの抽象化の実際の使用例について考えるのに役立ちます。
エンジン全体をよく理解していない限り（たとえば、よく知られた既存のエンジンを再実装するときなど）、通常はこれらのレイヤーを用意することをお勧めします。これにより、前のレイヤーの観点から特定のレイヤーについて考えることができ、通常はそれほど深くはありません。新しい便利な抽象化を使用して、レイヤーを実験して構築できます。実際に実用的であることが判明するものは、多くの場合、最初のアイデアから逸脱します。
うまくいけば、各レイヤーが十分に小さいため、複雑な図を必要としないか、便利な図を簡単に作成できます。
便利な複雑なコード図に出会ったことはありません。 相互作用とライフサイクルの図は役に立ちます。多くの場合、このような図は1〜2層に制限されているため、単純です。
私が通常最も価値があると思うのは、各レベルで提供されるインターフェースの説明と保証です。例えば。ベクトル数学のフォーマット、および数値エラーで何が起こるかより大きなオブジェクト記述のフォーマット（常に凸形？常に時計回り？、どのように交差するかなど）、相互作用の機械的パラメーター（時間の進行方法、質量の処理方法、運動量は常に維持されるか、力の計算方法？）適切な相互作用（摩擦の処理方法、変形、断片化）は、機械的エネルギーを熱損失に変えることですか？）。
各層は、それが導入し、それが提供することを保証する観察可能な量を持つために十分に小さくなければなりません。この説明は、（まだ）実装コードを記述せずに作成することもできます。これにより、ひどく間違った何かを3つの層で行ったと判断する可能性が低くなります。そうした場合、すでに最大で2つのレイヤーが表示されます。
建築図を作ろう！コメントに投稿された OpenGLパイプラインダイアグラム FrustratedWithFormsDesignerは、プログラムflowの良い例ですが、これは1種類のダイアグラムのみです便利です。
図を設計するときは、コードを理解するコードを理解するシンプルで直感的です。これには、高水準の概念（OpenGLパイプラインダイアグラムのノードの一番上の行など）、または非常にきめ細かい技術的詳細（完全な関数呼び出しグラフなど）の両方を含めることができます。
理想的には、ドキュメントは他の人がコードを理解しやすくする必要もあります。これにより、コードレビューやオープンソースコラボレーションなどが簡単になります。大規模なプロジェクトを見て、これがどのように達成されるかを確認します。何十万、何百万行ものコードを扱う場合、コードベースを追跡したり、他の人に紹介したりするために、プログラムを読まなくてもどのように機能するかを理解することが非常に重要です。 。 LOCが130万個あるVimリポジトリの / src/README.txt には、このための非常に優れた高レベルのドキュメント（IMO）があります。紹介します：
- 各ファイルのコードは何をしますか
- 重要なグローバル変数とその値
- メインループで何が起こり、それが呼び出す関数
- 各モードで何が起こるか、およびそれらを処理する主な機能
- ネイティブデバッグ機能とは
パッチを提供したい場合は、通常、掘り下げることなく目的を達成するためにどのファイルを変更する必要があるかを知っています。
Vimの_/src/README.txt_の最も優れた機能の1つは、簡単に見つけられ、包括的であることです。どのような意味でも細かいわけではありませんが、Githubのsrcフォルダをクリックすると、自動的に読み込まれ、他のコードやドキュメントを見つけるための指示が与えられます。それとは対照的に、私は例を探しましたが、Vimの_/src/README.txt_に相当するファイルを見つけることができませんでしたPowershellリポジトリとは対照的です。 （LOCが988千のプロジェクトの悪い兆候！）
ダイアグラム化または文書化する必要があるかもしれないいくつかのものが含まれます：
- 概念的なプログラムフロー（プログラムとはaccomplishで、その順序は？）
- 実装されたプログラムフロー/関数呼び出しグラフ（プログラムはどのようにしてその目的を達成しますか？どの関数が呼び出されるか、またはクラスが作成されますか？）
- どのファイルにどのコードが入っていますか？新しい機能がどこに行くかを決定するための組織体系とルールは何ですか？ 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 で入手できます。