《高效程序员的45个习惯——敏捷开发修炼之道》读书总结

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

---

第1章：什么是敏捷？

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

• 敏捷意味着可以快速适应变化。

• 敏捷开发宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。

• 人员：它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都尽最大可能做好自己的工作。

• 开发需持续不断，持续地推进系统前进和完善。

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

第2章：态度决定一切

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

• 在敏捷团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是在指责犯错者上面纠缠。

• 团队成员在一起工作，应互相帮助，而不是互相指责。

• 压力会迫使你走捷径，只看眼前利益，但是请记住：欲速则不达。

• 一个大型系统你自然不可能搞明白所有代码，但是你可以从更高的层面来了解大部分代码的功能。

• 对事不对人：在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。

• 工作中不感情用事是需要克制力的，而你需要能展现出成熟大度来。

• 做正确的事。要诚实，要有勇气去说出实情。

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

第3章：学无止境

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

• 如何才能跟上技术变化的步伐呢？

  • 迭代和增量式的学习；

  • 了解最新行情；

  • 参加本地的用户组活动；

  • 参加研讨会议；

  • 如饥似渴的阅读；

  
  

• 你不需要精通所有技术，但要清楚知道行业的动向，从而规划你的项目和职业生涯。

• 一个学习型的团队才是较好的团队。

• 新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础，但不能依赖它们。

• 为了解决问题，你需要很好地了解系统的全局。

• 许多不成功的项目中，基本上都是随意安排工作计划，没有任何规律，那样的随机安排很难处理。项目开发需要有一致和稳定的节奏。

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

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

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

• 业务应用需要开发者和业务负责人互相配合来开发。这种配合的感觉就应该像一种良好、诚实的工作关系。

• 设计可以分为两层：战略和战术。前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切的说，它应该只描述总体战略，不应该深入到具体的细节。

• 在考虑引入新技术或框架之前，你需要找到需要解决的问题，接下来考虑如下几个方面:

  • 这个技术框架真能解决这个问题吗？

  • 你将会被它拴住吗？

  • 维护成本是多少？

  
  

• 保证你的系统随时可以编译、运行、测试、部署、演示。

• 提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。

• 提早实现自动化部署。

• 使用演示获得频繁的反馈。

• 大部分用户都是希望现在就有一个够用的软件，而不是一年之后得到一个超级好的软件。

• 确定使产品可用的核心功能，然后把它们放在生产环境中，越早交到用户手里越好。

• 让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。

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

第5章：敏捷反馈

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

• 为了应对代码的变化，你需要持续获得代码健康状态的反馈：它是在做你期望的事情吗？最近一次修改有没有无意破坏了什么功能？这时你该带上守护天使——自动化单元测试。

• 进行单元测试的理由：

  • 单元测试能及时提供反馈。

  • 单元测试让你的代码更加健壮。

  • 单元测试是有用的设计工具。

  • 单元测试是让你自信的后台。

  • 单元测试是解决问题时的探测器。

  • 单元测试是可信的文档。

  • 单元测试是学习工具。

  
  

• 人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。

• 只在有具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。

• 不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极的寻找问题，而不是等问题来找你。

• 我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。

• 如果能一直让下一步工作是可见的，会有助于进度度量。最好的做法就是使用待办事项（backlog）。

• 不管它是否是产品的bug，还是文档的bug，或是对用户社区理解的bug，它都是团队的问题，而不是用户的问题。

• 每一个抱怨的身后都隐藏了一个事实。找出真相，修复真正的问题。

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

第6章：敏捷编码

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

• 开发代码时，应该注重可读性，而不是只图自己方便。

• 作为一个开发者，应该时刻提醒自己是否有办法让写出的代码更容易理解。

• 代码被阅读的次数要远超过被编写的次数，所以在编程时多付出一些努力来做好文档（利用代码本身；利用注释），会让你在将来受益匪浅。

• 与其花费时间去提升千分之一的性能表现，也许减少开发投入，降低成本，并尽快让应用程序上市销售更有价值。总而言之，要想应用成功，降低开发成本和缩短上市时间同样重要。

• 对代码做一些持续而有用的事情，而不是做一段长时间的编程或重构。

• 开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲，不要进行过分设计，也不要将代码复杂化。

• 让类的功能尽量集中，让组件尽量小。

• 保持系统灵活性的关键方式，是当新代码取代原有代码之后，其他已有的代码不会意识到任何差别。

一句话总结：在编写代码时，每天付出一点小的努力，可以避免代码“腐烂”，并且保证应用程序不至变得难以理解和维护。

第7章：敏捷调试

“你也许会对木匠那毫无差错的工作印象深刻。但我向你保证，事实不是这样的。真正的高手只是知道如何亡羊补牢。”

• 把你曾经遇到的棘手问题的解决方案记录下来，方便下次使用。不要在同一个地方跌倒两次，也不要付出更多地时间成本查找曾经的解决方案。

• 尽量将编译器的警告视为错误来解决，但实际中有些编辑器或第三方库会产生一些无法也不必消除的警告，你需要仔细区分。

• 识别复杂问题的第一步，是将他们从大型系统中分离出来。

• 处理或是向上传播所有的异常，而不是忽略或者压制。

• 一方面要提供给用户清晰、易于理解的问题描述和解释；另一方面还要提供关于错误的详尽技术细节来方便开发人员定位解决问题。

一句话总结：即使运作得最好的敏捷项目，也会发生错误，你所要做的就是提高自己的调试能力去“亡羊补牢”。

第8章：敏捷协作

“我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。”

• 使用站立会议，每个人都应该只回答下述三个问题：

  • 昨天有什么收获？

  • 今天计划要做哪些工作？

  • 面临着哪些障碍？

  
  

• 一个真正的架构师应该指导开发团队，提升他们的水平，以解决更为复杂的问题。架构师也应该参与代码编写，一个系统的设计者也应该亲自投入到实现中去。

• 实行代码集体所有制：版本管理系统，结对编程，代码评审都是手段。

• 分享自己的知识——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整体团队的实力。

• 作为一个指导者，告诉团队成员解决问题的方法，培养他们的思维和能力，而不是直接帮助他们解决。

• 及时通报进展与问题。让协作者和管理者了解项目的进度与问题。

一句话总结：项目的成功与否，依赖与团队中的成员如何一起有效的工作，如何互动，如何管理他们的活动。全体成员的行动必须要与项目相关，反过来每个人的行为又会影响到项目。