敏捷开发修炼之道

最近看了一本叫高效程序员的45个习惯，下面总结内容。

全书分为9个章节：

• 敏捷开发之道
• 态度决定一切
• 学无止境
• 交互用户想要的软件
• 敏捷反馈
• 敏捷编码
• 敏捷调试
• 敏捷协作
• 尾声：走向敏捷

第一章：敏捷开发之道

用原文的方法讲，敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

我想其实和学习任何事情都是一样的道理，实践出真知，不断地尝试和反馈，纠正自己的错误，这样容易推动进度，有目标性，效率也会更高。

第二章：态度决定一切

做事的态度非常重要，包括个人和团队。专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最终的成功开展工作。

1.做事

反例：“出了问题，第一重要的是确定元凶。找到那个白痴！一旦证实了是他的错误，就可以保证这样的问题永远不会再发生了”。

这个错误的观点很滑稽，但是从生活中也经常发现这种态度，比如出错了大家第一件事情就是找是谁的错，而不是想着解决问题的方法。

正确的做法：“把矛头对准问题的解决方法，而不是人。这是真正有用处的正面效应”。

勇于承认自己不知道的答案，这样让人感觉放心，一个重大的错误应该被视为一个学习而不是指责他人的机会。

平衡的艺术：

• “这不是我的错”，这句话不对。“这都是你的错”，更不对
• 如果你没犯过任何错误，那么说明你可能没有努力去工作（真是有道理！！！哈哈）
• 开发者和质量工程师争论某个问题是系统本身缺陷还是系统增强功能导致的，通常没什么意义，还不如赶紧去修复它
• 如果一个团队成员误解了一个需求、一个API，那么其他人可能也有相同误解
• 如果一个成员一再伤害团队，则他表现得很不职业，应该开掉他
• 如果大部分成员（尤其开发领导者）行为不职业，并且他们对团队目标都不感兴趣，你就应该离开这个团队

2.欲速则不达

反例：“你不需要真正理解那块代码，它只要能够工作就可以了。哦，只要在结果中加几行代码，他就可以工作了，干吧！就把那几行加进去，它应该可以工作”。

经常会遇到这种情况，出现一个bug，时间紧迫，通过加一行代码或者忽略那个列表最后一个条目，就可以工作（好像我也干过，欲哭无泪！！！）。但是接下来做法才能说明，谁是优秀程序员，谁是拙劣码农：

• 拙劣代码工人会不假思索完成改写，然后转向下一个问题；
• 优秀程序员会尽力去理解为什么这里+1，更重要是去想明白会产生说明其他影响；

因此，最好做到：

• 不要孤立地编码，实行代码复审，有利于代码更好理解和发现bug；
• 使用单元测试，项目可以分成更好管理的小块，还能直接阅读单元测试文档，更有利于理解代码模块，运行和使用代码；

平衡的艺术：

• 必须理解每一块的代码如何工作，但不需要成为专家，只要能够使用它有效工作就够了；
• 如果有成员宣布，某块代码其他人很难看懂，那么意味着任何人都很难维护它，需要修改它；
• 不要急于修复一段没有真正理解的代码；
• 对于大型系统，除了深入正在开发的模块，还需要从更高层了解大部分模块功能，理解系统各个功能块之间的交互

3.对事不对人

一个例子，当某人正在做一个新方案介绍时，下面有人说：“那样很蠢！”（也就暗示开发者也蠢），改进一下“那样很蠢，你忘记考虑它要线程安全。”，而最佳表达方式是：“谢谢，xx，但是我想知道，两个用户同时登录会发生什么情况？”

三种方式对应三种含义：

• 否定个人能力
• 指出明显缺点，并否定其观点
• 询问你的队友，并提出你的顾虑

对于团队决策需要做一下特殊技术：

• 设定最终期限，没有最好的方案，只有最好，在决策为难时，必须做出决策；
• 逆向思维，客观对待问题：先积极看到它的正面，然后再努力从反面去认识它；
• 设立仲裁人，仲裁人保证每个人都有发言机会，防止被明星员工操纵会议，及时打断假大空发言，如果没有积极参加这次讨论，你最好就退一步做会议监督者（咦，当我对问题不了解的时候，好像就是这么干的）；
• 支持已经做出的决定，无论谁定的方案，团队应该都努力完成，而不是关心谁的主意

4.排除万难，奋勇前进

发现某段代码太肮脏了，应该讲糟糕的代码放到一边，立刻重写。并且列出重写的理由，帮助你的老板和同事认清形势，并得到正确的解决方案。

第三章：学无止境

敏捷开发需要持续不断的学习和充电（所有行业都是，好吗！！）

5.跟踪变化

你能嗅到将要流行的新技术，知道它们已经发布或者投入使用。如果必须把工作切换到一种新的技术领域，你能做到。

平衡的艺术：

• 正确把握对新技术的投入精力
• 不可能精通每个技术，只要在某些方面成为专家，用同样的方法，很容易成为新领域的专家
• 要明白为什么需要这项新技术，它企图解决什么样的问题？可以被用在什么地方？
• 避免一时冲动情况下，只是想把新技术引入开发中，在做决策前，需要评估新技术的优势，开发一个小的原型系统

