Joel Test中的一个项目是项目/公司应该有规范。
我想知道什么使规格好。有些公司会编写大量无用的规范，没有人读过，其他公司也不会写下任何东西，因为“无论如何都不会读任何东西”。那么，你对你的规范有什么看法？两个极端之间的良好平衡是什么？有没有特别重要的东西真的，真的（！）应该总是记录在规范中？
答案 0 :(得分：54)
最好的规格是：
答案 1 :(得分：14)
答案 2 :(得分：11)
根据我的经验，如果规范具有以下内容，那么规范将有更多的机会被阅读：
我见过那些编写规范的人不了解系统的公司。这几乎是通过编写规范来学习系统的一种方式。这通常以泪水结束......
答案 3 :(得分：4)
作为为客户开发定制软件的人，最佳规格是客户签署的。
无论您的规格有多精致 - 如果客户没有明确表示同意，他们会改变它并希望您能够无缝地推动他们的变化，破坏您美丽的建筑...... / p>
答案 4 :(得分：2)
良好的规范应包含可衡量和可验证的要求。在查看每个要求时，您应该能够轻松回答“我怎样才能证明我已满足此要求？”。
答案 5 :(得分：1)
阅读Joel对Joel Test文章的一系列“Painless Functional Specifications”后续内容。它们也出现在“Joel on Software”一书中。
答案 6 :(得分：1)
取决于项目的规模和（与所有架构决策一样）约束是什么。一个好的开始是
最重要的是进行验收测试，即可以检查的事物的可测试陈述，以及在完成这些事情后，项目完成的协议。
答案 7 :(得分：1)
如果您首先说明用户具有的目标或某个功能的全局概念，那么它也会有所帮助;而不是填写确切的实现。这总是让我觉得缩小开放的思想或使用创意较少（更有用）的解决方案。所以你应该保持“所有选项都开放”。
示例 您编写的软件用于衡量“X”。
而不是陈述： 必须有一个开始按钮和一个保存按钮。
使用： 用户必须能够开始测量并保存。
<强>为什么？ 因为在第一种情况下，您已经确定了解决方案的必要性，而第二种情况则为您提供了如何实现某些功能的灵活性。现在这看起来似乎微不足道，但我感觉“程序员”倾向于在解决方案中而不是在问题（或情境）中思考更多。当您添加更多功能时，这变得更加明显，因为使用向导或自动化过程可能更好，但您已经将想法缩小到使用按钮。
答案 8 :(得分：1)
对于功能要求 - 或者更具体地说，行为要求 - 我喜欢使用Cucumber和Gherkin。
以下是简单映射应用程序中新功能的简单和简短规范示例。该功能允许小型企业注册到地图平台，并在类似Google地图的服务上添加其营业地点。
Feature: Allow new businesses to appear on the map
Scenario Outline: Businesses should provide required data
Given a <business> at <location>
When <business> signs up to the map platform
Then it <should?> be added to the platform
And its name <should?> appear on the map at <location>
Examples: Business name and location should be required
| business | location | should? |
| UNNAMED BUSINESS | NOWHERE | shouldn't |
Examples: Allow only businesses with correct names
| business | location | should? |
| Back to Black | 8114 2nd Street, Stockton | should |
| UNNAMED BUSINESS | 8114 2nd Street, Stockton | shouldn't |
Examples: Allow businesses with two or more establishments
| business | location | should? |
| Deep Lemon | 6750 Street South, Reno | should |
| Deep Lemon | 289 Laurel Drive, Reno | should |
Examples: Allow only suitable locations
| business | location | should? |
| Anchor | 77 Chapel Road, Chicago | should |
| Anchor | Chicago River, Chicago | shouldn't |
| Anchor | NOWHERE | shouldn't |
这个规范看起来很简单，但实际上非常强大。
良好的规格清晰，明确，具体。它们不需要被破译以便编写工作代码。这正是Gherkin规范的内容。他们最好简短而简单。您可以通过在每次迭代中编写新的规范，让规范套件与您的产品一起发展，而不是撰写长屁股规范文档。
Gherkin是一种商业可读的语言，用于编写基于Given-When-Then模板的规范文档。模板可以自动进入验收测试。自动化规范可确保其保持最新，因为捕获的对话与测试代码直接相关。这样，测试可以用作文档，因为每次代码更改时，Gherkin功能都必须更改。
当每个业务规则都进行自动化测试时，Gherkin规范成为所谓的可执行规范规范，可以作为计算机程序运行。该程序测试验收标准是否正确实施。因此，在一天结束时，我们对我们的产品是否实际上正在做我们期望的事情 - 这本身就是非常有价值的问题 - 得到一个肯定或否定的答案，因为它有助于制作更好质量的软件
Gherkin规范和测试代码之间的直接联系通常通过创建和培养生活文档系统来减少浪费的损害。由于经常验证测试，如在持续集成系统中，您可以知道Given-When-Thens仍然是最新的 - 当您信任测试时，您可以使用相应的Gherkin规范作为整个系统的文档。
事实上，有一种称为规范说明的整个方法，它使用像Gherkin这样的工具。通过示例规范的实践，通过强制您在规范文档中使用具体，离散，明确的示例，为您提供与业务利益相关者交谈的框架，从而减少误解和返工的可能性。
如果您想了解更多关于Cucumber，Gherkin，BDD和Specification by Example的信息，我写了一本关于这个主题的书。 “Writing Great Specifications”探讨了编写出色场景的艺术，并将帮助您将可执行规范作为开发过程的核心部分。
如果您有兴趣购买“写出优秀的规格”，您可以使用促销代码39nicieja2 节省39％：）
答案 9 :(得分：0)
我认为编写“用例”应该可以节省大量的页面
答案 10 :(得分：0)
+1 @ KiwiBastard我会添加类似子弹并使每个子弹可测试。
答案 11 :(得分：0)
描述实施所需的所有关键信息的蓝图，但不会浪费任何努力来描述所有必要的琐碎或明显的信息。
应该只是足够的信息来确保实施“按预期”，而不会提供太多额外的噪音，而不是必要的。
在实践中，大多数人都错了，因为他们专注于简单的东西（这是最不必要的）并且回避硬件（这是你真正想要锁定的东西）。我已经看过太多2英寸的文件完全和完全错过了这一点，很少有3页的文件可以用它来点击它。
规格不必很长，只需要包含正确的东西！
（提示：如果程序员在编码时没有查看该页面，则可能不需要）
保罗。