高效程序员的45个习惯：敏捷开发修炼之道 阅读笔记1

这月开始阅读由苏帕拉马尼亚姆（美）、亨特（美）编著的高效程序员的45个习惯：敏捷开发修炼之道

作为一名编程人员我们必须要有自己的准则 这本书列下了45个习惯 这对于我们有很好的帮助

序号

名称

具体描述

扩展

 

态度决定一切

 

 

1

做事

把重点放到解决问题上，而不是指责人上。

 

2

欲速则不达

不要陷入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。

 

3

对事不对人

把重点放在我们解决了问题，而不是谁的主意更好。

1.没有最好，只有更合适。

2.你不需要很出色才起步，但是你必须起步才能更出色。

3.三个臭皮匠赛过诸葛亮。

4

排除万难，奋勇前进

做正确的事，要诚实，要有勇气去说出实情。有时这样做很困难，所以我们要有足够的勇气。

 

 

学无止境

 

 

5

跟踪变化

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

1.迭代和增量式学习

2.了解最新行情

3.参加本地的用户组活动

4.参加研讨会议

5.如饥似渴的阅读

6

对团队投资

提供你和团队学习得更好平台

1.持续、小步前进才是敏捷。稀少、间隔时间长不是敏捷。

7

懂得丢弃

学习新东西，丢弃旧的东西

1.敏捷的根本之一就是拥抱变化。既然变化是永恒的，你有可能一直使用相同的技术和工具吗？

2.意识到你还在使用过时的方法；真正的丢弃旧习惯。

8

打破砂锅问到底

不能只满足别人告诉你的表面现象。要不停地问知道你明白问题的根源。

 

9

把握开发节奏

保持事件之间稳定重复的间隔，更容易解决常见的重复任务。

1.一点点成功也是一个很大的激励，小儿可达到的目标会让每个人全速前进。

 

交付用户想要的软件

 

 

10

让客户做决定

用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。

1.记录客户做出的决定，并注明原因。

11

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

设计指引你向正确的方向前进，他不应该标识具体的路线。

1.此阶段提出的设计只是基于你目前对需求的理解而已。一旦开始，一切都会改变。

2.设计可以分为两层，战略和战术。前期的设计属于战略，具体实现属于战术。

3.好的设计应该是正确的而不是精确的。

4.计划是没有价值的，但计划的过程是必不可少的。

5.复杂的建模工具只会使你分散精力，而不是启发你的工作。

12

合理的使用战术

根据需要选择技术，而不是单纯为了学习

 

13

保持可以发布

保证你的系统随时可以进行编译、运行、测试并立即部署。

1.在本地运行测试、检查最新代码是否冲突、提交代码

14

提早集成、频繁集成

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

1.一般需要一天好几次

2.成功的集成就意味着所有单元测试不停地通过。

15

提早实现自动化部署

使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。

 

16

使用演示获得频繁反馈

在开发的时候，要保持应用可见。每隔一周或两周，邀请所有客户，给他们演示最新完成的功能，积极获得他们的反馈。

 

17

使用短迭代，增量发布

发布最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。

1.大部分客户都是希望有一个能够用的软件，而不是一年之后得到一个好软件。

2.没规定迭代完成后必须紧挨着下一个迭代，可以进行一周的维护。

18

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

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

1.提议做一个系统最初的、小的和有用的部分。

2.第一个迭代结束时客户有两个选择，继续或取消。

3.如此反复。

 

敏捷反馈

 

 

19

守护天使

使用自动化的单元测试

1.单元测试能够及时提供反馈

2.单元测试能够使你的代码更加健壮

3.单元测试是有用的设计工具

4.单元测试是让你自信的后台

5.单元测试是解决问题时的探测器

6.单元测试是可信的文档

7.单元测试是学习工具

20

先用它再实现它

将TDD作为设计工具，它会为你带来更简单更有效的设计

1.测试驱动开发

21

不同环境，就有不同问题

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

 

22

自动验收测试

为核心的业务逻辑创建测试。让你的用户单独验证这些测试，要让他们仙一般的测试哟眼可以自动运行。

 

23

度量真实的进度

不要用不恰当的度量来欺骗值得或者团队。要评估那些需要完成的待办事项。

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

24

倾听用户的声音

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

 

 

敏捷编码

 

 

25

代码要清晰地表达意图

要编写清晰的而不是讨巧的代码。

每个人都能写出能让机器运行的代码，但不是每个人都能写出能让人看懂的代码。

26

用代码沟通

在代码可以传递意图的地方不要使用注释。

使用细心选择，有意义的命名。

用注释描述代码意图和约束。

 

27

动态评估取舍

考虑性能、便利性、生产力、成本和上市时间

1.过早的优化是万恶之源

28

增量式编程

在很短的编辑/构建/测试循环中编写代码

 

29

保持简单

开发可以工作的、最简单的解决方案

1.简单不是简陋

30

编写内聚的代码

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

 

31

告知，不要询问

将命令和查询分开来

 

32

根据契约进行替换

通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。

针对is-a关系用继承

针对has-a或use-a关系使用委托

 

敏捷调试

 

 

33

记录解决问题的日志

维护一个问题及其解决方案的日志。

1.可以写技术博客

34

警告就是错误

将警告视为错误

 

35

对问题各个击破

在解决问题时，要将问题域与其周边隔离开，特别是大型应用中。

 

36

报告所有异常

处理或者是向上传播所有的异常，不要忽视它

 

37

提供有用的错误信息

提高更易于查找错误细节的方式。发生问题时，要尽量展示出多的支持细节，不过别让用户陷入其中。

 

 

敏捷协作

 

 

38

定期安排会面时间

使用立会。立会可以让团队达成共识。保证会议短小精悍而不跑题。

1.在会议中要给出具体的进度，而不要陷入细节之中。

39

架构师必须写代码

优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。

不知道系统的真实情况是无法展开设计的。

1.程序员在拒绝思考的同时，也就放弃了思考。

40

实行代码集体所有制

让开发人员轮换完成系统不同领域中不同模块的不同任务。

 

41

成为指导者

分享自己的知识

教学相长

42

允许大家自己想办法

指给他们正确的方向，而不是直接提供解决方案。

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

43

准备好后再共享代码

绝不要提交上未完成的代码。这应被视为玩忽职守。

 

44

做代码复查

通宵复查

捡拾游戏

结对编程

1.代码刚刚完成时，是寻找问题的最佳时机。如果放任不管，他也不会变得更好。

2.代码是否能被读懂和理解

3.是否有任何明显的错误

4.代码是否会对应用的其他部分产生不良影响

5.是否存在重复的代码

6.是否存在可以改进或重构的部分

45

及时通报进展与问题

不要等着别人来问项目状态如何

1.要经常抬头看看，不要老是低头写代码