私は小さなゲームを書いています。今は9個のC＃スクリプトを使って動作させています。私は正確に何が起こっているのか、どのように追跡しています。私は、ゲームが始まる瞬間からどのように動作するかを知りたい。何が起こっているのか、など。どのように流れて（動作する）のかを理解するためにコードを文書化するにはどうすればよいですか？
私は初心者です。あなたのプログラムフローを書き留めることを文書化すると聞いています。どのように文書化できますか？プログラムの流れを説明するために、コードのどこにでもコメントを書く必要がありますか？
コードに広範なコメントを付けるのは良いアプローチではありません。基本的には、コードを可能な限り自明にするようにしてください。これを行うには、クラスまたは関数に属するものを慎重に計画し、クラス、関数、および変数に意味のある名前を使用します。追加の説明が本当に必要な場合、コメントは最後の手段にすぎません。
あなたもまた、あなたのソフトウェアの特定の側面を説明するコードに加えて、いくつかの書類を持っている必要があり、多くの場合：
要件文書 - ソフトウェアの目的は何で、それは
を使用する方法をアーキテクチャとデザイン仕様 - ソフトウェアのモジュールとクラスとはどのようなもので、どのように相互作用しますか？多くの場合、このドキュメントは主に1つ以上の図（UMLなど）で構成されています。
ビルド・マニュアル - このリストは完全でもないも、それは必須でどのようにソフトウェアをコンパイル・リンクし
インストール手順
ユーザーマニュアル
。たとえば、ソフトウェアのユーザーインターフェイスがシンプルで自己説明的なものであれば、おそらくユーザーマニュアルは必要ありません。
ありがとう、私はそれをやります。 –
@downvoter：私の答えを説明してください。 –
図よりも図がテキストより優れていることがあります。制御フロー（プログラムであれ、ビジネスプロセスであれ）を作成する標準的な方法があります。彼らはそれを待つ...それを待つ... control-flow diagrams。しかし、私はそれがまさにあなたが何をしているのかとは思わない。
また、flow charts（たいてい1つの単語として記述されています）があります。これは、一般的な制御フロー図よりもソフトウェアに適している可能性があります。フローチャートはアルゴリズムを理解するのに役立ちますが、一般的には大きな画像が得られません。
複雑なプログラムでは、データのフローを覚えておくことがさらに重要です。私たちが持っている人のために...あなたは推測できますか？ ... data-flow diagrams（DFDs）。
DFDはさまざまなレベルで描画できます。システムの主要コンポーネントとそれらがどのように適合するかを示す上位レベルと、詳細を必要とするシステムの部分については細かい詳細を示す低レベルレベルを表示できます。
DFDは、脅威のモデリングなどのさまざまな分析に使用できます。しかし、私は新しいプロジェクト（または私が忘れてしまったもの）を見ているときに、何の概要を知ることができてすばらしいと思います。オンラインでDFDに関するいくつかのチュートリアルを見つけることができるはずです。私は、Visioのようないくつかの描画ソフトウェアはDFD専用のテンプレートを持っていると思います。
DFDは少し古い学校だと思う人もいますし、UML（Unified Modeling Language）のようなより厳密なシステムを好む人もいます。これはもっと多くの概念を表現し、 "モデル"とコードを直接マッピングできます。私は十分なUMLを学んだことがありません。ソフトウェアパターンに関する多くの書籍の図は、UMLで表現されています。
あまりにも広すぎると投票してください。ソフトウェアのドキュメント化は、人々が書籍や大学のコースを書くことができる（そして書いた）話題です。 – Patrick87
[OK]をクリックして、どこかで人を始めてください。私は本当に無知だ。 –
各スクリプトの先頭にコメントブロックを挿入します。他のスクリプトがこのスクリプトを呼び出すものと、このスクリプトが呼び出すその他のスクリプトを列挙します。スクリプトが何をするかを説明するために少し物語を付け加えてください。また、すべてのスクリプトを含む全体的なフローチャートと、コントロールが1つから別のものに移る方法/理由/時期。そうすることで、物の全体的な形を見るのに役立ちます。次回は、最上位レベルのデザインから始めて、下位と下位のディテールを開発する際にドキュメントに詳細を追加してください。 – rossum