《高效程序员的45个习惯——敏捷开发修炼之道》读书笔记&感悟

概述

可以输出的才是自己的！

本专栏为最近阅读经典书籍《高效程序员的45个习惯——敏捷开发修炼之道》的读书笔记，书已读大半，有种相见恨晚的感觉！尤其是改观了自己对于单元测试的认识。
持续更新中，欢迎各位朋友交流与分享。

日志

2021/8/14, 更新第8章笔记以及习惯39, 40, 41, 42, 43, 44, 45。
2021/8/12, 更新第8章笔记以及习惯38
2021/8/9，更新第九章笔记。
2021/8/6, 更新第七章笔记，及习惯33，34，35.
2021/8/3, 更新 第七章 习惯[36 报告所有的异常], [37 提供有用的错误信息]
2021/8/2，更新 第七章 习惯[35 对问题各个击破]

7 敏捷调试

无论再敏捷的设计，还是再敏捷的编码，都不能保证你的软件没有bug。如果有这个保证，估计也是痴人说梦。

软件出了bug怎么办？还能怎么办？

盘它

开始debug啊，复现问题，分析问题产生原因，找到问题产生所在的模块，分析软件修改方案，并且验证。

上述过程是调试解决BUG的一般过程。什么才是敏捷方式的调试呢？[The PP]推荐了习惯33 ~ 37。我们来看下这些习惯都是什么？

• 习惯33 记录解决问题的日志

  从经验累积的角度来实现敏捷调试，即记录问题解决日志，解决再次发生的问题。具体见33 记录解决问题的日志

• 习惯34 警告就是错误

  从问题预防发生的角度来谈敏捷调试的方法，对于我们平常不重视的警告，就是一个定时炸弹，要提前处理，不要等到爆炸的时候再去解决问题。减少问题的发生，这也是一个敏捷调试的办法。具体见34 警告就是错误。

• 习惯35 对问题各个击破
  分而治之，逐步缩小问题排查的范围，更容易找到问题发生的根本原因。具体见35 对问题各个击破。

• 习惯36 报告所有的异常

  习惯36 从软件设计的角度来实现敏捷调试，包括报告异常信息，不过滤异常信息，让调用者调用接口知道发生了什么，不要无返回值，或者只返回一点点信息，调用者了解更多信息，在发生问题后，更容易定位问题发生的根本原因。具体见36 报告所有的异常

• 习惯37 提供有用的错误信息
  习惯37 紧接习惯36，从软件设计的角度来实现敏捷设计。是为了解决提供什么调试信息的问题，以方便工程师在出现问题的时候，有更多的有效信息，来解决问题。具体见37 提供有用的错误信息

8 敏捷协作

我不禁发挥了自己的全部能力，还将我所仰仗的的人的能力发挥到机制。

时代背景：

只要是具有一定规模的项目，就必须要一个团队，靠单打独斗在车库里面开发出一个完整产品的日子早已不再。 注：书中虽这么说，不排除牛人的存在，但团队合作开发是时代的趋势。

团队合作和单兵作战时完全不同的。 一个人会突然发现，自己的行为会对团队以及整个项目的生产效率和进度产生影响。

团队合作提出的问题：

• 如何一起有效的工作
• 如何互动
• 如何管理他们的活动

全体成员的行动必须要与项目相关，反过来每个人的行为又会影响项目的环境。

高效协作是敏捷的基石。

敏捷协作的目标：

所有的团队成员全新投入到项目中，并且大家一起向着正确的方向努力。

• 敏捷协作习惯

  • 38 定期安排会面时间

  面对面会议，仍是最有效的工作方式， 具体见38 定期安排会面时间

  • 39 架构师必须写代码

  每个人都投入到开发工作中去，团队中的灵魂人物——架构师不能离开战场去后方，要在一线，才能做出有效的设计方案，根据上游变化，保持可逆性，保持迭代。具体见39 架构师必须写代码

  • 40 实行代码集体所有制

  整个团队都是项目工作的一部分，实行代码集体所有制，以保证任何团队成员的缺席不会对项目造成影响。具体见40 实行代码集体所有制

  • 41 成为指导者

  团队中一个人的知识，经常可以解决另外一个团队成员的问题。具体见41 成为指导者

  • 42 允许大家自己想办法

  帮助团队不断成长， 授之以鱼不如授之以渔。具体见42 允许大家自己想办法

  • 43 准备好后再共享代码
    不用未完成的工作给团队成员造成麻烦, 尤其是代码。具体见43 准备好后再共享代码
  • 44 做代码复查
    工作输出保证要有人复查，尤其代码，代码复查复查什么，什么时候进行，怎么复查。见44 做代码复查
  • 45 及时通报进展与问题
    不要到最后要交付的时候，再说自己完不成工作，解决不了问题。要有预判。在平常工作中，让大家了解彼此的进度、遇到的问题，以及在开发过程中发现有意思的东西。具体见45 及时通报进展与问题

9 尾声——走向敏捷

敏捷的精髓在于实践！纸上觉来终觉浅，觉知此事要躬行。
学习了这么多敏捷程序员的习惯，应该实践起来，第一步如何迈出去？chapter 9 给出了作者的一些实践经历，具体见9 尾声——走向敏捷。
不同的团队，不同软件开发过程，遇到的问题是不一样的，就像感冒还有热感冒，凉感冒。没有一个放之四海而皆准的药方。具体问题还是要具体分析，准确的抓住项目开发过程的主要矛盾，开展思维风暴，找到属于自己的药方，才能治好自己的症状。