我有一个问题，我觉得许多程序员可以与...相关...
我参与了许多小规模项目。在我最初的纸脑风暴后，我倾向于开始编码。我想出的通常是实际应用的粗略工作模型。我以断开连接的方式设计，所以我在讨论底层代码库，用户界面是最后一件事，因为库通常决定了UI中需要什么。随着我的项目变得更大，我担心我的“规范”或设计文档也应如此。
从我的调查来看，上述段落在互联网上以一种或另一种方式得到了回应。当涉及UI时，会有更多信息，但它是特定于UI的，与代码库无关。我开始意识到，代码可能代码是代码。从我的广泛研究看来，设计文档和代码之间没有1：1的映射。
当我需要研究一个主题时，我将信息转储到OneNote中，然后我将功能优先分配到版本中，然后分配到相关的块中，以便开发以相当线性的方式运行，我的任务看起来像这样：
现在任何值得他的盐的程序员都知道，在这三个要做的项目之间可能是一个潜在的代码墙，可以扩展到多个文件。我试图为每个任务映射完整的代码过程，但我认为它不能有效地完成。当一个mangles伪代码时，它本质上是代码，所以时间投入被否定了。
所以我的问题是：
我是否正确地假设最好的文档是代码本身。我们都同意需要高级别的概述。这应该有多高？你是设计到陈述，阶级还是概念层面？什么对你有用？
答案 0 :(得分：2)
我强烈建议您阅读Code Complete 2，以便对这些问题有一些很好的了解。
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
答案 1 :(得分：1)
我认为你想要的是软件需求规范。
以混乱的方式编码所有东西是一种错误的工作模式！ 您需要创建一个功能/非功能需求列表，以创建与UI要求和业务主角创建用例的链接/相关/子/父关系。
在此步骤之后，您需要最终管理UML或SPEUDO代码中的所有设计界面，但是当您正式化需求（对于小项目）时，需要关闭UML。
有关代码的文档，您可以使用doxygen或javadoc approch，简而言之， 您在代码上插入注释，并使用软件将所有文档放在HTML / PDF中。
通过这种方式，你可以按顺序接触到这个东西：
1 - 软件要求
现在，您可以全面了解您的软件是什么，也可以了解软件需要哪些功能（技术/非技术/时间/业务）。
还有用户在开发生命周期的最后阶段测试软件。
2 - UML或PSEUDO代码
将您的工作分成其他同事的简单方法，以及代码界面设计的简单代码概述。
3 - 像你这样的其他编码人员的图书馆文档以及不浪费的所有好处也太匹配了在项目结束时写下所有文档的时间！
我的2美分。google关键字： 软件工程doxygen软件开发生命周期，CMMI，IEEE SRS（软件需求规范）。
答案 2 :(得分：0)
最后，我发现有几种方法可以解决这个问题，从思维导图到概念图甚至是UML /伪代码。最后，对个人最有效的方法似乎就是使用它。