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

截止到如今本身已经有了3年多的敏捷团队实践，包括有一年多的敏捷团队管理经验。我的对敏捷仍是比较推崇的，可是必需要注意结合实际进行落地，不然就成了邯郸学步。其中我感受落地的重点就是千万不要生搬硬套敏捷的实施条款，而是去理解其精髓去融汇贯通。刚好《高效程序员的45个习惯——敏捷开发修炼之道》就给了咱们这么一个机会去深刻了解敏捷的精髓，在第二次读此书之际我对书中内容进行了些总结概括，分享给你们

---

第1章：什么是敏捷？

“无论路走了多远，错了就要从新返回。”

• 敏捷意味着能够快速适应变化。

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

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

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

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

第2章：态度决定一切

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

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

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

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

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

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

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

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

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

第3章：学无止境

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

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

  • 迭代和增量式的学习；

  • 了解最新行情；

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

  • 参加研讨会议；

  • 如饥似渴的阅读；

  
  

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

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

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

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

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

一句话总结：在一个企业化的社会中，只有一我的会为你负责——你本身。是否能跟上变化，彻底取决于你本身。

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

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

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

• 设计能够分为两层：战略和战术。前期的设计属于战略，一般只有在没有深刻理解需求的时候须要这样的设计。更确切的说，它应该只描述整体战略，不该该深刻到具体的细节。

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

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

  • 你将会被它拴住吗？

  • 维护成本是多少？

  
  

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

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

• 提前实现自动化部署。

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

• 大部分用户都是但愿如今就有一个够用的软件，而不是一年以后获得一个超级好的软件。

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

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

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

第5章：敏捷反馈

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

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

• 进行单元测试的理由：

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

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

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

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

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

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

  • 单元测试是学习工具。

  
  

• 人们不编写单元测试的不少借口都是由于代码中的设计缺陷。一般，抗议越强烈，就说明设计越糟糕。

• 只在有具体理由的时候才开始编码。你能够专一于设计接口，而不会被不少实现的细节干扰。

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

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

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

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

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

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

第6章：敏捷编码

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

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

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

• 代码被阅读的次数要远超过被编写的次数，因此在编程时多付出一些努力来作好文档（利用代码自己；利用注释），会让你在未来受益不浅。

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

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

• 开发人员更应该为本身可以建立出一个简单而且可用的设计而骄傲，不要进行过度设计，也不要将代码复杂化。

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

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

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

第7章：敏捷调试

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

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

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

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

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

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

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

第8章：敏捷协做

“我不只发挥了本身的所有能力，还将我所仰仗的人的能力发挥到极致。”

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

  • 昨天有什么收获？

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

  • 面临着哪些障碍？

  
  

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

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

• 分享本身的知识——付出的同时便有收获。还能够激励别人得到更好的成果，并且提高了总体团队的实力。

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

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

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