前言

这周的读书任务是阅读第6章的例子，上周学习了理论部分，这周则学以致用。将学到的知识应用起来才会被内化成自己的一部分。这周的小程序是计算保龄球比赛得分的，在编程过程中，会使用测试驱动的开发方法以及大量的重构。学习完这章，了解到保龄球比赛的计分规则，结对编程的过程，最后对比自己在平时工作中的方式，发现有些可以借鉴的地方。

保龄球比赛计分规则

保龄球比赛一局有10轮组成，每轮有两次投掷机会(第10轮有点特殊，稍后会提到)。投掷者在第一次投掷中击倒所有的瓶子，称为全中；如果第一次未击倒所有的瓶子，但是第二次把剩余的瓶子击倒，这称为补中；一轮中两次投掷加起来都没有把所有的瓶子击倒，这是普通投掷，不管怎样这一轮都算是结束。而第10轮有些特殊，第10轮全中，可以再多投两次，第10轮补中，可以再多投一次，因此第10轮最多能投3次。

那知道不同的情况，究竟是怎么计分的呢？ 

全中轮：10 + 接下来两次投掷击倒的木瓶数 + 前一轮的得分                                                                                 

补中轮：10 + 接下来一次投掷击倒的木瓶数 + 前一轮的得分    

其它轮：本轮两次投掷击倒的木瓶数 + 前一轮的得分

极限编程过程

这个过程我阅读了两遍，自己动手操作了一遍。我做那么多遍的原因是我刚开始没读懂，看不懂的我就多读几遍。

编码之前先讨论需求，为实现这个程序需要定义的模块(此例子中是定义Game, Frame,Throw类)，之后再进行编码工作。编码工作则是以测试开始，先考虑“其它轮”的计分，再逐渐增加“全中轮”，“补中轮”的测试和代码实现，最后再对已经能正常工作的代码进行重构。相同职责的代码放到同一个类里面，并对类里面的代码进行整理，继而产生scorer类。这个是重构的原则吧。

现在的工作方式vs极限编程方式

看完这章，也在脑海里过一遍我现在的工作方式，有不同的地方，也有难以做到的地方。

1 结对编程的方式无法实现。现在基本上是每个人都有自己的带着截止日期的任务，而且每个人只熟悉自己手头上的任务，在加上项目组并不推崇“结对编程”这种方式，所以结对编程在工作中没办法实现。

2 编码工作并不是测试为驱动。很多时候都是先把开发任务完成之后才去决定我要造什么样的单元测试去证明代码逻辑实现没有错，先想测试再去完成开发我觉得还蛮难的。

3 代码不经常重构。 现在项目希望每个开发也要做qa的工作，所以很多时候，开发任务完成，单元测试完成，就要去折腾qa的任务。感觉没有时间考虑重构这件事，虽然我知道这个是不对的。

可以改进的地方

1 在以后的工作中，尝试以测试为驱动的开发。在编码之前，提前考虑好客户可能的调用方式，并这对这个方式去些单元测试，一开始代码没有实现，单元测试肯定无法通过，随后再实现代码，让单元测试工作。以测试为驱动的开发对自己的挑战蛮大的。

2 要重构代码。我觉得这个可以在代码开发过程中完成，仔细斟酌变量和方法的命名，把经常使用的代码抽取出来形成一个类。

总结

阅读完这章学习了很多，但是我现在只能想到这些改进的点。在以后的工作中还是要多思考，不要偷懒，多去关注好的设计和优化方案。