刚才在InfoQ看到这篇文章，很有感触。记得在工作中经常告诉经理说，功能实现了、工作完了。但总有这样那样的问题。虽然任何的程序都很难没有bug，但我们有做完Alixx Skevington的“完成”添加列表吗？
Alixx Skevington贴出一篇“完成宣言”以引发讨论，其中谈到团队成员针对各自的工作质量向彼此做出的承诺，并清晰表明了他们对于使用代码交付业务价值的承诺。
他的“完成”条件列表包括：
- 我会确保我的代码可用。我的代码是为了供他人使用、与他人交互的，我所写的一切都要保证这是令人愉快的过程，而且应该降低工作量，而不是增加。
- 我会确保我的代码风格服从团队一致同意的风格。未来会是别人，而不是我，来维护和修补我的代码。所以虽然我可以灵活设计并利用任何技术来构建我的解决方案，我还是会遵循标准，以便于其他人将来维护我的代码。
- 我同意将我的方法保持在合理的大小。大方法难以查看与调试。我会尽量把我的方法保持在合理的大小，以降低复杂度。
- 我会注释所有的代码。不管是创建新代码还是变更现有代码，我都会写下简明扼要的注释，说明我做了什么。这样其他人在阅读代码时，就能理解我做了什么以及代码试图实现的目的。
- 我同意对我的代码做单元测试。我同意让这些测试可以重用、足够健壮。我会确保测试说明它测试的对象及其原因。这样其他人在重构或修复bug时，不仅可以运行我的测试，还能了解我的代码试图达到的效果。
- 我同意维护现有代码的单元测试。当我改变或添加现有代码的新功能时，我会确保所有的测试都可以通过，而且新功能也有对应测试。
- 我同意努力让我的代码的测试覆盖率达到80％。检查完代码覆盖率，我就可以确保所写的一切代码都有价值，不存在会在未来产生问题的“惊奇代码”。我会努力让覆盖率更高。
- 我同意正确检查代码的集成状况。当我写完我的代码后，我会和其他开发人员一起检查我的代码，确保与他人的代码可以一起正确工作，交付客户请求的功能。
这个帖子在LinkedIn的讨论组中引发了一些评论，人们建议加入更多列表项，比如：
我会加入“我会在签入代码前重新运行单元测试”。原因在于：看起来不相关的代码可能导致另一处的代码及其测试运行失败。这在我上一个工作中多次发生。（来自 David Kramer）
再说说单元测试。实际上，我会将其变为“我愿意在编写代码前先编写单元测试”，因为我笃信TDD。另一点关于测试的是：它们都是生产代码，要以同等态度对待。（来自 Scott Ames）
Scott Mcphee不同意代码注释那一条：
对于代码注释这一条，我坚决持反对意见。注释常常都是谎言，或者不过是引出明显的东西而已（比如： /* 设置x等于y */ x=y;），而且常常增加负担，人们必须要让其与实际代码保持一致。设计清晰、实现清晰的代码不需要“简明扼要的注释说明我做了什么”，从代码就能明显看出它做了什么，而且配置管理提交的注释和代码中的版本差异应该说明写代码的原因。如果做不到的话，就要重构，以做到这一点。API文档是完全不同的东东，但其主要是给公开方法的用户看的，而不是代码文件的读者，API文档也是发布交付物的一部分。
Jay Packlick加入了他认为至关重要的一点：
“完成”最重要的定义是隐含的，但是最值得留意，我愿意把它放在列表的第一条：所有关于“完成”某个功能的验收条件都要以测试表述，而且都要通过。
您愿意对这个列表做出哪些补充或改变？
