对《高效程序员的45个习惯》读书总结

截止到现在自己已经有了3年多的敏捷团队实践，包括有一年多的敏捷团队管理经验。个人对敏捷还是比较推崇的，但是必须要注意结合实际进行落地，否则就成了邯郸学步。其中我感觉落地的重点就是千万不要生搬硬套敏捷的实施条款，而是去理解其精髓去融汇贯通。恰好《高效程序员的45个习惯——敏捷开发修炼之道》就给了我们这么一个机会去深入了解敏捷的精髓，在第二次读此书之际我对书中内容进行了些总结归纳，分享给大家

第1章：什么是敏捷？

“不管路走了多远，错了就要重新返回。”

敏捷意味着可以快速适应变化。
敏捷开发宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
人员：它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都尽最大可能做好自己的工作。
开发需持续不断，持续地推进系统前进和完善。

一句话总结敏捷：敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

第2章：态度决定一切

“选定了要走的路，就是选定了它通往的目的地。”

在敏捷团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是在指责犯错者上面纠缠。
团队成员在一起工作，应互相帮助，而不是互相指责。
压力会迫使你走捷径，只看眼前利益，但是请记住：欲速则不达。
一个大型系统你自然不可能搞明白所有代码，但是你可以从更高的层面来了解大部分代码的功能。
对事不对人：在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。
工作中不感情用事是需要克制力的，而你需要能展现出成熟大度来。
做正确的事。要诚实，要有勇气去说出实情。

一句话总结：专业的态度应该着眼于项目和团队的积极成果。关注个人和团队的成长，围绕最后的成功开展工作。

第3章：学无止境

“即使你已经在正确的道路上，但如果只是停止不前，也仍然会被淘汰出局。”

如何才能跟上技术变化的步伐呢？
- 迭代和增量式的学习；
- 了解最新行情；
- 参加本地的用户组活动；
- 参加研讨会议；
- 如饥似渴的阅读；
你不需要精通所有技术，但要清楚知道行业的动向，从而规划你的项目和职业生涯。
一个学习型的团队才是较好的团队。
新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础，但不能依赖它们。
为了解决问题，你需要很好地了解系统的全局。
许多不成功的项目中，基本上都是随意安排工作计划，没有任何规律，那样的随机安排很难处理。项目开发需要有一致和稳定的节奏。

一句话总结：在一个企业化的社会中，只有一个人会为你负责——你自己。是否能跟上变化，完全取决于你自己。

第4章：交付用户想要的软件

“没有任何计划在遇敌后还能继续执行。”

业务应用需要开发者和业务负责人互相配合来开发。这种配合的感觉就应该像一种良好、诚实的工作关系。
设计可以分为两层：战略和战术。前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切的说，它应该只描述总体战略，不应该深入到具体的细节。
在考虑引入新技术或框架之前，你需要找到需要解决的问题，接下来考虑如下几个方面:
- 这个技术框架真能解决这个问题吗？
- 你将会被它拴住吗？
- 维护成本是多少？
保证你的系统随时可以编译、运行、测试、部署、演示。
提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
提早实现自动化部署。
使用演示获得频繁的反馈。
大部分用户都是希望现在就有一个够用的软件，而不是一年之后得到一个超级好的软件。
确定使产品可用的核心功能，然后把它们放在生产环境中，越早交到用户手里越好。
让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。

一句话总结：敏捷——成功的软件开发方法——取决于你识别和适应变化的能力。只有这样才有可能在预算之内及时完成开发，创建真正符合用户需求的系统。

第5章：敏捷反馈

“一步行动，胜过千万专家的意见。”

为了应对代码的变化，你需要持续获得代码健康状态的反馈：它是在做你期望的事情吗？最近一次修改有没有无意破坏了什么功能？这时你该带上守护天使——自动化单元测试。
进行单元测试的理由：
- 单元测试能及时提供反馈。
- 单元测试让你的代码更加健壮。
- 单元测试是有用的设计工具。
- 单元测试是让你自信的后台。
- 单元测试是解决问题时的探测器。
- 单元测试是可信的文档。
- 单元测试是学习工具。
人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。
只在有具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。
不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极的寻找问题，而不是等问题来找你。
我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。
如果能一直让下一步工作是可见的，会有助于进度度量。最好的做法就是使用待办事项（backlog）。
不管它是否是产品的bug，还是文档的bug，或是对用户社区理解的bug，它都是团队的问题，而不是用户的问题。
每一个抱怨的身后都隐藏了一个事实。找出真相，修复真正的问题。

一句话总结：从实践中得到反馈，确保你明确知道项目的正确状态，而不是主观臆测。

第6章：敏捷编码

“任何一个笨蛋都能够让事情变得越来越笨重、越来越复杂、越来越极端。需要天才的指点以及许多的勇气，才能让事情向相反的方向发展。”

开发代码时，应该注重可读性，而不是只图自己方便。
作为一个开发者，应该时刻提醒自己是否有办法让写出的代码更容易理解。
代码被阅读的次数要远超过被编写的次数，所以在编程时多付出一些努力来做好文档（利用代码本身；利用注释），会让你在将来受益匪浅。
与其花费时间去提升千分之一的性能表现，也许减少开发投入，降低成本，并尽快让应用程序上市销售更有价值。总而言之，要想应用成功，降低开发成本和缩短上市时间同样重要。
对代码做一些持续而有用的事情，而不是做一段长时间的编程或重构。
开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲，不要进行过分设计，也不要将代码复杂化。
让类的功能尽量集中，让组件尽量小。
保持系统灵活性的关键方式，是当新代码取代原有代码之后，其他已有的代码不会意识到任何差别。