我正在编写一个小游戏，现在我有9个C＃脚本可以使它工作。我已经忘记了究竟发生了什么以及如何发生。我想知道从比赛开始的那一刻起事情是如何运作的。发生了什么以及如何等等。
我是初学者，我听说写下你的程序流程就是记录它。我该怎么记录？我是否必须在代码中的任何地方写注释来解释程序的流程？
答案 0 :(得分：0)
在代码中添加大量注释并不是一个好方法。基本上你应该尽量使你的代码尽可能不言自明。您可以通过仔细规划属于类或函数的内容以及为类，函数和变量使用有意义的名称来实现此目的。如果真的需要额外的解释，评论只不过是最后的手段。
在大多数情况下，除了解释软件某些方面的代码之外，您还应该有一些文档：
需求文档 - 软件的用途是什么，如何使用
架构和设计规范 - 软件的模块和类是什么以及它们如何交互。该文档通常主要由一个或多个图表（UML或其他）组成。
构建手册 - 如何编译和链接软件
安装说明
用户手册
此列表既不完整也不是强制性的。例如，如果您的软件的用户界面简单且自我解释，您可能不会需要用户手册。
答案 1 :(得分：-1)
有时候，图表比文字更好。有一种标准化的控制流程图（无论是程序还是业务流程）。他们被称为......等待...... control-flow diagrams。但我并不认为这正是你所追求的。
还有flow charts（通常拼写为一个单词），它可能比一般控制流程图更适合软件。流程图对于理解算法很有用，但它们通常不能提供良好的全局视图。
对于一个复杂的程序，要记住的更重要的是数据流程。对于那些我们......你能猜到吗？ ...... data-flow diagrams（DFDs）。
可以在不同的细节水平上绘制DFD。您可以使用一个高级别组件来显示系统的主要组件以及它们如何组合在一起，而低级组件则显示需要更多详细信息的系统部分的细节。
DFD可用于各种分析，包括威胁建模等。但是我发现它们非常适合概述当我看到一个新项目（或者我已经忘记的项目）时会发生什么。您应该能够在线找到有关DFD的一些教程，我认为一些绘图软件（如Visio）具有专门用于DFD的模板（可能还有我提到的其他类型的图表）。
有些人可能会认为DFD有点老派，而更喜欢更严格的系统，比如UML（Unified Modeling Language），它能够表达更多的概念，并且在你的＆＃34;模型和＃之间有非常直接的映射。 34;和你的代码。我从来没有学过足够的UML来充分利用它。许多关于软件模式的书中的图表都用UML表示。