极限编程XP︱一文搞懂极限编程XP的关键实践

后做出来的产品的质量的确是没话说的。

 

当然，要使用 TDD 也是有前提的，第一当然是领导和团队的支持，第二就是团队的编码规范完善，第三就是整体水平还不能太次。因为如果你一开始就把测试写错了，那么写出来的代码也不可能对。另外，如果滥用这些单元测试的话，还会让人走向极端，追求完美的 100% 的测试覆盖率，这也是不可取的。大部分情况下，从 60 分到 80 分，我们可能付出 100 分的努力就可以达到，而从 80 分到 95 分，可能需要付出 500 分的努力。但是从 95 分到 99 分，可能就需要 100000 分的努力，而 99 到 100 ，则有可能是 10 的 N 次方的努力了。当我们陷入到这种情况的时候，往往就会得不偿失。

 

TDD 最核心的是去测什么东西呢？在 单元测试 阶段，最需要测的是核心的算法，比如电商项目中的折扣金额之类的计算，返点优惠的计算等。在代码架构中，这些往往是服务层要解决的问题，所以，我们主要测试的目标应该是服务层的代码。

 

再从分层架构上来说，控制层分发请求，接收参数，做好效验方面的测试即可。模型层处理数据持久化，一定要注意入库数据的安全性和完整性，做好这方面的测试即可。而服务层，也就是我们公共的计算部分，承担着整个系统的核心，这些才是单元测试真正需要关心的地方。因此，和上方的结论一致，我们最重要的测试内容就是服务层的核心算法或核心逻辑。

当然，你也可以在控制层写服务，也可以在模型层写服务，总之，找出关键核心的处理业务逻辑和算法的地方，加强这个地方的测试覆盖率，不要盲目的以整体的测试覆盖率为标准，这才是 TDD 能够更好运用的重要方面。

 

理论归理论，这方面其实我并没有太多的实战经验，不过我也觉得测试覆盖率不能说明一切，在这里更希望有经验的同学能够分享相关的经验，可以评论里留链接或者加好友转载文章哦！

 

编程方法（三）：重构

 

这个词对于写代码的人来说就更不陌生了，甚至很多人在换到新的公司时，第一个建议就是咱们重构一下老项目的代码吧，因为前人写得太X了。当然，想法总是好的，但现实其实是很残酷的，真正的重构不是说我们要让所有的代码都变成你喜欢的代码。真正的重构是源于敏捷的不断迭代的重构。在收下两种情况下，我们通常会开始重构一段代码。

 

实现某个特性之前：尝试改变现有的代码结构，以使得实现新的特性更加容易

实现特性之后：检查刚刚写完的代码后，看是否能够进一步的优化

 

在重构中，有一个重要的概念就是 Don't Repect Your Self 也就是非常出名的 DRY 原则。从开发的角度来说，就是不要让一段相同的代码出现两次。另外，重构还和 XP 中的其它元素紧密相关，比如说代码集体所有制，让代码共享所有人都能看到代码，并且通过结对编程，你的重构也会被别人发现并指出优劣。需要完善的测试驱动开发机制，这样才能确保你的重构不会带来问题。简单的设计，会让你在重构的过程中关注最核心的部分，写出能够实现功能的最简单的代码。

 

通过上述内容，其实我们也就保证了 XP 中 勇气 的含义，让你能够勇敢的去重构。

 

编程方法（四）：简单设计

 

还记得 XP 核心思想中的 简单 原则吗？没错，设计是很重要，但是，我们应该从最简单的设计开始，通过迭代和增量不断地完善它，而不是一开始就做出一个复杂的设计来。对于简单来说，并不是说所有的设计都很小