我从来没有写过功能规范，我更喜欢跳进代码和设计东西。到目前为止，它工作得很好，但是对于最近的一个个人项目，我正在写一些描述产品所有功能的规范，以及它应该如何“工作”，而不涉及如何实现的细节，我发现它非常有价值。
你有什么想法，你是写规范还是只是开始编码和计划，哪种做法更好？
Java
问问题
1652 次
11 回答
13
如果您从家开车到最近的杂货店，您可能不需要地图。但...
如果您要开车去另一个州从未去过的地方，那么您可能会这样做。
如果您为了驾驶乐趣而随意开车，您可能不需要地图。但...
如果你想以最有效的方式到达某个地方（最小化距离、最小化时间、沿途做三个特定的停靠点等），你可能会这样做。
如果您是自己开车，可以随心所欲地走，看到有趣的东西随时停下来或重新考虑您的目的地或路线，您可能不需要地图。但...
如果您作为车队的一部分开车，并且所有人都需要一起提供食物和过夜住宿，并且需要一起到达，那么您可能会这样做。
如果您认为我不是在谈论编程，您可能不需要功能规范、故事卡、叙述、CRC 等。但是......
如果您认为我是，您可能需要至少考虑以上其中一项。
;-)
于 2009-01-03T15:35:39.633 回答
11
对于“跳入代码”和“随手设计”的人，我会说编写任何包括功能规范在内的东西都比您当前的方法要好。如果您在开始之前花时间仔细考虑并设计它，则可以节省大量时间和精力。
- 需求有助于定义您需要做什么。
- 设计有助于定义您计划制作的内容。
- 用户文档定义了你做了什么。
你会发现大多数地方都会有这三个文件的一些变化。功能规范可以集中到设计文档中。
如果您不相信，我建议您阅读快速开发。如果您花更多时间进行计划和设计，您确实可以更快地完成工作。
于 2009-01-03T15:11:55.810 回答
5
为大型软件项目“直接编写代码”几乎肯定会导致失败（就像立即开始摆砖架桥那样）。
37 Signals的人会说，在纸上写一个简短的文档比写一个复杂的规范要好。我想说这对于快速模拟新网站可能是正确的（设计和想法可能比僵化的模式更好），但在其他现实生活中并不总是可以接受的。
想想您的客户签署的规范文件可能具有的（法律，甚至）重要性。
士气可能是：灵活，并根据您的项目方案尽可能多地计划功能或技术规格。
于 2009-01-03T15:16:21.840 回答
4
对于一次性黑客和小型实用程序，请不要打扰。
但是，如果您正在编写一个严肃的大型应用程序，并且有要求苛刻的客户并且必须运行很长时间，那么这是必须的。阅读 Joel 关于该主题的精彩文章- 它们是一个好的开始。
于 2009-01-03T15:12:51.970 回答
3
我是双向的，但我从测试驱动开发中学到了一些东西......
如果您使用路线图进行编码，那么您将比如果您只是开始走在路上而不知道它将如何在中间分叉，那么您将快得多。
您不必写下每个功能将要做什么的每一个细节，而是定义您的基础知识，这样您就知道应该做什么才能使所有功能协同工作。
话虽如此，我昨天需要编写一系列异常处理程序，而我只是一头扎进去，根本没有尝试构建它。也许我应该重读我自己的建议；）
于 2009-01-03T15:07:41.263 回答
3
许多人不想承认或意识到的是，软件开发是一门工程学科。关于他们如何处理事情，可以学到很多东西。在小型项目中，规划您将在应用程序中执行的操作并不一定至关重要，因为通常更容易快速返回并修复您的错误。与写下系统首先要做什么相比，您看不到浪费了多少时间。
实际上，在大型项目中，几乎有必要制定系统工作原理和功能的路线图。如果您愿意，可以将其称为功能规范，但通常您必须有一些东西可以向您展示为什么步骤 b 遵循步骤 a。我们都认为我们可以在飞行中想出来（我也肯定对此感到内疚），但实际上它给我们带来了问题。回想一下，问自己有多少次遇到某事并对自己说：“伙计，我希望我早点想到这一点？” 或者其他人看到你做了什么，并向你展示了你可以采取 3 个步骤来完成一项需要 10 个步骤的任务。
把它写在纸上真的会迫使你思考你要做什么。一旦它写在纸上，它就不再是一个模糊的想法，然后你可以查看它并评估你的想法是否真的有意义。更改一页文档比更改 5000 行代码更容易。
于 2009-01-03T15:21:25.260 回答
3
如果您在 XP（或类似）环境中工作，您将使用故事来指导开发以及大量的单元和走廊可用性测试（我猜我喝过Kool-Aid）。
但是，有一个领域绝对需要规范：与外部团队协调时。我与一家大型保险公司有一个项目，我们需要就某些程序行为、数据库设计的某些方面和一些文件布局达成协议。如果没有规范，我对我们所承诺的内容进行创造性的解释是开放的。这些人都是好人——我信任他们并且喜欢和他们一起工作。但是，如果没有那个规范，那将是一场死亡行军。有了这个规范，我总能指出他们在哪里偏离了商定的布局，或者他们在哪里要求额外的定制工作（$$！）。如果使用半对立的关系，规范可以使您免于更糟糕的情况：诉讼。
哦，是的，我同意 Kieveli 的观点：“直接跳代码”几乎从来都不是一个好主意。
于 2009-01-03T15:26:43.393 回答
1
我会说这完全“取决于”问题的类型。我倾向于问自己我是为了它还是为了你上面的层次而写它。我也对此进行了辩论，我的个人经验表明，你应该这样做，因为它使项目保持在预期的轨道上（而不是偏离轨道）。
于 2009-01-03T15:17:52.600 回答
0
出于多种原因，我喜欢先在纸上松散地分解任何不重要的问题，而不是跳入代码；
- 我写在纸上的东西不必编译或对计算机有任何意义
- 我可以在纸上以任意抽象层次工作
- 我可以很容易地添加图片和图表
- 我可以很快地思考和调试一个概念
如果我正在处理的问题可能涉及大量时间或许多其他人，我会将其写成大纲功能规范。如果我由其他人支付开发软件的费用，并且可能存在歧义，我将添加足够的额外细节以消除这种歧义。一旦编写了软件，我还喜欢使用此文档作为开发自动化测试用例的起点。
换句话说，我编写了足够多的功能规范以正确理解我自己编写的软件，并为其他相关人员解决任何可能的歧义。
于 2009-01-03T16:46:17.213 回答
-1
我很少觉得需要功能规范。OTOH我总是让用户负责这个功能，一个电话就可以了，所以我可以随时向他们询问功能要求。
对我来说，功能规范更像是一种政治工具，而不是技术工具。我想一旦你有了一个规范，如果你以后发现实现的问题，你总是可以责怪规范。但是怪谁对我来说真的不感兴趣，即使找到替罪羊，问题仍然存在，不如重新审视实施并尝试将其做好。
编写一个好的规范几乎是不可能的，因为你真的对问题或工具或环境中的未来变化了解得不够多，无法正确地做到这一点。
因此，我认为采用敏捷方法进行开发并投入足够的资源和时间来随时重新审视和重构更为重要。
于 2009-01-03T15:42:59.087 回答
-5
重要的是不要写它们：功能规范没有任何功能
于 2009-01-03T15:06:43.980 回答