高效程序员的45个习惯

### 推荐序

- 没有动机，没有欲望，哪里来的毅力呢？

- 只有明白了“为什么做”，才能够解决“如何做”的问题。

- 内家武功招数：

```

迭代开发，价值优先

分解任务，真实进度

站立会议，交流畅通

用户参与，调整方向

结对编程，代码质量

测试驱动，安全可靠

持续集成，尽早反馈

自动部署，一键安装

定期回顾，持续改进

不断学习，提高能力

```

- 但，正所谓“练拳不练功，到老一场空”。学习招数和套路不难，难的是如何练就一身真功夫。内家功，以练内为主，内外结合，以动作引领内气，以内气催领动作，通过后天的修炼来弥补先天的不足。

- 它注重于北洋软件开发者的态度、原则、操守、价值观，即识、胆、气、劲、神是也。

### 第一章 敏捷——高效软件开发之道

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

- 你要不断从自己写的代码中得到反馈，并且使用自动化工具不断地构建（持续集成）和测试系统。

- 先难后易。我们首先要解决困难的问题，把简单的问题留到最后。

### 第二章 态度决定一切

做事。

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

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

- 只有在你对项目、工作、事业有一个专业的态度时，使用敏捷方法才会生效。

- 他们把精力直接放在解决问题上，而不是抱怨。

- 过程符合标准并不意味着是正确的。

欲速则不达。

- 优秀的程序员会更深挖一层，尽力去理解为什么这里必须要加1，更重要的是，他会想明白会产生什么其他影响。

- 所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。

对事不对人。

- 然而，好的软件开发作品和好的软件设计，都需要大量的创造力和洞察力。

- 你必须把重点放在解决问题上，而不是极力去证明谁的主意更好。

- 你不需要很出色才能起步，但是你必须起步才能变得很出色。

- “能欣赏自己并不接受的想法，表明你的头脑足够有学识。” — 亚里士多德

- 工作中不感情用事是需要克制力的，而你若能展现出成熟大度来，大家一定不会视而不见。

排除万难，奋勇前进。

- 绝妙的计划会因为勇气不足而最终失败。

- 你必须有勇气向前冲锋，做你认为对的事情。

- 如果你在压力下对代码质量作出妥协，你可以指出，作为一名开发者，你没有职权毁坏公司的资产（所有的代码）。

### 第三章 学无止境

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

跟踪变化。

- 你要正确把握自己投入的精力。

- 在做决策之前，你必须评估新技术的优势。开发一个小的原型系统，是对付技术狂热者的一剂良药。

对团队投资。

- 不同才能和背景的人混在一起，是一个非常理想的学习环境。

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

- 优秀的管理者会重用那些能提高其他团队成员价值的人。

- 坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

懂得丢弃。

- 在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。

- 打破旧习惯很难，更难的是自己还没意识到这个问题。

- 思维定式是经过多年摸爬滚打才构建成型的，已经根深蒂固，没有人可以很容易就丢弃它们。

把握开发节奏。

- 如果在你工作的时候没有一个固定的最终期限（例如一天的结束）， 就应该好好想想了。

- 许多的敏捷技巧来源于时间盒——设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。

- 鲨鱼必须不停地向前游，否则就会死亡。在这方面，软件项目就像是鲨鱼，你需要不停地前进，同时要清楚自己的真实进度。

- 如果开发节奏过于密集，你会精疲力竭的。一般来说，当与其他团队合作时，你需要减慢开发节奏。因此人们常说，互联网时代发展太快，有害健康。

交付用户想要的软件。

- 软件开发如战争，形势的变化快速而又剧烈。

- 使用短迭代，增量开发来帮助经常发布新功能，与用户的需求变化联系更紧密。

- 固定的价格就意味着背叛承诺。

让设计指导而不是操纵开发。

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

- 即使初始的设计到后面不管用，你仍需要设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程是必不可少的。”在设计过程中学习是有价值的，但设计本身也许没有太大的用处。

- 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力，而不是启发你的工作。

合理地使用技术。

- 你的代码写得越少，需要维护的东西就越少。

- 新技术就应该像是新的工具，可以帮助你更好地工作，它自己不应该成为你的工作。

- 如果你还没有足够的经验，不要急于决定使用什么技术。

- 不要开发那些你容易下载到的东西。虽然有时需要从最基础开发所有你需要的东西，但那是相当危险和昂贵的。

保持可以发布。

- 你有一个持续集成系统，可以自动集成并报告集成成果。

提早集成，频繁集成。

- 使用mock对象，它更容易控制，能够模仿需要的行为，使测试更加简单。

提早自动化部署。

使用演示获得频繁反馈。

- 没有人的思想和观点可以及时冻结，特别是项目的客户。

使用短迭代，增量发布。

- 软件开发不是精细化的制造业，而是创新活动。

- 对付大项目，最理想的办法就是小步前进，这也是敏捷方法的核心。

固定的价格就意味着背叛承诺。

- 主动提议先构建系统最初的、小的和有用的部分。挑选一系列小的功能，这样完成第一次交付应该不多于6~8周。向客户解释，这时候还不是要完成所有的功能，而是足够一次交付，并能让用户真正使用。

