《解析极限编程—拥抱变化》读后感

<!--[if !supportLists]-->1. <!--[endif]-->任何情况下，变化是绝对的，不变是相对的，我们不要抱怨变化的发生，重要的时要有应付变化的能力。但是那绝对不是听从别人来变化，而是自适应形势的变化。

<!--[if !supportLists]-->2. <!--[endif]-->四个变量：成本、时间、质量、范围

<!--[if !supportLists]-->3. <!--[endif]-->四个原则：沟通、简单、反馈、勇气

<!--[if !supportLists]-->4. <!--[endif]-->所有的实践：

<!--[if !supportLists]-->a) <!--[endif]-->计划游戏

<!--[if !supportLists]--> i. <!--[endif]-->业务人员需要决定的内容：

<!--[if !supportLists]-->1. <!--[endif]-->范围

<!--[if !supportLists]-->2. <!--[endif]-->优先级

<!--[if !supportLists]-->3. <!--[endif]-->版本的组成

<!--[if !supportLists]-->4. <!--[endif]-->发布的日期

<!--[if !supportLists]--> ii. <!--[endif]-->技术人员决定的内容：

<!--[if !supportLists]-->1. <!--[endif]-->估算

<!--[if !supportLists]-->2. <!--[endif]-->后果

<!--[if !supportLists]-->3. <!--[endif]-->过程

<!--[if !supportLists]-->4. <!--[endif]-->详细的日程计划

<!--[if !supportLists]-->b) <!--[endif]-->小版本

包含最有价值的业务需求。

<!--[if !supportLists]-->c) <!--[endif]-->隐喻

每个XP软件项目都是由一个全面的隐喻指导的。

<!--[if !supportLists]-->d) <!--[endif]-->简单设计 任何时候，正确的软件设计都具有下面的特征：

<!--[if !supportLists]--> i. <!--[endif]-->能够运行所有测试

<!--[if !supportLists]--> ii. <!--[endif]-->没有重复的逻辑

<!--[if !supportLists]--> iii. <!--[endif]-->陈述每个对程序员重要的意图。

<!--[if !supportLists]--> iv. <!--[endif]-->有尽可能少的类别和方法

<!--[if !supportLists]-->e) <!--[endif]-->测试

测试有助于增强程序员的信心；只对有可能出错的方法编写测试代码。

<!--[if !supportLists]-->f) <!--[endif]-->重构

<!--[if !supportLists]-->g) <!--[endif]-->结对编程

一个人思考实现此方法的最佳途径，另一个应更加偏重于战略性的角度进行思考。

<!--[if !supportLists]-->h) <!--[endif]-->集体所有权

只有代码的正式所有者才可以更改代码

<!--[if !supportLists]-->i) <!--[endif]-->持续集成

用一台计算机专门作集成工作

<!--[if !supportLists]-->j) <!--[endif]-->每周工作40小时

加班时项目存在严重问题的征兆

<!--[if !supportLists]-->k) <!--[endif]-->现场客户

指的是在系统投产后真正使用系统的人

<!--[if !supportLists]-->l) <!--[endif]-->编码标准

标准应强调沟通，并必须被整个团队自愿地采纳。

<!--[if !supportLists]-->5. <!--[endif]-->环境可能是最后被考虑到的东西，但是往往是非常重要的。

<!--[if !supportLists]-->6. <!--[endif]-->一定要保证一个小组在工作的时候不被干扰，否则就无法真正集中精力工作。

<!--[if !supportLists]-->7. <!--[endif]-->业务人员应该选择：

<!--[if !supportLists]-->a) <!--[endif]-->发布的范围或时间

<!--[if !supportLists]-->b) <!--[endif]-->提出的功能的相对优先权

<!--[if !supportLists]-->c) <!--[endif]-->提出的功能的确切范围。

<!--[if !supportLists]-->8. <!--[endif]-->开发组织必须确定：

<!--[if !supportLists]-->a) <!--[endif]-->实现各种功能所需的时间估算

<!--[if !supportLists]-->b) <!--[endif]-->各种可选的技术方案的后果估算

<!--[if !supportLists]-->c) <!--[endif]-->适合他们的个性、业务环境和公司文化的开发过程。