6.对团队投资

提供个人和团队学习的更好平台，例如通过午餐会议增进每个人的知识和技能，并且帮助大家聚集在一起进行沟通交流。

平衡的艺术：

• 一起读书，但是选好的书
• 尽量让讲座走入团队，如果午餐会议在礼堂中进行，还要使用幻灯片，那么减少了接触和讨论机会
• 坚持有规律讲座，持续、小步前进才是敏捷
• 如果有人因为吃饭缺陷，用美食诱惑他们
• 不要局限于纯技术主题，项目估算、沟通技巧非技术主题也可以

7.懂的丢弃

新技术会让人感到恐惧，毕竟需要学习很多东西。但是已有的技能和习惯为你打好了基础，但不能依赖它们。

8.打破砂锅问到底

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

9.把握开发节奏

项目开发需要一致和稳定的节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会更加容易

平衡的艺术：

• 在每天结束的时候，测试代码，提交代码，没有残留的代码
• 不要搞得经常加班
• 以固定、规律的长度运行迭代
• 如果开发过于密集，你就会筋疲力尽
• 有规律的开发节奏会暴露很多问题，让你有更多鼓起勇气的借口
• 就像减肥一样，一点点的成功也是很大的鼓励，小而可达到的目标会让每个人全速前进，庆祝每一次难忘的成功：共享没事和啤酒或者团队聚餐（我喜欢！！！！）

第四章：支付用户想要的软件

开发的目标应该由客户决定，因此为了让软件符合用户需求，要提早集成，频繁集成，使得代码一直保持可以发布，由于需要一次又一次给用户演示，因此应当提早实现自动化部署。

10.让客户做决定

开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。

平衡的艺术：

• 记录客户做的决定，并注明原因
• 不要用低级别和没价值的问题打扰繁忙的业务人员
• 不要随意假设低级别的问题不会影响他们的业务
• 如果业务负责人回答“我不知道”，这也是一个称心如意的答案，也许是他们还没想那么远，也许是他们只有看到运行的实物才能评估结果，尽可能给他们提供建议，实现代码的时候也要考虑可能出现的变化

11.让设计指导而不是操作开发

好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节，因此它是目标，而不是具体处方。

如果写得太具体有两个弊端，一是程序员没有代码决定权，只是翻译伪代码，没成就感；二是，花费太多时间，如果项目变动，或者规划有问题，就浪费了大量时间。

平衡的艺术：

• 在真正代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是一件危险的事情
• 白板、草图、便利贴都是非常好的设计工具，复杂的建模工具只会让你分散精力，而不是启发你的工作

12.合理地使用技术

根据需要选择技术，首先决定什么是你需要的，接着为这些具体的问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并真实地回答。

平衡的艺术：

• 如果没有足够经验，不要急于决定用什么技术，如果再做系统原型，演示给用户看时，可以用散列表代替数据库
• 每一门技术都有优缺点，需要清楚它的利弊
• 不要开发那些容易下载到的东西

13.保持可以发布

任何时候进行项目展示时，都能很自信毫不犹豫地给别人演示最新构建的软件。项目一直处于可以运行的稳定状态。

平衡的艺术：

• 做了一些大改动，需要一个月才能保证发布，这种情况应该只是例外，不能养成习惯
• 如果不得不让系统长期不可以发布，那么做一个分支版本

14.提早集成，频繁集成

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

平衡的艺术：

• 成功的集成就意味着所有的单元测试不停地通过
• 通常每天都要和团队其他的成员一起集成代码好几次。但是如果每次修改就集成，大部分时间花在集成而不是写代码，那么就是集成得太过频繁了
• 如果不够频繁，也许发现每天都在解决代码集成带来的问题，而不是专心写代码

15.提早实现自动化部署

一开始就实现自动化部署应用，使用部署系统安装你的应用，保证在不同的机器上用不同的配置文件测试依赖的问题。系统的安装或者部署应该简单、可靠及可重复。

16.使用演示获得频繁反馈

清晰可见的开发，在开发的时候保持应用可见（客户心中也要了解）。每隔一周或者两周，邀请所有客户，演示最新完成的功能，积极获得他们的反馈

17.使用短迭代，增量发布

短迭代让人感觉非常专注且具有效率。你能看到一个实际确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

平衡的艺术：

• 如果每个迭代周期不够用，要么任务太大，要么迭代周期太短（所以一定要把握自己的节奏和时间）
• 如果发布功能背离用户需求，多半是因为迭代周期太长了
• 增量的发布时必须的，并且能为用户提供价值

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

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

第五章：敏捷反馈

19.守护天使

使用自动化的单元测试，好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。

平衡的艺术：

• 人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常抗议越强烈，就说明设计越糟糕
• 不是测试越多质量就越高，测试必须要有效，如果测试无法发现任何问题，也许他们就是没有测试对路

20.先使用它再实现它