- 你的评估数据会在整个项目中发生变化——它们不是固定的。但是，你会觉得自信心在不断增加，你会越来越清楚每个迭代可以完成的工作。随着时间的推移，你的评估能力会不断地提高。

- 如果你对答案不满意，那么看看你是否可以改变问题。

- 如果你在完成第一个迭代开发之前，拒绝做任何评估，也许你会失去这个合同，让位于那些提供了评估的人，无论他们做了多么不切实际的承诺。

### 第五章 敏捷反馈

守护天使。

- coding feedback

- 不要放过任何一个失败的测试。

先用它再实现它。

- 先写测试有助于消除过度复杂的设计，让你可以专注于真正需要完成的工作。

- 什么是成功地实现特定功能的最低成本。

- Good design doesn’t mean more classes.

自动验收测试。

- 关键业务逻辑必须要独立进行严格的测试，并且最后需要通过用户的审批。

度量真实的进度。

- 判断工作进度最好是看实际花费的时间而不是估计的时间。

- 这里诚实非常重要，隐瞒真相毫无意义。

- 关注功能，而不是日程表。

- 一周工作40个小时，不是说你就有40个小时的编码时间。

倾听用户的声音。

- 对客户的那些愚蠢抱怨，你既不会生气，也不会轻视。你会查看一下，找出背后真正的问题。

- “它就是这样的。”这不是一个好的答案。

### 第六章 敏捷编码

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

- 想写出简单的代码要远比写出令人厌恶的、过分复杂的代码难得多。

- 开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过编写的次数，所以在编写的时候值得花点功夫让它读起来更加简单。实际上，从衡量标准来看，代码清晰程度的优先级应该排在执行效率之前。

- 在编写代码时，应该使用语言特性来提升表现力。

- 不要明日复明日。如果现在不做的话，以后你也不会做的。

保持简单。

- 不要让自己被迫进行过分设计，也不要将代码过分复杂化。

- 许多开发人员倾向于将投入的努力与程序复杂性混同起来。

- 开发人员更应该为自己能够创造出一个简单并且可用的设计而骄傲。

- 优雅的代码第一眼看上去，就知道它的用处，而且很简洁。但是这样的解决方案不是那么容易想出来的。这就是说，优雅是易于理解和辨识的，但是要想创建出来就困难得多了。

- 告知，不要询问。不要抢别的对象或者是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。

### 第七章 敏捷调试

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

- 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。

- 将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。

对问题各个击破。

- 单元测试带来的积极效应之一，是它会强迫形成代码的分层。如果不是这样，你会发现自己在修改bug之前，就已经陷入到整个系统中，徒然增加了压力，而且降低了工作效率。

- 在这些状况下，最好花一些时间把关注的代码提取出来，而且创建一个可让其工作的测试环境。

报告所有的异常。

- 像java中那样的检查异常会强迫你捕捉异常，或是把异常传播出去。

- 处理或者是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。

- 决定由谁来负责处理异常是设计工作的一部分。

定期安排会面时间。

- 要保证会议议题不会发散，每个人都应该只回答下述三个问题。

```

昨天由什么收获？

今天计划要做哪些工作？

面临着哪些障碍？

```

- 只能给予每个参与者很少的发言时间（大约两分钟）。

实行代码集体所有制。

- 任何人都可能遭遇到诸如车祸等突发的灾难事故，或者有可能被竞争对手雇佣。如果不向整个团队分享知识，反而增加了丧失知识的风险。

成为指导者。

- 为团队成员在寻求帮助之前陷入某个问题的时间设定一个时限，一个小时应该是不错的选择。

允许大家自己想办法。

- 用问题来回答问题，可以引导提问的人走上正确的道路。

做代码复查。

- 代码刚刚完成时，是寻找问题的最佳时机。

- 代码复查随着开发活动持续进行，而且每次针对的代码量相对较少。感觉复查就像是项目正在进行的一部分，而不是一种令人畏惧的事情。

及时通报进展与问题。

- 及时通报进展与问题，有情况发生时，就不会让别人感到突然，而且他们也很愿意了解目前的进展状况。

- 当经理或同事来询问工作进展、最新的设计、或研究状况时，不会感到头痛。

工作应该要有一个固定的最终期限，比如一天的结束，它会让你的工作有一个节奏，在每天下班的时候，提交所有的工作，开心手工，时间本身就是一个非常重要的反馈。

固定的价格意味着背叛承诺

低内聚性的代码会造成很严重的后果。假设有这样一个类，实现了五种完全不相干的功能。如果这5个功能的需求或细节发生了变化，这个类也必须跟着改变。如果一个类（或者一个组件）变化得过于频繁，这样的改变会对整个系统造成“涟漪效应”，并导致更多的维护和成本的发生。考虑另一个只实现了一种功能的类，这个类变化的频度就没有那么高。类似地，一个更具内聚性的组件不会有太多导致其变化的原因，也因此更加稳定。根据单一职责原则，一个模块应该只有一个发生变化的原因。