我们总是写函数或类，它们的逻辑非常复杂。如果这些结构没有规范，以后连我们自己都很难掌握。
你如何为复杂的函数和类编写规范？
请告诉我一些你自己的经历，但不仅仅是一些链接，谢谢。
问问题
18320 次
4 回答
13
我发现功能规范的最大挑战不是直接的格式，而是使它们与驱动它们的事物（需求）和建立在它们之上的事物（测试用例、文档）保持同步。
出于这个原因，我更喜欢使用模型驱动的方法而不是纸张驱动的方法来处理这个问题。
我使用 UML 建模工具（Sparx Systems 的 Enterprise Architect，但许多工具也可以工作）在一个地方捕获项目的所有工件并在它们之间创建可追溯性。在 Enterprise Architect 中，我可以创建从需求工件到设计工件（例如）的可追溯性，只需将它们放在同一个图表上并通过鼠标拖动创建从一个到另一个的连接器。
我的“功能规范”实际上是活动图的集合，系统中的每个用例都有一个。每个用例都与需要该用例的一个或多个需求相关联。甚至最终用户也发现遵循活动图并对其进行验证很容易（让最终用户阅读，更不用说理解和验证传统的纸质功能规范有多容易？）
以类似的方式，我可以创建从我的活动图（用例）到特定设计工件（如类图）的可追溯性。
QA 可以对测试用例进行建模并创建从测试用例到用例的可追溯性。这样，我们可以查看是否有任何用例没有测试用例（或没有足够的测试用例）。
Enterprise Architect 作为一个工具的好处是所有这些工件都存储在一个 SQL 数据库中，所以我可以运行一些随着时间的推移而建立的查询来查找工件，而无需跟踪它们。
于 2009-08-28T23:43:10.240 回答
0
我在上面看到一些关于链接到 Joel 的东西而不是内联文本的抱怨，所以这是我对他所说的话的看法。
在最高级别，功能规范需要向消费者或客户传达程序旨在做什么。在这一点上，我 100% 赞同 Joel：严格使用的英语（好吧！）语言是一种非常强大的工具，您的所有客户都将成为消化专家。他们不是 UML 的专家。
顶级功能规范文档 (FSD) 可以提供一个逻辑框架，该框架在人们容易理解 的逻辑模型中捕获系统的需求。
纯粹的需求文档——在 FSD 之前的东西——是一个棘手的问题。很少有人能够在心理上区分什么是需求，什么是解决方案的一部分。因此，最好确实将要求保持在非常高的水平，并且作为分析师，专注于 FSD。
FSD 应该是一个完整的系统顶层模型，以及更详细地充实模型层次结构的后续设计过程。最后一级的细节是真实的代码。
FSD 应该以一组简单的英语语句结束。在文档中使用单个标题级别，将段落减少到最多两个句子，并为每个段落编号。查看段落并确保每个段落都说一些有用的东西。如果没有，请删除它。短的很好！
认真思考 FSD 中的语言。对段落中的关键名词有严格的定义。这些名词成为你的类。你使用的动词成为你的类方法。真的就是这么简单！
正如乔尔所说，给你写句子，就像你要编译它们一样。例如，写“如果事情发生了，那就做更多”，而不是“如果事情发生了，做更多”或“当事情发生时做更多”。
这些类型的书面模型可以从使用特定图（例如有限状态图）中受益，但请注意您可以使用一组 UML 图来捕获系统。这些东西不够强大、不够灵活或不够严谨，不足以单独作为一个完整的描述。从用严谨的英语编写的大纲开始，并在必要时对其进行补充会更有效。
至于迭代的问题，在理想的世界里，你应该只需要对模型的较低层次进行返工。如果你必须改变高水平，那么严重的事情是错误的。至于 UML 工具在启用复习方面更快 - 罂粟公鸡！关键是所有这些描述都是简短而简洁的。英语是要走的路，因为我们都练习了这么久。
我见过人们花了一个下午试图使实体图之类的东西在重叠线方面看起来很漂亮。比如为什么？您的最终解决方案是二维盒子和线条吗？不！这就是 UML 的问题：图表本身成为分析师的目的，并切断了您与客户的联系，而不是帮助沟通。
于 2014-11-14T14:46:36.047 回答