Alixx Skevington贴出了一篇《完成宣言》，开启了一段关于下列话题的讨论——团队成员对工作的质量和清晰描述代码所交付的商业价值所负有的义务。

 

他列出了如下的完成标准：

 

• 我肯定我的代码是可用的。我的代码供他人使用和交流。我的代码应使这一过程充满乐趣，减少而不是增加工作量。

 

• 团队接受我编写的代码风格。除了我，其他人也能维护和改进我的代码。当我拥有用任何技术设计问题解决方案的自由时，我仍然遵守这一规则，编写出其他人可以维护的代码。

 

• 我赞成保持方法的合理长度。长方法难以阅读和调试。我会尽可能地缩短方法的长度，以降低复杂性。我会注释所有的代码。无论是编写新代码还是修改既有代码，我都会用简明的注释来解释我做了什么。这样其他人在阅读时就能理解我做了什么，代码要解决什么问题。

 

• 我赞成对自己的代码进行单元测试。我赞成编写可重用的、不易出错的测试用例。我应使测试用例解释它在测试什么和为什么这样测。这样其他人在重构和修改bug时，不但可以运行我的测试用例，还能理解代码在做什么。

 

• 我同意为既有代码维护测试用例。当我在既有代码上修改或添加功能时，我会确保原有的和新增的测试用例都通过。

 

• 我同意使自己代码的覆盖率达到至少80%。通过代码覆盖率检查，我能够确认我所写的所有代码都是有价值的。我的代码中不存在可能造成问题的隐患。我会努力使代码覆盖率更高。

 

• 我赞成检查代码是否被正确地集成。当我写完代码后，我会与其他开发者一起确认我的代码能够与他们的代码一起工作，实现预期功能。

 

文章在LinkedIn上一经贴出，引来了很多网友回复，建议加入更多的条目，例如：

 

我要添加一条：“在签入代码前我会重新运行全部的单元测试”。理由是代码修改后可能会给其他地方带来问题。这种情况在我上一份工作中发生过好几次。（David Kramer）

 

回复：这与单元测试有关：其实我想把这句话改为“我会在编写代码前编写单元测试”，因为我是个测试驱动开发的忠实信徒。另外一条与测试有关的是：它们也是生产代码，请用同等标准对待。（Scott Ames）

 

Scott Mcphee不同意关于代码注释的条目：

我不得不说我完全不同意关于代码注释的说法。注释经常撒谎，或者重复那些显而易见的东西（比如这样：/* 让y等于x */ x=y;），总是让我们背上额外的包袱，去维护代码以外的东西。清晰的设计和编码不需要“简明的注释来解释我做了什么”——这都是代码本身所能说明的，而签入配置管理服务器时的注释和版本比较也足够说明“为什么要这样做”。如果代码不能体现这一点，那么就对其进行重构，直至达到上述要求为止。 API文档是另外一个麻烦，不过通常不是针对源代码的读者来编写的，而是为使用公开方法的用户所提供的，正式发布的产品的一部分。

 

Jay Packlick提出了他认为最为关键的一点：

“完成”的定义所暗示的最重要的一条应当被明确指出，我把它放在列表的第一项：“定义了‘完成功能’的所有的确认条件都应该以测试的形式体现，并能够通过测试”。