高效程序员的45个习惯

以下来自我的 Practices of an Agile Developer 笔记

书籍简介

Practices of an Agile Developer: Working in the Real World, by Andy Hunt, Venkat Subramaniam, published in 2005

中文版：高效程序员的 45 个习惯：敏捷开发修炼之道，2010 出版

本书是 Pragmatic Programmers 系列书籍，作者Andy Hunt 是Pragmatic Programmers 的创始人，也是敏捷宣言的起草人之一，另著有《程序员修炼之道：从小工到专家》、《单元测试之道 C# 版：使用 NUnit》。

相关网站： blogs.pragprog.com pragmaticprogrammer.com

6. 对团队投资

午餐会议

P32. 每个人都比你厉害，那太好了。有动力继续提高自己。

P33. 持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

7. 懂得丢弃

丢弃旧技术、方法和习惯，那些会影响生产力。现在，程序员的时间是稀缺资源。

不是完全忘记旧方法，而是要根据情况转变习惯。

9. 把握开发节奏

每天结束的时候，没有残留的代码、任务。不要把每天最后的尝试性的代码带到下一天，应重新开始。

P41. 时间盒：设定一个短时的期限，最终期限。不知道完成所有任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。如：番茄工作时间管理方法。

10. 让客户做决定

如果业务负责人（通常是客户）回答“我不知道”，也许是他们还没有想到那么远，也许是他们只有看到运行的实物才能评估出结果。

11. 让设计指导而不是操纵开发 [Important]

这是敏捷方法对传统方法，如 统一过程 (UP) 等，最具颠覆性的挑战之一，也体现了敏捷宣言中的：可工作的软件产品胜于面面俱到的文档。

Is Design Dead?, by Martin Fowler，是深入讨论本主题的一篇文章。

不做过度的设计，而非不做设计，请画关键工作图。

设计满足实现即可，不必过于详细。

反面示例：更新和维护详细的设计文档变成了主要工作。

战略设计 vs. 战术设计。CRC：类-职责-协作 卡片的设计方法，应用于战术设计。

P51. 完全无设计情景：深入编码只为了学习或创造原型，随后把这些代码扔掉。

P51. 在设计过程中学习是有价值的，但设计本身也许没有太大的用处。这里指，不可缺少设计过程，但不要巨细。

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

23. 度量真实的进度

如果时间表是为工资会计准备的，那么它就很难真实地反映工作完成状况。

随意用一个比率进行度量，如已完成 80%，是没有意义的。

应该测定还剩下多少工作量没有完成，如：估计用 40 小时，已开发 35 小时，认为还需另外 30 个小时。

待办事项 (backlog)

不要花费很多时间来了解你所花费的时间，而没有足够的时间进行工作。意思是，不要说我已工作了多少小时，而要说我已完成了多少个功能，即关注功能，而不是日程表。

Other Chapters

Ch6. 敏捷编码

25. 代码要清晰地表达意图 26. 用代码沟通 27. 动态评估取舍 28. 增量式编程 29. 保持简单 30. 编写内聚的代码 31. 告知，不要询问 32. 根据契约进行替换

Ch7. 敏捷调试

33. 记录问题解决日志 34. 警告就是错误 35. 对问题各个击破 36. 报告所有的异常 37. 提供有用的错误信息

Ch8. 敏捷协作

38. 定期安排会面时间 39. 架构师必须写代码 40. 实行代码集体所有制 41. 成为指导者 42. 允许大家自己想办法 43. 准备好后再共享代码 44. 做代码复查 45. 及时通报进展与问题

### 推荐序

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

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

- 内家武功招数：

```

迭代开发，价值优先

分解任务，真实进度

站立会议，交流畅通

用户参与，调整方向

结对编程，代码质量

测试驱动，安全可靠

持续集成，尽早反馈

自动部署，一键安装

定期回顾，持续改进

不断学习，提高能力

```

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

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

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

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

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

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

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

做事。

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

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

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

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

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

欲速则不达。

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

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

对事不对人。

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

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

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

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

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

排除万难，奋勇前进。

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

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

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

### 第三章 学无止境

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

跟踪变化。

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

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

对团队投资。

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

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

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

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

懂得丢弃。

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

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

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

把握开发节奏。

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

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

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

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

交付用户想要的软件。

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

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

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

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

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

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

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

合理地使用技术。

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

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

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

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

保持可以发布。

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

提早集成，频繁集成。

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

提早自动化部署。

使用演示获得频繁反馈。

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

使用短迭代，增量发布。

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

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

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

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

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

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

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

### 第五章 敏捷反馈

守护天使。

- coding feedback

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

先用它再实现它。

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

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

- Good design doesn’t mean more classes.

自动验收测试。

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

度量真实的进度。

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

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

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

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

倾听用户的声音。

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

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

### 第六章 敏捷编码

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

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

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

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

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

保持简单。

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

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

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

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

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

### 第七章 敏捷调试

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

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

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

对问题各个击破。

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

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

报告所有的异常。

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

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

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

定期安排会面时间。

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

```

昨天由什么收获？

今天计划要做哪些工作？

面临着哪些障碍？

```

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

实行代码集体所有制。

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

成为指导者。

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

允许大家自己想办法。

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

做代码复查。

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

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

及时通报进展与问题。

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

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

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

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

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