想了一下，决定将读书的历程通过日期的形式记录下来，评论部分就放读书的讨论和感想。
2005-06-01:
这几天公司项目不紧张，终于可以有时间看看这些好书，我的心情是格外高兴的。又一次拿起《敏捷软件开发－原则、模式与实践》，我的心情是比较激动的，在一年前买了这本书，草草的看了一遍，但不能将里面的精髓用到实际的工作之中，所以很多部分只是了解一，二。一点也不系统，现在工作了，而且公司也给了我空间和时间，于是想好好研读一下，将学和做结合起来。
前言部分引用了《人件》中的一句话：“人与人之间的交互是复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面”。他强调了人在软件开发中的重要性。确实，软件行业和其他行业是有所不同的，是知识密集型的劳动，对员工的技能，素质等要求都是很高的。我们不能将软件开发人员当作机器，认为软件开发人员就是流水线上的工人，项目按流程来，各个部分干好自己的事情就可以了。
第一章又有一句德国诗人海因里希·海涅的明言：“教堂尖顶上的风标，即使由钢铁制成，如果不懂的顺应风势的艺术，一样会被暴风立即摧毁”。
这句话很好的诠释了软件如果没有面对变化的能力，那么在刚进入市场、甚至还没有进入市场时就已经失败了。事实就是这样的，我们现在经常在网络上，电视上看到IBM的广告语：随需应变。如何才能提高软件的应变能力，如何才能发现软件的变化方向，这些知识在《敏捷软件开发－原则、模式与实践》一书中都得到了解答。
敏捷是如何提出的呢？在以前，专家们为了更好的解决软件开发的困难，制定了软件开发方法，这些方法是结合原来软件的失败得出的解决方案，并把他们抽象成条条框框。并且确实使软件开发质量提高了，但是专家们么有想到软件的变化越来越快，开发人员用原来的方法已经不能解决问题，于是，专家又在原来的方法的基础上再加上一些条条框框。久而久之，方法越来越庞大，不仅不能很好的解决软件开发问题，而且还束缚了软件的开发，使软件开发延加长。这种情况的严重性引起了专家们的注意，因此,他们制定了“敏捷宣言”，内容如下：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
2005-06-02
今天看了《敏捷软件开发－原则、模式与实践》的第二章，觉得每次看觉的讲的相当不错，但总觉得里面的东西过于理想化，几乎没有哪个软件公司是可以完全做到的。但我想大师说的肯定有大师的道理，如果我们有些条件做不到，应该有一些合适的替代方法，但是这些替代方法有的我是想不到的，希望有经验的程序员给于指点。下面我就把第二章的每一点内容谈谈自己的想法。
1：“客户作为团队成员”。
我觉得这一点在中国是很难做到的，大部分客户都没有软件的知识，他们认为只要和开发人员开个会，将需求讲清楚，再给一定的时间，软件自然而然的就完成的。实际情况不是这样，需要客户紧密的和开发人员在一起，随时指出开发人员对项目理解的错误，同时通过软件的慢慢成型，可以更清楚的知道自己想要什么样的软件。但是客户有自己的工作，而且工作强度也不会小。更有甚者是客户可能同时需要几个软件系统，正在和不同的软件团队打交道。我们该如何让客户充分的加入到我们的开发队伍之中呢?我现在没有想到更好的办法，但是可以通过加强团队自己对客户所在行业的理解程度，来弥补客户无法加入团队的不足。现在很多之名的解决方案提供商之所以可以为各行业提供解决方案，是因为他们拥有一批对各行业业务都十分了解的精英。我们公司是做银行业务的，在准备招标一个项目之前，会请银行的顾问给我们充分的讲解该业务相关的专业知识，我觉得这一点确实做的不错，在这里说出来。业希望大家能够说说自己公司在这方面是如何做的。
2：“用户素材”。
这一点讲的是在做需求是只需要做到能够估算他的程度就够了。我理解这句话的意思，是说软件的需求细节在开发过程之中是会随时改变的，如果在做需求是过分的追求设计，那么就有可能做无用功，还有可能延误项目的开发时间。但认为要想做到这一点是很不容易的。这需要丰富的项目经验，可以知道什么情况是分析的不足，什么是过分的分析。但在这一点上我是没有经验的，希望大家指点。
3：“结对编程”。
这一点说了两个程序员一起编程，一个编码，一个在方便发表意见并检查错误，隔一段时间互换一下角色，这样在效率上远远大于两个人单独使用一台PC编程的效率。并且业会大大降低项目途中开发人员离开的风险。虽然这一点不难理解，但是想让公司充分接受也是不可能的，公司可能会说：“这个想法确实很好，但现阶段公司人手不多，结对相当于又减少了一半的开发人员”。我也没有什么经验，只是在学校的软件开发组中这样的做过，觉得效果相当好。很希望得到老板的支持。
4：“重构”。
这一点是我这次看书印象最深的一点，说的是我们的代码是在软件开发过程之中不断更改的，有经验的程序员应该知道，在项目初期，我们的设计都是简单，明了的。但随着项目的进行，代码在不断的更改，拷贝。慢慢的代码就混乱了。那么这一点告诉我们要定期的整理代码，使代码总保持着清晰的结构和风格。在我们每次实现一个功能后，我们应该立即优化这部分代码，在每周进行一次代码的结构调整，这样，最后的代码才是健壮的，易于维护和调试的。
5：“测试驱动的开发”。
讲的是先写测试用例，在写代码是测试用例通过。但我在其他说上看得并不一定要先写测试用例，也可以后写测试用例。测试驱动开发主要的好处就是可以开发出方便测试的代码，是测试工作简单、高效。不过想写出好的测试用例也是学校很深的功底的，这一点不是理解就可以的。
今天就说这么多，提了很多问题，希望得到大家的解答
待续... ...