<!--[if !supportLists]-->d) <!--[endif]-->使用哪组时间来开始，即以使用什么样的进程来评审实践的效果和对变化进行试验。

<!--[if !supportLists]-->9. <!--[endif]-->制定计划的目的：

<!--[if !supportLists]-->a) <!--[endif]-->团结和组织开发团队

<!--[if !supportLists]-->b) <!--[endif]-->决定范围和优先级

<!--[if !supportLists]-->c) <!--[endif]-->估算成本和日程

<!--[if !supportLists]-->d) <!--[endif]-->让大家对系统的成功信心百倍

<!--[if !supportLists]-->e) <!--[endif]-->为反馈提供一个基准

<!--[if !supportLists]-->10. <!--[endif]-->制定计划的原则：

<!--[if !supportLists]-->a) <!--[endif]-->只制定下一个阶段所需的计划（计划需要不停的进行迭代）

<!--[if !supportLists]-->b) <!--[endif]-->接受的责任（责任只能被接受，而不能被强加）

<!--[if !supportLists]-->c) <!--[endif]-->负责实现的人进行估算

<!--[if !supportLists]-->d) <!--[endif]-->忽略个部分之间的依赖关系

<!--[if !supportLists]-->e) <!--[endif]-->为优先级作计划与为开发作计划的比较—谨记计划的目的

<!--[if !supportLists]-->11. <!--[endif]-->首要的一个问题是如何处理好人与人之间的关系，如果大家都能够做到权责明确，并且和睦相处，那么就具备了一个好团队所必须的一点。

<!--[if !supportLists]-->12. <!--[endif]-->业务方和开发方一定要做到相互信任，相互尊重。

<!--[if !supportLists]-->13. <!--[endif]-->如果能够把一项工作做的像是大家在共同进行一个游戏的话，大多数人都会乐意去做，而且很快乐。

<!--[if !supportLists]-->14. <!--[endif]-->配对编程是一种非常值得尝试的方式，可能一旦使用就会永远喜欢上这种方式。

<!--[if !supportLists]-->15. <!--[endif]-->最佳设计：能运行所有测试用例的最简单的设计

<!--[if !supportLists]-->16. <!--[endif]-->最简单的四种约束：

<!--[if !supportLists]-->a) <!--[endif]-->系统必须能够沟通任何你希望沟通的内容

<!--[if !supportLists]-->b) <!--[endif]-->系统不能够包含重复的代码

<!--[if !supportLists]-->c) <!--[endif]-->系统拥有尽可能少的类

<!--[if !supportLists]-->d) <!--[endif]-->系统拥有尽可能少的方法

<!--[if !supportLists]-->17. <!--[endif]-->软件的设计不可能没有变化，我们要做的是如何来面对并处理这些变化。在极限编程中，对于变化我们会返工，但是那就像是修改一篇文章一样，是一件令人快乐的事情。

<!--[if !supportLists]-->18. <!--[endif]-->不停的进行测试的方法似乎与制作网页的过程有些类似，在制作网页的过程中我们会不断的进行预览，查看在浏览其中实际的效果，而且所有的网页都是在持续集成的过程中完成的。

<!--[if !supportLists]-->19. <!--[endif]-->测试先行并不意味着我们在什么情况下都要先编写测试，然后编写代码。在Eclipse中，如果没有一定的代码，测试程序根本就是无法通过的，又来的什么正确不正确呢。而且，在编好了基本的类之后，使用自动化的工具来生成测试程序，在一定程度上也可以提高工作的效率，何乐而不为呢？

<!--[if !supportLists]-->20. <!--[endif]-->当一个人编写的程序里面Bug太多的时候，并不意味着他没有重视测试，大多时候是因为他还没有掌握测试的方法和工具。不知道怎样来测试，怎么可能做好呢？

<!--[if !supportLists]-->21. <!--[endif]-->在保存项目的时候，如果使用极限编程，应该不仅保存项目的源代码，而且要保存所有的测试用例。而且在写注释的时候，不仅在程序的源代码里面要有详尽的注释，在测试用例的代码中也应该做到这一点。