利用测试驱动开发作为设计工具，这样只有具体理由才开始编码，可以专注于设计接口，而不会被很多实现细节干扰

21.不同环境，就有不同问题

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

22.自动验收测试

为核心业务逻辑创建测试，让你的客户单独验证这些测试，要让它们像一般测试一样可以自动运行。

23.度量真实地进度

使用代办事项，使得下一步工作是可见的，有助于进度度量，而不是按照百分比安排。不要用不恰当的度量来欺骗自己或者团队，要评估那些需要完成的待办事项。（每天列清单果然是好习惯，再加番茄工作法，用来计时）

平衡的艺术：

• 时间单元不要太细或者太粗，6分钟或者一周都不合适（所以番茄工作法的半个小时，一个小时是OK的）
• 关注功能，而不是日程表
• 一周工作40个小时，实际上编码时间不足40个小时，还有会议、电话等时间

24.倾听用户的声音

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

平衡的艺术：

• 没有愚蠢的用户
• 只有愚蠢自大的开发用户
• “它就是这样的。”这不是一个好答案
• 如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补
• 用户可能阅读所有文档，但是也可能不会

第六章：敏捷编码

代码要清晰表达意图，项目是增量式开发，写程序也应该增量式编程。

25.代码要清晰地表达意图

要编写清晰地而不是讨巧的代码，向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明（让自己或者团队任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制）

平衡的艺术：

• 现在对你显而易见的事情，对别人可能并非如此
• 不要明日复明日，现在不做，以后你也不会做

26.代码沟通

用注释沟通，使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码

27.动态评估取舍

动态评估权衡，考虑性能、便利性、生产力、成本和上市时间。如果性能够了，就应该把注意力放在其他因素上，不要为了感觉上的性能提升或者设计的优雅，从而将设计复杂化。

28.增量式编程

在很短的编辑/构建/测试循环中编写代码，这要比花费长时间仅仅做编写代码的工作好得多，可以创建更加清晰、简单、易于维护的代码。

平衡的艺术：

• 如果构建和测试循环花费的时间过长，就不会希望经常运行它们。要保证测试可以快速运行
• 在编译和测试运行中，停下来想一想，并暂时远离代码细节，这是保证不会偏离正确方向的好办法
• 要休息就好好休息。休息时远离键盘（哈哈哈）
• 要像重构代码一样，重构测试，而且要经常重构测试

29.保持简单

开发可以工作的、最简单的解决方案，除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。

当你觉得所编写的代码中没有一行多余的，并且仍能交付全部功能时，这种感觉就对了。这样的代码容易理解和改正。

30.编写内聚的代码

让类的功能尽量集中，让组件尽量小，要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。

31.告知，不要询问

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

32.根据契约进行替换

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

平衡的艺术：

• 相对继承来说，委托更加灵活，适应力更强
• 如果不确定一个接口做出来什么样的承诺，或是有什么样的需求，那就很难提供一个对其有意义的实现了

33.记录问题解决日志

对解决的问题可以记录以下条目：

• 问题发生日期
• 问题简述
• 解决方案详细描述
• 引用文章或者网址
• 任何代码片段，设置或对话框截图

34.警告就是错误

嵌入带有警告的代码，就跟嵌入有错误或者没有通过测试的代码一样，都是极差的做法。

35.对问题各个击破

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

36.报告所有的异常

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

37.提供有用的错误信息

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

第八章：敏捷协作

38.定期安排会面时间

大家都期盼立会，希望彼此了解各自的进度和手上的工作，而且不怕把各自遇到的问题拿出来公共讨论。

39.架构师必须写代码

积极的编程可以带来深入的理解，不要使用不愿意编程的架构师——不知道系统的真是情况，是无法展开设计的。

架构、设计、编码和测试，这些工作给人的感觉就像是同一个活动——开发的不同方面。它们彼此之间应该是不可分割的。

40.实行代码集体所有制

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

平衡的艺术：

• 不要无意间丧失团队的专家技能，某些开发人员在某个领域中极其精通，就让他驻留此领域当专家
• 大型项目中，如果每个人都随意改变任何代码，一定会把项目弄得一团糟
• 开发人员不必了解项目每一个部分的每个细节，但是不能因为要处理某个领域的代码而感到惊恐
• 有些场合是不能采用代码集体所有制
• 任何人可能出车祸，或者被挖，这样就增加了丧失知识的风险

41.成为指导者

分享自己的知识很有趣，付出的同时便有收获，还可以激励别人获得更好的成果，而且提升了整个团队的实力

42.允许大家自己想办法

指给别人正确的方向，而不是直接提供解决方案

43.准备好后再共享代码

绝不要提交尚未完成的代码，故意嵌入编译未通过的或者没有通过单元测试的代码，对项目来说，应被视为玩忽职守的犯罪行为

44.做代码复查

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

45.及时通报进展与问题

发布进展状况、新的想法和目前正在关注的主题，不要等着别人来问项目状态如何

尾声：走向敏捷

哈哈，感觉入手敏捷开发吧！