2010年3月20日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2010年1月14日

守-破-离

守：是提供一种具体的方法（规范/流程），可供初学者遵循以获得成功。

破：是在“守”的基础上，去了解更多可选的方法，并了解每种方法的异同、适用范围。

离：对于各种方法融会贯通，不拘泥于具体的形式而运用自如。

XP的三级成熟度模型：

1、遵循XP方法的各种规则

2、在做到1之后，尝试对规则进行变通

3、最终无需在意是否在使用XP方法

应用：

要根据对方（特定于主题）所处的层次来安排谈话内容。

  2008年3月25日

项目管理艺术（The Art of Project Management）P122

I've argued with other managers on this very point. They couldn't imagine not allowing their team to code at full speed all the time, regardless of whether the programmers understood the direction the project was going. If the programmers were idle, then the project must be idle, right? Wrong. There is hypocrisy here: if the programmer's time is so valuable, the use of it should be well planned. "What will the programmers do?", they'd ask me. And I'd say, "They will wait for a plan worthy of their time, or help the team to find it."

我曾和其他经理人就这点争论过。他们无法想象，不让团队随时全力撰写程序代码的情况，无论程序员究竟是否了解项目的前进方向。如果程序员空闲，项目就必然闲置，对吗？错。这里有个伪善的说法：如果程序员的时间如此宝贵，在使用上就应充分被计划。他们问我：“那程序员要做什么？”而我说：“他们要等待值得他们付出时间的计划，或者协助团队找出来。”