2、 简单（simplicity）
保持代码和设计尽可能简单是系统可扩展性和可维护性的重要保障。关于Simple Design的讨论可见徐X的Agile 101: Pair Programming & Simple Design 。kent beck用四个条件定义了简单的系统代码：运行所有的测试获得通过、意图明确、没有重复、使用尽可能少的类和方法。我和accompanier也一直在向这个目标努力。
3、 反馈（feedback）
没有持续的反馈，敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通，掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次，所以客户也能在很短的时间内知道完成的新功能，并及时提出改进意见和建议（其实客户的需求也是一直不停地在变的）。
4、 勇气（courage）
为了使代码更加清晰、质量更好，对工作代码进行大范围的修改和重构需要勇气，把某些代码彻底抛弃需要勇气，告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气，希望系统越来越大、代码越来越多的时候还有这样的勇气。
三、测试驱动开发（TDD）
关于TDD我们一直在尝试寻找更爽的方法，目前采用的是webwork、spring、hibernate的组合框架，在大脑里无意识的已经存在了三层结构，我觉得采用TDD，这三层结构应该是最后被驱动出来产生的，而不是一开始就定好三层，然后再TDD编码。
我们目前是分别对每层进行TDD，还是觉得service层驱动最有成就感，看到green bar 就令人兴奋，action层老是mock来mock去的走流程实在属没啥意思。
最近又看到了使用Selenium和Castle进行测试驱动开发 ，本想采纳，但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了，我是对green bar有点上瘾了的人，不能忍受那么长时间的red bar，怀疑它会对偶的身心健康造成影响，所以就作罢，还是由底至上的方法使测试通过的实践最短，不知道各位对这样的三层结构是怎么TDD的？
Robert C. Martin大叔的TDD三条军规如下：
1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。
2.只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开始编写产品代码；但是到了原则3，你就只能编写产品代码，直到让测试编译成功或通过断言为准。
此文章共有3页 上一页 1 2 3 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
