Joel考试的最新情况？[关闭]

我想说服我的合作伙伴，我们应该有一个规范，并且应该在编写新代码之前修复错误。我应该参考Joel考试吗？您是否认为Joel测试是最新的？我认为没有规范是不好的项目管理。您是否同意Joel测试？你能加些东西吗？它没有提到例如开源。

我认为Joel测试是最新的-与“永恒”的其他软件写作一样是最新的。

在没有规格的情况下进行产品开发（包括软件开发）只是疯狂。

您怎么知道要去哪里？

关于编写规范，我只想提一点（实际上，我并不认为Joel的规范非常好……总比没有好，但没有那么好）。关键是：

编写规范时，请仅说出产品必须做什么，而不要说怎么做。

这意味着您无需在规范中规定实施细节。那是一项设计活动，您将其留给设计师的经验和创造力。

[此规则只有一个例外：有时会强制或要求特定的实现细节或方法，在这种情况下将其放入。例如，如果软件必须用PHP编写且不可协商，则它将进入规格。这种情况应该很少。]

我可能会补充：没有错误跟踪是同样疯狂的行为。这只是最不专业和最愚蠢的操作方式，将导致巨大的痛苦和折磨。

我将在这里扮演魔鬼的拥护者，并建议Joel测试不是最新的。这太笼统了。随着技术的成熟，这些问题应该比他编写测试时更具体。

既然我们拥有用户案例和敏捷开发流程，那么就不需要规格文件，至少不需要大型的前期规格文件。该问题应更改为“文档级别是否适合所设计的解决方案？” 在大多数情况下，每两周发布一次更小，更紧凑的用户故事，比起详细描述该产品的大型文档有用得多。但是，如果要建造下一个火星探测器，则可能需要详细的前期设计文档。如果您问一家公司是否具有设计规范，那么听到“并非如此，我们实际上使用敏捷流程和用户案例”的答复，我不会感到惊讶。

其次，“每日构建”问题应改为关于持续集成的问题。除非您要构建需要花费数小时才能构建的软件（99.99％的地方不会使用），否则问题应该询问公司是否使用持续集成。

乔尔（Joel）测试中的大多数实际上还没有过时。这仍然是指示工作环境的好方法。