【总结】《敏捷中国十八年目睹之怪现状》读后感

1. 如何做到“测试驱动”
2. TDD是什么，如何执行
3. 既有项目如何优秀的重构
4. 需求分析如果不是如文中的反例那样，正确规范的是如何做
5. 持续集成具体如何落地，Java/SSM框架/纯内网环境下如何实现
6. 看书《敏捷软件开发》《敏捷中国史》《测试驱动开发》，了解“敏捷宣言”、“测试驱动”，“Scrum”
7. 文中需求管理、配置管理、项目管理、质量管理四个小结的例子在身边均真实存在，对应的正确实践方法是什么？ 

 

《极限编程-阅读笔记》

1.  缺陷管理，发现Bug，必须创建验收测试。

每次发现Bug，需要建立相应的测试以防止Bug再现。产品中的Bug，需要写一个验收测试来防止再次出现。发现Bug后，不要急于着手调试，首先为其创建一个验收测试，这样可以帮助客户简洁地定义问题、并将问题传达给程序员。有一个失败的测试在手，程序员就可以专注于修复这个测试，并且清晰知道问题是否得到了修复。

有了一个失败的验收测试之后，开发人员可以创建单元测试，从深入源代码的角度展示缺陷的存在。失败的单元测试可以给开发人员更加迅速的反馈，以便知道Bug是否被修复了。当单元测试100%通过后，我们就可以再次运行验收测试，确认Bug是否得到修复。

http://www.extremeprogramming.cn/content/xp/bug.html

2. 人员流动，新人与老人结对编程有利于培养新人和让团队都融入项目，不会出现工作饥饿和工作过度。

如果每个人都能对系统的各个部分有充分的了解，团队工作起来就会更顺畅，也会更有灵活性。这样，整个团队都能够高效地产出，而不会只依赖某几个成员承担大部分工作、其他人无事可做。每位开发者都可以工作在系统的任何角落上。果真能做到如此均衡灵活的人员分配，想必也是每位管理人员日思夜想的期盼吧。

http://www.extremeprogramming.cn/content/xp/move-people-around.html

3. 简单设计，仅对必须实现的功能编写代码，复杂的方案总可分解成简单的方案或者在一次次的重构中涌现，所以保持简单设计是既短期实用，又长期有效。

简单的设计往往在项目开展一段时间后才会涌现。促成简单设计的最佳做法是：一面仅为必须实现的功能编写代码，一面积极为简单的设计寻求必要的知识。一旦对设计有了新的理解，就可以渐进地往那个方向进行重构。

绝不在真正需要某项功能之前实现它，如此方能维护设计的长期简洁。即便如此也仍然要明白：保持简单的设计需下苦功，不可能一蹴而就。

http://www.extremeprogramming.cn/content/xp/simple-design.html

 

---

题外话：

最近看了挺多 单元测试，持续集成，软件再工程，重构类的书和博客，发现大多都是.Net技术体系的，而Java体系的文章反而很少，很有意思，不知道为什么。

 

阅读书籍：

《软件再工程》，机械工业出版社，华章图书。讲述如何再工程.Net项目，虽然不是Java体系，但原理和方法是通用的。